Ajout de la résilience zonale au cluster Kafka d'Etsy : Partie 2

Initialement, les mises à niveau de la plateforme pour les brokers Kafka étaient fastidieuses et chronophages, nécessitant des heures de surveillance manuelle et d'attente. Pour améliorer cela, une architecture multi-zone a été mise en œuvre, permettant à plusieurs brokers d'être mis à jour simultanément sans affecter la disponibilité. Cependant, la stratégie de mise à jour en roulage native de Kubernetes n'était pas appropriée en raison de la distribution zonale des réplicas. Une logique personnalisée a été développée pour contrôler les mises à jour, permettant à plusieurs brokers dans une zone d'être redémarrés en parallèle. Cela a été mis en œuvre en tant que travail par lots Kubernetes pour garantir la fiabilité et prévenir les problèmes de déploiement accidentels. Les tests en production ont montré que, avec un parallélisme de trois, les mises à niveau pouvaient être terminées en environ deux heures. Bien que le redémarrage de tous les brokers dans une zone simultanément était techniquement possible, cela a été évité pour éviter d'accroître la charge sur les brokers restants. L'architecture multi-zone et la logique de mise à jour personnalisée ont considérablement réduit le temps de mise à niveau, passant de sept heures à environ deux heures. Cette amélioration n'a pas seulement économisé du temps, mais a également réduit la peine et le stress associés aux mises à niveau. Le nouveau processus a garanti des mises à niveau rapides et efficaces, avec un impact minimal sur le cluster Kafka. Le succès du projet a été mesuré non seulement par la réduction du temps, mais également par la facilité et la tranquillité d'esprit qu'il a apportée pendant les mises à niveau.