Comment Amazon MSK nous a aidés à arrêter le babysitting kafka

Introduction

Pendant des années, nous avons utilisé Kafka dans le centre de données, puis nous avons déménagé dans AWS et avons commencé à utiliser EC2 pour exécuter Kafka. Cependant, les maux de tête ont augmenté avec notre utilisation. Nous avons commencé à avoir l’impression de passer plus de temps à gérer Kafka que de créer quoi que ce soit de valeur en raison de Mises à niveau des courtiers, problèmes de gardien de zoo, partitions déséquilibrées et frais de transfert de données croisés.

Migration vers AWS MSK

Par conséquent, nous avons essayé Amazon MSK pour voir si cela pourrait vraiment faciliter la vie plutôt que de simplement servir de remplacement sans rendez-vous. Alerte de spoiler: c’est le cas. Cependant, cela nous a également pris de surprise de manière inattendue. Si vous voulez savoir comment nous avons migré de Kafka sur EC2 à AWS MSK, consultez ceci bloguer. Dans ce blog, je discuterai brièvement des avantages de la migration vers AWS MSK. Commençons!

Pourquoi nous avons migré vers AWS MSK?

Notre objectif était simple:

• Arrêtez de gérer Kafka manuellement
• Maintenir un accès complet aux API Kafka (pas d’emballages étranges)
• Améliorer la stabilité et, surtout, réduire les coûts.

MSK a coché toutes les cases. Il gère l’approvisionnement en courtier, le correctif et le gardien de zoo (oui, toujours requis pour l’instant). Nous n’avions pas du tout à changer nos producteurs ou nos consommateurs. Mais ce qui s’est démarqué, c’est ce à quoi nous ne nous attendions pas.

Ce qui nous a surpris (dans le bon sens)

1. Sensibilisation du rack = Économies de coûts réels

Lorsque nous avons activé la sensibilisation au rack dans MSK, nos consommateurs de DME ont commencé à tirer des données des courtiers dans le même AZ. Cela signifiait moins de trafic croisé, et cela signifiait des factures plus basses. Nous avons sauvé près de 100 $ une journée juste à partir de cette configuration. C’était facile et sauvage à la fois. La plupart des gens manquent cela. Il est enterré dans les paramètres, mais cela fait une énorme différence. Consultez ce blog pour savoir comment nous avons permis la sensibilisation à la rack.

2. Les métriques CloudWatch ont aidé

Nous avons tous vu des grappes de mesures aléatoires et les avons ignorées. Mais nous avons pris le temps de configurer des tableaux de bord à l’aide de journaux CloudWatch et OpenSearch, et cela a payé. Nous avons suivi des choses comme:

• Le retard du consommateur (ce qui nous a aidés à repérer les emplois lents tôt)
• Déséquilibre de partition
• CPU du courtier, mémoire, réseau et utilisation du disque
  

  cloudwatch_dashboard

Un tableau de bord nous a aidés à assister à un sujet mal configuré qui enregistrait beaucoup trop et à manger du rangement. Nous n’aurions pas su autrement.

3. Configurations personnalisées sans le désordre

Nous avons été habitués à faire des nœuds Kafka pour modifier les fichiers de configuration et redémarrer les courtiers de manière redémarrée. Avec MSK, nous n’avons pas eu à le faire. Il vous permet d’appliquer des configurations Kafka personnalisées via la console AWS ou l’API. Nous l’avons utilisé pour:

• Réduisez la période de rétention pour les sujets de Kafka
• Définir les types de compression (Snappy a mieux fonctionné pour nous)
• Ajustez les paramètres des lots pour un meilleur débit
• Conscience de rack activé
  

  msk_configuration

C’était comme gérer Kafka, sans être sur appel à chaque petite chose.

4. Améliorations de la sécurité

• Encryption: fonctionnalité de chiffrement en transit et en repos.
• IAM Authentification: Soutenu, mais nous sommes restés sur PlainText + SASL pour l’instant
• Connectivité privée: passerelle de transit d’occasion pour la connectivité à partir de plusieurs VPC, mais AWS PrivateLlink est également disponible pour une sécurité plus stricte

Comparaison (Kafka sur EC2 vs AWS MSK)

Quelques conseils si vous commencez par MSK

• Utilisez IAAC comme Terraform ou Cloudformation Si vous gérez des clusters MSK. Gave le temps et réduit les erreurs.
• Taguez tout. Sérieusement. Clusters, groupes de sécurité et même configurations, si possible. Cela aide plus tard.
• Activer le cryptage par défaut. MSK facilite la tâche, donc aucune raison de ne pas le faire.
• Gardez un œil sur les courtiers et les connexions de gardien de zoo. Oui, AWS gère ZK, mais si votre application se comporte mal, vous le ressentirez toujours.
• Configurez les tableaux de bord et l’exploitation forestière du jour 1 – vous vous remercierez plus tard.

Conclusion

Amazon MSK n’a pas simplement rendu Kafka plus facile – cela l’a amélioré. Nous sommes passés de la lutte contre les incendies à nous concentrer sur la construction de pipelines de données réels. Ce n’est pas parfait. Démarrage au froid, les retards de propagation de configuration et les bizarreries de tarification existent. Mais dans l’ensemble, c’est l’un des mouvements les plus percutants que nous ayons passés dans notre plateforme de données.

Si vous dirigez toujours Kafka à l’ancienne, donnez un coup de feu à MSK. Non pas parce que c’est nouveau ou brillant, mais parce que ça marche. Partenariat avec un fournisseur de services cloud gérés comme Au nouveau Peut vous aider à adopter la bonne architecture et les bonnes stratégies pour débloquer ces économies et améliorer vos charges de travail Kafka sur AWS. Nos architectes certifiés AWS et ingénieurs DevOps se sont engagés à gagner du temps et des ressources tout en améliorant l’efficacité et la fiabilité de l’entreprise.

Vous avez trouvé cela utile? PARTAGEZ-LE