Kafka Broker サイジング実践ガイド: CPU/メモリ/ディスクの設計

Kafka のブローカーは CPU、メモリ（JVM ヒープと OS ページキャッシュ）、ディスク、ネットワークのバランスで性能が決まります。特定の数値に依存するより、ワークロード（メッセージサイズ、圧縮、レプリケーション、消費者数、コンパクション有無）から資源の主要ボトルネックを見極める方が安定したサイジングにつながります。

本稿は CCAAK（Confluent の管理者系資格）で頻出の基本概念（ページキャッシュ重視、順次 I/O、acks/min.insync.replicas、パーティションと並列度など）に沿って、設計・検証までの手順を端的にまとめます。

前提の整理とスループットモデル

まず「どれだけのバイト/秒を入出力するか」を決めます。プロデューサの入力スループットを B_in（MB/s）、レプリケーション係数を RF、同時に追随するコンシューマグループ数を CG とすると、ネットワーク入方向は概ね B_in、ブローカー間レプリケーションの出方向は B_in × (RF − 1)、クライアント向け出方向は B_in × CG です。ディスクは基本的に順次書き込みで、OS ページキャッシュが吸収するため、入出力が即座にランダム I/O になるわけではありません（コンパクションや再読み取りが多いとディスク負荷は増えます）。

サイジングは「どの資源が先に飽和するか」を見ます。圧縮や TLS を多用すれば CPU 側が先に詰まりやすく、コンパクションや多読取であればディスク帯域とページキャッシュが効いてきます。CCAAK では、Kafka が OS ページキャッシュを前提にログを順次書き込みする点、およびレプリケーションがネットワークとディスク負荷を増幅する点がよく問われます。

以下の比較表は代表的なワークロードと主ボトルネックの対応を示します。実際には計測で補正してください。

• 重要: RF を上げるとネットワークとディスクの両方が線形に増える。
• コンシューマグループが複数同時追随すると、ブローカーの外向き帯域は B_in × グループ数に近づく。
• 小さなメッセージはスループットより CPU/スレッド切替コストが支配的になりやすい。

概算式: ブローカー台数の初期見積もり

入力スループット B_in_MBps
レプリケーション係数 RF
同時追随コンシューマグループ数 CG
1 ブローカーあたり許容入方向帯域 C_in_MBps
1 ブローカーあたり許容出方向帯域 C_out_MBps
1 ブローカーあたり許容ディスク帯域 C_disk_MBps

ネットワーク入方向負荷 ≈ B_in_MBps
ネットワーク出方向負荷 ≈ B_in_MBps × (RF - 1 + CG)
ディスク書き込み負荷 ≈ B_in_MBps × RF  （順次 I/O 前提／コンパクション等で上振れ）

必要ブローカー数 N は各資源で計算し最大値を採用:
N_in  = ceil( B_in_MBps                   / C_in_MBps )
N_out = ceil( B_in_MBps × (RF - 1 + CG)   / C_out_MBps )
N_disk= ceil( B_in_MBps × RF              / C_disk_MBps )
N = max(N_in, N_out, N_disk) × 余裕係数（例: 1.3〜1.5）

注: 実測で C_* を更新し反復。

CPU サイジングの考え方

CPU は主に圧縮・暗号化・シリアライズ/デシリアライズ・リクエスト処理で消費されます。トピックの compression.type=producer を使うと、ブローカーは受信した圧縮バッチを基本的に再圧縮せずに保持でき、CPU 負荷を抑えられます（互換性のためのダウンコンバージョンが必要な場合は再圧縮が発生し得ます）。

スレッド構成は num.network.threads、num.io.threads、num.replica.fetchers などで調整できますが、CPU コア数や NIC/Disk の並列度に見合わないスレッド過多はコンテキストスイッチ増大を招き逆効果です。圧縮を重くするほど CPU ボトルネックになりやすいので、LZ4/Snappy など低オーバーヘッドのコーデックを優先し、必要に応じてパーティション数で並列度を上げるのが安全です。

• 試験観点: compression.type=producer はブローカーの再圧縮を避けられるため CPU に有利。
• 小さなメッセージはプロトコル処理が相対的に支配的。バッチングで CPU 効率が上がる。
• ダウンコンバージョンやトランザクション有効化は CPU/ディスクの追加オーバーヘッド要因。

