Contents
Kafkaトピック設計の基本概念
Kafka のトピックを作成するときに最も重要なのは パーティション数、レプリケーション因子、キー設計 です。これらはスループット・耐障害性・コンシューマ側の負荷分散に直接影響し、運用コストやシステムの安定性を左右します。本節ではそれぞれの選定基準と実務での注意点をまとめ、設計時の判断材料を提供します。
パーティション数とレプリケーション因子の選定基準
パーティションは並列処理単位、レプリケーション因子はデータ耐障害性を決めます。以下に実測ベンチマークと前提条件を示します。
- パーティションあたりの上限スループット
- Confluent の 2023 年ベンチマーク（SSD、CPU 8 コア、メッセージサイズ 500 B）では、単一パーティションで約 120 MB/s（書き込み）を安定して達成できました。複数パーティションに分散するとネットワーク帯域とブローカー I/O がボトルネックになる点に注意してください。
-
前提条件: Replication factor = 3、プロデューサはバッチ送信（batch.size = 100 KB）を使用。
-
レプリケーション因子の選定
- 最低でも 3 コピー を推奨します。これは「1 台がリーダー、残り 2 台がフォロワー」構成で、同時に 2 台故障しても ISR（In‑Sync Replica）が維持され、データ損失を防げるためです。
- AWS の公式ブログ（2022 年）でも「ミッションクリティカルな環境では 5 コピー」まで検討することが推奨されています。
設計指針：パーティションはスループット要件から逆算し、レプリケーションは最低 3 コピーを確保したうえで ISR の監視を徹底します。
キー設計がスループットとデータ分散に与える影響
キーはレコードのパーティション割り当てを決定するため、偏りがあると特定パーティションだけがボトルネックになります。
- キー偏りのリスク
-
同一キーが集中すると、そのパーティションへの書き込み/読み取りが集中し、レイテンシが 3〜5 倍に増大するケースがあります（Medium 記事「Kafka設計失敗事例」）。
-
均等分散のテクニック
- ハッシュ関数をカスタマイズするか、キーにサフィックスやモジュロ演算 (
userId_mod_10) を付与してキー空間を広げます。 - メッセージサイズが小さい場合は レコードバッチ化 と合わせてキー設計を行うと、ネットワーク往復回数を削減できます。
設計指針：キーはデータ局所性と負荷分散のバランスを考慮し、偏りが出ないようにハッシュやプレフィックスで拡張します。
本セクションまとめ
- パーティション数は「総スループット ÷ 120 MB/s」＋30% の余裕で算出
- レプリケーションは最低 3、必要に応じて 5 を検討
- キー設計は均等分散を意識し、ハッシュやモジュロで衝突回避
スループット・スケーラビリティとパーティショニング計算
本章では「要求スループット → 必要パーティション数」の具体的な計算式と、増分パーティショニング時の安全手順を示します。実務ですぐに適用できる例として、10 GB/秒 の総スループットが必要なシナリオを取り上げます。
スループット要求から導くパーティション数の計算式
以下の前提で計算します。
| 前提条件 | 内容 |
|---|---|
| メッセージサイズ | 500 B |
| 平均バッチサイズ | 100 KB |
| Replication factor | 3 |
| パーティションあたり上限スループット | 120 MB/s（Confluent 2023 年ベンチマーク） |
計算手順は次の通りです。
- 総スループット要件：10 GB/s = 10 000 MB/s
- 単位パーティション上限：120 MB/s × (1 ÷ Replication factor) ≈ 40 MB/s（レプリケーションによるネットワーク負荷を考慮）
- 必要パーティション数 = ⌈10 000 / 40⌉ = 250
実務では「余裕分 +30%」が安全ですので、325 パーティション を目安に設定します。以下は作成例です（replication=3）。
|
1 2 3 4 5 6 7 |
kafka-topics.sh --create \ --topic orders-events \ --partitions 325 \ --replication-factor 3 \ --config cleanup.policy=delete \ --config retention.ms=604800000 # 7日保持 |
設計指針：スループット要件から逆算し、レプリケーションによるオーバーヘッドと30% の余裕を加えたパーティション数で設計します。
増分パーティショニングとレプリカ再配置の安全手順
増分でパーティションを拡張する際は ISR が完全に復旧したことを確認し、段階的に実行します。以下の表は作業フローと注意点です。
| 手順 | 操作内容 | 主なチェックポイント |
|---|---|---|
| 1 | 現行トピックの ISR とリーダー状態を kafka-topics.sh --describe で確認 |
ISR が全パーティションでフルかつレプリカが同期中 |
| 2 | --alter --partitions <増分> でパーティション数を拡張（例: +50） |
増加後のパーティション割り当てが均等か、キー偏りシミュレーションを実施 |
| 3 | 必要に応じて kafka-reassign-partitions.sh でレプリカ配置を再計画 |
各ブローカーのディスク使用率 < 70% を維持 |
| 4 | 再配置完了後、ISR が復帰したことを kafka-consumer-groups.sh --describe 等で確認 |
ピーク時間外に実施し、レイテンシ上昇が許容範囲か検証 |
設計指針：増分パーティショニングは「ISR 完全復旧 → 次のステップ」へ進むことで、データロスや過負荷を防止します。
本セクションまとめ
- パーティション数は「総要件 ÷ (上限÷レプリケーション)」＋30% が実務的な目安
- 増分拡張時は ISR 完全復旧とディスク均衡を必ずチェック
耐障害性とデータ保持ポリシー
可用性とコストのバランスを取るために、レプリケーション設定とログ保持戦略は欠かせません。本節では推奨コピー数・ISR 管理・ディスク容量計画の具体手順を示します。
レプリケーションベストプラクティス
| 項目 | 推奨設定 | 理由 |
|---|---|---|
| コピー数 (replication.factor) | 3（標準）／5（ミッションクリティカル） | 3 で多数障害に耐え、5 にするとデータロス確率がさらに低減 |
ISR 閾値 (min.insync.replicas) |
2 | ISR が 2 未満になると書き込みを拒否し、データ損失リスクを防止 |
| 監視指標 | UnderReplicatedPartitions、ReplicaLag、ISR Shrinkage Rate |
異常時に即座にアラートを上げられるよう設定 |
設計指針：最低コピー数は 3 とし、
min.insync.replicas=2を併用して書き込み保護を実装します。
ログ保持・ディスク容量計画とコンパクション設定
| 項目 | 推奨値 | 根拠 |
|---|---|---|
保持期間 (retention.ms) |
30 日（259200000） | ビジネス要件とコストのトレードオフで一般的に採用 |
保持サイズ上限 (retention.bytes) |
10 GB/パーティション | ディスク使用率を 70% 以下に抑える計算式に基づく |
コンパクションポリシー (cleanup.policy) |
compact（キーがユニークなマスターデータ）または delete（イベントストリーム） |
用途別に最適化 |
ディスク容量概算
|
1 2 3 |
必要容量 ≈ 平均書き込み速度 (GB/日) × 保持期間(日) × パーティション数 例: 5 GB/日 × 30 日 × 325パーティション ≈ 48.75 TB |
設計指針：レプリカは最低 3、保持ポリシーは容量計画と合わせて設定し、コンパクション対象はキーがユニークなトピックに限定します。
本セクションまとめ
- コピー数は 3 を基本、5 は要件次第で採用
min.insync.replicas=2と監視指標で障害時の書き込み阻止を実装- 保持期間とサイズはディスク使用率 < 70% を目安に計算
Consumer Group とオフセット管理、トピック変更時の安全手順
コンシューマ側の設計とトピック設定変更はデータロスや重複処理のリスクが高いため、段階的かつ検証済みの手順が必須です。
Consumer Group 設計とオフセット永続化の注意点
- グループサイズはトピックのパーティション数以下に抑える。余剰コンシューマはアイドル状態となり、リバランス頻度が増えてレイテンシが上昇します。
- オフセット保存先はデフォルトで
__consumer_offsetsトピックです。重要系アプリではこのトピックのレプリケーション因子を 3 に明示的に設定します（offsets.topic.replication.factor=3）。 - コミット戦略は
enable.auto.commit=falseとし、処理成功後にcommitSync()またはcommitAsync()（コールバックでエラーハンドリング）を使用。これにより「一部レコードだけ再処理」や「重複書き込み」のリスクが低減します。
設計指針：コンシューマグループはパーティション数と同等かそれ以下にし、手動コミットで確実なオフセット永続化を行います。
トピック設定変更（パーティション増加・レプリカ再配置）の段階的実施方法
- 事前バックアップ
-
kafka-run-class.sh kafka.tools.ExportZKMetadataまたは KRaft 環境ではkafka-metadata-shell.sh --snapshotを使用してメタデータを保存。 -
ステージングでリハーサル
-
本番と同構成のテストクラスターに変更を適用し、ISR とレイテンシを測定。
-
本番適用
- パーティション増加:
kafka-topics.sh --alter --partitions <新総数>（例: 325 → 350） -
レプリカ再配置: JSON 形式の割当計画を作成し、
kafka-reassign-partitions.sh --execute --reassignment-json-file plan.json -
変更後モニタリング
- 15 分間は
UnderReplicatedPartitions、ReplicaLag、ConsumerGroupLagを重点的に監視。異常が検出されたら即座にロールバック手順を実行。
設計指針：変更前に必ずステージングで検証し、ISR がフル復帰したことを確認してから本番に適用します。
本セクションまとめ
- コンシューマはパーティション数以下、手動オフセットコミットで信頼性向上
- トピック変更はバックアップ → ステージングリハーサル → 本番実施 → 監視 の4ステップで安全に行う
最新運用要点と監視・テスト戦略
KIP‑500 による ZooKeeper 廃止やクラウドネイティブへの移行が進む中、最新の運用ポイントと実践的な監視・負荷テスト手法を整理します。
KIP‑500 とクラウドネイティブ考慮点
- KIP‑500 の効果：メタデータ管理が内部 Raft コンロールプレーンに統合され、ZooKeeper が不要になることでブローカー再起動時間が約 30% 短縮されます（Confluent 2023 年リリースノート）。
- クラウドマネージド環境（Amazon MSK、Confluent Cloud）ではデフォルトで KRaft が有効です。
kafka.controller.quorum.votersの設定が必要な場合は、各ベンダーのドキュメントを参照してください。 - オンプレミス移行手順：まず KRaft モードのテストクラスターを構築し、
kafka-metadata-migration.shで既存 ZooKeeper メタデータを移行。その後段階的に本番ブローカーへ切り替えます。
運用指針：KIP‑500 移行はテスト環境で十分に検証し、メトリクス取得方法が変わらないこと（ISR 監視の重要性は増す）を確認してから本番導入します。
主要監視指標とアラート設定例
以下は Prometheus + Alertmanager で推奨する Kafka 用メトリクスです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
# 1. パーティションのレプリケーション不足 - alert: KafkaUnderReplicatedPartitions expr: sum(kafka_cluster_partition_under_replicated) > 0 for: 2m labels: severity: critical annotations: summary: "パーティションがレプリケーション不足" description: "{{ $labels.topic }} の {{ $value }} 個のパーティションが ISR 未満です。" # 2. レプリカ遅延が閾値超過 - alert: KafkaReplicaLagHigh expr: max(kafka_consumer_lag) > 500000 # 約5分以上遅延 for: 5m labels: severity: warning annotations: summary: "レプリカ遅延が高い" description: "Consumer グループ {{ $labels.group }} の遅延が {{ $value }} メッセージです。" # 3. ディスク使用率が80%を超える - alert: KafkaDiskUsageHigh expr: (kafka_log_dir_size_bytes / kafka_log_dir_capacity_bytes) > 0.8 for: 10m labels: severity: critical annotations: summary: "ディスク容量逼迫" description: "ブローカー {{ $labels.instance }} のディスク使用率が {{ printf \"%.2f\" ($value*100) }}% に達しています。" |
- ISR は
kafka_cluster_partition_under_replicated、レプリカ遅延 はkafka_consumer_lag、ディスク容量 はkafka_log_dir_*系メトリクスで取得できます。
運用指針：KIP‑500 でコントローラが単一になる分、ISR の監視はシステム全体の健全性を示す最重要指標となります。
負荷テストと失敗事例から学ぶ回避策
| テスト項目 | 推奨ツール・コマンド | 評価ポイント |
|---|---|---|
| スループット測定 | kafka-producer-perf-test.sh、kafka-consumer-perf-test.sh または k6 + kafka‑js |
パーティション増減がスループットに与える影響 |
| レイテンシ 99th Percentile | 同上の --print-metrics オプションで取得 |
ピーク時の遅延耐性 |
| ブローカー障害シミュレーション | tc netem でネットワーク partition、または Chaos Mesh |
ISR 復旧時間とデータロス有無 |
実際の失敗例（Medium）：パーティション数を過小に設定し、特定キーが集中した結果、レイテンシが 5 倍に増大。回避策として 「キー分散テスト + パーティションスケーリング計画」 をリリース前に実施しています。
運用指針：負荷テストは本番と同等のハードウェア構成で行い、パーティショニング・レプリカ設定がボトルネックにならないか事前に検証します。
本章まとめ
- KIP‑500 は運用をシンプル化するが ISR 監視は依然重要
- Prometheus + Alertmanager のアラート例で主要指標を網羅
- 負荷テストと失敗事例のレビューにより、設計段階でパーティション・キー偏りリスクを排除
全体まとめ
| 項目 | 推奨設定/手順 |
|---|---|
| パーティション数 | 「総スループット ÷ (120 MB/s ÷ Replication)」＋30% の余裕で算出し、必要に応じて段階的に増加 |
| レプリケーション因子 | 最低 3、ミッションクリティカルは 5。min.insync.replicas=2 を設定 |
| キー設計 | ハッシュ・モジュロで均等分散、偏り検証を必須 |
| オフセット管理 | 手動コミット、__consumer_offsets のレプリケーション因子 3 |
| ログ保持 | retention.ms=30d、retention.bytes=10GB/パーティション、用途別に compact／delete を選択 |
| 監視指標 | ISR, ReplicaLag, DiskUsage → Alertmanager で即時通知 |
| 負荷テスト | スループット・レイテンシ・障害シミュレーションを本番相当環境で実施 |
| KIP‑500 移行 | テストクラスターで Raft 化検証、メタデータ移行ツール活用 |
これらの指針と手順を踏むことで、Kafka トピック設計・運用におけるスループット最適化、耐障害性確保、そして安全な変更管理が実現できます。