プロンプトとスコープ
あなたはクラシックグループプロトコルを使用しているステートフルなKafka Streamsアプリケーションを担当しています。Kafka 4.2へのアップグレード後、チームはインスタンスの参加、離脱、または障害発生時におけるグローバルな調整による停止（ポーズ）を削減するため、ブローカードリブンのStreams Rebalance Protocolの導入を望んでいます。面接官は移行計画、互換性の境界、およびロールバック手順を求めています。
Kafka Streams 4.2.x、既存のchangelogおよびrepartitionトピックが存在し、計画外のフルステート再構築は発生しない前提とします。公式ガイドによると、新プロトコルはブローカー上でタスク割り当てを継続的に計算し、専用のstreams groupを使用します。新しいKafka 4.2クラスターではこの機能がデフォルトで有効になっていますが、クライアント側では引き続きgroup.protocol=streamsを設定する必要があります。
面接官が評価するポイント
- 単に設定値を暗記して答えるのではなく、ブローカードリブンの調整がクライアント側のグローバルバリアをどのように排除するかを説明できるか。
- 新規streams groupの作成、オンラインでのクラシックグループアップグレード、サポートされているオフライン移行を明確に区別して理解しているか。
- ブローカーとクライアントのバージョン、および4.2.0におけるKAFKA-20254のリスクを確認しているか。
- コミット済みオフセットは保持される一方で、その他のグループメタデータは再構築されることを把握しているか。
- 未対応の静的メンバーシップ（static membership）、トポロジ更新、正規表現サポートの欠如をリリースの判定条件（ゲート）に組み込めるか。
不十分な回答例は「設定を変更してローリングアップデートする」というものです。優れた回答では、バージョンと機能のギャップを棚卸しし、新規グループ作成またはメンテナンスウィンドウでの移行を選択した上で、オフセット、changelog、repartitionトピック、および復旧目標を記録・管理します。
回答前に確認すべき事項
- KafkaとStreamsクライアントは両方とも4.2以上か？ そうでなければプロトコル全体を安全に有効化できません。
- アプリケーションは静的メンバーシップ、オンラインでのトポロジ更新、正規表現（regex）によるサブスクリプション、スタンバイ／ラック認識（rack-aware）割り当てに依存しているか？ これらのいずれかに依存していると移行がブロックされる可能性があります。
- グループが空になる間、すべてのインスタンスを停止できるか？ 公式の4.2のパスではオフライン移行のみがサポートされています。
- バージョンは4.2.0か、それとも4.2.1以降か？ 4.2.0にはオフライン移行に関する既知のブローカー側のバグがあり、4.2.1で修正されています。
- 新しい
application.idを使用できるか？ 新規グループを使用するとリスクを隔離できますが、状態が再構築され、オフセット管理が変わります。
これらの回答によって計画が変わります。ダウンタイムが許容されない場合はオンライン移行が可能だと主張してはならず、未サポートの機能が必要な場合はクラシックプロトコルに留まるか、事前にリファクタリングを行う必要があります。
30秒で答えるフレームワーク
「まずブローカーとクライアントが4.2.xであることを確認し、新プロトコルでサポートされていない機能を棚卸しします。Streams Rebalance Protocolはタスクの調整をブローカーに移し、クライアント側のグローバルバリアを排除しますが、移行は通常のローリングデプロイではありません。ドキュメント化されている手順では、グループを空にし、group.protocol=streamsを設定してインスタンスを起動します。保持されるのはコミット済みオフセットのみです。changelogとrepartitionトピックはそのまま残りますが、その他のグループメタデータは再構築されます。4.2.0は避けて4.2.1以降を採用し、オフセットと状態のチェックポイントを記録し、復旧、レイテンシ、リバランスのメトリクスを検証します。チェックに失敗した場合はクラシックに戻すか、新しいアプリケーションIDで再構築します。」
ステップごとの解決策
1. 何が変わるのかを説明する
クラシックなStreamsグループはクライアント上でメンバーのタスク割り当てを計算するため、メンバーシップの変更時にグローバルな調整ポイントが生じる可能性がありました。新プロトコルではstreams-groupのメタデータとタスク割り当てをブローカー上に保存し、アプリケーションは専用のハートビートとstreams groupを介して調整を行います。公式ガイドではこれをブローカードリブンと表現しており、独立したstreams-groupの状態とAdmin APIを提供しています。
2. 機能ギャップを棚卸しする
Kafka 4.2のドキュメントには明確な制限事項が記載されています。静的メンバーシップは使用不可、大幅なトポロジ更新には新しいstreams groupが必要、sticky task assignorのみがサポートされるためウォームアップタスクやラック認識割り当ては使用不可、パターン（正規表現）サブスクリプションは未サポート、そしてクラシックとstreams group間のオンライン移行は不可です。プロトコルを変更する前に、これらをリリースチェックリストに含めてください。
3. 移行パスを選択する
ドキュメント化されているオフライン手順は次のとおりです。すべてのインスタンスを停止し、session.timeout.msを待つか明示的に離脱してグループを空にし、group.protocol=streamsを設定してインスタンスを起動します。ブローカー上に保持されるのはコミット済みオフセットのみです。changelogおよびrepartitionトピックは通常の内部トピックとして残りますが、その他のグループメタデータは再構築されます。
Stop all instances
↓
Confirm an empty streams group and record committed offsets
↓
Upgrade brokers and clients to a compatible version
↓
Set group.protocol=streams
↓
Start instances and observe recovery and rebalance metricsメンテナンスウィンドウを設けることが不可能な場合は、クラシックプロトコルを維持するか、シャドー検証のために新しいapplication.idを使用してください。クラシックコンシューマーにおけるローリングアップグレードの前提をStreams Rebalance Protocolに当てはめてはなりません。
4. バージョンリスクに対処する
Kafkaのアップグレードガイドでは、4.2.0におけるクラシックからstreamsへのオフライン移行はブローカー側のバグKAFKA-20254の影響を受けるため推奨されないと警告されています。この修正は4.2.1に含まれています。面接では単に「Kafka 4.2がサポートしている」と言うのではなく、4.2.1を移行の最小バージョンとして提示してください。
5. 状態とオフセットの検証を設計する
移行前に、各入力トピックのコミット済みオフセット、changelogの状態、処理レイテンシを記録します。移行後は、新しいグループが期待されるオフセットから再開していること、ステートストアがchangelogから復元されていること、repartitionトピックが同じパーティション数で存在し続けていること、重複や欠落レコードが合意済みの処理セマンティクスに合致していることを検証します。プロセスの起動だけを確認するのではなく、移行前のベースラインと比較してください。
6. 監視とロールバック
streams-groupの状態、リバランスの回数/レート、復旧時間、処理レイテンシ、エラー率を監視対象（観測面）とします。復旧がタイムアウトした場合や結果のチェックが失敗した場合は、新しいグループを停止し、オフセットとログを保持して設定をクラシックに戻します。すでにクラシックグループが空になっていた場合、復旧にはバックアップまたは新しいアプリケーションIDが必要です。グループメタデータが魔法のように勝手に復元されることはありません。
質の高い模範回答
「私はこれを通常のローリングリリースとしては扱いません。まず4.2.xのブローカーとクライアントを確認し、静的メンバーシップ、オンラインでのトポロジ更新、正規表現サブスクリプション、ウォームアップ、またはラック認識割り当ての使用有無をチェックします。公式のパスはオフラインであるため、4.2.1以降を選択し、メンテナンスウィンドウですべてのインスタンスを停止してグループが空であることを確認し、コミット済みオフセットとステートストアのチェックポイントを記録した上で、group.protocol=streamsを設定します。
変更後は、オフセットが正しく引き継がれていること、changelogからステートストアが復元されること、repartitionトピックが維持されていること、そしてstreams-groupの状態、リバランスメトリクス、復旧時間、ビジネスレイテンシが健全であることを検証します。保持されるのはコミット済みオフセットのみであり、その他のグループメタデータは再構築されます。4.2.0にはKAFKA-20254のリスクがあるため、安全な移行バージョンとは呼びません。検証に失敗した場合は、新しいグループを停止してクラシックに戻すか、新しいアプリケーションIDで再構築し、原因究明のためにエビデンスを保持します。」
よくある間違い
- 間違い:
group.protocol=streamsをローリング切り替えとして扱う → 失敗する理由: オンライン移行はサポートされていない → 修正策: グループを空にするメンテナンスウィンドウをスケジュールする。 - 間違い: 4.2.0で移行する → 失敗する理由: 公式アップグレードガイドにKAFKA-20254が記録されている → 修正策: 修正済みの4.2.1以降を使用する。
- 間違い: すべてのグループ状態が保持されると請け負う → 失敗する理由: 残るのはコミット済みオフセットのみで、他のメタデータは再構築される → 修正策: オフセット、ステートストア、トピックのチェックを個別に記録する。
- 間違い: 静的メンバーシップやトポロジ更新を無視する → 失敗する理由: 新プロトコルではまだサポートされていない → 修正策: 機能を棚卸しし、必要に応じてクラシックに留まる。
フォローアップの質問と回答
業務を停止できません。2つのインスタンスバッチで段階的に切り替えることはできますか？
それをドキュメントで規定されたStreamsの移行として説明してはなりません。ダウンタイムが不可能な場合は、クラシックを維持するか、シャドー検証用に新しいアプリケーションIDを作成し、切り替えに伴う状態再構築のコストをビジネス層側で吸収してください。
コミット済みオフセットが残るのに、なぜステートストアを検証するのですか？
オフセットは次にどこから読み取るかを示すだけであり、ローカルの状態が完全であることを示すものではありません。changelogの再生、非互換性、または処理の失敗により、ステートストアがオフセットと不整合を起こす可能性があるため、状態とビジネス結果を検証する必要があります。
4.2.0はGA（一般提供）されています。なぜ避けるのですか？
GAはその機能がリリースされたことを意味しますが、すべての移行パスに既知の不具合がないことを意味するわけではありません。公式ガイドではオフライン移行におけるKAFKA-20254を特定しており、4.2.1で修正されたと記載されています。GAというラベルではなく、修正済みバージョンを選択してください。
アプリケーションが正規表現サブスクリプションを使用しています。どうすればよいですか？
新しいstreamsプロトコルはパターンベースのトピックサブスクリプションをサポートしていません。クラシックに留まるか、移行を再検討する前にディスカバリーを明示的なトピックリストに変更してください。グループプロトコルを変更するだけでは不十分です。
新しいアプリケーションIDを使用するかどうかはどのように判断しますか？
並行検証が必要な場合、古いグループを安全に空にできない場合、または状態復旧のリスクを隔離する必要がある場合に使用します。コストとして再処理、ステートストアの再構築、追加のリソースが発生するため、事前に復旧時間とストレージを見積もってください。
参考文献
- Apache Kafka Streams Rebalance Protocol 開発者ガイド
- Apache Kafka 4.2 Streams アップグレードガイド
- Apache Kafka 4.2.0 リリースアナウンス