プロンプトとスコープ
面接官は次のように質問する場合があります。「Kafkaトピックで数年分の履歴を保持する必要がある場合、Tiered Storageのローカルおよびリモート保持ポリシーをどのように設計しますか？」
重要なのは設定名を丸暗記することではありません。ローカル層とリモート層をまたぐログセグメントのライフサイクルを説明することです。KIP-405はKafkaブローカー上にローカル層を維持しつつ、完了したログセグメントを外部ストレージにアップロードします。ブローカーのディスク負荷を軽減するため、ローカルの保持期間はリモートの保持期間よりも短く設定できます。完全な回答には、オブジェクトストレージの障害、履歴読み取りのレイテンシ、削除の責任範囲、およびリカバリも含まれます。
面接官が見ているポイント
- Tiered StorageをKafkaがオブジェクトストレージ化することではなく、ログセグメントのホット/コールド配置として理解しているか。
- クラスター全体の機能、トピックレベルの
remote.storage.enable、および保持ポリシーを切り分けて考えられるか。 - ホットディスク容量、リモート容量、アップロード遅延（upload lag）、およびリプレイ帯域幅を見積もることができるか。
- リモートの停止、メタデータの一貫性、パーティション移動、およびコンシューマーのリプレイを考慮しているか。
- 偶発的または無制限の増加を防ぐため、リモート削除の明確な責任範囲を定めているか。
確認すべき質問
- どのトピックが履歴ストレージを必要とし、すべてのトピックで有効化すべきか？
- ホット読み取りのレイテンシと履歴リプレイのスループット目標は何か？
- ローカルディスクの予算、リモートストレージクラス、リージョン要件、およびコンプライアンス要件は何か？
- オブジェクトストレージの停止時、プロデュース、リアルタイムコンシューマー、および履歴リーダーはどのように縮退（デグレード）するか？
- 削除は時間、サイズ、コンプライアンスイベント、またはテナントポリシーのいずれに基づいて行われるか？
30秒での回答
以下のように答えることができます。
私はKafkaのローカル層を低レイテンシのホットキャッシュとして扱い、完了したセグメントをリモート層にアップロードして、ローカルとリモートの保持期間を個別に定義します。remote.storage.enableは必要なトピックにのみ有効化し、ローカル保持でブローカーのディスクを制御し、リモート保持で監査やリプレイの要件を満たします。アップロード遅延、リモート読み取りレイテンシ、オブジェクトストレージの障害、パーティション移動を定量化し、リモートクリーンアップの責任者を割り当てます。リアルタイムコンシューマーはローカルパスを維持し、履歴リプレイはスロットリングと監視を行いながら追加のレイテンシを許容します。
段階的な思考プロセス
2層ライフサイクルの確立
Kafkaは依然としてパーティションログセグメントを基本単位として使用します。アクティブなセグメントはローカルに書き込まれ、ローリング後、リモートログコンポーネントがセグメントとインデックス情報を設定されたリモートストレージにアップロードします。クライアントは、すべての過去のバイトがブローカーのディスク上に残っていると想定してはなりません。
producer -> leader broker local segment
| segment roll
v
remote object store
consumer <---- local cache or remote fetchローカル層は低レイテンシの消費に対応し、リモート層はより長い保持期間を担います。アップロード完了とローカル削除の間に観測可能な安全マージン（セーフティウィンドウ）を設けてください。オブジェクトの作成だけでは、インデックスやメタデータが使用可能であることの証明にはなりません。
トピックごとの機能の適用範囲
Apache Kafkaのドキュメントに記載されているとおり、ブローカー側の設定後も、トピックはremote.storage.enableによってオプトインします。すべてのトピックで有効化するとコストや障害リスクが増大する可能性があるため、ガバナンスモデルがオプトインなのかデフォルト有効なのかを明示してください。
ローカル保持とリモート保持の分離
ホットデータと再割り当てに必要な読み取り容量を維持するためにローカル保持を時間またはサイズで設定し、監査、リプレイ、コンプライアンスのためにリモート保持を設定します。不変条件（インバリアント）は、リモートオブジェクト、インデックス、メタデータ、およびリカバリテストが検証されるまで、唯一のローカルコピーを削除しないことです。リモートの削除には、独立した監査とリトライ処理が必要です。
読み取りと縮退運用の設計
リアルタイムコンシューマーは最初にローカル層から読み取ります。ローカルウィンドウを超えたオフセットはリモート読み取りをトリガーします。リモートストレージが低速化した場合は、履歴リプレイをスロットリングしてライブトラフィックを保護します。リモートストレージが利用できない場合は、どのアドレス（オフセット）が一時的に読み取り不可になるか、アラートがどのように発報されるか、リカバリがどのように機能するかを明記します。パーティション移動、リーダー交代、ブローカー再起動時のメタデータとキャッシュの再構築時間をテストします。
模範的な高評価回答
まずトピックのホット読み取りウィンドウ、リプレイスループット、保持期間、およびコンプライアンス要件を確認します。KIP-405に基づき、ブローカーのローカル層をホットキャッシュとし、ローリングされたセグメントをリモートオブジェクトストレージにアップロードします。履歴が必要なトピックのみremote.storage.enableを有効にします。ローカル保持はディスク予算とリアルタイムリプレイのニーズに従い、リモート保持は監査期間に従います。削除の条件（ゲート）は、単なるアップロードリクエストではなく、検証済みのリモートオブジェクト、インデックス、メタデータです。コンシューマーはローカルウィンドウ内では低レイテンシを維持し、過去のリプレイにはスロットリングを伴うリモート読み取りを使用します。アップロード遅延、リモート読み取りレイテンシ、キャッシュヒット率、オブジェクト/メタデータの不整合、削除失敗、読み取り不可オフセットを監視し、オブジェクトストレージ停止、ブローカー再起動、パーティション移動のリカバリを訓練します。リモートクリーンアップには責任者、監査証跡、およびリストア手順が必要であり、ブローカーファイルを削除したからといってその責任が消えるわけではありません。
よくある間違い
- Tiered Storageがセグメントローリングを無視して、すべてのKafkaレコードをオブジェクトストレージに直接ストリーミングすると主張すること。
- クラスター側のスイッチのみを挙げて、トピックレベルの
remote.storage.enableを省略すること。 - リモート読み取りレイテンシ、アップロード遅延、リプレイ帯域幅を無視して、オブジェクトのコストだけを計算すること。
- ブローカーファイルを削除すれば、リモートオブジェクトも自動的に削除されると思い込むこと。
- リモート障害時に、履歴リプレイによってライブトラフィックに必要なリソースが消費されるのを放置すること。
- オブジェクト、インデックス、メタデータの一貫性に関する監視やリカバリ訓練を省略すること。
フォローアップ質問と回答
1. ローカル保持時間はどのように決定しますか？
最大リアルタイム巻き戻しウィンドウ、ディスク予算、再割り当てのリカバリ時間、および障害発生時の安全マージンから逆算します。平均的なコンシューマー遅延だけでなく、ピーク時のリプレイやメンテナンスウィンドウも含めて計算します。
2. リモートオブジェクトストレージが一時的に利用できなくなった場合はどうなりますか？
ローカルウィンドウを超える読み取りを一時停止またはスロットリングし、検証済みのローカル範囲を維持した上で、アップロードおよび読み取りの失敗についてアラートを発報します。プロデュースとリアルタイム消費は検証済みのローカル容量内で継続し、履歴の読み取りは復旧後に追いつきます。空のデータを返すのではなく、読み取り不可のオフセットに対して明示的な状態を返します。
3. 削除が安全であることをどのように証明しますか？
ローカルセグメントを削除する前に、そのリモートオブジェクト、インデックス、およびメタデータが読み取り可能であることを検証し、セグメント範囲を記録します。リモート削除については、保持ポリシーを監査し、読み取りのサンプリングを行い、リストア訓練を実施します。削除の失敗、孤立オブジェクト、メタデータの欠落に対してアラートを設定します。