Il s'agit d'un article co-écrit avec Rivlin Pereira et Vaibhav Pandey de Tanzu CloudHealth (VMware by Broadcom).

VMware Tanzu CloudHealth est la plateforme de gestion des coûts cloud de choix pour plus de 20,000 2.0 organisations dans le monde, qui s'appuient sur elle pour optimiser et gouverner leurs environnements multi-cloud les plus vastes et les plus complexes. Dans cet article, nous expliquons comment l'équipe DevOps de VMware Tanzu CloudHealth a migré ses charges de travail Apache Kafka autogérées (exécutant la version XNUMX) vers Amazon Managed Streaming pour Apache Kafka (Amazon MSK) exécutant la version 2.6.2. Nous discutons des architectures système, des pipelines de déploiement, de la création de sujets, de l'observabilité, du contrôle d'accès, de la migration des sujets et de tous les problèmes auxquels nous avons été confrontés avec l'infrastructure existante, ainsi que de comment et pourquoi nous avons migré vers la nouvelle configuration Kafka et de quelques leçons apprises.

Présentation du cluster Kafka

Dans le paysage en évolution rapide des systèmes distribués, la plate-forme de microservices de nouvelle génération de VMware Tanzu CloudHealth s'appuie sur Kafka comme épine dorsale de messagerie. Pour nous, le système de journalisation distribué hautes performances de Kafka excelle dans la gestion de flux de données massifs, ce qui le rend indispensable pour une communication transparente. En tant que système de journaux distribués, Kafka capture et stocke efficacement divers journaux, des journaux d'accès au serveur HTTP aux journaux d'audit des événements de sécurité.

La polyvalence de Kafka brille dans la prise en charge de modèles de messagerie clés, en traitant les messages comme des journaux de base ou des magasins de valeurs-clés structurés. Un partitionnement dynamique et un classement cohérent garantissent une organisation efficace des messages. La fiabilité inébranlable de Kafka s'aligne sur notre engagement envers l'intégrité des données.

L'intégration des services Ruby avec Kafka est rationalisée via la bibliothèque Karafka, agissant comme un wrapper de niveau supérieur. Nos autres services de pile de langage utilisent des wrappers similaires. Les fonctionnalités de débogage et les commandes d'administration robustes de Kafka jouent un rôle essentiel pour garantir le bon fonctionnement et la santé de l'infrastructure.

Kafka comme pilier architectural

Dans la plateforme de microservices de nouvelle génération de VMware Tanzu CloudHealth, Kafka apparaît comme un pilier architectural essentiel. Sa capacité à gérer des débits de données élevés, à prendre en charge divers modèles de messagerie et à garantir que la livraison des messages s'aligne parfaitement sur nos besoins opérationnels. Alors que nous continuons à innover et à évoluer, Kafka reste un compagnon fidèle, nous permettant de construire une infrastructure résiliente et efficace.

Pourquoi nous avons migré vers Amazon MSK

Pour nous, la migration vers Amazon MSK se résumait à trois points de décision clés :

• Opérations techniques simplifiées – Exécuter Kafka sur une infrastructure autogérée représentait pour nous une surcharge opérationnelle. Nous n'avions pas mis à jour la version 2.0.0 de Kafka depuis un certain temps, et les courtiers Kafka tombaient en production, ce qui entraînait des problèmes de mise hors ligne des sujets. Nous avons également dû exécuter des scripts manuellement pour augmenter les facteurs de réplication et rééquilibrer les leaders, ce qui représentait un effort manuel supplémentaire.
• Pipelines hérités obsolètes et autorisations simplifiées – Nous cherchions à nous éloigner de nos pipelines existants écrits en Ansible pour créer des sujets Kafka sur le cluster. Nous avions également un processus fastidieux consistant à donner aux membres de l'équipe l'accès aux machines Kafka lors de la préparation et de la production, et nous voulions simplifier cela.
• Coût, correctifs et support - Car gardien de zoo Apache est entièrement géré et corrigé par AWS, le passage à Amazon MSK allait nous faire gagner du temps et de l'argent. De plus, nous avons découvert que l'exécution d'Amazon MSK avec le même type de courtiers sur Cloud de calcul élastique Amazon (Amazon EC2) était moins cher à exécuter sur Amazon MSK. Combiné au fait que AWS applique des correctifs de sécurité sur les courtiers, la migration vers Amazon MSK a été une décision facile. Cela signifiait également que l’équipe était libre de travailler sur d’autres choses importantes. Enfin, l'obtention du support d'entreprise d'AWS a également été essentielle dans notre décision finale de passer à une solution gérée.

