Kafka リバランスの流れと影響: イベント発生条件と停止時間の削減

リバランスはコンシューマグループの安定性と可用性に直結します。試験では概念と設定の因果、運用では停止時間の最小化が要点です。

本稿は公式挙動に基づき、イベント発生条件、プロトコル差分、設定のトレードオフ、監視・運用までを一気通貫で解説します。

Kafka リバランスの基本と前提

リバランスは、コンシューマグループ内でパーティション割り当てを再計算し直すプロセスです。グループコーディネータが JoinGroup と SyncGroup の往復でメンバーに割り当てを通知し、各メンバーは再開前に revoke/assign の処理を行います。

プロトコルには大きく Eager と Cooperative（増分）があります。Eager は全メンバーが一度すべてのパーティションを手放す方式で停止時間が伸びがち、Cooperative は段階的に譲り合うため停止時間を短縮できます。

• グループの安定状態は Stable、リバランス中は PreparingRebalance/CompletingRebalance を遷移
• 再均衡時は onPartitionsRevoked でコミット、onPartitionsAssigned で初期化が基本
• 停止時間は「全メンバーが読めない時間」ではなく「各メンバーが担当パーティションを読めない時間」の総和で観測されることが多い

基本シーケンス（簡略）

Java コンシューマのリバランスリスナー（要点のみ）

consumer.subscribe(Collections.singletonList("orders"), new ConsumerRebalanceListener() {
  @Override
  public void onPartitionsRevoked(Collection<TopicPartition> partitions) {
    // 処理中メッセージを安全に終了し、最後まで読んだ位置を同期コミット
    consumer.commitSync();
  }
  @Override
  public void onPartitionsAssigned(Collection<TopicPartition> partitions) {
    // 再開時の位置調整。必要に応じて seek を行う
    // consumer.seekToCommitted(partitions);
  }
});

リバランスのイベント発生条件

リバランスは任意の変更で常に発生するわけではありません。主因はメンバーシップ、サブスクリプション、トピック構成の変化です。心拍やポーリングの時間超過は、実務で最も多い誘因です。

コーディネータのフェイルオーバー時はメンバーの再参加が発生し得ますが、必ずしも割り当てが大幅に変わるわけではありません。とはいえ短時間の空白や再同期は覚悟が必要です。

• 新規メンバーの参加・離脱（プロセス終了、クラッシュ、スケール操作）
• session.timeout.ms の超過、または heartbeat.interval.ms の異常でのメンバー喪失判定
• max.poll.interval.ms 超過（アプリが長時間 poll を呼べずに不健康と見なされる）
• サブスクリプションの変更（subscribe の対象更新）
• トピックのパーティション数増加
• グループコーディネータの移動や再起動に伴う再参加

発生条件の概念マップ

代表的なコンシューマ設定（発生回避の土台）

# 心拍とメンバー健全性
session.timeout.ms=...        # 過度に短い/長いは不安定化
heartbeat.interval.ms=...     # session.timeout の分数に収める

# アプリ処理健全性
max.poll.interval.ms=...      # 処理が長いなら適切に延長
max.poll.records=...          # 1 回の処理量を制御して超過を防ぐ

Eager と Cooperative の違いと選択指針

Eager 方式（Range/Sticky など）は再均衡開始時に全メンバーがいったん全パーティションを revoke し、割り当て完了まで読むのを止めます。単純で互換性が広い反面、停止時間が伸びがちです。

Cooperative Sticky は増分的に譲り合う方式で、影響のあるパーティションのみを段階的に移譲します。複数ラウンドを経て安定化しますが、多くのケースで総停止時間は短くなります。

• 短時間停止・ローリングデプロイ優先なら Cooperative Sticky を検討
• 古いクライアント混在や特定のエコシステム要件がある場合は Eager を選ぶこともある
• 同一グループ内で複数アサイナー混在は避ける（挙動が不安定になる）

Eager と Cooperative の時間挙動（概念）

Eager:
[Revoke all]----[Assign all]----[Resume]
         ^ 全停止

