Rollback from KRaft mode to ZooKeeper mode

KRaft mode (finalization前) からZooKeeper modeへのロールバック方法に関する知見を共有します。

Transcript

1. © LY Corporation Rollback from KRaft mode to ZooKeeper mode LY Corporation (LINEヤフー株式会社) Tomohiro Warashina (和良品 友大)
2. © LY Corporation • KRaft mode (finalization前) からZooKeeper modeへのロールバック方法に関する知見を共有 • Finalization前では、ロールバック可能となっているが、検証した際にトラブルが発生し失敗 • トラブルの内容と原因、回避策、アップグレードする際に気を付けることを共有 What you will learn 2 Overview
3. © LY Corporation Agenda Overview Premise Symptom Observations Findings Root Cause Analysis Solutions Precautions for Migrating Back to KRaft Mode 3 Preliminaries Summary
4. © LY Corporation • ZooKeeper modeからKRaft modeへ移行するためには、2つの移行フェーズを経由してfinalizationする 必要がある • finalization後はロールバック不可 Our target is a KRaft cluster prior to the Finalization 4 Premise ZooKeeper Kafka Cluster (Brokers) ZooKeeper Kafka Cluster (Brokers) KRaft Controller Quorum ZooKeeper Kafka Cluster (Brokers) KRaft Controller Quorum ZooKeeper Kafka Cluster (Brokers) KRaft Controller Quorum Finalization ZooKeeper Mode KRaft Mode (Transitional Phase 1) KRaft Mode (Transitional Phase 2) KRaft Mode (Finalization)
5. © LY Corporation • 本発表は、最後のKRaft mode finalization前の状態からZooKeeper modeへのロールバックを想定 • 特にTransitional Phase1 → ZooKeeper Mode間のロールバックにフォーカスします Our target is a KRaft cluster prior to the Finalization Premise ZooKeeper Kafka Cluster (Brokers) ZooKeeper Kafka Cluster (Brokers) KRaft Controller Quorum ZooKeeper Kafka Cluster (Brokers) KRaft Controller Quorum ZooKeeper Kafka Cluster (Brokers) KRaft Controller Quorum Finalization ZooKeeper Mode KRaft Mode (Transitional Phase 1) KRaft Mode (Transitional Phase 2) KRaft Mode (Finalization)
6. © LY Corporation • KRaft mode finalization前のクラスタは、移行手順の逆順を行うことで、ZooKeeper Modeへのロール バックが可能となっている What happened? 6 Symptom ZooKeeper Kafka Cluster (Brokers) ZooKeeper Kafka Cluster (Brokers) KRaft Controller Quorum ZooKeeper Kafka Cluster (Brokers) KRaft Controller Quorum ZooKeeper Mode
7. © LY Corporation • KRaft mode finalization前のクラスタは、移行手順の逆順を行うことで、ZooKeeper Modeへのロール バックが可能となっている • しかし、ロールバック後、Partitionの状態を変化させる操作を行うと、クラスタ不整合が発生 What happened? 7 Symptom ZooKeeper Kafka Cluster (Brokers) ZooKeeper Kafka Cluster (Brokers) KRaft Controller Quorum ZooKeeper Kafka Cluster (Brokers) KRaft Controller Quorum ZooKeeper Mode
8. © LY Corporation Broker (id=3) 1台をサービス停止 (Graceful Shutdown) して、PartitionのISRを1つ減らした時の症状 • kafka-topics.sh --describeの出力では、サービス停止したid=3のBrokerが全PartitionのISRに参加していて、 Partition2のLeaderがnoneになっている • ZooKeeperからpartitionのstate情報を見ると、ISRは全て揃っていて、leaderはid=3のbroker What happened? 8 Symptom この不整合により、クラスタに接続しているProducerのデータ送信が停止
9. © LY Corporation • state-change.logを確認すると、TopicA-2に関する以下のエラーログが吐かれていた • エラーの内容は、 • Epoch 10のControllerが、TopicA partition2に対して状態変化させようとしたが、失敗した • 状態変化の内容は、leader electionを行って、offline状態からonlineへ変化させるというもの • 失敗理由は、過去によりepochの大きいcontroller (epoch 100) から操作を受けていて、その controllerが正しいと判断されてしまったため What was observed from logs? 9 Observations
10. © LY Corporation • state-change.logのエラーログを踏まえた上で改めてこの状態を見る • TopicA partition2の考えられる状況は、 • Id=3のbrokerでサービス停止 (Graceful Shutdown) が行われる • Epoch 10のcontrollerが、TopicA partition2の残りのISRに対してleader electionを実行 • しかし、過去にepoch 100のcontrollerから操作を受けていたせいで、leader electionの要求が跳ねら れ、Graceful Shutdownに失敗 • → Id=3のbrokerがunclean shutdownし、partition2のleaderがnoneになる • 一方、epoch 100のControllerからは何も指示が無く、ずっとnoneのままになる What was observed from logs? 10 Observations Epoch 100のControllerは何者?
11. © LY Corporation • Epoch: 複数台のleader (controller) から、activeなleader (controller) を判別するための世代番号 • 0から始まる単調増加変数で表現され、状態変化 (主にactive leaderを変更) した際に +1 される • Leaderは、epochを管理し、システムに対して操作する際に、リクエストに自身のepochを含める • システムは、操作を受ける度にleaderのepochを記録し、その値以上のleaderの操作のみ受け付ける • Kafkaでは、leaderやcontrollerがどのサーバかを判別するため、複数種類のepochを管理している What is Epoch? 11 Preliminaries Controller (Epoch 10) Controller (Epoch 100) TopicA-2 (Epoch 100)
12. © LY Corporation Kafkaには、controllerを管理するためのepochとして以下のものがある (epoch名は発表の便宜上付けたもの) • ZKMode Controller Epoch • ZooKeeper Mode時のControllerが扱うepoch • KRaft Controller Epoch • KRaft Mode時のepoch。ZKMode Controller Epochとは別のEpochとして管理されている • Partition Stored Epoch • 以下ZooKeeperの保存場所のstate内にある “controller_epoch” の値 • ControllerからPartition操作を受けると、そのcontrollerのepochに値が上書きされる。この変数は、 ZKModeとKRaft Mode両方のepochの値になりうる。(両者を区別しない) • ZooKeeperの保存場所: /brokers/topics/<topic名>/partitions/<partition番号>/state Controller Epoch 12 Findings
13. © LY Corporation Findings Controller Epoch 13 /kafka-root /brokers/topics/topicA/partitions/2/state /controller_epoch /migration Partition Stored Epoch ZKMode Controller Epoch KRaft Controller Epoch ZooKeeper topicA-2 Broker & Controller Broker Broker KRaft Controller KRaft Controller KRaft Controller KRaft Controller Quorum Kafka Cluster
14. © LY Corporation 各controller epochを確認すると、以下のようになっていた • ZKMode Controller Epoch: epochが10 • KRaft Controller Epoch: epochが100 • Partition Stored Epoch: 最後に操作を受けたcontrollerのepochが100 Controller Epoch 14 Findings Epoch 100は、ロールバックでサービス停止したKRaft controllerのepochであることが判明
15. © LY Corporation 各controller epochを確認すると、以下のようになっていた • ZKMode Controller Epoch: epochが10 • KRaft Controller Epoch: epochが100 • Partition Stored Epoch: 最後に操作を受けたcontrollerのepochが100 Controller Epoch 15 Findings クラスタ不整合について推測が立ったが、何故KRaft Controller Epochは ここまで大きな値になってしまったのか?
16. © LY Corporation • KRaft modeでは、Controller Quorumが過半数を下回ると、KRaft Controller Epochが急上昇する現象を 確認した • 過半数を下回ると、QuorumがDUAL_WRITE状態からINACTIVEになり、epochが1上昇する • 以降は、1 ~ 2秒毎に INACTIVE → INACTIVEの状態変化が起き、その度にepochが1上昇する • この事象が起きると「ZKMode Controller Epoch < KRaft Controller Epoch」が容易に満たされる Surge in KRaft Controller Epoch 16 Findings
17. © LY Corporation Root Cause Analysis What happened in the end? 17 ZooKeeper Kafka Cluster (Brokers) B B B KRaft Controller Quorum C C C 初期状態: KRaft ModeのKafkaクラスタ Controller Epoch Value ZKMode 10 KRaft 5 Partition 10
18. © LY Corporation Root Cause Analysis What happened in the end? 18 ZooKeeper Kafka Cluster (Brokers) B B B KRaft Controller Quorum C C C 検証の過程でquorumを過半数を下回ってしまい、KRaft Controller Epochが急上昇 Controller Epoch Value ZKMode 10 KRaft 5 → 100 Partition 10
19. © LY Corporation Root Cause Analysis What happened in the end? 19 ZooKeeper Kafka Cluster (Brokers) B B B KRaft Controller Quorum C C C 検証過程でbroker 1台のサービスを停止。PartitionのLeader変更等の状態変更を controllerが要求し、受理される。Partitionのepochが、要求を受理したcontroller (KRaft Controller) のepochで上書きされる。 Controller Epoch Value ZKMode 10 KRaft 100 Partition 10 → 100 ControllerがPartition の状態変更を要求 KRaft Controllerの要求を受け入れ、 そのEpochの値でPartitionのController Epochが上書きされる
20. © LY Corporation Root Cause Analysis What happened in the end? 20 ZooKeeper Kafka Cluster (Brokers) C B B KRaft Controller Quorum C C C KRaft Controller EpochがZKMode時のcontroller epochを上回った状態でロールバック Epochが100のcontrollerがサービスを停止し、実質的にcontroller不在の状態に Controller Epoch Value ZKMode 10 KRaft 100 Partition 100
21. © LY Corporation Root Cause Analysis What happened in the end? 21 ZooKeeper Kafka Cluster (Brokers) C B B 「ZKMode Controller Epoch <= Partition Stored Epoch」の状態で、 Partitionの状態を変更させるような操作 (例: Broker 1台のサービス停止) が実行される Controller Epoch Value ZKMode 10 KRaft 100 Partition 100
22. © LY Corporation Root Cause Analysis What happened in the end? 22 ZooKeeper Kafka Cluster (Brokers) C B B ZKMode Controllerからの要求は、古いcontrollerからの要求と見なされ棄却される これにより、クラスタ不整合が発生した Controller Epoch Value ZKMode 10 KRaft 100 Partition 100
23. © LY Corporation ZKmode Controller Epoch > Partition Stored Epochの場合 • 対応不要 それ以外の場合 • ZKmode Controller Epoch を KRaft Controller Epoch + 1以上で作り直し、controller electionを行う • Controller electionを行わないと、既存のcontrollerがローカルにキャッシュしているepochの情報を 使って、リクエストを送信してしまうため、epochをリロードさせるためにelectionを行う How can we prevent the issue? 23 Solutions
24. © LY Corporation Kafka公式ドキュメントのKRaftに関する説明が、3.9と3.9未満とで異なっているため注意 • 特に3.9のドキュメントにのみ書いてある/migrationの削除をしないと、ロールバック後、再度KRaft移行 する際に失敗するので注意 Note for Kafka < 3.9 operators 24 Precautions for Migrating Back to KRaft Mode 3.8 https://kafka.apache.org/38/operations/kraft/ 3.9 https://kafka.apache.org/39/operations/kraft/
25. © LY Corporation Kafka公式ドキュメントのKRaftに関する説明が、3.9と3.9未満とで異なっているため注意 • 特に3.9のドキュメントにのみ書いてある/migrationの削除をしないと、ロールバック後、再度KRaft移行 する際に失敗するので注意 • Kafka 3.9でいくつか新しいKRaft周りの設定が導入されていたりと、3.9未満と3.9で差があるため、単に 3.9のドキュメントを見るのではなく、3.9にアップグレードしてからKRaft移行することを推奨します • 弊チームは、管轄の全Kafkaクラスタを3.8 → 3.9にアップグレードを行った Note for Kafka < 3.9 operators 25 Precautions for Migrating Back to KRaft Mode
26. © LY Corporation • KRaft modeからZooKeeper modeにロールバックする際には、controller epochの値に注意する • 「ZKmode Controller Epoch <= Partition Stored Epoch」になっていた場合は、KRaft controller epoch+1以上の値で、Zkmode controller epochを作り直し、controller electionさせる • KRaft modeのクラスタをfinalizeするまで、KRaft Controller Quorumを過半数未満にしないように注意 • ドキュメントは3系最新の3.9のものを見るようにする • できることなら、クラスタも3.9にアップグレードしてからKRaft modeへ移行する Lessons learned 26 Summary
27. © LY Corporation End of Presentation Questions?