DevOpsナレッジハブ
DevOpsナレッジハブ

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

Kafkaの重要なデータ保持ポリシーを習得し、ストレージ、パフォーマンス、コンプライアンスを最適化しましょう。本ガイドでは、時間ベース（`retention.ms`）とサイズベース（`retention.bytes`）の戦略について徹底的に解説し、ブローカーレベルとトピックレベルの両方での設定方法を実演します。実用的な意味合いを理解し、イベントストリームを管理するためのベストプラクティスを発見し、Kafkaクラスターが必要な期間だけ効率的にデータを保存し、高額なディスク枯渇や重要なデータ損失を防ぐ方法を確保しましょう。

43 ビュー

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

分散イベントストリーミングプラットフォームであるKafkaは、その高スループット、耐障害性、スケーラブルなアーキテクチャで知られています。Kafkaの核となるのは、すべての受信データをイベントの不変ログとして扱い、新しいメッセージを継続的に追加していくという点です。しかし、この追記専用の性質は、次のような重要な疑問を生じさせます。このデータはどれくらいの期間保持されるべきなのでしょうか？この記事では、Kafkaのデータ保持ポリシーに深く掘り下げ、貴重なイベントストリームがどれくらいの期間保存されるかを決定する重要なメカニズムを説明し、ストレージ、パフォーマンス、コンプライアンスを最適化するためにそれらを効果的に管理する方法を解説します。

データ保持を理解し、正しく設定することは、あらゆるKafkaデプロイメントにとって極めて重要です。不適切な設定は、ディスク容量の急速な枯渇、パフォーマンスの低下、あるいは逆に、下流のコンシューマー、分析、コンプライアンス要件に影響を与える早期のデータ損失につながる可能性があります。ここでは、Kafkaがデータ保持のために採用している主要な戦略—時間ベースとサイズベース—を探り、Kafkaクラスターが効率的かつ確実に運用されるように、これらの設定を構成および監視する方法について実践的なガイダンスを提供します。

Kafkaにおけるデータ保持の重要性

データ保持は単なる技術的な設定ではなく、データエコシステム全体に大きな影響を与える戦略的な決定です。これを効果的に管理するには、いくつかの重要な要因のバランスを取ることが含まれます。

  • ストレージコスト：大量の履歴データを無期限に保存することは、特にストレージに課金されるクラウド環境では、法外に高価になる可能性があります。効率的な保持ポリシーにより、真に必要とされる期間だけデータを保持できます。
  • パフォーマンスと安定性：Kafkaはスケーリングのために設計されていますが、過度に大きなログファイルは、ブローカーの起動時間、障害発生後のリカバリプロセス、およびシステム全体の安定性に影響を与える可能性があります。適切な保持は、管理可能なログサイズを維持するのに役立ちます。
  • コンプライアンスとガバナンス：規制要件（例：GDPR、HIPAA）は、特定の種類のデータをどのくらいの期間保持する必要があるか、または逆に、どのくらいの速さで削除する必要があるかをしばしば規定します。Kafkaの保持ポリシーは、これらの義務を満たすための重要なツールです。
  • コンシューマーのニーズ：下流のアプリケーション、データウェアハウス、または分析ツールは、再処理、エラーリカバリ、またはバッチ分析のために履歴データにアクセスする必要がある場合があります。保持設定は、コンシューマーが期待する最大再処理ウィンドウと一致する必要があります。

Kafkaのログ管理の基本

Kafkaはメッセージをトピックに保存し、トピックはパーティションに論理的に分割されます。各パーティションは、コミットログに似た、順序付けられた不変のメッセージシーケンスです。新しいメッセージは常にパーティションのログの末尾に追加されます。物理的には、各パーティションのログはログセグメント—ブローカーのディスク上のファイル—に分割されます。ログセグメントがあるサイズまたは年齢に達すると、Kafkaはそれを「ロール」し、新しいアクティブなセグメントを作成して受信メッセージを追加し、古いセグメントをクローズとしてマークします。データ保持ポリシーは、主にこれらの古い、クローズされたログセグメントを削除することによって機能します。

Kafkaはデータ保持のために2つの主要な戦略を提供しています。

  1. 時間ベースの保持：指定された期間よりも古いメッセージを削除します。
  2. サイズベースの保持：パーティションの合計サイズが定義された制限を超えた場合に、最も古いメッセージを削除します。

これらのポリシーはパーティションごとに適用されます。両方が構成されている場合、最初に削除をトリガーした保持ポリシーが優先されます。

時間ベースのデータ保持（log.retention.ms）