メモリ（Heap と OS ページキャッシュ）

Kafka はログデータ本体を JVM ヒープに保持せず、OS ページキャッシュを積極活用してディスク I/O を平滑化します。JVM ヒープはメタデータ、コントロールパス、ネットワークバッファなどに使われ、過大にすると GC ポーズが伸び、過小だとメタデータやバッファ不足が顕在化します。従ってヒープは中庸に、残りをページキャッシュに回すのが原則です。

ページキャッシュが厚いほど、追随するコンシューマの読み取りがディスクに落ちにくくなり低レイテンシを保ちやすくなります。コンパクションや再スキャンが多いワークロードでは、さらにメモリ（ページキャッシュ）を厚く取る価値があります。

• 試験観点: Kafka の性能は OS ページキャッシュへの依存が大きい。
• ヒープは GC 安定性を優先して中庸に設定、オフヒープ/ページキャッシュを厚めにする。
• パーティション数増はメタデータ量を増やしヒープ圧にも影響。

ブローカーのデータパスとメモリの役割

ディスクとログレイアウト

Kafka のログは基本的に順次書き込みで、OS ページキャッシュから非同期フラッシュされます。複数ディスクを持つ場合は log.dirs にマウント毎のディレクトリを列挙し、JBOD 的に使うのが一般的です。レプリケーションが耐障害性を担うため、単一ブローカー内での RAID 冗長は必須ではありません。I/O 一貫性よりも順次書き込み帯域を重視します。

ログセグメントサイズ（log.segment.bytes）や保持ポリシー（retention.ms/bytes）はディスク使用量とクリーナ作業量に直接効きます。コンパクションを多用する場合は高速 SSD/NVMe と十分な帯域、log.cleaner.threads の適切値が必要です。

• 試験観点: Kafka は順次 I/O とページキャッシュを前提。RAID より JBOD 推奨の文脈が多い（レプリケーションが前提）。
• 複数 log.dirs を別物理ディスクに割り当て、1 パーティションは 1 ディレクトリに配置される。
• 保持設定を厳しくするとディスクは節約できるが、圧縮や削除のバックグラウンド I/O が増えることもある。

レプリケーションと可用性のトレードオフ

レプリケーション係数 RF を上げると、書き込みあたりのネットワーク出力（フォロワー向け）とディスク書き込みが増えます。可用性を高める構成（acks=all と min.insync.replicas の併用）は、同時に容量とスループットのコストを引き上げます。試験では acks=all と min.insync.replicas の関係、ISR が縮小した場合の書けない条件などが頻出です。

ラックアウェア配置を有効化すると、同一ラック障害に対する耐性が高まりますが、ブローカー間トラフィックがラックを横断する前提になるため、ネットワークの東西帯域にも気を配ります。

• RF=3、acks=all、min.insync.replicas=2 なら 1 台故障時でも書き込み継続可（ISR>=2 を維持できることが条件）。
• RF を上げると N_out と N_disk が線形に増加するため、台数見積もりに必ず反映する。
• ラックアウェアでパーティションのレプリカを異なるラックに散らす。

キャパシティプランニング手順と検証

計画は「仮説 → 検証 → 補正」を前提にします。平均値だけでなくピークとパケット分布（メッセージサイズ、バッチング有無）を集め、RF や CG を含む拡張後トラフィックを見積もってから、少数ノードで負荷試験を行い、1 ブローカーの実測限界（C_in、C_out、C_disk）を得ます。これを元に必要台数を再計算し、20〜40% 程度の余裕を確保します。

運用では BytesInPerSec/BytesOutPerSec、RequestHandlerAvgIdlePercent、NetworkProcessorAvgIdlePercent、UnderReplicatedPartitions、IsrShrinksPerSec、LogFlush/Fetch/Produce 関連のレイテンシ、ディスク使用率・I/O 待ち、GC 指標などを監視し、早期にボトルネックを特定・増設判断ができるようにします。

• ワークロード特性を集計（B_in、平均/95p メッセージサイズ、RF、CG、コンパクションの有無）。
• 少数ノードでプロデューサ/コンシューマ負荷試験を行い C_in/C_out/C_disk を実測。
• 見積もり式で台数を算出し、将来成長とメンテナンス余裕を上乗せ。

問題で確認

よくある質問