Approche API-First de la création de sujets Kafka

Les équipes d'ingénierie de DoorDash ont réorganisé la création de sujets Kafka en remplaçant une approche basée sur Terraform/Atlantis par une API interne, Infra Service. Cela a permis de réduire de 95 % le temps d'intégration du pipeline en temps réel et d'économiser d'innombrables heures de travail pour les développeurs.

L'équipe Real-Time Streaming Platform (RTSP) de DoorDash fait partie de l'organisation Data Platform et gère plus de 2 500 sujets Kafka répartis sur cinq clusters. Kafka est la couche pub-sub du pipeline Iguazu, qui fournit des événements en temps réel à DoorDash. Près de six milliards de messages sont traités chaque jour à un rythme moyen de quatre millions de messages par minute, avec parfois des pointes au double. 

L'équipe RTSP cherche constamment des moyens d'accélérer l'intégration d'Iguazu. L'étape la plus lente de ce processus était le provisionnement des sujets Kafka, qui nécessitait l'approbation de l'ingénieur d'astreinte et était susceptible d'échouer, ce qui augmentait encore la charge de travail de l'équipe d'astreinte. Pour améliorer cette situation, RTSP s'est associé aux équipes de stockage et de cloud de DoorDash pour automatiser la création de ressources Kafka en s'intégrant à un service interne de création de ressources d'infrastructure.

Terminologie clé

Voici des définitions et des liens vers de la documentation supplémentaire sur les outils que nous avons utilisés. Nous abordons la manière dont ces outils sont utilisés et leurs avantages et inconvénients dans l'article principal. 

• Terraform: Plate-forme d'infrastructure en tant que code (IaC). Elle utilise le langage de configuration HashiCorp (HCL) pour configurer les ressources de l'infrastructure. Pour approvisionner l'infrastructure, il faut créer un plan d'exécution, appelé plan Terraform, puis exécuter le plan via Terraform Apply.
• Atlantis: Un outil d'automatisation de Terraform. Exécute Terraform Plan et Apply. Fusionne les demandes d'extraction Terraform en cas d'exécution réussie.
• Pulumi: Semblable à Terraform, il s'agit également d'une plateforme IaC, mais sans HCL. Pulumi s'appuie sur les langages de programmation existants pour gérer l'infrastructure.
• Prometheus: Une base de données de surveillance et de séries chronologiques. Conçue pour surveiller les métriques des applications et de l'infrastructure. Expose le langage de requête PromQL pour l'écriture d'alertes sur les métriques.
• Chronosphère: Plate-forme d'observabilité native dans le nuage. Construite sur Prometheus. 
• Cadence Workflow : Moteur de flux de travail tolérant aux pannes, avec état, capable d'exécuter des graphes acycliques dirigés (DAG).

Comprendre l'architecture existante

Comme le montre la figure 1 ci-dessous, l'ancienne approche de DoorDash en matière de création de sujets comportait plusieurs étapes au sein d'un flux de travail Cadence.

1. Orchestrator déclenche un appel API vers le repo GitHub pour les sujets Kafka, créant une demande d'extraction, ou PR, pour un nouveau sujet et une entrée de liste de contrôle d'accès (ACL) correspondante.
2. Le service Orchestrator déclenche l'exécution par Atlantis de Terraform Plan sur le sujet. 
3. Le personnel de garde reçoit une notification automatique par courrier électronique au sujet de la RP. 
4. Le service Orchestrator interroge le statut PR pour vérifier l'approbation de l'astreinte. 
5. Une fois approuvé et dans un état fusionnable, Atlantis Apply est déclenché contre le PR. 
6. Les services de l'Orchestrateur surveillent la réussite de la fusion des PR. En cas d'échec, la PR est supprimée et le processus recommence à l'étape 1.

Malheureusement, le processus de création des thèmes échoue souvent pour l'une ou l'autre des raisons suivantes :

• Conflits de fusion GitHub lors de la création d'un PR lorsque plusieurs PR sont coupés dans le même commit
• Dérive de l'état de Terraform par rapport à l'état de Kafka
• Atlantis se bloque parfois sur des clusters contenant des centaines de sujets et se termine dans un temps non déterministe. 
• Dérive de l'état d'Atlantis par rapport à l'état de Terraform. Terraform est appliqué mais Atlantis n'a pas fusionné le PR.
• L'examen et l'approbation des RP prenant beaucoup de temps, les personnes de garde manquaient parfois la notification par courrier électronique, ce qui entraînait des interruptions de service. Remarque : lors du lancement d'un produit, le volume de nouveaux PR créés par un thème peut dépasser les 20 par heure.

