Kafkaトピック削除と保持ポリシーコマンドの比較

Kafkaにおけるデータ削除には、トピック全体を削除する方法と、アクティブなトピックから保持期間を過ぎた古いログセグメントを削除する方法の2つがあります。Kafkaトピックを効果的に管理することは、システムの健全性維持、ストレージの最適化、データ整合性の確保に不可欠です。これには、トピックの作成や監視だけでなく、不要になったデータを適切に削除する方法の理解も含まれます。データ削除には主に2つのメカニズムがあります。即時トピック削除と時間ベースの保持ポリシーです。どちらも最終的にはデータが削除されますが、機能的な違い、ユースケース、影響は大きく異なります。

トピック自体を削除したい場合はトピック削除を使用します。トピックは残しつつ古いデータを自動的に削除したい場合は保持設定を使用します。

Kafkaトピック削除の理解（`kafka-topics.sh --delete`）

Kafkaにおけるトピック削除は、トピック、そのすべてのパーティション、データ、メタデータをKafkaクラスターから完全に削除するための直接的かつ即時的なアクションです。これは通常、トピックが廃止された場合、誤って作成された場合、またはシステム内で不要になった場合に使用されます。

トピック削除の仕組み

トピック削除コマンドを実行すると、Kafkaはそのトピックを削除対象としてマークします。実際の削除プロセスは以下の手順で行われます。

削除対象としてマーク: ZooKeeper（またはKRaftクラスターのKafka Raftクォーラム）内のトピックのメタデータが更新され、削除対象としてマークされます。
コントローラーのアクション: Kafkaコントローラー（特別な役割を持つブローカー）が削除を調整します。他のブローカーに対して、マークされたトピックのパーティションへのプロデュースやコンシュームを停止するよう指示します。
ログディレクトリのクリーンアップ: 削除されたトピックのパーティションをホストしていた各ブローカーは、最終的に関連するログセグメントとインデックスファイルをディスクから削除します。このクリーンアップは非同期で行われ、ブローカー/コントローラーの調整と、パーティションをホストしていたブローカー上のファイルシステムのクリーンアップに依存します。

トピック削除の有効化

トピックを削除する前に、すべてのKafkaブローカーでトピック削除を明示的に有効にする必要があります。これは、偶発的なデータ損失を防ぐための重要な安全対策です。

トピック削除を有効にするには、各Kafkaブローカーのserver.propertiesファイルに以下のプロパティを設定します。

delete.topic.enable=true

server.propertiesを変更した後、変更を反映するためにKafkaブローカーを再起動します。

実践例：トピックの削除

my-obsolete-topicという名前のトピックを削除するには：

kafka-topics.sh --bootstrap-server localhost:9092 --delete --topic my-obsolete-topic

出力例：

Deleting topic my-obsolete-topic.

トピックを一覧表示することで、トピックが削除対象としてマークされていることを確認できます。

kafka-topics.sh --bootstrap-server localhost:9092 --list

成功した場合、my-obsolete-topicは最初はリストに表示されるかもしれませんが（削除対象としてマーク）、すべてのブローカーでクリーンアッププロセスが完了すると完全に表示されなくなります。

警告: トピックの削除は破壊的で元に戻せない操作です。一度削除するとデータは失われます。細心の注意を払い、バックアップがあるか、データが本当に不要であることを確認してください。

Kafkaトピック保持ポリシーの設定

Kafkaの保持ポリシーは、メッセージをトピックに保持する期間や占有する容量を定義することで、より細かく自動的にデータライフサイクルを管理する方法を提供します。これは、イベント、ログ、メトリクスの継続的なストリームを保存するトピックに最適で、古いデータは時間の経過とともに自然に重要性を失います。

保持ポリシーの仕組み

Kafkaブローカーは、ログクリーナープロセスを継続的に実行し、定義された保持制限を超えたデータがないかトピックセグメントを定期的にチェックします。主な保持設定は2つあります。

retention.ms（時間ベースの保持）: この設定は、Kafkaがログセグメントを削除対象とするまでの最大時間（ミリ秒）を指定します。たとえば、retention.msが604800000（7日間）に設定されている場合、7日より古いメッセージはすべて削除されます。
retention.bytes（サイズベースの保持）: この設定は、トピックのパーティションがディスク上で占有できる最大サイズ（バイト）を指定します。retention.bytesに達すると、Kafkaはトピックサイズが制限内に収まるまで最も古いセグメントを削除します。これはretention.msに関係なく行われます。

retention.msとretention.bytesの両方が設定されている場合、先にトリガーされたポリシーが優先されます。たとえば、サイズ制限に達する前にデータが時間制限に達した場合、retention.msによって削除されます。時間制限に達する前にサイズ制限に達した場合、retention.bytesが削除をトリガーします。

注: retention.msの値が-1の場合、無期限の保持（データが時間によって削除されることはありません）を示します。

