プロンプトとコンテキスト
マルチテナントのKafkaクラスターが現在もZooKeeperで稼働しています。チームはKRaftへ移行し、Kafka 4.2へアップグレードすることを望んでいます。このクラスターはトランザクショナルプロデューサー、Kafka Streams、Connectを使用しており、メッセージの損失、コミットの重複、長時間の停止を許容できません。事前チェック、ローリングアップグレード、metadata-versionのゲート、クライアントの互換性、障害復旧、およびロールバックを設計してください。
面接官がテストするポイント
- Kafka 4.2を通常のブローカー置き換えとして扱うのではなく、KRaft専用（KRaft-only）であることを認識しているか。
- ソフトウェアバージョン、
metadata.version、および移行状態を分離して管理できているか。 - 4.2.0におけるStreamsのオフライン移行およびトランザクショナルプロデューサーのアップグレードに関する修正を考慮し、4.2.1を選択しているか。
- 検証において、コントローラー、ブローカー、クライアント、Connect、Streamsを網羅できているか。
- ロールバックがサポートされるタイミングと、メタデータの変更により前方復旧（フォワードリカバリ）が必要になるタイミングを把握しているか。
明確にすべき質問
- Kafka、ZooKeeper、クライアント、Streamsのバージョンは何であり、それらはKRaft移行の前提条件を満たしていますか？
- トランザクションの冪等性、トランザクションのタイムアウト、および未完了のトランザクションはどのように監視されていますか？
- リージョン間レプリケーション、MirrorMaker、または検証済みのリカバリ用クラスターは存在しますか？
- ワークロードはStreams Rebalance Protocol、Share Groups、またはその他の4.2機能を使用していますか？
- ビジネス側で許容できるローリングウィンドウ、コンシューマーのリバランス、およびロールバック時間はどれくらいですか？
30秒の回答
私は4.2をアーキテクチャの移行として扱います。ZooKeeperクラスターはアップグレードする前にKRaftへ移行する必要があります。4.2.0のStreamsオフライン移行の不具合とトランザクショナルプロデューサーのローリングアップグレードの問題を回避するため、ターゲットには4.2.1を採用します。移行前にリスクの高い変更を凍結し、クライアント、トランザクション、Streamsの状態、リカバリ用レプリカのインベントリを作成します。まずソフトウェアをローリング方式で更新し、挙動とパフォーマンスを監視した上で、metadata.versionを別途引き上げます。各ステップで、エンドツーエンドのメッセージ、トランザクションのコミット、コンシューマーラグ、コントローラークォーラム、Streamsの状態を確認します。問題が発生した場合はメタデータのアクティベーション前に停止するか、メタデータの変更を可逆的なスイッチとして扱うのではなく、サポートされている互換パスを通じて復旧します。
ステップごとの詳細解説
1. バージョンと状態のマトリクスを作成する
Kafka 4.2はKRaftのみをサポートしているため、まずZooKeeperモードを移行する必要があります。ソフトウェアバージョン、メタデータバージョン、コントローラークォーラムの状態は独立した次元です。前提条件を確認し、ブローカー、コントローラー、クライアント、Connect、Streams、およびプロトコルのバージョンを監査可能なチェックリストに記録します。
ZooKeeper -> KRaft migration -> rolling broker/controller upgrade -> verify -> raise metadata.version
| | | |
+-- blocked --+----------------------+----------> stop and recover2. 修正済みバージョンと順序を選択する
ターゲットとして4.2.1を使用します。公式アップグレードガイドには、UnsupportedVersionExceptionを生成する可能性があったトランザクショナルプロデューサーのローリングアップグレードに対する修正と、Streams Rebalance Protocolのオフライン移行の不具合に対する修正が記載されています。4.2.0で影響を受けるclassicからstreams groupへの移行を実行すべきではありません。まずツールとクライアントマトリクスをアップグレードし、その後複数の障害ドメインを同時に変更することを避けるため、ブローカーを1台ずつローリング更新します。
3. メタデータとコントローラーの変更をゲートで制御する
ローリングソフトウェアアップグレードの後、kafka-features.shを使用してmetadata.versionを引き上げる前に、クラスターの挙動とパフォーマンスを観察します。ゲートには、コントローラークォーラムの安定性、リーダー選出、メタデータ伝播レイテンシ、ISR、ディスクの健全性が含まれます。Kafka 4.2にはメタデータの変更がない場合のダウングレードサポートが記載されていますが、ターゲットバージョンごとに独自のメタデータ互換性チェックが必要です。
4. トランザクション、Streams、Connectを検証する
トランザクションテストでは、プロデューサーエポック、コミット、アボート、再起動、重複、タイムアウトを対象とします。Streamsテストでは、状態ストアの復元、リバランス、チェンジログ、処理セマンティクス、オフライン移行パスを対象とします。Connectテストでは、オフセット、タスクの再起動、外部システムの冪等性を対象とします。ブローカーの健全性だけでは不十分であるため、クライアントクラスごとにエンドツーエンドの送受信チェックを実行します。
5. 障害を観察・リハーサルする
コントローラーの選出、メタデータバージョン、ブローカーのエラー、リクエストの失敗、トランザクションの状態、コンシューマーラグ、Streamsの復元、Connectタスク、ディスクの増加を記録します。ブローカーの再起動、コントローラーの喪失、中断されたトランザクション、Streams移行の失敗、互換性のないクライアントをリハーサルします。各シナリオにはアップグレード停止条件とリカバリ条件が必要です。
6. ロールバックとリカバリの境界を定義する
metadata.versionを引き上げる前に、古いバイナリ、設定、スナップショット、およびリカバリクラスターを保持し、読み取り専用の検証ウィンドウを定義します。ローリングアップグレードの失敗時は、互換性のあるバージョンで停止してブローカーを復元できます。サポートされていないメタデータの変更が発生した場合、ロールバックは互換スナップショットからの復元または新規クラスターの再構築となるため、バイナリの強制ダウングレードは行わないでください。スループットを回復する前に、トランザクションとオフセットの整合性を維持します。
模範解答
まず、これが日常的なバージョンアップグレードではないことを示します。Kafka 4.2ではZooKeeperのサポートが削除されているため、既存のクラスターはKRaftへ移行する必要があります。公式ガイドにトランザクショナルプロデューサーのローリングアップグレードおよびStreamsのオフライン移行に関する修正が記載されていることから、4.2.1を選択します。事前にブローカー、コントローラー、クライアント、Connect、Streams、トランザクション、リカバリレプリカをバージョン/状態マトリクスにリストアップします。
ブローカーを1台ずつローリング更新し、コントローラークォーラム、ISR、レイテンシ、挙動を検証した上で、metadata.versionを引き上げます。トランザクションテストではエポック、コミット、アボート、再起動、重複を網羅し、Streamsテストでは状態ストア、チェンジログ、リバランス、移行を網羅し、Connectテストではオフセットとタスクの復旧を網羅します。メタデータバージョン、選出、ラグ、エラーを記録します。メタデータ変更前の障害は互換性のある段階で停止できます。サポートされていないメタデータ変更後は、バイナリを強制ダウングレードするのではなく、スナップショットまたはリカバリクラスターから再構築します。
よくある間違い
- KRaftへの移行を行わずに、ZooKeeperブローカーを直接Kafka 4.2に置き換える。
- トランザクション、Streamsの状態、Connectのオフセット、エンドツーエンドのメッセージを確認せず、ブローカーの生存確認のみを行う。
- ローリングソフトウェアアップグレードの直後に
metadata.versionを引き上げる。 - 既知のリスクがあるStreamsのオフライン移行を4.2.0で実行する。
metadata.versionを、常にダウングレード可能な通常の設定項目として扱う。- リカバリクラスター、スナップショット、または明確なアップグレード停止ゲートを用意していない。
フォローアップの質問と回答
なぜZooKeeperクラスターを直接Kafka 4.2へアップグレードできないのですか？
Kafka 4.2はKRaft専用であり、ZooKeeperモードが削除されたためです。4.2のローリングアップグレードパスに進む前に、クラスターの移行とコントローラークォーラムの検証を完了しておく必要があります。
metadata.versionはいつ引き上げるべきですか？
すべてのブローカー/コントローラーのソフトウェアがアップグレードされて安定し、クォーラム、ISR、クライアントエラー、パフォーマンスが合格した後に引き上げます。個別に引き上げることで、コードの問題とプロトコルのアクティベーションを区別できます。
メタデータのアクティベーション後にStreamsの状態復元が失敗した場合はどうしますか？
さらなる機能のアクティベーションを停止し、証拠とログを保持して、サポートされているスナップショットまたは再構築パスから復旧します。チェンジログを削除したり、バイナリのダウングレードを強制したりして不整合を隠蔽してはなりません。