En outre, il est difficile d'auditer par programme les clusters Kafka et d'effectuer des opérations de mise à l'échelle telles que l'ajout de partitions ou la migration vers des clusters dédiés sans intervention manuelle. 

Développer une nouvelle architecture

Dans un premier temps, nous avons envisagé un certain nombre d'approches potentielles, notamment

• Création d'un état durable en mémoire pour suivre la progression fine et pour synchroniser les flux de travail. L'état serait récupéré sur disque lors du redémarrage de l'Orchestrator.
• Utilisation de la base de données de traitement des transactions en ligne (OLTP) pour conserver l'état mentionné ci-dessus.
• Écrire un fournisseur Terraform personnalisé
• Augmentation du nombre de tentatives d'accès au flux de travail. 

Ces quatre solutions n'auraient été que des solutions de fortune, incapables de résoudre complètement les problèmes sous-jacents : Synchronisation des états entre Terraform hébergé sur Git, Atlantis, Cadence workflow et Kafka. Bien que les deux premières solutions aient pu résoudre certains des problèmes mentionnés, elles auraient risqué de compliquer davantage la gestion des états en introduisant de nouveaux états à synchroniser. En tant que source de vérité faisant autorité, Kafka doit être cohérent avec toutes les solutions que nous choisissons. 

Capturer une petite victoire : Un cas d'utilisation pour les super utilisateurs de Kafka

En explorant ces solutions, nous avons identifié que les conflits de fusion ne se produisaient que dans les fichiers ACL pour les utilisateurs d'Iguazu. Chaque consommateur et éditeur du pipeline Iguazu dispose d'un compte utilisateur Kafka distinct. À chaque création de thème, le fichier ACL d'un utilisateur d'Iguazu était mis à jour avec une entrée ACL pour ce thème. Les fichiers ACL ont fini par contenir des centaines de permissions, ce qui a considérablement ralenti les applications Atlantis.

Nous avons eu le déclic lorsque nous avons réalisé qu'il s'agissait d'un cas d'utilisation parfait pour les comptes de super-utilisateurs. Les écueils liés aux permissions font que nous évitons généralement de créer des super-utilisateurs. Mais si chaque utilisateur d'Iguazu - proxy REST ou jobs Flink en amont et en aval - avait besoin d'accéder à tous les sujets d'un cluster, l'idéal serait de donner à ces utilisateurs un accès complet en lecture ou en écriture, selon les besoins, ce qui éliminerait le fichier ACL et les problèmes qui y sont liés. En outre, le flux de travail existant pourrait être encore amélioré, comme nous le verrons plus loin.

La recherche de la grande victoire : Création simplifiée de ressources Kafka 

Infra Service est une plateforme interne qui fournit une API pour effectuer des opérations CRUD sur les composants de l'infrastructure. Elle est construite et maintenue par l'organisation de l'infrastructure de DoorDash. Elle remplace l'approche traditionnelle consistant à utiliser l'infrastructure en tant que code et GitOps pour approvisionner l'infrastructure. Infra Service reproduit les fonctions importantes fournies par Git et GitHub, y compris le contrôle de version et les révisions de changement. Il est également piloté par des plugins, ce qui permet aux équipes d'ajouter la prise en charge des ressources qu'elles souhaitent gérer de manière programmatique. La majeure partie du travail nécessaire à la mise en œuvre d'un plugin Infra Service consiste à écrire un programme Pulumi sous-jacent.

Infra Service utilise Pulumi pour gérer le provisionnement de l'infrastructure sous le capot. Pulumi est un outil d'infrastructure en tant que code similaire à Terraform, mais contrairement à Terraform, Pulumi permet d'utiliser des langages de programmation généraux pour définir l'infrastructure. Il dispose d'un support solide pour les tests et d'un vaste catalogue de fournisseurs. Infra Service gère l'invocation programmatique de Pulumi lorsqu'un changement est demandé et la propagation de tout résultat résultant de l'exécution de Pulumi vers l'utilisateur final.

