Kafka Topic と Partition の基礎: 分散とスケーラビリティの要

Topic は論理名、Partition は順序付きの不変ログ。スケールと順序保証は Partition が単位になります。

可用性は複製（replication）と ISR に依存。並列度は「Partition 数 ≤ Consumer 並列度」で制限されます。

基本: Topic / Partition / Replica / Offset

Kafka の Topic はイベントのカテゴリ名、Partition はその Topic を水平分割した順序付き・不変のログです。各レコードは Partition 内で単調増加する offset を持ち、順序保証の範囲は Partition 内に限られます。

可用性は複製（replication）で確保されます。各 Partition には 1 つの Leader と 0 個以上の Follower があり、Follower は Leader のログを追従します。最新に追従できている集合を ISR（In-Sync Replicas）と呼びます。書き込みの耐久性は acks と min.insync.replicas の組み合わせで制御します（詳細は後述）。

• Partition は並列処理とスケールの最小単位
• 順序保証は Partition 内のみ（Topic 全体の全順序は原則なし）
• オフセットはコンシューマが管理する読み取り位置指標（__consumer_offsets にコミット）
• 複製係数（replication.factor）は本番では少なくとも 3 を推奨

トピックの分散配置と複製（例: partitions=3, RF=3）

CLI でトピックを作成/確認（3 パーティション、RF=3）

kafka-topics --bootstrap-server broker1:9092 \
  --create --topic orders --partitions 3 --replication-factor 3

kafka-topics --bootstrap-server broker1:9092 \
  --describe --topic orders

プロデューサ: パーティショニングと順序保証

プロデューサはパーティショナーで送信先 Partition を決定します。キー付きレコードでは、キーのハッシュなどにより同一キーが同一 Partition に送られ、キー単位の順序が保たれます。これが CCDAK で頻出のポイントです。

キーなしレコードの分散方法はクライアント実装に依存します（ラウンドロビンやバッチ効率を高めるスティッキー分散など）。試験/設計の要点は「順序が必要ならキーを使う」ことです。耐久性は acks、重複抑制は idempotent プロデューサ（enable.idempotence=true）で強化できます。

• 同一キーは同一 Partition → キー単位の順序が保たれる
• キーなしはクライアントの戦略に依存（ラウンドロビン/スティッキー等）
• 高信頼: acks=all と適切な min.insync.replicas を併用
• 重複抑制: enable.idempotence=true（再試行時の二重書き込み抑制）
• 圧縮（compression.type）で帯域とスループットを改善

コンソールプロデューサでキーを付与して送信

kafka-console-producer --bootstrap-server broker1:9092 \
  --topic orders --property parse.key=true --property key.separator=:
# 入力例（左がキー、右が値）
user-42:{"op":"create","id":1}
user-42:{"op":"update","id":1}
user-7:{"op":"create","id":2}

コンシューマグループと並列度

同一グループ ID のコンシューマは Partition を分担して読みます。1 つの Partition を同時に処理できるのは同一グループ内で 1 コンシューマだけです。したがって、最大並列度は min(Partition 数, コンシューマ数) で頭打ちになります。

再均衡（リバランス）はグループのメンバー変動やサブスクリプション変更時に発生し、一時的に処理が止まります。セッションタイムアウトや心拍の調整、安定したデプロイ戦略で過剰な再均衡を避けます。

• 最大並列度 = min(Partition 数, グループ内コンシューマ数)
• 1 Partition は同一グループ内で専有される（同時処理は不可）
• オフセットは明示コミット（enable.auto.commit=false）で制御性向上
• auto.offset.reset=earliest/latest は未コミット時の開始位置

グループを使って読み取り（複数プロセスで並列化）

# ターミナル1
kafka-console-consumer --bootstrap-server broker1:9092 \
  --topic orders --group app-readers --from-beginning
# ターミナル2（同一グループ。Partition が分担される）
kafka-console-consumer --bootstrap-server broker1:9092 \
  --topic orders --group app-readers

設計ガイド: パーティション数をどう決めるか

目標スループット、1 Partition あたりが出せる処理量、必要なコンシューマ並列度から見積もります。経験的には「現状需要を満たす数 + 余裕」を用意し、足りなければ増やします（減らすことはできないため初期値は慎重に）。

Partition を増やすほどメタデータ・ファイル数・オープンファイルやネットワークの負荷が増えます。全順序が必要なワークロードでは Partition を 1 に抑える代わりにスループットが制限されます。用途に応じたトレードオフを明確化しましょう。

• 1 Partition = 1 並列スロット（コンシューマグループ基準）
• 増やせるが基本的に減らせない（新トピック作成と移行が必要）
• 多すぎる Partition はブローカー/コントローラの負荷増・運用複雑化
• 厳格な全順序が必要なら単一 Partition を検討

レプリケーションと可用性: acks と min.insync.replicas

書き込みの耐久性は acks 設定で制御します。acks=all は Leader と ISR 上の必要数のレプリカにレコードが複製されてから応答します。min.insync.replicas は“acks=all のとき応答に必要な同期レプリカ数の下限”です。

実務推奨は、重要なトピックで replication.factor=3、min.insync.replicas=2、プロデューサで acks=all。これにより 1 台のブローカー障害下でも書き込みを継続しつつデータ損失リスクを抑えられます。クラスター健全性の指標として Under-Replicated/Offline Partitions は常に 0 を目標に監視します。

• RF≥3、min.insync.replicas≥2（重要データ）
• acks=all と組み合わせて耐久性を確保
• 不潔なリーダー選出（unclean leader election）は本番で無効推奨
• ISR からの離脱が続く場合はネットワーク/ディスク/負荷を点検

トピック/プロデューサの耐久性関連設定例

# トピック作成時に min.insync.replicas を設定
kafka-topics --bootstrap-server broker1:9092 \
  --create --topic critical-events --partitions 6 --replication-factor 3 \
  --config min.insync.replicas=2

# プロデューサ（プロパティ例）
acks=all
enable.idempotence=true
retries=2147483647
max.in.flight.requests.per.connection=5

運用とチューニング: ライフサイクルと再分散の注意

Partition 数は増やせますが減らせません。既存のキーが新しい Partition 数で別の Partition にマッピングされる可能性があるため、増加後は“同一キーが常に同じ Partition”という性質が過去データと跨っては維持されない点に注意します（Partition 内の順序保証という基本は不変）。

保持は retention.ms/retention.bytes、クリーンアップ方針は cleanup.policy=delete/compact で制御します。コンパクションはキーごとに最新値を残す用途に向き、イベントの完全履歴を必要とする場合は delete 方針＋十分な保持期間を設定します。再割り当てやメンテ作業ではレプリカの移動が I/O を消費するため、ウィンドウを設けて段階的に行います。

• 増やせるが減らせない → 減らしたい場合は新トピック作成＋移行
• 再割当: kafka-reassign-partitions（計画と検証を踏む）
• 監視: under-replicated partitions、offlinePartitionsCount、コンシューマラグ
• 保持と圧縮の設定はユースケース（ログ保持 vs. KV 最新化）で分ける

代表的な運用コマンド

# Partition 数の増加
kafka-topics --bootstrap-server broker1:9092 \
  --alter --topic orders --partitions 12

# トピック保持の調整
kafka-configs --bootstrap-server broker1:9092 --entity-type topics \
  --entity-name orders --alter --add-config retention.ms=604800000

# 再割当の開始（例。JSON で計画を指定）
kafka-reassign-partitions --bootstrap-server broker1:9092 \
  --execute --reassignment-json-file plan.json

問題で確認

よくある質問