Flux transparents : maîtriser la migration de Kafka d’EC2 vers AWS MSK

Dans le monde de la gestion des données, les entreprises cherchent à rationaliser leurs opérations et à améliorer l’évolutivité. L’un des parcours clés consiste à migrer les clusters Apache Kafka autogérés d’AWS EC2 vers Amazon MSK. Nous avons exécuté une telle migration pour un client sans temps d’arrêt, offrant des informations et des stratégies dans ce blog.

Motivations derrière la migration

1. Limites d’évolutivité: La mise à l’échelle des clusters Kafka autogérés pour répondre à l’augmentation des volumes de données et des demandes de traitement était un défi, nécessitant une intervention manuelle pour déployer des instances EC2 supplémentaires, configurer les fichiers et rééquilibrer les partitions.

2. Frais généraux opérationnels : Le système Kafka autogéré nécessite des efforts humains et des connaissances importants pour être déployé, configuré et maintenu efficacement. Les correctifs de sécurité, les plans de surveillance et de sauvegarde ont ajouté à la charge administrative, détournant l’esprit des exigences réelles de l’entreprise.

3. Problèmes d’efficacité : Utilisation des ressources sous-utilisées et capacité surprovisionnée, entraîné des coûts inutiles et des inefficacités opérationnelles.

4. Problèmes de mise à niveau : La mise à niveau des versions de Kafka dans des environnements autogérés était difficile et fastidieuse, nécessitant une planification, des tests et une coordination minutieux pour minimiser le rayon d’explosion et garantir la compatibilité avec les applications et l’infrastructure existantes.

5. Raisons de sécurité et de conformité : Bien entendu, ne pas mettre à niveau le cluster Kafka a entraîné de nombreux problèmes de sécurité et de conformité. La version de Kafka était ancienne et présentait de nombreuses failles de sécurité.

Configuration existante et analyse des coûts

1. Configurations de cluster Kafka: La configuration incluse 15 Nœuds Kafka avec m5,2xlarge instances, totalisant environ 200 To d’espace disque. Version Apache Kafka : 0.8.2.
2. Configurations du nœud Zookeeper: 3 Nœuds Kafka Zookeeper, utilisant c5.xlarge instances avec des disques de 100 Go, géraient le cluster Kafka.
3. Facteur de réplication dans Kafka : Le facteur de réplication fait référence au nombre de copies conservées pour chaque partition de sujet Kafka dans le cluster. Dans notre configuration, chaque message dans Kafka a été triplé sur 3 courtiers, maintenant un RF de 3.
4. Coûts de transfert de données inter-AZ : L’architecture était répartie sur 3 AZ dans la région US-West-2 sur AWS pour une haute disponibilité. Cependant, AWS impose des frais de transfert de données inter-AZ pour la communication entre les courtiers Kafka situés dans différentes zones de disponibilité. L’architecture, conçue pour garantir la haute disponibilité, a entraîné par inadvertance des coûts de transfert de données inter-AZ substantiels, contribuant de manière significative aux dépenses mensuelles AWS.

Énoncé du problème

L’ajout de tous ces facteurs et infrastructures nous coûtait des dépenses mensuelles, totalisant environ 40 000 dollars américains. Le principal facteur de coût provenait des frais de transfert de données entre zones de disponibilité, reflétant le volume important de données échangées entre les courtiers Kafka dans les zones de disponibilité. Pour résoudre ce problème, nous avons envisagé la migration vers Amazon MSK pour bénéficier d’avantages tels qu’une haute disponibilité, une mise à l’échelle rapide et l’absence de frais de transfert de données entre les courtiers de différentes zones de disponibilité.

Questions ouvertes

• Quelles applications et autres ajustements sont nécessaires pour prendre en charge le nouveau cluster MSK ?
• Comment pouvons-nous garantir que les performances du cluster MSK répondent à nos exigences ?
• Quelles configurations MSK sont optimales pour les environnements de production et hors production ?
• Comment réinitialiser les décalages du pipeline de données au « premier » avant de lire à partir de MSK ?
• MSK nécessite-t-il une forme de préchauffage avant la transmission de données à grande échelle, tout comme les équilibreurs de charge dans AWS ?
• Quels plans de restauration devraient être mis en place si des problèmes surviennent après le passage à MSK ?

Bien que ces questions puissent varier en fonction de votre scénario spécifique, nous les aborderons de manière exhaustive tout au long de ce blog.

Diagramme de présentation de la migration

• Configuration existante
  
  

  Configuration AWS existante

• Pendant la migration
  
  

  Compte AWS pendant la migration

• Post-migration
  
  

  Après la migration du compte AWS

Plan de migration