Pour créer des ressources Kafka et de base de données, nous avons développé un composant dans Infra Service appelé Storage Self-Serve Platform. Ce composant est illustré ci-dessous à la figure 2.

Dans la figure 2, toujours enveloppée dans un flux de travail Cadence, l'approvisionnement en thèmes est réduit à un processus en deux étapes :

1. Le service Minions de l'Orchestrator envoie une requête gRPC à la passerelle Infra Service pour approvisionner le sujet Kafka. Les Minions reçoivent une réponse synchrone indiquant si la demande de création de thème est persistante. À ce stade, la création du sujet n'est peut-être pas terminée. Du point de vue des Minions, tout ce qui se trouve derrière la passerelle de services Infra est une boîte noire qui gère la déduplication, la validation et les nouvelles tentatives.
2. Étant donné qu'un thème est considéré comme créé lorsqu'il apparaît avec une utilisation du disque non nulle, Minions interroge en permanence la plateforme de métrologie Prometheus Chronosphere pour connaître cet état. Tous les thèmes, même ceux qui ne contiennent pas de messages, contiennent des métadonnées qui sont sauvegardées sur le disque. Nous utilisons Chronosphere pour deux raisons : Premièrement, elle corrobore de manière indépendante l'état de la boîte noire Infra Service et, deuxièmement, DoorDash utilise Chronosphere avec une disponibilité de quatre neuf (99,99 %). Cela signifie que les pannes de Chronosphere n'existent pas. Si Kafka ne signale pas les métriques des sujets pendant quelques minutes, il est improbable que cela continue plus longtemps - à moins qu'il n'y ait des problèmes plus importants avec Kafka. Lorsque les métriques apparaîtront finalement dans Chronosphere, elles seront tirées par les Minions. 

Savourer la victoire

Cette nouvelle architecture permet de provisionner environ 100 nouveaux sujets par semaine sans intervention manuelle. Grâce à ce flux de travail basé sur l'API, nous avons réduit le temps d'intégration d'Iguazu de 95 %. Auparavant, les clients étaient assurés d'être pris en charge dans un délai de deux jours ouvrables, soit environ 48 heures. Désormais, l'intégration s'effectue dans l'heure qui suit la soumission de la demande et souvent en 15 minutes. Autre avantage : les interventions manuelles sur appel ont été réduites d'environ quatre heures par semaine.

Chaque sujet créé à l'aide de la nouvelle architecture comprend de riches métadonnées sur la propriété, les attentes en matière de débit et la taille des messages, ce qui facilitera l'application de garde-fous en matière de fiabilité à l'avenir.

Enfin, en intégrant la plateforme de libre-service de stockage standard au sein d'Infra Service, nous avons accès à des contrôles administratifs, notamment la modification des configurations des sujets, la récupération des mots de passe des utilisateurs et un accès convivial à l'état des clusters Kafka pour les développeurs. 

Explorer l'avenir du stockage en libre-service

En nous appuyant sur le succès du service Infra et de la plate-forme de stockage en libre-service, nous prévoyons d'ajouter les fonctionnalités suivantes pour améliorer nos garde-fous et l'expérience des clients. La figure 3 illustre l'architecture de haut niveau de la future conception. 

• Une logique de validation centralisée, qui sera maintenue par l'équipe chargée du stockage. Cette logique de validation peut être continuellement adaptée aux besoins de l'entreprise.
• Valeurs par défaut intelligentes. Le nombre de partitions et le facteur de réplication peuvent être calculés à la demande du client. Cela simplifie la saisie de l'utilisateur pour l'approvisionnement d'un sujet.
• Attraper les requêtes en double plus tôt dans le processus de provisionnement grâce à une logique de déduplication spécifique à Kafka. Renvoyer les erreurs d'API aux utilisateurs.

Remerciements

Cette victoire technique est le fruit d'un travail d'équipe entre plusieurs équipes : Plateforme de streaming en temps réel, Stockage et Cloud. Nous remercions tout particulièrement tous les ingénieurs qui ont contribué à la réalisation de ce projet : Roger Zeng, Luke Christopherson, Venkata Sivanaga Saisuvarna Krishna Manikeswaram Chaitanya, Basar Hamdi Onat, Chen Yang, Seed Zeng, Donovan Bai, Kane Du, Lin Du, Thai Pham, Allen Wang, Zachary Shaw et Varun Narayanan Chakravarthy.