Kafkaデータ保持: イベントストリームの理解と管理

Kafkaのデータ保持は、実用的な質問に答えます: イベントストリームをKafkaが削除できるようになるまで、どのくらいディスクに保持すべきか？設定が緩すぎるとブローカーのディスク容量が不足する可能性があります。設定が厳しすぎると、遅いコンシューマーがデータを再生する機会を失う可能性があります。

Kafkaはレコードをパーティションログに保存します。これらのログはセグメントファイルに分割され、保持クリーンアップは古いクローズされたセグメントを削除します。この詳細が重要なのは、Kafkaは通常、レコードが古くなった瞬間に1つずつ削除するわけではないからです。セグメントは、設定された保持ルールを満たした場合にのみ削除対象となります。

保持設定が重要な理由

保持は、ストレージ、再生のニーズ、運用リスクのトレードオフです。

ストレージコスト: 高スループットのトピックで長期間保持すると、ブローカーのディスクを大量に消費する可能性があります。
コンシューマーの復旧: 保持ウィンドウは、最も長い現実的なコンシューマーの停止期間または再処理ウィンドウよりも長くなければなりません。
安定性: ディスクがいっぱいになると、ブローカーが書き込みを受け付けなくなり、クラスター全体に問題が発生する可能性があります。
コンプライアンス: 一部のデータは最低限の期間保持する必要があり、他のデータはすぐに削除する必要があります。

支払いトピックは、数日間の再生履歴が必要な場合があります。開発クラスターのデバッグログトピックは、数時間だけ必要な場合があります。

Kafkaが古いデータを削除する方法

Kafkaトピックはパーティションに分割されます。各パーティションは、順序付けられた追加専用ログです。Kafkaは新しいレコードをアクティブセグメントに書き込み、現在のセグメントが設定されたサイズまたは経過時間に達すると、新しいセグメントにロールします。

保持はパーティションごとに適用されます。retention.bytes=1073741824を設定した場合、それはトピック全体で約1 GiBではなく、パーティションあたり約1 GiBです。したがって、12パーティションのトピックは、レプリカをカウントする前に約12 GiBを保持できます。

時間ベースとサイズベースの両方の保持が設定されている場合、Kafkaはどちらかの制限がクリーンアップを必要とするときに、削除可能な古いセグメントを削除できます。

時間ベースの保持

時間ベースの保持は、設定された期間レコードを保持します。

ブローカーレベルでは、log.retention.msがオーバーライドしないトピックのデフォルトを設定します。トピックレベルでは、retention.msが1つのトピックのデフォルトをオーバーライドします。

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name orders \
  --alter \
  --add-config retention.ms=259200000

この例では、ordersを3日に設定します。次のコマンドで確認します:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name orders \
  --describe

主な要件が再生ウィンドウである場合、例えば「コンシューマーが週末の停止から復旧できる必要がある」場合に、時間保持を使用します。

サイズベースの保持

サイズベースの保持は、各パーティションが保持できるログデータの量に上限を設定します。

ブローカーレベルでは、log.retention.bytesがパーティションあたりのデフォルト制限を設定します。トピックレベルでは、retention.bytesが1つのトピックのデフォルトをオーバーライドします。値-1は、その設定によるサイズ制限がないことを意味します。

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name high-volume-logs \
  --alter \
  --add-config retention.bytes=1073741824

これにより、パーティションあたり1 GiBの制限が設定されます。ディスク保護が固定の時間ウィンドウよりも重要な場合に、サイズ保持を使用します。バースト的なトピックには注意してください。トラフィックの急増により、実効的な再生ウィンドウが短くなる可能性があります。

ブローカーのデフォルトとトピックのオーバーライド

ブローカーのデフォルトはserver.propertiesにあり、独自の保持値を設定していないトピックに適用されます。

log.retention.ms=604800000
log.retention.bytes=-1
log.retention.check.interval.ms=300000

ブローカーのデフォルトを変更するには、通常、ブローカーの再起動または動的ブローカー設定の変更が必要です。これは、Kafkaのバージョンとデプロイツールによって異なります。kafka-configs.shによるトピックレベルの変更は、異なるトピックが同じ保持ウィンドウを必要とすることはほとんどないため、多くの場合より安全です。

新しいトピックの場合、作成時に保持を設定します:

kafka-topics.sh --bootstrap-server localhost:9092 \
  --create \
  --topic audit-events \
  --partitions 6 \
  --replication-factor 3 \
  --config retention.ms=604800000 \
  --config retention.bytes=2147483648

既存のトピックの場合、トピック設定を変更します:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name audit-events \
  --alter \
  --add-config retention.ms=1209600000

ブローカーのデフォルトに戻すには、トピックのオーバーライドを削除します:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name audit-events \
  --alter \
  --delete-config retention.ms

保持とログコンパクション

Kafkaのクリーンアップはcleanup.policyによって制御されます。一般的な値はdelete、compact、または両方のcompact,deleteです。

deleteは、保持時間またはサイズに基づいて古いログセグメントを削除します。
compactは、各キーの最新の値を保持し、時間の経過とともにそのキーの古い値を削除します。
compact,deleteは、コンパクションと削除の両方のルールを適用できるようにします。

コンパクションは、顧客IDをキーとした顧客プロファイルの更新など、変更ログスタイルのトピックに役立ちます。これは、保持の一般的な代替手段ではありません。トゥームストーンと削除保持には独自のタイミング動作があるため、クリーンアップに依存する前に、コンパクションされたトピックをテストしてください。

実用的な保持チェックリスト

許容できる最長のコンシューマー停止期間から始めてください。コンシューマーグループが48時間オフラインになる可能性がある場合、24時間の保持ウィンドウは短すぎます。

本番トピックを変更する前に、ディスクの必要性を見積もってください:

1秒あたりの取り込みレート x 保持秒数 x パーティション数 x レプリケーションファクター

これは推定値にすぎません。圧縮、レコードサイズ、インデックス、セグメントオーバーヘッドが実際の数値に影響するためです。それでも、有用な出発点となります。

ブローカーのディスク使用量、トピックの成長率、アンダーレプリケーションパーティション、コンシューマーラグを一緒に監視してください。ディスクの圧迫とラグの上昇は、コンシューマーが保持ウィンドウの外に出る可能性があるという警告です。

最も安全なデフォルトはシンプルです: トピックレベルの保持を使用し、各高スループットトピックに設定がある理由を文書化し、本番環境に適用する前にステージングで短い保持をテストしてください。