Kafka Log Compaction 徹底理解: キー単位の最新値保持と実務適用

ログ圧縮は、同一キーの古いレコードをバックグラウンドで間引き、少なくとも最新(最後に書かれた)値を保持するKafkaのクリーンアップ方式です。履歴をすべて残すのではなく、最新の状態を取り出したい用途に有効です。

本稿では、仕組み・保証・代表設定・適用シーン・運用の勘所を、試験での出題ポイントと合わせて解説します。特に、tombstone(null値)の扱い、compactとdeleteの併用、セグメントとクリーンナーの関係は重点項目です。

1. Log Compactionの基本と保証

ログ圧縮は、トピックのcleanup.policy=compactを有効にすると、パーティション内の各キーについて「最後に観測されたレコード」(last write)を少なくとも1件保持します。これにより、コンシューマはトピックを最初から読むだけで、最新状態のマップ(キー→値)を再構築できます。

値がnullのレコード(通称tombstone)は、そのキーの削除を意味します。tombstone自体はdelete.retention.msの期間だけ保持され、その後のクリーンで物理的に除去されます。ログ圧縮は即時ではなく、バックグラウンドで非同期に進みます。

• 単位はパーティション: 同じキーは同一パーティションにマップされる(ハッシュ)。キー間の最新値保証はパーティション内で成立。
• 順序は保持: 圧縮後も残存レコードの相対順序は維持されます。
• クリーン対象は「閉じたセグメント」: 現在書き込み中のセグメントは圧縮対象外。
• tombstoneは削除指示: 一定期間保持後、当該キーの古い値とともに消去されます。
• キー必須: 値だけでキーがないレコードは圧縮できない(無関係扱い)。

キーA/Bの更新と圧縮の概念図

Partition P0 (時系列 →)
| A:1 | B:x | A:2 | A:3 | B:y | A:null | B:z |
            ^  古いAはA:3により不要
                       ^  A:nullはAの削除指示(tombstone)
圧縮後(概念): | ... | A:null | B:z |
結果: Aは削除、Bは最新zが保持

キー付きで投入する例(console-producer)

kafka-console-producer \
  --broker-list localhost:9092 \
  --topic users-compact \
  --property parse.key=true \
  --property key.separator=:
# 例: userId:json
u1:{"name":"Ann","v":1}
u1:{"name":"Ann","v":2}
u2:{"name":"Bob","v":1}
# 圧縮後、u1はv=2のみが残る(しばらく後に)

2. セグメントとログクリーナーの内部動作

パーティションは複数のセグメントに分割されます。書き込み中のアクティブセグメントは対象外で、ローテーション済み(閉じた)セグメントがクリーンの候補になります。クリーンはキーごとの最新オフセットをインデックス化し、古い重複を間引いた新しいセグメントへ再書き込みします。

どの程度“汚れて”いれば(重複が多ければ)クリーンするかはmin.cleanable.dirty.ratioや関連しきい値で制御されます。クリーナースレッド数、I/Oスループット、圧縮形式は独立で、クリーンは時間基準では実行されません。

• クリーンはブローカープロセス内で動作し、レプリカごとに独立に実施される。
• クリーン後は新セグメントが有効化され、旧セグメントは削除候補になる(完全に不要なら物理削除)。
• tombstoneはdelete.retention.msの間は残り、同一キーの復活(再投入)があれば削除扱いは打ち消される。

セグメントのクリーンの流れ

Before:
[Seg-1(closed)] [Seg-2(closed)] [Seg-3(active)]
  A:1 B:1 A:2     B:2 A:3        ...
Cleaner →
  - 各キーの最新(A:3, B:2)を抽出
  - 新しいクリーン済みセグメントへ再配置