Comment nous avons migré vers Amazon MSK

Une fois les principaux facteurs identifiés, nous avons avancé avec une proposition de conception visant à migrer Kafka autogéré existant vers Amazon MSK. Nous avons effectué les étapes de pré-migration suivantes avant la mise en œuvre effective :

• Évaluation:
  • Réalisation d'une évaluation méticuleuse du cluster EC2 Kafka existant, en comprenant ses configurations et ses dépendances
  • Compatibilité vérifiée de la version Kafka avec Amazon MSK
• Configuration d'Amazon MSK avec Terraform
• Configuration du réseau:
  • Connectivité réseau transparente garantie entre les clusters EC2 Kafka et MSK, réglage fin des groupes de sécurité et des paramètres de pare-feu

Après les étapes de pré-migration, nous avons implémenté les éléments suivants pour la nouvelle conception :

• Pipelines automatisés de déploiement, de mise à niveau et de création de sujets pour les clusters MSK :
  • Dans la nouvelle configuration, nous souhaitions automatiser les déploiements et les mises à niveau des clusters MSK de manière reproductible à l'aide d'un outil IaC. Par conséquent, nous avons créé des modules Terraform personnalisés pour les déploiements de clusters MSK ainsi que les mises à niveau. Ces modules ont été appelés depuis un Jenkins pipeline pour les déploiements et les mises à niveau automatisés des clusters MSK. Pour la création de sujets Kafka, nous utilisions un pipeline développé en interne basé sur Ansible, qui n'était pas stable et a suscité de nombreuses plaintes de la part des équipes de développement. En conséquence, nous avons évalué les options de déploiement pour Kubernetes clusters et utilisé le Opérateur de sujet Strimzi pour créer des sujets sur les clusters MSK. La création de sujets a été automatisée à l'aide de pipelines Jenkins, que les équipes de développement pouvaient mettre en libre-service.
• Meilleure observabilité pour les clusters :
  • Les anciens clusters Kafka n'avaient pas une bonne observabilité. Nous n'avons eu que des alertes sur la taille du disque du courtier Kafka. Avec Amazon MSK, nous avons profité de surveillance ouverte en utilisant Prométhée. Nous avons mis en place un serveur Prometheus autonome qui récupérait les métriques des clusters MSK et les envoyait à notre outil d'observabilité interne. Grâce à une observabilité améliorée, nous avons pu configurer des alertes robustes pour Amazon MSK, ce qui n'était pas possible avec notre ancienne configuration.
• COGS amélioré et meilleure infrastructure de calcul :
  • Pour notre ancienne infrastructure Kafka, nous avons dû payer pour la gestion des instances Kafka et Zookeeper, ainsi que pour les coûts supplémentaires de stockage du courtier et de transfert de données. Avec le passage à Amazon MSK, comme Zookeeper est entièrement géré par AWS, nous n'avons à payer que les nœuds Kafka, le stockage du courtier et les coûts de transfert de données. En conséquence, lors de la configuration finale d'Amazon MSK pour la production, nous avons économisé non seulement sur les coûts d'infrastructure, mais également sur les coûts opérationnels.
• Opérations simplifiées et sécurité renforcée :
  • Avec le passage à Amazon MSK, nous n'avons plus eu à gérer d'instances Zookeeper. Les correctifs de sécurité des courtiers ont également été pris en charge par AWS pour nous.
  • Les mises à niveau des clusters sont devenues plus simples avec le passage à Amazon MSK ; c'est un processus simple à lancer à partir de la console Amazon MSK.
  • Avec Amazon MSK, nous avons un courtier mise à l'échelle automatique hors de la boîte. En conséquence, nous n'avons pas eu à nous soucier du manque d'espace disque des courtiers, ce qui a conduit à une stabilité supplémentaire du cluster MSK.
  • Nous avons également bénéficié d'une sécurité supplémentaire pour le cluster, car Amazon MSK prend en charge le chiffrement au repos par défaut et diverses options de chiffrement en transit sont également disponibles. Pour plus d'informations, reportez-vous à Protection des données dans Amazon Managed Streaming pour Apache Kafka.

