Kafka ログ保持チューニング: 時間・サイズ・セグメント設定の実務と CCAAK 対策

Kafka の保持は「いつ消すか(時間)」「どれだけ残すか(サイズ)」「どこで切るか(セグメント)」の3層で決まる。これらは独立に作動し、どれかの条件に該当すれば最古セグメントから削除が進む。

CCAAK では ms 付き設定の優先、トピック単位の上書き、delete と compact の相互作用、ロールと保持の違いが頻出。実務ではディスク安全域と監視、セグメント粒度の現実解がカギ。

基礎: ログ保持の考え方と用語整理

Kafka の保持はパーティション単位で評価される。ログは複数のセグメントファイルへローテーションされ、削除は常に「セグメント単位」で行われる。新規書き込みは常にアクティブセグメントに追記され、しきい値を超えるとロールして新しいセグメントが開かれる。

時間ベース保持はセグメント内の最大タイムスタンプが retention.ms を超えたら削除候補にする。サイズベース保持はパーティション合計サイズが retention.bytes を超えると最古セグメントから削除で調整する。保持判定は一定間隔で行われる（log.retention.check.interval.ms）。

トピック設定がブローカ既定より優先される。ms サフィックスの設定（retention.ms, roll.ms など）が存在すれば、時間単位の設定（hours, minutes）より優先されることが公式動作。バージョンで既定値は変わりうるため、試験・実務ともに明示設定が安全。

• 用語: ロール=新規セグメントへの切替、保持=古いセグメントの削除
• 評価単位: すべてパーティション単位。replica 間で独立に評価される
• 削除はセグメント境界でのみ。セグメント内のレコード単位では行われない

ブローカ内のセグメントローテーションと削除の流れ

Producer --> Broker

TopicA-0 (log dir)
  |
  |-- 00000000000000000000.log  [CLOSED]
  |-- 00000000000001234567.log  [CLOSED]  <-- oldest, candidate for deletion
  |-- 00000000000009876543.log  [ACTIVE]  <-- new appends
         ^            ^
         |            |
   retention check    roll (segment.bytes or roll.ms)
         |
   if time expired OR total size > retention.bytes => delete oldest CLOSED segment(s)

server.properties の最小関連設定例（ブローカ既定）

# 時間ベース保持（トピック未指定時の既定）
# log.retention.ms=604800000  # 例: 7日（バージョンにより既定は変わり得るため明示推奨）

# サイズベース保持（-1 は無制限）
# log.retention.bytes=-1

# セグメントサイズとロール（サイズ/時間のいずれかで新規セグメント作成）
# log.segment.bytes=1073741824   # 例: 1GiB（明示推奨）
# log.roll.ms=604800000          # 例: 7日（hours と併用しない）

# 保持チェック間隔
# log.retention.check.interval.ms=300000  # 例: 5分

時間ベース vs サイズベース: 何がいつ消すのか

時間ベースはセグメント内の最大タイムスタンプで判定する。メッセージタイムスタンプの種別は message.timestamp.type（CreateTime または LogAppendTime）に従い、CreateTime の場合はプロデューサの時刻の歪みに注意する。保持は log.retention.check.interval.ms ごとに評価され、条件を満たせば該当する最古セグメントから削除が始まる。

サイズベースはパーティション合計サイズが retention.bytes を超えている間、最古セグメントから削減する。時間・サイズはどちらか片方でも条件に達すれば削除される。retention.bytes が -1 の場合はサイズでは削除されず、時間のみで削除される。

実務では時間ベースで期間保証を与え、サイズベースでディスク上限をガードする二重フェイルセーフが一般的。試験では ms 付き設定の優先、パーティション単位、チェック間隔の存在を押さえる。

• 優先ルール: retention.ms が設定されていれば hours/minutes より優先される
• 評価単位: retention.bytes はパーティション単位の合計サイズに適用
• チェック間隔: 即時ではなく log.retention.check.interval.ms ごとに評価

トピック単位での保持設定（時間・サイズ）

# 時間ベース保持を 7 日、サイズベースを 50GiB に設定（例）
bin/kafka-configs.sh --bootstrap-server <broker:9092> \
  --alter --topic my-topic \
  --add-config retention.ms=604800000,retention.bytes=$((50*1024*1024*1024))

# 設定の確認
bin/kafka-configs.sh --bootstrap-server <broker:9092> \
  --describe --topic my-topic | grep -E 'retention'

セグメント設計とロールの実務勘どころ

セグメントはログの最小削除単位であり、ロールは新しいセグメントを開始するトリガ。ロールは通常、log.segment.bytes に到達するか、log.roll.ms（または hours）を超えた時点で発生する。ロールは保持とは別物であり、ロールしても直ちに削除はされない点を区別する。

設計の原則は、復旧・リーダー切替・ログクリーナの効率とファイル数のバランスを取ること。高スループットでは大きめの segment.bytes で I/O 効率を上げ、低トラフィックでは roll.ms を設定して「いつまでも巨大な単一セグメントにならない」ようにする。既定値はリリースにより変わり得るため、ワークロードに合わせて明示設定する。

