Kafkaキャパシティプランニング実践ガイド: パーティション・ブローカー・保管容量をどう決めるか

Kafkaはスケールアウトに強い一方、パーティション数・ブローカー台数・ストレージ容量の初期設計を外すと、後追いの再割当てや費用超過が発生します。本稿は、公式ドキュメントの安定概念に基づき、試験(CCAAK)で問われやすい要点と、現場で通用する見積り手順をまとめました。

キーワードは3つです。並列度(パーティション)、耐障害性(レプリケーション/ブローカー)、保持(容量)。この3点をワークロードから逆算するのが最短経路です。

1. 前提整理: ワークロードとSLAを数値化する

キャパシティ計画は、入力レート、メッセージサイズ、保持期間、可用性/遅延SLAを数値で固めるところから始まります。特に平均とピークを分け、ピーク係数(例: p95/p99)を明示します。

Kafkaはバッチ効率でスループットが伸びるため、プロデューサのbatch.sizeやlinger.ms、コンシューマのfetch設定の目標値も併せて前提化しておくと、パーティション数の算出が安定します。

• 平均/ピークIngress (MB/s) と平均メッセージサイズ (bytes)
• トピックごとの保持方針: retention.ms / retention.bytes と cleanup.policy(delete/compact)
• 可用性目標とRPO/RTOに応じた replication.factor および min.insync.replicas
• 読み取りパターン: コンシューマグループ数、同時サブスクライバ数、トラフィックの比率(書き:読み)
• 運用余裕(ヘッドルーム)比率: 一般に20〜30%を初期ガードに設定

ワークロード前提のテンプレート例

# unit: MB/s unless noted
workload:
  topic: orders
  ingress_avg: 50
  ingress_peak: 120
  msg_size_bytes_avg: 1024
  consumers_groups: 3
  retention_ms: 604800000   # 7 days
  cleanup_policy: delete
  availability:
    replication_factor: 3
    min_insync_replicas: 2
  headroom: 0.25            # 25% extra

2. パーティション設計: 並列度とスループットを一致させる

スループットは基本的にパーティション数に比例して伸びます。1パーティションは順序保証のため単一リーダーへの直列書き込みであり、ハードウェアとバッチ設定次第で処理可能な上限が出ます。まずは小さく負荷試験を行い、1パーティションあたり実効スループット(Tp)を把握し、必要パーティション数を逆算します。

キー分布が偏るとホットパーティションが発生し、計画どおりに伸びません。可能ならキー空間にシャーディング要素を足す、またはStickyPartitionerの特性とバッチサイズを調整してバランスさせます。

• 必要パーティション数 ≈ ceil(ピークIngress / 実効Tp/partition)
• コンシューマ並列度は「グループあたり最大=パーティション数」。読取並列要件からも下限を決める
• 最初はやや多めに作り、将来の拡張余地を確保。後から増やすと再バランスのコストが発生
• Segmentサイズやインデックスはパーティション数に比例してメモリ/FDを消費するため、ブローカーのメモリと併せて上限を意識

パーティション数のラフ算出式と例

# 実測に基づく計算を推奨
# Tp_per_partition_MBps: 1パーティションの実効MB/s（負荷試験で取得）
# required_partitions = ceil(peak_ingress_MBps / Tp_per_partition_MBps)

peak_ingress_MBps=120
Tp_per_partition_MBps=8
required_partitions=$(( (peak_ingress_MBps + Tp_per_partition_MBps - 1) / Tp_per_partition_MBps ))
echo ${required_partitions}  # => 15 (例)

# 作成例（RF=3, min.insync.replicas=2）
# kafka-topics.sh --create --topic orders --partitions 16 --replication-factor 3 \
#   --config min.insync.replicas=2

3. ブローカー台数: 可用性と配置の原則

レプリケーション係数RFは可用性の基礎です。各パーティションはRF個のレプリカを持ち、そのうちリーダー+ISR(min.insync.replicas以上)が書き込みの前提になります。一般的な可用性要件ではRF=3, min.insync.replicas=2が出発点です。

ブローカー台数は最低でもRF以上、障害ドメイン(ラック/アベイラビリティゾーン)ごとにレプリカを分散できる数を確保します。追加で、1ブローカーあたりの許容パーティション総数とディスク帯域/CPUの上限を超えないように、台数を決めます。

• 最少ブローカー数 ≥ RF。ラックアウェア配置を使う場合はラック数もRF以上が望ましい
• min.insync.replicas = RF - 1 を目安にし、acks=all と組み合わせて耐障害性と一貫性を両立
• 1ブローカーのパーティション上限はハードウェア依存。数千単位でGC/メタデータ負荷が増えるため、運用実績に基づき上限を設定
• コントローラ負荷と再割り当て時間を短くするため、空き余力を20〜30%確保

