元々、Kafka ブローカーのプラットフォーム・アップグレードは、手動的な監視と待機が必要で、数時間を要する退屈で時間のかかる作業でした。 これを改善するために、マルチゾーン・アーキテクチャーが導入され、複数のブローカーが同時に更新されることができ、可用性に影響を与えません。 ただし、Kubernetes のネイティブ・ローリング・アップデート・ストラテジーは、レプリカのゾナル分布のため適切ではありませんでした。
カスタム・ロジックが開発され、ゾーン内の複数のブローカーが同時に再起動されることを許可し、信頼性と誤ったデプロイメントの問題を防ぐために Kubernetes バッチ・ジョブとして実装されました。
プロダクションでのテストでは、並列性が 3 の場合、アップグレードが約 2 時間で完了することが示されました。 ただし、ゾーン内のすべてのブローカーを同時に再起動することは技術的に可能でしたが、残りのブローカーに対する負荷の増加を防ぐために避けられました。
マルチゾーン・アーキテクチャーとカスタム・アップデート・ロジックは、アップグレード時間を 7 時間から約 2 時間に大幅に短縮し、ストレスの軽減も実現しました。
新しいプロセスは、Kafka クラスターに対する影響を最小限度に抑えつつ、迅速かつ効率的なアップグレードを実現しました。 プロジェクトの成功は、アップグレードの時間の短縮にとどまらず、更新時のストレスの軽減も評価の基準となりました。
etsy.com
Adding Zonal Resiliency to Etsy’s Kafka Cluster: Part 2
