Kafka Tiered Storage実践ガイド: ブローカーと外部ストレージの分離でスケールと運用を最適化

Tiered Storageは、Kafkaブローカーのホットデータをローカルディスクに、コールドデータを外部オブジェクトストレージ（S3/GCS/Azure Blobなど）に退避する仕組みです。これにより、コンピュート（ブローカー）とストレージを独立にスケールでき、障害復旧やコスト最適化の選択肢が広がります。

Confluent Platform/Confluent CloudではTiered Storageとして提供され、Apache Kafka本体でもRemote Log Storage APIにより実現可能になりつつあります。試験（CCAAK）では、プロデュース/フェッチの基本セマンティクスが変わらない点、リテンションやセグメントの基礎、運用上の効果と制約を正しく説明できることが問われます。

なぜブローカーとストレージを分離するか

分離の最大の狙いは、計算資源（CPU/メモリ/ネットワーク）とストレージ容量を独立にスケールさせることです。ローカルディスクはホットセット提供に最適化し、長期の保持はオブジェクトストレージに任せます。これにより、ディスク増設のためだけにブローカー台数を増やす非効率が減ります。

Tiered Storageは書き込みパスやISR/acksのセマンティクスを変えません。プロデューサーは従来どおりブローカーのローカルログに追記し、セグメントがロールした後に外部ストレージへ段階的にオフロードされます。コンシューマーが古いオフセットを読む際は、必要部分が外部ストレージから取り寄せられます。

• 容量とスループットの独立スケール
• 復旧時間短縮（ブローカー入替時のデータ再同期を削減）
• トータルコスト最適化（ローカルSSDを小さく、オブジェクトストレージを活用）
• セマンティクス不変（acks/ISR/EOSに影響しない）

ティアードストレージのアーキテクチャ

基本コンポーネントは、ブローカーのローカルログ（アクティブ/最近のセグメント）、オフローダ（セグメントを外部ストレージに転送する役割）、外部オブジェクトストレージ、そしてフェッチ時のオンデマンド読取りです。オフロードはセグメントがクローズされ、ローカル保持条件を満たした後に非同期で実行されます。

読み取りは原則としてローカルから行われます。要求範囲がローカルにない場合、ブローカーは外部ストレージから対象セグメントの該当部分を取得し、読み出しを継続します。これによりホットワーキングセットは低レイテンシ、過去データはコールドでも到達可能というバランスを取ります。

• 書き込みパスは従来どおり。アクティブセグメントはローカル
• セグメントロール後、オフローダが外部ストレージへ転送
• 古い読み取りはオンデマンドで外部から取得
• メタデータとインデックスはブローカー側で追跡（実装依存）

Kafka Tiered Storageの概念図

設計・設定の要点（セグメント、リテンション、しきい値）

セグメントサイズはスループット、オフロード頻度、復旧時間に直結します。大きすぎるとオフロードやフェッチの単位が重くなり、小さすぎるとメタデータ過多になります。一般的には数百MB〜1GB程度が妥当な起点です。

ローカル保持とグローバル保持を分けて考えます。ローカル保持（ホットセット）は直近N時間/日分の読取りをローカルで満たすための容量計画、グローバル保持（オブジェクトストレージ）は監査/分析用途の長期保存です。ベンダーやRLM実装により設定キーは異なりますが、log.segment.bytes、log.retention.ms/bytesなどの基本キーは共通して重要です。

内部トピック（__consumer_offsets、__transaction_stateなど）は、低レイテンシと可用性の観点からティアード対象外にするのが一般的です。対象トピックはビジネスデータ中心に限定し、SLAに応じてローカル保持期間を設けます。

• セグメントは均一化（segment.bytes/segment.msの整合）
• ローカル保持期間をSLAから逆算（例: 24〜72時間）
• グローバル保持はコンプライアンス要件で設定
• 内部トピックは原則ローカルのみ
• ベンダー固有の有効化/バケット/IAM設定は公式ドキュメントを参照