RF=3のクラスター配置イメージ(ラックアウェア)

ラック識別とトピック作成例

# server.properties（各ブローカー）
# broker.rack=rack-a|rack-b|rack-c

# 新規トピック（RF=3, min.insync.replicas=2）
# kafka-topics.sh --create --topic orders --partitions 18 --replication-factor 3 \
#   --config min.insync.replicas=2

4. ストレージ容量: 保持ポリシーからの逆算

容量見積りは、圧縮前/後の実効Ingress、保持期間、RFを掛け合わせ、インデックスやセグメントのオーバーヘッド、さらに運用ヘッドルームを加えます。公式の保持動作はretention.ms/retention.bytesおよびcleanup.policy(delete/compact)で制御されます。

ログ圧縮を使う場合は、ユニークキーの総サイズと更新頻度を中心に見積もり、deleteも併用するなら二段構えで上限を管理します。

• 基本式: 容量(単一レプリカ) ≈ 実効Ingress(MB/s) × 保持秒 × 圧縮係数
• クラスター必要容量 ≈ 単一レプリカ容量 × RF × (1 + ヘッドルーム)
• オーバーヘッド: インデックス/タイムインデックス、セグメント切替余白。安全側で+10〜20%を見込む
• ディスクは余裕を確保し、ログクリーナやコンパクタが詰まらないようIOPS/帯域を評価

計算例（delete保持, RF=3, 7日, ヘッドルーム25%）

# 前提
# 実効Ingress = 50 MB/s（圧縮後）
# 保持 = 7日 = 604800 秒
# RF = 3, ヘッドルーム = 25%
# オーバーヘッド係数 = 1.1 （インデックス等）

echo "scale=2; 50*604800*1.1*3*1.25/1024/1024" | bc
# => 約 120.4 TB （クラスター総容量の目安）
# 実機ではディスク単位（例 4TB x 台数）に割り付け、将来増設余地を残す

5. ネットワーク/ディスク帯域: 複製と消費を含めた予算化

クラスターIngressはプロデューサ→リーダーへの書き込みです。さらに、RF>1ではフォロワーがリーダーから複製フェッチを行います。理想的には、総受信は約「クライアントIngress × RF」に近づきます（重複ACKやメタデータ通信は小さめ）。Egressはコンシューマ数と読み取りパターンに比例します。

ディスクはシーケンシャル書き込みに強いHDDでも高スループットを出せますが、混在ワークロード（読み書き/圧縮/コンパクション）ではSSDのほうがジッタが少なく、レイテンシSLAを守りやすいです。

• NIC予算: 受信 ≈ Ingress×RF、送信 ≈ Ingress×(RF-1) + 総Egress（概算）
• ディスク予算: 書き込みはIngress、読み出しはEgressと複製/コンパクションが重なるピークで評価
• バッチ・圧縮(LZ4/ZSTD)はNIC/ディスクの効率改善に寄与。ただしCPU使用率とトレードオフ
• プロデューサacks=all + min.insync.replicasは待ちが増えうるため、遅延SLAと帯域を合わせて検証

ネットワーク概算フォーミュラ

# 例: Ingress=120 MB/s, RF=3, 総Egress=240 MB/s（複数グループ合算）
# 受信Rx ≈ 120 * 3 = 360 MB/s
# 送信Tx ≈ 120 * (3-1) + 240 = 480 MB/s
# 10GbE(実効~1,200 MB/s)なら1本で足りるが、冗長/将来増分を見て2ポート以上を推奨

6. 運用余裕とスケール戦略: 安全マージンと再割り当て

キャパシティは静的ではありません。トピックやトラフィックの成長を見込み、常に20〜30%の余力を維持し、しきい値に近づいたらブローカーやディスクを追加します。追加後はパーティション再割り当てで均衡させます。

再割り当てはネットワーク/ディスクに負荷をかけます。メンテナンスウィンドウ、スロットリング、優先リーダー選出の活用で影響を抑えます。

• 再割り当て時はクォータ（replication.throttled.rate）で帯域制御
• 優先リーダー選出でリーダーを計画的に分散
• メトリクス監視: パーティション/ブローカー数、ディスク使用率、ISRの安定性、リクエスト遅延
• 段階的スケール: まずディスク増設、次にブローカー追加と再割り当て

再割り当てと優先リーダー選出の例

# reassignment.json（例）
# {"version":1, "partitions":[{"topic":"orders","partition":0,"replicas":[1,2,3]}]}

# 実行
# kafka-reassign-partitions.sh --bootstrap-server <broker> --reassignment-json-file reassignment.json --execute
# 帯域スロットルを適用する場合は broker/topic 設定で replication.throttled.* を活用

# 優先リーダー選出
# kafka-preferred-replica-election.sh --bootstrap-server <broker>

問題で確認

よくある質問