Au cours de nos étapes de pré-migration, nous avons validé la configuration sur l'environnement de test avant de passer à la production.

Stratégie de migration de sujets Kafka

Une fois la configuration du cluster MSK terminée, nous avons effectué une migration des données des sujets Kafka de l'ancien cluster exécuté sur Amazon EC2 vers le nouveau cluster MSK. Pour y parvenir, nous avons effectué les étapes suivantes :

• Configurer MirrorMaker avec Terraform – Nous avons utilisé Terraform pour orchestrer le déploiement d’un MiroirMaker cluster composé de 15 nœuds. Cela a démontré l'évolutivité et la flexibilité en ajustant le nombre de nœuds en fonction des besoins de réplication simultanée de la migration.
• Mettre en œuvre une stratégie de réplication simultanée – Nous avons mis en œuvre une stratégie de réplication simultanée avec 15 nœuds MirrorMaker pour accélérer le processus de migration. Notre approche basée sur Terraform a contribué à l'optimisation des coûts en gérant efficacement les ressources pendant la migration et a assuré la fiabilité et la cohérence des clusters MSK et MirrorMaker. Il a également montré comment la configuration choisie accélère le transfert de données, optimisant à la fois le temps et les ressources.
• Migrer des données – Nous avons réussi à migrer 2 To de données dans un délai remarquablement court, minimisant les temps d'arrêt et démontrant l'efficacité de la stratégie de réplication simultanée.
• Mettre en place une surveillance post-migration – Nous avons mis en œuvre une surveillance et des alertes robustes pendant la migration, contribuant ainsi à un processus fluide en identifiant et en résolvant les problèmes rapidement.

Le diagramme suivant illustre l'architecture une fois la migration des sujets terminée.

Défis et leçons apprises

Se lancer dans un voyage de migration, en particulier avec de grands ensembles de données, s'accompagne souvent de défis imprévus. Dans cette section, nous examinons les défis rencontrés lors de la migration de sujets d'EC2 Kafka vers Amazon MSK à l'aide de MirrorMaker, et partageons des informations et des solutions précieuses qui ont façonné le succès de notre migration.

Défi 1 : Compenser les écarts

L'un des défis que nous avons rencontrés était l'inadéquation des décalages de sujets entre les clusters source et de destination, même avec la synchronisation des décalages activée dans MirrorMaker. La leçon apprise ici est que les valeurs de décalage ne doivent pas nécessairement être identiques, tant que la synchronisation de décalage est activée, ce qui garantit que les sujets ont la bonne position pour lire les données.

Nous avons résolu ce problème en utilisant un outil personnalisé pour exécuter des tests sur des groupes de consommateurs, confirmant que les décalages traduits étaient soit plus petits, soit rattrapés, indiquant une synchronisation selon MirrorMaker.

Défi 2 : migration lente des données

Le processus de migration s'est heurté à un goulot d'étranglement : le transfert de données a été plus lent que prévu, en particulier avec un ensemble de données important de 2 To. Malgré un cluster MirrorMaker de 20 nœuds, la vitesse était insuffisante.

Pour surmonter ce problème, l'équipe a regroupé stratégiquement les nœuds MirrorMaker en fonction de numéros de port uniques. Des clusters de cinq nœuds MirrorMaker, chacun doté d'un port distinct, ont considérablement augmenté le débit, nous permettant de migrer les données en quelques heures au lieu de quelques jours.

Défi 3 : Manque de documentation détaillée des processus

Naviguer sur le territoire inexploré de la migration de grands ensembles de données à l'aide de MirrorMaker a mis en évidence l'absence de documentation détaillée pour de tels scénarios.

