Introduction

Apache Kafka® est la pierre angulaire de la pile technologique d’Uber. Il joue un rôle crucial dans plusieurs cas d’utilisation critiques et constitue la base des systèmes batch et temps réel chez Uber.

Kafka stocke les messages dans des segments de journal en mode ajout sur le stockage local du courtier. Chaque sujet peut être configuré avec une rétention ciblée basée sur la taille ou le temps. Cela garantit aux utilisateurs de consommer les données dans la période de rétention ou de taille même en cas de défaillance des applications consommatrices respectives ou de ralentissement pour plusieurs raisons. Le stockage total sur un cluster dépend de facteurs tels que le nombre total de partitions de sujets, le débit de production et la configuration de rétention. Un courtier Kafka a généralement besoin d’un stockage plus important pour prendre en charge les partitions de sujets requises hébergées sur un courtier.

Motivation/Contexte du Projet

Le stockage de cluster Kafka est généralement dimensionné en ajoutant plus de nœuds courtiers au cluster. Mais cela ajoute également de la mémoire et des CPU inutiles au cluster, rendant le coût global du stockage moins efficace par rapport au stockage des données plus anciennes dans un stockage externe. Un cluster plus grand avec plus de nœuds ajoute également à la complexité du déploiement et augmente les coûts opérationnels en raison du couplage étroit du stockage et du traitement. Cela soulève plusieurs problèmes liés à la scalabilité, à l’efficacité et aux opérations.

Nous avons proposé le Stockage Hiérarchisé de Kafka pour éviter le couplage étroit du stockage et du traitement dans un courtier. Il fournit deux niveaux de stockage, appelés local et distant. Ces deux niveaux peuvent avoir des politiques de rétention respectives basées sur les cas d’utilisation respectifs.

Objectifs

Voici les principaux objectifs que nous avons fixés pour le stockage hiérarchisé :

• Étendre le stockage au-delà du courtier
• Soutien de stockage local et distant (y compris les stockages cloud/objets comme S3/GCS/Azure)
• Durabilité et cohérence sémantiques similaires au stockage local
• Isolation de la lecture des données les plus récentes et historiques
• Aucun changement requis de la part des clients
• Réglage et provisionnement faciles des clusters
• Améliorer l’efficacité opérationnelle et les coûts

Architecture

Un cluster Kafka activé avec un stockage hiérarchisé est configuré avec deux niveaux de stockage appelés local et distant. Le niveau local est le stockage local du courtier où les segments sont actuellement stockés. Le nouveau niveau distant est le stockage étendu, tel que HDFS/S3/GCS/Azure. Ces deux niveaux auront des configurations de rétention respectives basées sur la taille et le temps. La période de rétention pour le niveau local peut être considérablement réduite de quelques jours à quelques heures. La période de rétention pour le niveau distant peut être beaucoup plus longue - jours, voire des mois. Les applications sensibles à la latence effectuent des lectures de queue et sont servies à partir du niveau local, en utilisant l’utilisation efficace du cache de pages de Kafka pour la récupération des données. D’autre part, les applications telles que le backfill ou celles récupérant des échecs nécessitant des données plus anciennes que ce qui est disponible localement, sont servies à partir du niveau distant.

Cette approche permet la scalabilité du stockage dans un cluster Kafka sans être liée aux ressources mémoire et CPU, transformant ainsi Kafka en une option de stockage viable à long terme. De plus, cela réduit le fardeau du stockage local sur les courtiers Kafka, réduisant ainsi la quantité de données à transférer lors de la récupération et du rééquilibrage. Les segments de journal accessibles dans le niveau distant ne nécessitent pas de restauration sur le courtier et peuvent être accédés directement depuis le niveau distant. Cela élimine la nécessité d’étendre le stockage du cluster Kafka et d’ajouter de nouveaux nœuds lors de l’extension de la période de rétention. De plus, cela permet une rétention de données beaucoup plus longue sans la nécessité de pipelines de données distincts pour transférer des données de Kafka vers un stockage externe (une pratique courante dans de nombreuses configurations actuelles).

Le stockage hiérarchisé divise le journal d’une partition de sujet en deux composants logiques différents appelés journal local et journal distant. Le journal local contient une liste de segments de journal locaux et le journal distant contient une liste de segments de journal distants. Le sous-système de journal distant copie les segments éligibles de chaque partition de sujet du stockage local vers le stockage distant. Un segment est éligible pour être copié lorsque son décalage de fin est inférieur à <em>LastStableOffset</em> d’une partition.

Conclusion

Dans ce blog, nous avons couvert une introduction et une architecture de haut niveau du stockage hiérarchisé chez Uber. Si vous êtes intéressé par plus de détails, vous pouvez lire la conception détaillée sur <span></span>. La majeure partie de cette fonctionnalité est disponible en accès anticipé dans Apache Kafka 3.6.0. Cette fonctionnalité est en production depuis ~1-2 ans dans différents charges de travail respectivement. Dans la prochaine partie de cette série de blogs, nous couvrirons notre expérience de production et comment cela a contribué à une meilleure fiabilité, scalabilité et efficacité de nos clusters.

Apache®, Apache Kafka™ et Kafka™ sont des marques déposées ou des marques commerciales de la Apache Software Foundation aux États-Unis et/ou dans d’autres pays. Aucune approbation de la part de la Apache Software Foundation n’est implicite par l’utilisation de ces marques.

Source de l’article