1. Provisionner et configurer le cluster MSK: Nous avons commencé par mettre en place le cluster MSK dans des environnements inférieurs comme QA & dev. Configurez-le selon vos besoins, garantissant des performances, une sécurité et une évolutivité optimales. Pour déterminer le nombre approprié de courtiers pour votre cluster MSK et comprendre les coûts, consultez le Dimensionnement et prix MSK tableur. Cette feuille de calcul fournit une estimation du dimensionnement d’un cluster MSK et des coûts associés d’Amazon MSK par rapport à un cluster Apache Kafka similaire, autogéré et basé sur EC2.
2. Secrets et configurations Kafka mis à jour: Mise à jour d’AWS Secret Manager et des configurations dans les applications (consommatrices et productrices) pour pointer vers le cluster MSK nouvellement provisionné.
3. Test de performance: Nous avons effectué des tests de performances à l’aide de MirrorMaker pour valider les performances du cluster MSK. Évalué son débit, sa latence et son évolutivité dans diverses conditions de charge pour garantir qu’il répond aux exigences et aux attentes de notre organisation.
4. Valider la fonctionnalité de l’application: Testé minutieusement la fonctionnalité des applications déployées sur le cluster MSK. Vérification de l’ingestion, du traitement et de la communication des données entre les composants fonctionnant comme prévu.
5. Surveillance des performances du cluster MSK: Surveillez en permanence les performances du cluster MSK à l’aide d’outils tels qu’AWS CloudWatch et de solutions de surveillance personnalisées. Gardez un œil sur les indicateurs clés tels que le débit, la latence et les taux d’erreur pour identifier toute anomalie ou problème de performances.
6. Problèmes de dépannage: Résoudre activement les problèmes qui surviennent pendant le processus de déploiement et de validation.
7. Valider les résultats: Valider le déploiement et le fonctionnement réussi des applications sur le cluster MSK. Vérification que les journaux d’application sont exempts d’erreurs liées à Kafka et que les taux d’ingestion et de traitement des données répondent aux attentes.

Plan de tests de performances

Nous avons exploré la possibilité d’utiliser MirrorMaker pour répliquer les données de l’ancien cluster Kafka vers le nouveau cluster MSK. Bien que MirrorMaker puisse être utilisé pour tester les performances, il ne réplique pas les décalages, ce qui le rend inadapté au processus de migration réel.

Créateur de miroir :

Kafka MirrorMaker est un composant d’Apache Kafka qui facilite la réplication des données entre les clusters Kafka. Il permet la réplication de sujets d’un cluster Kafka à un autre. Nous avons utilisé Mirrormaker pour répliquer les données de l’environnement de production Kafka exécuté sur EC2 vers l’environnement de test AWS MSK et y avons pointé les applications de l’environnement de test. Cela nous a aidé à valider et tester la compatibilité des applications avec AWS MSK avec des données de production en temps réel.
Consultez ce blog pour plus d’informations sur Mirrormaker : https://www.tothenew.com/blog/mirror-maker-for-kafka-migration/

Retard du consommateur:

• La différence entre la façon dont les producteurs placent les enregistrements sur les courtiers et le moment où les consommateurs lisent ces messages.

Nous avons utilisé l’outil Consumer Offset Checker pour calculer et surveiller le décalage du consommateur pour chaque partition d’un sujet et avons tracé le décalage sur cloudwatch, aidant ainsi à identifier les goulots d’étranglement potentiels ou les problèmes de performances dans le traitement du consommateur. Ici se trouve le Script Python pour calculer le décalage du consommateur.

Nous avons automatisé l’exécution du script Python à l’aide de Jenkins et AWS SSM, en utilisant une tâche cron planifiée pour une intégration transparente dans notre flux de travail. Cette automatisation nous a permis d’exécuter le script à des intervalles prédéfinis. Lié à Fichier Jenkins. Nous avons créé un tableau de bord Cloudwatch avec le décalage des consommateurs pour tous les sujets.

Tableau de bord Cloudwatch-1

Tableau de bord Cloudwatch – 2

Après avoir vérifié les données entre les environnements de production et d’intégration sur différentes périodes, il est devenu évident que les applications étaient capables à la fois de produire et de consommer des données. Une fois l’intégrité et la fonctionnalité des données confirmées, nous avons procédé au processus de basculement dans l’environnement de production.

Post-migration et nettoyage

Une fois la migration terminée, plusieurs tâches post-migration sont nécessaires pour assurer une transition en douceur et nettoyer toutes les ressources résiduelles :

• Mettez à jour les configurations de l’application et supprimez les références à l’ancien cluster Kafka.
• Validez l’intégrité et la cohérence des données entre les applications.
• Mettez hors service les anciens clusters Kafka et les ressources associées.
• Surveillez les performances du cluster MSK en production et effectuez les ajustements nécessaires.

Conclusion

La migration de Kafka d’EC2 vers AWS MSK offre plusieurs avantages, notamment une gestion simplifiée, une évolutivité et une fiabilité. En suivant un plan de migration structuré et en tenant compte des considérations clés, les organisations peuvent transférer en toute transparence leurs charges de travail Kafka vers AWS MSK et libérer tout le potentiel du streaming de données en temps réel sur le cloud. Un partenariat avec un fournisseur de services cloud gérés qui peut vous aider à choisir le bon chemin de migration est un moyen de surmonter ce type de défis de migration.

Nous à AU NOUVEAU fournissez une migration simplifiée vers le cloud AWS en suivant les activités ci-dessus pour déployer la solution pour vous. Un fournisseur de services gérés dans le cloud peut également vous aider à gérer la solution et à assurer la sauvegarde et la reprise après sinistre de votre entreprise. AUX NOUVEAUX architectes et ingénieurs DevOps certifiés AWS peut vous aider à économiser du temps et des ressources et à accroître l’efficacité de votre entreprise.

Les références

VOUS TROUVEZ CECI UTILE ? PARTAGEZ-LE