Cooperative:
[Revoke impacted]--[Assign subset]--[Resume some]--[Next round]--[Stable]
         ^ 影響範囲のみ停止

アサイン戦略の設定例

# Cooperative（推奨・対応クライアント）
partition.assignment.strategy=[org.apache.kafka.clients.consumer.CooperativeStickyAssignor]

# Eager（互換優先）
# partition.assignment.strategy=[org.apache.kafka.clients.consumer.StickyAssignor]
# または RangeAssignor を明示

停止時間の見積もりと影響ポイント

コンシューマの有効停止時間は、revoke から resume までの区間と、アプリの処理中断・再初期化コストの和で決まります。Cooperative では対象が一部に限定されるため、合計としての空白が短くなります。

アプリ側のコミット設計が未熟だと、リバランスに伴う重複処理や取りこぼしのリスクが上がります。onPartitionsRevoked での同期コミットと、再割り当て時の初期化を明確にしましょう。

• 重い処理で max.poll.interval.ms を超過しないようにバッチ分割
• コミット遅延が長いと再開時の重複が増える（小さくし過ぎるとオーバーヘッド）
• パーティション増加時はウォームアップ時間（キャッシュ、接続）も停止体感に効く

タイムライン（単一メンバーの視点）

time --->
[poll]--process--process--RebalanceStart--revoke--commit--assign--init--resume--process
                       ^ 停止窓口

処理の一時停止と再開の基本パターン

// revoke 受領で安全停止
consumer.pause(currentPartitions);
consumer.commitSync();
// 必要なクローズ処理...

// assign 受領で再初期化
// for (tp : assigned) { seekToCommitted(tp); }
consumer.resume(assignedPartitions);

停止時間を減らす実践テクニック

停止時間を下げる近道は、発生頻度を減らし、発生時の影響範囲を狭めることです。Cooperative Sticky と静的メンバーシップの併用、適切なハートビート・ポーリング設定、計画的スケールが柱になります。

ローリングデプロイ時は静的メンバーシップでスロットを保持しつつ、1 台ずつ入れ替えると再分散の波及を抑えられます。

• Cooperative Sticky を明示設定し、全 revoke を避ける
• group.instance.id を付与して静的メンバー化、ローリング時の再分散を抑制
• heartbeat.interval.ms と session.timeout.ms の比率を健全に保つ
• バッチ分割と backpressure で max.poll 超過を予防
• パーティション増加は閑散時間帯に実施し、段階的に検証

静的メンバーシップのスロット保持イメージ

設定とローリングの基本例

# 静的メンバー + Cooperative
partition.assignment.strategy=[org.apache.kafka.clients.consumer.CooperativeStickyAssignor]
group.instance.id=order-svc-1   # グループ内で一意

# ローリング手順（概念）
# 1) 1 台ずつ停止
# 2) すぐに同一 group.instance.id で起動
# 3) 安定化を確認して次の台へ

監視・トラブルシュートと運用コマンド

リバランスの過多はアプリ停止時間とレイテンシ悪化に直結します。クライアントとブローカのメトリクス、ログ、CLI を組み合わせて早期検知・切り分けを行います。

典型的な兆候は rebalances-total の急増、heartbeat-rate の低下、RebalanceInProgressException の多発です。原因がアプリ処理か、インフラ遅延か、設定かを切り分けます。

• クライアント JMX: consumer-coordinator-metrics.rebalances-total、heartbeat-rate、commit-latency-avg
• ログ: Member x in group y has failed, RebalanceInProgressException
• CLI: kafka-consumer-groups で割り当てとラグを即時確認

グループ状態の遷移（概念）

よく使う運用コマンド

# 現在の割り当てとラグ
kafka-consumer-groups --bootstrap-server <bkr:9092> --describe --group <group>

# グループのメンバー一覧
kafka-consumer-groups --bootstrap-server <bkr:9092> --describe --members --group <group>

# オフセットを安全に調整（計画メンテ用）
# 実行前に --dry-run で必ず確認
kafka-consumer-groups --bootstrap-server <bkr:9092> --group <group> --topic <t> --reset-offsets --to-latest --dry-run

問題で確認

よくある質問