Déploiement de la configuration réseau Databricks sur des dizaines de millions de VM Serverless

Résumé

• La plateforme serverless de Databricks lance des dizaines de millions de VM chaque jour, et chaque VM a besoin d'une configuration réseau, comme les destinations autorisées et les points de terminaison privés, avant de pouvoir traiter les charges de travail des clients. Chaque nœud récupérant sa configuration au démarrage et recherchant régulièrement des mises à jour tout au long de son cycle de vie, cela se traduit par des milliards de requêtes de configuration réseau par jour. L'ancienne architecture récupérait ces informations de manière synchrone auprès de plusieurs services en amont, ce qui créait de la latence et des goulots d'étranglement en matière de disponibilité.
• Nous avons repensé l'architecture de distribution des configurations réseau en utilisant des pipelines basés sur les événements et le précalcul de snapshots, ce qui a permis de réduire la latence RPC de 97,5 % (de 5 000 ms à 125 ms) et d'atteindre une disponibilité de service de 99,99 %.

Problématique

La plateforme de calcul serverless de Databricks alimente la quasi-totalité de nos produits de données et d'IA, tels que les SQL warehouses, les notebooks, les points de terminaison de service ML, et bien plus encore. La plateforme lance des dizaines de millions de VM chaque jour sur AWS, Azure et GCP.

Avant qu'une charge de travail serverless ne puisse s'exécuter, la VM doit connaître sa configuration réseau : à quelles destinations de stockage peut-elle accéder ? Existe-t-il des points de terminaison de liaison privée (private link) par lesquels elle doit acheminer le trafic ? Y a-t-il des modifications récentes dans Unity Catalog qui accordent l'accès à de nouvelles destinations de stockage ? Devons-nous commencer à consommer de nouvelles destinations partagées via Delta Sharing ?

Le défi réside dans le fait que la configuration réseau n'est pas stockée dans un emplacement unique. Elle doit être assemblée à partir de plusieurs services en amont, chacun apportant une pièce du puzzle.

L'ancienne architecture

Dans la conception d'origine, à chaque démarrage d'un cluster serverless, notre service de configuration réseau appelait de manière synchrone tous les services en amont, agrégeait leurs réponses, calculait la configuration réseau par espace de travail et la renvoyait au dataplane serverless. Cela se produisait sur le chemin critique de la création du cluster.

Bien que l'ancienne architecture ait été simple et fonctionnait bien à petite échelle, elle souffrait de problèmes fondamentaux, reflétés par les indicateurs suivants que nous suivons sur notre tableau de bord opérationnel :

1. Latence : avec plusieurs services en amont sur le chemin critique, la latence RPC pour fournir la configuration réseau était de 5 000 ms au p99. Cela impactait la latence de démarrage des clusters serverless.
2. Taux de réussite du serveur : chaque service en amont a ses propres caractéristiques de disponibilité. Avec plusieurs services en série, la disponibilité globale chute rapidement, ce qui se traduit par une probabilité accrue d'échecs de lancement de clusters serverless par an.

Alors que l'utilisation du serverless continuait de croître rapidement, le modèle synchrone est devenu de moins en moins viable. Chaque appel synchrone déclenchait des opérations coûteuses sur l'ensemble des espaces de travail, effectuant souvent des calculs en double. Cette charge supplémentaire augmentait proportionnellement au nombre de clients (tenants) et de leurs ressources configurées.

Solution : précalcul basé sur les événements

Nous avons entièrement repensé l'architecture de la distribution des configurations réseau par Databricks. Elle repose sur les principes fondamentaux suivants :

1. Pipeline basé sur les événements : au lieu de passer des appels synchrones à tous les services en amont, le nouveau système s'abonne aux événements de changement via une file d'attente de messages. Lorsqu'un client crée une nouvelle connexion Unity Catalog ou modifie une politique réseau, le service en amont émet un événement. Le système le traite et met à jour la configuration précalculée.
2. Précalcul de snapshots : les configurations réseau sont calculées de manière asynchrone en arrière-plan et stockées dans un magasin de snapshots précalculés. Le chemin de distribution se résume à une simple et rapide récupération dans le stockage, totalement découplée des services en amont.
3. Stabilité statique : en cas de panne d'un service en amont, nous pouvons maintenir une configuration statique, garantissant ainsi la stabilité statique des clusters serverless.