After:
[Seg-1'(cleaned: A:3 B:2)] [Seg-3(active)]
旧Seg-1/2は削除候補

セグメント内容を検査(kafka-dump-log.sh)

kafka-dump-log.sh --skip-record-metadata --print-data-log \
  --files /var/lib/kafka/data/users-compact-0/00000000000000000000.log | head -n 50
# 圧縮の前後でキーごとの残存レコードを比較して確認する

3. 主要設定と試験での落とし穴

ログ圧縮はトピック単位で有効化し、ブローカー既定のしきい値をトピックで上書き可能です。特にcleanup.policy、delete.retention.ms、min.cleanable.dirty.ratio、segment.ms/segment.bytes、min.compaction.lag.ms/max.compaction.lag.msの相互作用を押さえます。

compact,deleteを併用すると、最新値を保持しながら古い完全クリーン済みセグメントを期限で削除できます。tombstoneはdelete.retention.msの間は残るため、即時に完全消去はされません。試験では「キー必須」「tombstoneの意味」「クリーンは非同期」の3点が頻出です。

• cleanup.policy=compact または compact,delete を明示設定する。
• delete.retention.ms は tombstone の保持期間を決める。短すぎると遅延コンシューマの再構築に影響。
• min.compaction.lag.ms は“最低いつまで圧縮しないか”の待機時間。取り違え注意。
• セグメントがローテートされないとクリーン対象にならないため、segment.ms/bytesも重要。

retentionとcompactionの適用順序イメージ

書き込み → セグメントローテーション → (閾値到達)Compaction →
[compactのみ] 最新値を保持
[compact,delete] さらに“完全クリーン済みかつ期限超”のセグメントを削除

トピック作成時にcompactionを有効化

kafka-topics.sh --create \
  --bootstrap-server localhost:9092 \
  --topic users-compact \
  --partitions 6 \
  --replication-factor 3 \
  --config cleanup.policy=compact \
  --config min.cleanable.dirty.ratio=0.5 \
  --config delete.retention.ms=86400000 \
  --config segment.ms=3600000

4. 適用シーンとアンチパターン

典型的な適用は、CDCの更新ストリーム(顧客の最新住所、在庫残量)、キャッシュのウォームアップ/更新、Kafka Streamsの状態ストア(changelog)です。いずれも“最新状態”が重要で、過去の細かな更新履歴は不要です。

アンチパターンは、完全履歴が不可欠な監査ログ、順序通りの全イベント再生が必要なイベントソーシング、キーが無い(またはほぼユニークで更新の無い)データです。これらはdeleteベースの保持か、別のストレージを選ぶべきです。

• CDC + compaction: Debezium等のUpdate/Deleteイベントと相性が良い。
• キャッシュ再構築: earliestから読み、最終マップを構築。
• 状態ストア: Streamsのchangelogトピックはcompact推奨。
• アンチ: キー無し、更新が一度きりのイベント、履歴完全保存が要件。

CDCから最新ビュー構築までの流れ

DB → CDC(更新/削除) → [compacted topic] →
            → キャッシュ/ビュー(キーごとの最新のみ)
削除イベントはtombstoneとして流れ、一定期間後に物理削除

tombstoneを送る(Java Producer)

Properties p = new Properties();
p.put("bootstrap.servers", "localhost:9092");
p.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
p.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
try (KafkaProducer<String, String> producer = new KafkaProducer<>(p)) {
    // 通常の最新値
    producer.send(new ProducerRecord<>("users-compact", "u1", "{\"name\":\"Ann\"}"));
    // 削除(tombstone): 値にnullを指定
    producer.send(new ProducerRecord<>("users-compact", "u1", null));
    producer.flush();
}

5. 運用・監視・トラブル対処

圧縮は非同期で、負荷としきい値に左右されます。監視では、ログクリーナースレッドの稼働状況、クリーン対象バイト量、ディスク使用量、クリーンのバックログを追います。トピックごとの設定差分も定期点検します。

“圧縮されない/遅い/消えない”は定番の相談です。キーポイントは、(1)セグメントが閉じていない、(2)dirty比率が低い、(3)tombstone保持期間内、(4)キー無しレコード混在、(5)クリーナーのスループット不足、のいずれかであることが多いです。

• まず設定を確認: cleanup.policy、min.cleanable.dirty.ratio、segment.ms/bytes、delete.retention.ms。
• ブローカーのログとJMXでクリーナーの進捗とエラーを確認。
• ディスク水位・I/O競合が強いとクリーンが進みにくい。スレッド数やI/O帯域を調整。

tombstoneの寿命タイムライン

Write key=K, value=null (tombstone)
  ↓ 保持(delete.retention.ms)
Compaction removes K's old values
  ↓ 期限後
Tombstone自体も物理削除

運用時の設定確認/変更

# 設定確認
kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics --entity-name users-compact --describe

# 動的変更(例): dirty比率を調整
kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics --entity-name users-compact \
  --alter --add-config min.cleanable.dirty.ratio=0.4

6. 実装例と移行戦略

既存のdeleteベースのトピックからcompactまたはcompact,deleteへ移行する場合は、(1)キー付きで再発行できるか、(2)初期状態のバックフィル手段があるか、を先に確認します。キーが無いと圧縮の恩恵を受けません。

青/緑切替が安全です。新トピックをcompactで作成→バックフィル→新旧両配信→コンシューマ切替→旧トピック廃止の順で進めると、ダウンタイムとロールバックリスクを抑えられます。

• 移行時は“earliestから読み直せば最新ビューが作れること”を検証。
• compact,deleteを使うならretention.ms設計も併せて行う。
• Streams/KConnectなどミドル層で確実にキーを付与してから出力。

青/緑移行の流れ

Producers → [old-topic(delete)] → Consumers(旧)
          ↘︎ 変換/バックフィル ↘︎
            [new-topic(compact)] → Consumers(新)
切替後にold-topicを段階廃止

最新値のみを書き出すStreamsトポロジ(例)

StreamsBuilder b = new StreamsBuilder();
KStream<String, String> s = b.stream("src");
KTable<String, String> latest = s.groupByKey().reduce((agg, v) -> v);
latest.toStream().to("dst-compacted");
// dst-compacted は cleanup.policy=compact で作成しておく

問題で確認

よくある質問