• 目安: 1〜2 時間で 1 セグメント程度に落ち着くよう segment.bytes/roll.ms を合わせる
• セグメントが小さすぎるとファイル数やインデックス負荷が増大
• セグメントが大きすぎると復旧時間や compaction の一括処理が重くなる

ロール調整の例（低トラフィック対策）

# 低トラフィックでサイズ到達が遅い場合、時間ロールを明示
bin/kafka-configs.sh --bootstrap-server <broker:9092> \
  --alter --topic events-low \
  --add-config roll.ms=7200000,segment.bytes=$((256*1024*1024))  # 2時間 or 256MiB の早い方

cleanup.policy と保持の相互作用（delete/compact）

cleanup.policy=delete は本稿で扱う時間・サイズ保持がそのまま適用され、最古のセグメント単位で削除される。

cleanup.policy=compact はキー重複の古いレコードをマークして除去するプロセスで、保持とは別経路。compact,delete を併用すると、コンパクションで古いバージョンを間引きつつ、delete 側の時間・サイズでセグメントを削除する。tombstone の保持には delete.retention.ms が関わり、一定期間後に tombstone 自体も除去される。

コンパクション関連の調整例としては、log.cleaner.enable、min.cleanable.dirty.ratio、log.cleaner.min.compaction.lag.ms などがある。セグメント粒度はコンパクション単位にも影響するため、segment.bytes が極端に大きいと一回のコンパクション負荷が増す。

• compact でも retention.ms/bytes は有効。delete と併用時は両者が独立にトリガする
• tombstone は delete.retention.ms 経過後に削除される
• コンパクションの進行は十分なディスク空きと I/O 帯域が前提

コンパクション併用時の設定例

# コンパクトかつ時間保持（7日）を適用
bin/kafka-topics.sh --bootstrap-server <broker:9092> \
  --create --topic kv-store \
  --partitions 6 --replication-factor 3 \
  --config cleanup.policy=compact,delete \
  --config retention.ms=604800000 \
  --config delete.retention.ms=86400000 \
  --config segment.bytes=$((256*1024*1024))

運用チューニング手順とモニタリング

変更手順の基本は、対象トピックの現在設定を確認し、影響を見積もったうえで段階的に適用すること。サイズ上限を厳しくする場合は先にディスク使用量を確認し、削除が連鎖して突発的な I/O 増大を招かないようにする。保持を延長する場合は空き容量とスループットから所要ディスクを再試算してから適用する。

監視では、パーティション単位サイズ、セグメント数、削除・ロールのレート、ログクリーナのスループットとラグを観測する。JMX では kafka.log のメトリクスやブローカのログを参照し、必要に応じて describeLogDirs でブローカごとのディスク使用を点検する。

• 段階適用: まず一部トピックやステージングで検証し、ロールアウト
• ディスク安全域: 平常時使用の 20〜30% の空きを目安に確保
• 設定の出自を明確化: ブローカ既定かトピック上書きかを常に確認

現況確認と影響見積コマンド例

# ブローカごとのログディレクトリ使用量
bin/kafka-log-dirs.sh --bootstrap-server <broker:9092> --describe

# トピック設定の出所確認
bin/kafka-configs.sh --bootstrap-server <broker:9092> --describe --topic my-topic

# セグメントファイルの概数を把握（ブローカ側で）
ls /kafka-logs/my-topic-*/ | wc -l

代表シナリオ別の推奨設定と落とし穴

イベントストリーミング（7日保証、スパイク対策付き）: 時間で 7 日を保証し、サイズで頭打ちを設ける。セグメントは 512MiB〜1GiB を起点に実測で調整。CreateTime を使う場合はプロデューサの時刻同期をSRE手順に含める。

監査ログ（90日保持、容量優先）: サイズで強く制限しつつ、時間で 90 日を目標に。実効がサイズで先にトリガする可能性を想定し、可観測性要件に合わせてアーカイブ連携を前提設計にする。

状態ストアのチェンジログ（compact 併用）: compact,delete の両立。delete.retention.ms を短めに、segment.bytes は中庸にして compaction のバッチ負荷を抑える。

• イベント: retention.ms=7d, retention.bytes=ディスクの安全域を含む上限, segment.bytes=512MiB〜1GiB
• 監査: retention.ms=90d, retention.bytes=現実的上限, roll.ms を明示してセグメント肥大化を防止
• チェンジログ: cleanup.policy=compact,delete とし、delete.retention.ms を短めに設定

シナリオ別の設定適用例

# イベントストリーミング
bin/kafka-configs.sh --bootstrap-server <broker:9092> --alter --topic events \
  --add-config retention.ms=604800000,retention.bytes=$((200*1024*1024*1024)),segment.bytes=$((512*1024*1024))

# 監査ログ
bin/kafka-configs.sh --bootstrap-server <broker:9092> --alter --topic audit \
  --add-config retention.ms=$((90*24*60*60*1000)),retention.bytes=$((500*1024*1024*1024)),roll.ms=$((24*60*60*1000))

# チェンジログ
bin/kafka-configs.sh --bootstrap-server <broker:9092> --alter --topic changelog \
  --add-config cleanup.policy=compact,delete,delete.retention.ms=$((12*60*60*1000)),segment.bytes=$((256*1024*1024))

問題で確認

よくある質問