L'architecture sépare clairement deux chemins. Le chemin de gestion s'exécute de manière asynchrone en arrière-plan : les services en amont émettent des événements de changement vers une file d'attente de messages, qu'un processeur d'événements consomme pour déterminer quels espaces de travail sont affectés et diffuser des notifications de mise à jour par espace de travail. Un gestionnaire d'événements local récupère ensuite les détails pertinents en amont, recalcule la configuration réseau de l'espace de travail et stocke le résultat dans un magasin de snapshots précalculés. Un outil de réconciliation périodique synchronise également à nouveau tous les espaces de travail en arrière-plan, garantissant une cohérence finale même si des événements sont manqués. Le chemin de distribution, en revanche, est critique et rapide : lorsqu'un cluster serverless démarre et a besoin d'une configuration réseau, le service de configuration réseau la fournit directement à partir du magasin de snapshots à l'aide d'une seule lecture de stockage, ce qui ne nécessite aucun appel de service en amont et réduit considérablement la charge sur ces derniers.

Décisions de conception clés

• Les services en amont poussent les événements de changement vers la file d'attente de messages. Le système traite ces événements en arrière-plan. Un outil de réconciliation à basse fréquence synchronise périodiquement tous les espaces de travail en guise de filet de sécurité, offrant la fiabilité d'un framework synchrone alliée à l'efficacité du push.
• Les configurations réseau sont calculées et stockées localement au sein de chaque partition de service, colocalisées avec les espaces de travail qu'elles desservent. Cela répartit le calcul, réduit la zone d'impact en cas d'incident et élimine les dépendances inter-partitions sur le chemin de distribution.
• Les événements ne contiennent que des identifiants d'espace de travail et de ressource. Cela permet de garder les événements légers, de les rendre idempotents (ils peuvent être rejoués dans n'importe quel ordre) et d'éviter le transfert de données client sensibles via le pipeline de messagerie.

Flux des événements

Lorsqu'un client crée une nouvelle connexion Unity Catalog, Unity Catalog émet un événement de changement vers la file d'attente de messages. Le processeur d'événements reçoit alors l'événement, détermine quels espaces de travail sont rattachés au metastore concerné et diffuse une notification de mise à jour par espace de travail. Dans la partition de chaque espace de travail, le gestionnaire d'événements reçoit cette notification, récupère les détails de la connexion mise à jour, recalcule la configuration réseau de l'espace de travail et la stocke avec une nouvelle marque de version. À partir de ce moment, lorsqu'un cluster serverless demande la configuration réseau, celle-ci est fournie directement depuis le magasin de snapshots, sans qu'aucun appel en amont ne soit nécessaire.

Impact

Après le déploiement de la nouvelle architecture, les résultats ont été transformateurs sur l'ensemble des indicateurs opérationnels :

Au-delà des indicateurs principaux :

1. Le volume d'appels en amont a été réduit de 86 %. Le système n'appelle les services en amont que lorsqu'un événement indique un changement, et non à chaque requête.
2. Nous avons constaté une amélioration significative de la fraîcheur de la configuration réseau.
3. L'ancien framework synchrone a été entièrement abandonné.

Conclusion

Ce projet nous a enseigné plusieurs leçons sur l'exploitation d'une infrastructure réseau à l'échelle du cloud :

Le précalcul découple les chemins critiques. En déplaçant l'agrégation coûteuse en arrière-plan, le chemin de distribution devient extrêmement simple et rapide. C'est la décision architecturale qui a eu le plus d'impact. Elle a transformé une chaîne de dépendances multi-services en une simple lecture de stockage.

L'architecture basée sur les événements troque la cohérence contre l'évolutivité, et la réconciliation sert de filet de sécurité. Le push basé sur les événements gère efficacement les cas courants, tandis qu'un outil de réconciliation périodique rattrape tout ce qui passe entre les mailles du filet.

Concevez pour l'extensibilité dès le premier jour. L'architecture modulaire par étapes signifie que l'ajout de la prise en charge d'une nouvelle source de données en amont nécessite uniquement l'implémentation d'une nouvelle étape, sans aucune modification du pipeline central. À mesure que la gamme de produits de Databricks s'élargit, le système de configuration réseau évolue avec elle.

Aujourd'hui, ce système traite des milliards de requêtes de configuration réseau par jour sur l'ensemble de la flotte serverless mondiale de Databricks, avec une latence d'environ 125 ms et une disponibilité de 99,99 %. Alors que le calcul serverless poursuit sa croissance rapide, l'architecture basée sur les événements garantit que la distribution des configurations réseau évolue au même rythme.

Nous recherchons constamment des ingénieurs qui aiment relever les défis des systèmes distribués à l'échelle mondiale. Si ce genre de problèmes vous passionne, nous serions ravis de faire votre connaissance. N'hésitez pas à consulter nos postes ouverts sur databricks.com/careers !

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original