実践例：保持期間を設定したトピックの作成

24時間の保持期間（86,400,000ミリ秒）を持つトピックmy-event-streamを作成するには：

kafka-topics.sh --bootstrap-server localhost:9092 \
                --create \
                --topic my-event-stream \
                --partitions 3 \
                --replication-factor 1 \
                --config retention.ms=86400000

実践例：既存のトピックの保持期間の変更

既存のトピックmy-log-topicの保持期間を7日間（604,800,000ミリ秒）に変更し、サイズ制限を1GB（1,073,741,824バイト）追加するには：

kafka-configs.sh --bootstrap-server localhost:9092 \
                 --entity-type topics \
                 --entity-name my-log-topic \
                 --alter \
                 --add-config retention.ms=604800000,retention.bytes=1073741824

特定の保持設定を削除するには（たとえば、retention.bytesをブローカーのデフォルトに戻す場合）：

kafka-configs.sh --bootstrap-server localhost:9092 \
                 --entity-type topics \
                 --entity-name my-log-topic \
                 --alter \
                 --delete-config retention.bytes

トピック設定の表示

トピックの現在の設定（保持設定を含む）を確認できます。

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

主な違いとユースケース

機能	トピック削除（`--delete`）	保持ポリシー（`retention.ms`/`retention.bytes`）
アクションタイプ	手動、即時、元に戻せない	自動、継続的、設定可能
範囲	トピック全体（すべてのデータとメタデータ）を削除	アクティブなトピック内の古いデータセグメントを削除
目的	廃止されたトピックの排除、エラーの修正	アクティブなトピックのデータライフサイクル管理、ストレージ使用量の制御
データ損失リスク	高い（すべてのデータが即座に失われる）	制御されている（ポリシーを超えたデータのみ削除）
設定	ブローカーレベルの`delete.topic.enable`、その後コマンド実行	トピックレベルの設定（`--config`または`--alter`）
元に戻せるか	いいえ	将来のデータについては変更または無効化可能だが、過去の削除は永続的

トピック削除を使用する場合

廃止されたトピック: プロジェクトやサービスが廃止され、関連するKafkaトピックが不要になった場合。
開発/テストのクリーンアップ: 開発中やテストサイクル中に作成された一時的なトピックのクリーンアップ。
エラーの修正: トピックが誤った設定（パーティション数が多すぎる、レプリケーションファクターが間違っているなど）で作成され、最初から再作成する方が簡単な場合。

保持ポリシーを使用する場合

ログ/監視データ: アプリケーションログ、メトリクス、監査イベントを収集するトピックで、古いデータが最終的に価値を失う場合。
イベントストリーム: イベント駆動型アーキテクチャで、イベントをリプレイやコンシューマーの同期のために一定期間アクセス可能にする必要があるが、無期限ではない場合。
リソース管理: トピックがKafkaブローカー上の過剰なディスク容量を消費するのを防ぎ、クラスターの安定性とコスト効率を確保するため。
コンプライアンス: 特定の期間後にデータを削除することを義務付けるデータ保持規制に準拠するため。

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

delete.topic.enable=trueは慎重に有効化する: 削除に必要ですが、本番環境で削除操作を実行できるユーザーを制限してください。
保持を自動化する: ほとんどのアクティブなトピックでは、最初から適切な保持ポリシーを設定して、予期しないディスク容量の問題を防ぎます。
ディスク使用量を監視する: Kafkaブローカーのディスク使用量を定期的に監視します。トピックが予期せず増加している場合は、保持ポリシーを確認するか、プロデューサーの動作を調査します。
削除/保持をテストする: 非本番環境でトピック削除をシミュレートし、保持ポリシーの動作を観察して、その影響を完全に理解します。
重要なデータをバックアップする: ミッションクリティカルなデータや長期アーカイブデータを含むトピックについては、Kafkaの無期限保持にのみ依存するのではなく、外部アーカイブソリューション（S3、HDFSなど）を検討するか、retention.msを-1に設定し、retention.bytesを十分に大きくするか-1に設定します。
コンパクト化されたトピック: ログコンパクションが有効なトピック（cleanup.policy=compact）の場合、retention.msはコンパクト化された古いセグメント（個々のメッセージではない）の削除に適用され、min.cleanable.dirty.ratioはコンパクションの実行タイミングを制御します。これは標準的な保持とは別のメカニズムであり、特定のキーの最新の値が重要なトピック（データベース変更ログ、ユーザープロファイルなど）に使用されます。

まとめ

Kafkaトピックを削除するのは、プロデューサー、コンシューマー、およびダウンストリームの依存関係がそれを必要としなくなった場合のみにしてください。アクティブなトピックについては、retention.msとretention.bytesを意図的に設定し、ブローカーのディスク使用量を監視して、ストレージの圧力が問題になる前に古いデータが期限切れになるようにします。