時間ベースの保持は最も一般的に使用される戦略です。これは、指定された期間よりも古いメッセージが削除の対象となることを意味します。これにより、履歴データが無期限に蓄積されるのを防ぎます。

設定パラメータ：

  • log.retention.ms：このブローカーレベルのプロパティは、それをオーバーライドしないすべてのトピックのデフォルトの保持期間をミリ秒単位で定義します。デフォルト値は604800000 ms（7日間）です。
  • retention.ms：このトピックレベルのプロパティにより、特定のトピックのブローカーレベルのデフォルトをオーバーライドできます。これも保持期間をミリ秒単位で指定します。

仕組み：

Kafkaブローカーは、各パーティション内のログセグメントを定期的にチェックします。セグメント内のすべてのメッセージがretention.ms（またはlog.retention.ms）のしきい値よりも古い場合、セグメントファイル全体がディスクから削除されます。

実践的な考慮事項：

  • コンシューマーラグ：すべてのコンシューマーがメッセージを処理するのに十分な保持期間を確保してください。コンシューマーが遅れすぎると、読み取られる前にデータが削除される可能性があります。
  • リカバリウィンドウ：アプリケーションエラーや新しいコンシューマーのデプロイメントの場合、どのくらいの期間までデータを再処理できる必要がありますか？
  • 開発環境 vs. 本番環境：開発環境ではリソースを節約するために短い保持期間（例：24時間）を使用する場合がありますが、本番環境では数日または数週間が必要になる場合があります。

例：3日間データを保持するようにトピックを設定する

my-important-topicという名前のトピックのデータを3日間（72時間）保持するように設定するには、kafka-configs.shツールを使用します。

# 3日間をミリ秒に変換：3 * 24 * 60 * 60 * 1000 = 259200000 ms
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-important-topic --alter --add-config retention.ms=259200000

# 設定を確認する
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-important-topic --describe

サイズベースのデータ保持（log.retention.bytes）

サイズベースの保持は、パーティションのログがディスク上で特定の合計サイズを超えないようにします。この制限に達すると、Kafkaは合計サイズがしきい値以下になるまで、最も古いログセグメントを削除します。

設定パラメータ：

  • log.retention.bytes：このブローカーレベルのプロパティは、パーティションのログのデフォルトの最大サイズをバイト単位で定義します。デフォルトは-1であり、デフォルトではサイズ制限は適用されません（時間ベースの保持のみがアクティブです）。
  • retention.bytes：このトピックレベルのプロパティにより、特定のトピックのブローカーレベルのデフォルトをオーバーライドできます。これは、単一パーティションのログの最大サイズをバイト単位で指定します。

仕組み：

時間ベースの保持と同様に、Kafkaは各パーティションのログの合計サイズを定期的にチェックします。合計サイズがretention.bytes（またはlog.retention.bytes）を超える場合、サイズが設定された制限内に収まるまで、最も古いログセグメントが削除されます。

実践的な考慮事項：

  • ディスク容量：ディスク容量が限られている場合に重要です。メッセージのスループットに関係なく、トピックがディスクを使い果たすことを保証します。
  • メッセージスループットの変動：メッセージの生成率が変動する場合、サイズベースの保持はピーク時にデータをより速く削除する可能性があり、一貫したルックバックウィンドウを必要とするコンシューマーに影響を与える可能性があります。
  • パーティションあたりの制限：retention.bytesはパーティションあたりで適用されることに注意してください。したがって、10個のパーティションとretention.bytes=1GBを持つトピックは、合計で最大10GBのデータを保存できます。

例：パーティションあたり最大1 GBを保持するようにトピックを設定する

high-volume-logsという名前のトピックのパーティションあたり最大1 GB（1,073,741,824バイト）を保持するように設定するには、次のようにします。

# 1 GBをバイトに変換：1 * 1024 * 1024 * 1024 = 1073741824 バイト
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name high-volume-logs --alter --add-config retention.bytes=1073741824

# 設定を確認する
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name high-volume-logs --describe

Kafkaでのデータ保持の設定

保持設定は、ブローカーレベル（すべてのトピックのデフォルト）で適用するか、きめ細かな制御のためにトピックレベルでオーバーライドできます。

ブローカーレベルの設定

クラスター内のすべてのトピックのデフォルト保持ポリシーを設定するには、各Kafkaブローカーのserver.propertiesファイルを変更します。

# すべてのトピックのデフォルトの時間ベース保持：7日間
log.retention.ms=604800000

# すべてのトピックのデフォルトのサイズベース保持：制限なし（-1）
# グローバルなサイズ制限を設定したい場合はコメントを解除して値を設定してください
# log.retention.bytes=10737418240 # 例：パーティションあたり10GB

