Kafka Partition Assignor 戦略の実務整理: Range / RoundRobin / Sticky / Cooperative-Sticky

Consumer Group のスループットや安定性は、どの Partition Assignor（割当戦略）を選ぶかで大きく変わります。特に再バランス時の停止時間は、戦略選択とクライアント実装の細部に強く依存します。

ここでは Range / RoundRobin / Sticky / Cooperative-Sticky の違いを、公式挙動に基づき実務と CCDAK 対策の両面から整理します。既定値に任せず、要件に応じて明示設定するのが安全です。

Consumer Group とパーティション割当の基本

Kafka の Consumer Group では、同一 Group 内の消費者に対し、購読中トピックの各パーティションが重複なく割り当てられます。どの消費者にどのパーティションを割り振るかを決めるのが Partition Assignor です。Kafka クライアント設定 partition.assignment.strategy に複数クラス名を並べられ、Group はメンバー全員が共通でサポートするリストの先頭を採用します。

代表的な戦略は RangeAssignor、RoundRobinAssignor、StickyAssignor、CooperativeStickyAssignor の4つです。Range/RoundRobin/Sticky は Eager（全リボーク前提）、Cooperative-Sticky は Cooperative（段階的リボーク）という再バランス・プロトコルの違いが、停止時間と移動コストに直結します。

注意点として、subscribe を使う通常の Group 消費では Assignor が効きますが、assign を使って手動割当をすると Assignor は関与しません。また、デフォルト戦略は多くのバージョンで RangeAssignor のままです。レイテンシが厳しいワークロードや大規模 Group では Cooperative-Sticky を明示設定するのが実務の定石です。

• partition.assignment.strategy はクラス名のリスト。Group は「全メンバー共通の最初の戦略」を採用
• Eager は一度すべてをリボーク、Cooperative は必要最小限を段階的にリボーク
• assign を使う手動割当では Assignor は働かない（試験でも混同しがちな点）

RangeAssignor の特徴と注意点

RangeAssignor は「トピックごと」に、購読メンバーをソートし、パーティションを連続範囲で配分します。各トピックについて partitions ÷ consumers を基準に均等割りし、余りは先頭メンバーから順に多めに受け取ります。単一トピックでは直感的で安定しやすい一方、複数トピックを同一 Group が購読する場合、同じメンバーが各トピックで“先頭側”を取りやすく、総割当が偏る傾向があります。

例えば T1(6パーティション)と T2(4パーティション)を3消費者で購読すると、T1 の余り2つと T2 の余り1つが先頭側に寄り、同一メンバーの総割当が増えがちです。CCDAK では『Range はマルチトピックで偏りやすい』が頻出ポイントです。

• 長所: 実装が単純、単一トピックでは挙動が予測しやすい
• 短所: マルチトピックで偏りやすい、会員増減時の再配置がやや大きめ
• 適用: 単一トピック中心・既定値優先・後方互換性重視の環境

RoundRobinAssignor の特徴と注意点

RoundRobinAssignor は、対象となる全トピックの全パーティションを並べ、購読しているメンバーに対し「全体でのラウンドロビン」で配分します。購読集合が同一であれば、トピックをまたいでも非常に均等です。

ただし、メンバーごとに購読トピックが異なる場合、割当の見通しが悪くなり、メンバー増減時の移動が比較的大きくなります。再バランスのたびにパターンが崩れやすい点は、低遅延要件では不利です。

• 長所: 複数トピックをまとめてほぼ均等にできる
• 短所: 会員変動での再配置が大きい、購読集合の差が大きいと効果が落ちる
• 適用: 全メンバーが同一のトピック集合を購読する ETL パイプラインなど

Sticky / Cooperative-Sticky の違い

StickyAssignor は『均等さ』と『前回からの変更最小化（スティッキネス）』の両立を目指します。会員増減やパーティション数変化があっても、必要最小限だけを動かしつつ、各メンバーの総割当個数が均等になるよう調整します。プロトコルは Eager で、再バランス時はいったん広くリボークが発生します。

CooperativeStickyAssignor は Sticky の目標を保ったまま、プロトコルを Cooperative（増分的）にします。段階的に『必要なパーティションだけ』をリボーク・再割当するため、ストップ・ザ・ワールドを避けやすく、遅延スパイクを抑制できます。一般に Kafka/Confluent の近年バージョンで利用可能ですが、環境のサポート状況（ブローカーとクライアントの対応）を確認してから有効化してください。

• Sticky: 均等性 + 変更最小化、だが Eager のため一時停止は大きめ
• Cooperative-Sticky: 均等性 + 変更最小化 + 段階的リボークで停止を最小化
• 大規模 Group、状態付き処理、低遅延要件では Cooperative-Sticky を推奨

Eager vs Cooperative 再バランスの挙動と実務インパクト

Eager は全メンバーが一旦パーティションを手放し、その後に再割当します。短時間でも全体停止しやすく、コミットや状態管理の設計が重要です。Sticky 系でも Eager の場合はこの停止を避けられません。