Par essais et erreurs, l'équipe a conçu un module IaC à l'aide de Terraform. Ce module a rationalisé l'ensemble du processus de création de cluster avec des paramètres optimisés, permettant un démarrage transparent de la migration en quelques minutes.

Configuration finale et prochaines étapes

À la suite du passage à Amazon MSK, notre configuration finale après la migration des sujets ressemblait au diagramme suivant.

Nous envisageons les améliorations futures suivantes :

Conclusion.

Dans cet article, nous avons expliqué comment VMware Tanzu CloudHealth a migré son infrastructure Kafka existante basée sur Amazon EC2 vers Amazon MSK. Nous vous avons présenté la nouvelle architecture, les pipelines de déploiement et de création de sujets, les améliorations de l'observabilité et du contrôle d'accès, les défis de migration de sujets et les problèmes auxquels nous avons été confrontés avec l'infrastructure existante, ainsi que comment et pourquoi nous avons migré vers la nouvelle configuration Amazon MSK. Nous avons également parlé de tous les avantages qu'Amazon MSK nous a apportés, de l'architecture finale que nous avons obtenue avec cette migration et des leçons apprises.

Pour nous, l'interaction de la synchronisation offset, du regroupement de nœuds stratégiques et de l'IaC s'est avérée essentielle pour surmonter les obstacles et garantir une migration réussie d'Amazon EC2 Kafka vers Amazon MSK. Cet article témoigne du pouvoir de l’adaptabilité et de l’innovation face aux défis migratoires, offrant des informations à ceux qui empruntent un chemin similaire.

Si vous utilisez Kafka autogéré sur AWS, nous vous encourageons à essayer l'offre Kafka gérée, AmazonMSK.

À propos des auteurs

Rivlin Pereira est ingénieur DevOps chez VMware Tanzu Division. Il est très passionné par Kubernetes et travaille sur la création et l'exploitation de la plateforme CloudHealth pour des solutions cloud évolutives, fiables et rentables.

Vaibhav Pandey, ingénieur logiciel chez Broadcom, est un contributeur clé au développement de solutions de cloud computing. Spécialisé dans l'architecture et l'ingénierie des couches de stockage de données, il est passionné par la création et la mise à l'échelle d'applications SaaS pour des performances optimales.

Raj Ramasubbu est un architecte senior de solutions spécialisées dans l'analytique, spécialisé dans le big data et l'analytique et l'IA/ML avec Amazon Web Services. Il aide les clients à concevoir et à créer des solutions basées sur le cloud hautement évolutives, performantes et sécurisées sur AWS. Raj a fourni une expertise technique et un leadership dans la création de solutions d'ingénierie de données, d'analyse de données volumineuses, d'intelligence d'affaires et de science des données pendant plus de 18 ans avant de rejoindre AWS. Il a aidé des clients dans divers secteurs verticaux tels que la santé, les dispositifs médicaux, les sciences de la vie, la vente au détail, la gestion d'actifs, l'assurance automobile, les FPI résidentielles, l'agriculture, l'assurance titres, la chaîne d'approvisionnement, la gestion de documents et l'immobilier.

Todd McGrath est un spécialiste du streaming de données chez Amazon Web Services où il conseille les clients sur leurs stratégies, intégrations, architectures et solutions de streaming. Sur le plan personnel, il aime regarder et soutenir ses 3 adolescents dans leurs activités préférées ainsi que suivre ses propres activités telles que la pêche, le pickleball, le hockey sur glace et les XNUMX à XNUMX entre amis et en famille sur des bateaux pontons. Connectez-vous avec lui sur LinkedIn.

Satya Pattanaik est architecte de solutions senior chez AWS. Il aide les éditeurs de logiciels indépendants à créer des applications évolutives et résilientes sur le cloud AWS. Avant de rejoindre AWS, il a joué un rôle important dans les segments Entreprises dans leur croissance et leur succès. En dehors du travail, il passe du temps à apprendre « à cuisiner un barbecue savoureux » et à essayer de nouvelles recettes.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://aws.amazon.com/blogs/big-data/how-vmware-tanzu-cloudhealth-migrated-from-self-managed-kafka-to-amazon-msk/