# Kafkaが削除するログセグメントをチェックする頻度（デフォルト：5分）
log.retention.check.interval.ms=300000

server.propertiesを変更した後、変更を有効にするにはKafkaブローカーを再起動する必要があります。ブローカーレベルのlog.retention.bytesには注意してください。これはパーティションあたりに適用されるため、多くのトピックやパーティションで急速に合計される可能性があります。

トピックレベルのオーバーライド

トピックレベルの設定は、ブローカーレベルのデフォルトよりも優先されます。これは、異なるトピックが異なるデータライフタイム要件を持つことが多いため、保持を管理する推奨されるアプローチです。

新しいトピックの保持ポリシーの設定：

kafka-topics.sh --bootstrap-server localhost:9092 --create --topic my-new-topic \n    --partitions 3 --replication-factor 3 \n    --config retention.ms=172800000 `# 2日間` \n    --config retention.bytes=536870912 `# パーティションあたり512 MB`

既存のトピックの保持ポリシーの変更：

# 時間保持を5日間に変更
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-existing-topic --alter --add-config retention.ms=432000000

# サイズ保持を2GBに変更
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-existing-topic --alter --add-config retention.bytes=2147483648

# トピックレベルのオーバーライドを削除してブローカーのデフォルトに戻すには：
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-existing-topic --alter --delete-config retention.ms

トピック設定の記述：

保持設定を含むトピックの現在の設定を表示するには、次のようにします。

kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-existing-topic --describe

データ保持 vs. ログコンパクション（log.cleanup.policy）

データ保持（削除）とログコンパクションを区別することが重要です。Kafkaのlog.cleanup.policyは、古いログセグメントの処理方法を決定します。

  • delete（デフォルト）：これは、時間またはサイズの制限に基づいてログセグメント全体が削除される、説明してきた保持戦略です。
  • compact：このポリシーは、各メッセージキーの最新のメッセージを保持します。これは、変更ログまたは現在の状態（例：データベース変更ログ、ユーザープロファイル）を表すトピックに適しています。コンパクションでは、同じキーのメッセージの古いバージョンは最終的に削除されますが、各キーの最後の値は、時間やログの合計サイズに基づいて削除されることはありません（retention.msをトゥームストーンに明示的に設定しない限り）。

この記事ではdeleteポリシーに焦点を当てていますが、異なるユースケースのために代替戦略としてcompactを認識しておくことは非常に重要です。

ベストプラクティスと考慮事項

  1. コンシューマーを理解する：保持を設定する前に、下流のアプリケーションがデータにアクセスする必要がある期間を分析してください。それらの処理速度、ダウンタイムの可能性、および再処理要件を考慮してください。
  2. ディスク使用状況を監視する：Kafkaブローカーのディスク使用率を積極的に監視してください。ディスクが予想よりも速く満杯になっている場合は、保持ポリシーとメッセージスループットを確認してください。
  3. 妥当なデフォルトから始める：保守的な保持期間（例：7日間）から始めて、観察と要件に基づいて調整してください。保持を延長する方が、失われたデータを回復するよりも簡単です。
  4. トピックレベルの設定：常にトピックレベルで保持ポリシーを設定することを優先してください。これにより、他のトピックへの意図しない結果を防ぎ、柔軟性が得られます。
  5. 必要なストレージを計算する：データ取り込み率を推定し、希望する保持期間（時間ベースの場合）またはパーティションあたりの希望するログサイズ（サイズベースの場合）を掛けて、十分なディスク容量があることを確認してください。
  6. log.retention.check.interval.ms：この設定は、Kafkaが削除するセグメントをチェックする頻度を制御します。値が小さいほどチェックは頻繁になりますが、CPUオーバーヘッドも増加します。デフォルトの5分は通常十分です。
  7. 徹底的にテストする：特に保持期間を短縮する場合は、本番環境に適用する前に、必ずステージング環境で保持の変更をテストしてください。

結論

Kafkaのデータ保持ポリシーは、イベントストリームのライフサイクルを管理するための強力で不可欠なメカニズムです。ブローカーレベルとトピックレベルの両方でretention.ms（時間ベース）とretention.bytes（サイズベース）を理解し、効果的に設定することで、クラスターのストレージフットプリント、パフォーマンス、およびコンプライアンス体制を正確に制御できます。データ保持は「設定して忘れる」タスクではなく、データ量、コンシューマーのニーズ、およびビジネス要件が進化するにつれて、継続的な監視と調整が必要であることを忘れないでください。これらの概念を習得することで、Kafkaデプロイメントは堅牢でコスト効率が高く、組織の目標に沿ったものになります。