Cooperative は、必要最小限のパーティションだけをリボークし、残りは処理を継続できます。多段階の調整で最終配置へと収束し、レイテンシのスパイクとスループット低下を抑制します。ConsumerRebalanceListener 実装では、onPartitionsRevoked で『実際にリボークされる一部だけ』を確実にコミット・停止し、onPartitionsAssigned で安全に再開します。

• Eager: 容易だが全体停止が起きやすい。大きな Group ほど影響が顕著
• Cooperative: 増分的に収束。大規模・低遅延ワークロード向き
• 実装注意: onPartitionsRevoked ではリボーク対象のみの明示コミットが安全

Cooperative-Sticky による段階的リボーク（新規 Consumer 参加時）

時系列 --->

C1: [P0][P1][P2]         ──> revoke [P2] ──> [P0][P1]        ──> 最終: [P0][P1]
C2: [P3][P4][P5]         ──> revoke [P5] ──> [P3][P4]        ──> 最終: [P3][P4]
C3:           (join)      ────────────────> assign [P2][P5]  ──> 最終: [P2][P5]

ポイント: 全メンバーが一斉停止せず、必要分だけを段階的に移動して収束する。

設定例と移行パターン（ローリングで Cooperative-Sticky へ）

partition.assignment.strategy はクラス名のリストで指定します。ローリング移行では、新旧が混在する間は共通部分（例: Range）が選ばれ、全台が Cooperative-Sticky をサポートした段階で自動的に Cooperative-Sticky に切り替わるよう並べます。

Cooperative を使う際は、ConsumerRebalanceListener でリボーク対象だけを確実にコミット・停止し、再割当で安全に再開する実装が重要です。状態付き処理（ローカルキャッシュや外部セッション）では、partial revoke を想定した停止・再開処理を用意してください。

• 推奨: CooperativeStickyAssignor を先頭に、Range を後方互換のフォールバックとして列挙
• 全メンバーのアップグレード完了後に Range をリストから外せば Cooperative が有効化
• static membership（group.instance.id）併用で再バランス頻度自体も抑制可能

設定例（Java / properties）とリバランスリスナー

# Java Properties 例（ローリング移行: Cooperative を先頭、Range をフォールバック）
Properties props = new Properties();
props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "broker:9092");
props.put(ConsumerConfig.GROUP_ID_CONFIG, "orders-group");
props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
props.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG, java.util.List.of(
    org.apache.kafka.clients.consumer.CooperativeStickyAssignor.class.getName(),
    org.apache.kafka.clients.consumer.RangeAssignor.class.getName()
));
// optional: static membership で再バランス頻度を低減
// props.put(ConsumerConfig.GROUP_INSTANCE_ID_CONFIG, "orders-c1");

KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);

// Cooperative を意識した RebalanceListener
Map<TopicPartition, OffsetAndMetadata> currentOffsets = new HashMap<>();
ConsumerRebalanceListener listener = new ConsumerRebalanceListener() {
  @Override
  public void onPartitionsRevoked(Collection<TopicPartition> partitions) {
    // リボーク対象のみを同期コミット（必要に応じて明示コミットを分割）
    Map<TopicPartition, OffsetAndMetadata> toCommit = new HashMap<>();
    for (TopicPartition tp : partitions) {
      OffsetAndMetadata off = currentOffsets.get(tp);
      if (off != null) toCommit.put(tp, off);
    }
    if (!toCommit.isEmpty()) consumer.commitSync(toCommit);
  }
  @Override
  public void onPartitionsAssigned(Collection<TopicPartition> partitions) {
    // 必要に応じてシーク/再開処理を実装
  }
};

consumer.subscribe(java.util.List.of("orders"), listener);

# consumer.properties 例（同様の並び順）
# partition.assignment.strategy はカンマ区切りでクラス名を列挙
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor,org.apache.kafka.clients.consumer.RangeAssignor

CCDAK 対策の要点と実務チェック

試験では、戦略の『均等性』『再配置量』『再バランス方式（Eager/Cooperative）』と、『マルチトピック時の偏り（Range）』『購読集合が同じときに最も均等（RoundRobin）』『スティッキネス（Sticky 系）』が問われがちです。設定キー名（partition.assignment.strategy）と、複数候補を並べたときの選択ロジック（共通先頭）も押さえておきましょう。

実務では、低遅延・大規模 Group・状態付き処理では Cooperative-Sticky を基本選択肢にし、移行はローリングで。Range の既定値をそのまま使う場合でも、マルチトピックでの偏りを常に念頭に置き、メトリクスで消費遅延や負荷の偏りを監視するのが安全です。

• 覚えるフレーズ: 『Range はマルチトピックで偏る』『RoundRobin は同一購読集合で最均等』『Cooperative-Sticky は停止最小化』
• 設定問題: 共通でサポートされる戦略リストの先頭が採用される
• 運用: Cooperative では onPartitionsRevoked/Assigned の実装が品質を左右

問題で確認

よくある質問