server.properties例（安定キー中心、ティアード有効化はベンダー依存）

# セグメントと保持の基本設定（Kafka共通の安定キー）
log.segment.bytes=1073741824        # 1 GiB
log.segment.ms=0                     # 時間によるロール無効（必要なら設定）
log.retention.ms=604800000           # 7日（例）
log.retention.bytes=-1               # 容量制限を使わない例

# 内部トピックは短めかローカル優先の方針で（対象外にする運用ルール）
# 例: __consumer_offsetsの保持を短く保つ
offsets.retention.minutes=10080      # 7日（要件に応じて）

# ティアードストレージの有効化と外部ストレージ設定は製品ごとに異なる
# Confluent Platform/CloudやApache Kafka RLM実装の公式ドキュメントで確認すること
# 例（擬似）:
# tiered.storage.enable=true
# tiered.storage.bucket=<your-bucket>
# tiered.storage.region=<region>
# tiered.storage.credentials.provider=<provider>

運用：コスト、復旧、スケーリング

コスト観点では、ホットセットを支えるローカルSSDの容量を抑え、長期保持をオブジェクトストレージへ寄せるのが定石です。アクセス頻度の低いデータのコスト/GBは大幅に下がりますが、リストアや初回フェッチ時のリクエスト課金・帯域を見積もる必要があります。

障害復旧やスケールアウトが速くなります。新規ブローカーを追加・交換しても、過去セグメントの大部分は外部ストレージに既にあり、必要最小限のアクティブデータやメタデータの同期で済むためです。パーティション再割当の時間短縮にも寄与します（ただし実装とデータ量に依存）。

• 外部ストレージのSLA/耐久性とリージョン選択を明確化
• バケット/コンテナのライフサイクル管理と暗号化を有効化
• ネットワーク帯域（egress/ingress）と課金イベントを監視
• ブローカー交換時の再同期時間をSLOとして可視化

可観測性とトラブルシュート

監視の主眼は、オフロードの滞留、リモート読取りのレイテンシ、ローカルキャッシュのヒット率、そして外部ストレージのエラー率/IAMエラーです。通常時のベースラインを作り、夜間バッチ等でのピークを織り込んだSLOを定義します。

典型的な障害は、権限不足による外部ストレージアクセス失敗、レイテンシ劣化（初回フェッチが遅い）、オフロードバックログの増加などです。まずは認証情報/バケットポリシーとネットワーク経路を確認し、次にブローカー側のオフローダスレッド/キュー、タイムアウト設定を点検します。

• 監視候補: remote read latency, remote bytes fetched/sec, offload queue depth
• ローカル対リモートのヒット率（ヒートマップ）
• 外部ストレージの4xx/5xxとリトライ比率
• IAM/キーのローテーション失敗検知
• コンシューマレイテンシとスロットリングの相関分析

試験対策と比較（ローカルのみ vs ティアード）

CCAAKでは、Tiered Storageはあくまでストレージ階層化であり、プロデュース/フェッチ/ISR/acks/トランザクションの基本セマンティクスは変えない点を押さえます。メリット（スケール分離、復旧短縮、コスト最適化）と、考慮点（初回リモート読取りの遅延、外部ストレージSLA/IAM依存）を対で説明できるようにします。

コンパクションやトピッククリーンアップとの相互作用は実装依存です。受験では、サポート状況は製品ドキュメント前提で説明し、内部トピックをティアード対象外にする設計判断や、ローカル保持と全体保持の違いを正確に区別できることが重要です。

• セマンティクス不変（acks/ISR/EOS）を明言
• ローカル保持と全体保持の定義を区別
• 初回のリモート読取りは遅くなり得る
• 内部トピックは原則ローカル
• 障害復旧・再割当が速くなる理由を説明

問題で確認

よくある質問