Comment la sensibilisation du rack dans Amazon MSK a économisé 36 000 $ / an pour une entreprise adtech de premier plan

Introduction

La construction et le déploiement d’applications qui utilisent Apache Kafka pour le traitement des données en temps réel sont simples avec Amazon MSK (streaming géré pour Apache Kafka)un service entièrement géré par AWS. La sensibilisation au rack est un changement de configuration négligé qui peut considérablement augmenter la tolérance aux défauts et la rentabilité, même si MSK s’occupe d’une grande partie de l’infrastructure pour vous.

Dans ce blog, nous explorerons ce qu’est la sensibilisation au rack, comment Kafka ou MSK l’utilise, et comment la configuration de vos consommateurs Kafka à lire à partir de la réplique la plus proche plutôt que du leader de partition peut entraîner des économies de coûts majeures. Nous avons fait cette activité pour le Client mondial de la plate-forme de gestion de la publicitéune puissance de la publicité et des téléviseurs connectés. Avec une plate-forme de gestion de la publicité télévisée connectée de pointe, ils avaient besoin d’un partenaire de confiance pour contrôler leurs factures de cloud. Dans notre cas, les économies étaient presque 100 $ par jour dans la facture de transfert de données Cross-Az. Commençons et explorons la solution.

Qu’est-ce que la sensibilisation au rack à Kafka?

La caractéristique de sensibilisation aux racks répartit les répliques de la même partition sur les racks (racks ou zones de disponibilité). Permettre aux consommateurs de Kafka de récupérer les données de la réplique la plus proche réduit la latence et le trafic croisé et garantit qu’un échec en un seul endroit ne détruira pas toutes les répliques de partition.

Avantages de la sensibilisation au rack

• Haute disponibilité: Même si un AZ entier échoue, les partitions continuent de fonctionner. Les données peuvent être récupérées auprès d’autres courtiers AZ.
• Résilience: Aucun AZ ne devient un seul point d’échec.
• Faible coût de transfert de données: Les consommateurs rapporteront les données des répliques dans le même AZ, ce qui ne se traduira pas par des coûts de transfert de données croisés.
• Performance: La lecture des données des mêmes courtiers / répliques AZ entraînera une faible latence et des performances élevées.
  

  Avantages de la sensibilisation au rack

Comment Amazon MSK gère la conscience du rack

Amazon MSK mappe automatiquement les courtiers à différentes zones de disponibilité. Chaque courtier a un courtier. Propriété de rack définie par MSK en fonction de son AZ.
Jetons un coup d’œil à l’exemple de la région de l’Oregon dans AWS:

Broker 1 → us-west-2a

Broker 2 → us-west-2b

Broker 3 → us-west-2c

Broker 4 → us-west-2a

.
.
.
.

Broker 15 → us-west-2c

Lorsqu’un sujet est créé avec un facteur de réplication de 3, MSK garantit que les répliques sont distribuées sur différents AZ.

Activer la réplique la plus proche

Alors que MSK s’occupe des affectations de rack de courtier, pour exploiter entièrement la sensibilisation au rack, vos consommateurs Kafka doivent être configurés pour récupérer à partir de la réplique la plus proche. Cela nécessite des modifications de configuration des côtés du courtier et du consommateur.

Configuration du courtier

Activez la propriété suivante dans votre configuration MSK:

replica.selector.class=org.apache.kafka.common.replica.RackAwareReplicaSelector

MSK prendra environ 15 minutes pour appliquer cette configuration, mais elle dépend également de la taille et des données du cluster. Pendant ce temps, le cluster reste entièrement fonctionnel, il est donc complètement sûr d’appliquer ce changement à tout moment.

Avant d’activer cette configuration sur le cluster:

Après avoir activé:

Nous pouvons voir que la propriété est maintenant appliquée sur le cluster, et elle permet désormais aux consommateurs de Kafka de récupérer les données de la réplique la plus proche au lieu de toujours contacter le leader de partition, réduisant le transfert et la latence croisés de données. Le courtier utilise cette valeur pour trouver la réplique de lecture préférée.
Référence: https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html

Configuration du consommateur

Définissez dynamiquement l’ID de rack du consommateur en utilisant le service de métadonnées d’instance EC2 (IMD). Dans notre cas, nous exécutons le consommateur sur un cluster Amazon EMR, et nous récupérons l’ID AZ lors de l’exécution à l’aide d’AWS Secrets Manager. Cet ID AZ est ensuite transmis à la propriété Client.Rack dans la configuration du consommateur Kafka. Par exemple:

client.rack=us-west-2b

Cela indique au client Kafka, dans notre cas Java AWS SDK, pour préférer les répliques dans le même AZ. Consultez la configuration du client: https://kafka.apache.org/35/documentation.html#consumerConfigs_client.rack
Vérification de la sensibilisation aux racks
Vous pouvez vérifier la configuration du rack de courtier en utilisant:

./kafka-configs.sh --describe --entity-type brokers --bootstrap-server <broker-endpoint>

Pour vérifier que les clients lisent à partir de la réplique la plus proche, vous pouvez surveiller les modèles d’utilisation du réseau ou utiliser les métriques Kafka via des tableaux de bord CloudWatch pour identifier les changements dans la distribution du trafic après l’activation de la sensibilisation du rack.
Avant d’activer cette optimisation, la plupart de notre trafic de consommation est passé au chef de partition, qui résidait souvent dans un autre AZ.

Après la mise en œuvre de la récupération du rack:

• Les consommateurs ont commencé à lire des répliques In-Az, puis nous avons observé différents modèles de métriques CloudWatch maintenant. Les transactions de flux de données et de paquets de réseau étaient élevées sur les courtiers, qui étaient dans le même AZ que le consommateur.

• Les coûts de transfert de données croisés croisés ont considérablement baissé. Nous économisons maintenant environ 100 $ par jour.
• Cela s’ajoute à 36 500 $ / an Dans les économies de coûts pour un seul cas d’utilisation, montrant le réel avantage financier de l’optimisation approfondie des plateformes.

Meilleures pratiques

• Utilisez au moins 3 AZ: Répartir les courtiers à travers 3 AZ pour une meilleure tolérance aux défauts.
• Définir le facteur de réplication approprié: Assurez-vous au moins 3 répliques par partition.
• Activer le sélecteur de répliques de rack-Aware: Sur les courtiers et les clients.
• Réfléchissez dynamiquement AZ: Surtout si vous utilisez des groupes EMR ou des groupes d’automate.
• Moniteur avec CloudWatch: Configurez les tableaux de bord pour suivre le transfert de données et le trafic de courtier.

Conclusion

La sensibilisation au rack dans Amazon MSK n’est pas seulement une fonctionnalité de haute disponibilité ou de résilience – c’est un puissant mécanisme d’économie lorsqu’il est configuré correctement. En permettant aux consommateurs de s’approcher des répliques les plus proches, les organisations peuvent réduire la latence et économiser considérablement sur les frais de transfert de données croisés.
Si vous utilisez Amazon MSK ou l’open source Kafka fonctionnant sur EC2 ou une autre plate-forme et que vous n’avez pas examiné la réplique de la réplique du rack, c’est le moment. De petites modifications de configuration peuvent entraîner de grandes victoires dans les performances et votre facture AWS. 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 s’engagent à vous éviter de temps et de ressources tout en améliorant l’efficacité et la fiabilité des entreprises.

Vous avez trouvé cela utile? PARTAGEZ-LE