Repenser les systèmes distribués pour des performances et une fiabilité sans serveur

La création d'un calcul véritablement sans serveur pour Apache Spark a nécessité de résoudre des défis architecturaux fondamentaux qui existaient depuis la création de Spark. La complexité va bien au-delà de la simple création de pools de machines préchauffées ou de la mise en œuvre d'une mise à l'échelle automatique de base. Il a fallu repenser les hypothèses fondamentales sur le fonctionnement des systèmes de calcul distribué.

Les déploiements Spark traditionnels exposent directement l'infrastructure aux utilisateurs, créant un couplage étroit entre les applications et le calcul. Les charges de travail se disputent les ressources partagées, de petites inefficacités peuvent entraîner des défaillances en cascade, et les utilisateurs sont contraints d'équilibrer manuellement les performances, les coûts et la fiabilité. À mesure que la demande évolue, les systèmes peinent à maintenir à la fois une utilisation élevée et des performances prévisibles.

Le calcul sans serveur adopte une approche différente en gérant entièrement l'infrastructure afin que l'utilisateur puisse se concentrer sur les données et les insights. La stabilité devient une propriété du système plutôt qu'une responsabilité de l'utilisateur, rendue possible par des architectures qui isolent les charges de travail, les placent intelligemment et adaptent dynamiquement les ressources.

Le calcul sans serveur est conçu pour améliorer la stabilité, les performances et la simplicité opérationnelle. Trois systèmes fondamentaux rendent cela possible :

1. Spark Connect, qui sépare les applications utilisateur de l'infrastructure de calcul
2. La Passerelle sans serveur, qui achemine intelligemment les charges de travail à travers les ressources de calcul
3. Un autoscaler adaptatif, qui optimise continuellement la taille du cluster pour les performances et les coûts

Ensemble, ces systèmes permettent un modèle où les performances sont atteintes en assurant d'abord la stabilité de l'ensemble du système.

Spark Connect : La stabilité par l'isolation

Spark Connect représente la transformation architecturale la plus significative de l'histoire de Spark, une rupture complète avec la conception monolithique qui a défini le calcul distribué pendant plus d'une décennie. Dans les architectures traditionnelles, les applications utilisateur s'exécutent directement sur la même machine que le pilote Spark, créant un couplage étroit qui introduit des limitations critiques. Lorsque plusieurs applications se disputent les ressources sur le même cluster ou lorsque le code utilisateur consomme une mémoire ou un CPU excessif, le système devient instable, entraînant des défaillances qui peuvent se propager à travers les charges de travail.

Spark Connect introduit une architecture client-serveur dans laquelle les applications communiquent avec le pilote Spark via gRPC, et le pilote exécute les requêtes au nom du client plutôt que d'exécuter directement les processus utilisateur. Cela déplace l'unité d'exécution des processus d'application vers les requêtes et permet une séparation nette entre les applications utilisateur et l'infrastructure.

Ce découplage améliore considérablement la fiabilité et permet à la plateforme de gérer les pilotes indépendamment des charges de travail utilisateur. En isolant les applications du calcul, Spark Connect crée la base nécessaire à une exécution multi-locataire stable et permet une gestion des ressources plus avancée à travers le système.

Cette architecture permet à Databricks de livrer plus de 25 mises à niveau majeures du runtime Spark par an avec un taux de réussite de 99,998 % sur plus de 4,5 milliards de charges de travail, sans aucune action de l'utilisateur requise.¹

La Passerelle : Équilibrer efficacité et prévisibilité

Les systèmes distribués ont longtemps été confrontés à une tension fondamentale entre efficacité et prévisibilité. Maximiser l'utilisation conduit souvent à des contentions de ressources, tandis qu'isoler les charges de travail peut entraîner une capacité sous-utilisée. Les modèles de clusters traditionnels forcent les utilisateurs à gérer ce compromis manuellement, entraînant souvent des performances imprévisibles ou une exécution peu fiable à mesure que les charges de travail changent.

Considérez ce qui se passe lorsque des dizaines de requêtes arrivent simultanément : certaines, de petites analyses exploratoires exécutées sur des données échantillon, d'autres, de gros jobs ETL de production traitant des centaines de gigaoctets. Un routeur naïf les traite de manière identique, forçant les gros jobs à attendre derrière les petits ou laissant les charges de travail se disputer le même cluster, ce qui entraîne une dégradation imprévisible des performances. Cette dynamique rend difficile d'offrir à la fois une utilisation élevée et des performances constantes dans des environnements partagés.

La passerelle Databricks achemine chaque charge de travail en évaluant trois signaux en temps réel : la taille estimée de la requête (dérivée du plan logique), l'utilisation actuelle du pool de clusters et le profil de latence : si une session est interactive et sensible à la latence ou un job par lots optimisé pour le débit. Une petite requête exploratoire est acheminée vers un cluster peu chargé qui peut répondre en quelques secondes ; un job ETL lourd est dirigé vers un cluster disposant d'une marge de manœuvre disponible pour son volume de données, ou l'autoscaler est signalé pour en provisionner un. Lorsque les conditions changent (un cluster se remplit, un job de longue durée se termine, un nouveau cluster est mis en ligne), la passerelle réévalue continuellement les placements et corrige le routage sans intervention de l'utilisateur. Le résultat : les charges de travail sont isolées les unes des autres. Une requête incontrôlable sur un cluster ne retarde pas les requêtes sur un autre, et le système maintient une utilisation élevée sans sacrifier la prévisibilité.

Mise à l'échelle automatique : Optimiser la courbe coût-performance

Le dimensionnement dynamique des clusters est le principal mécanisme d'optimisation du rapport prix-performance dans les systèmes distribués, mais déterminer la quantité optimale de calcul est intrinsèquement complexe. La configuration optimale dépend des caractéristiques de la charge de travail, de la taille des données et de l'importance relative de la latence par rapport au coût, aucune configuration unique ne fonctionnant dans tous les scénarios. Databricks serverless offre deux modes pour s'adapter aux différents besoins : Standard, qui utilise moins de calcul pour réduire les coûts, et Optimisé pour la performance, qui offre un démarrage et une exécution plus rapides pour les charges de travail sensibles au temps.

Le démarrage est une priorité pour nous, et les Notebooks et Workflows sans serveur ont fait une énorme différence. Le calcul sans serveur pour les notebooks facilite les choses en un seul clic. — Chiranjeevi Katta, Data Engineer chez Airbus

Databricks nous a aidés à passer au calcul sans serveur, tout en éliminant les workflows redondants. Ces gains d'efficacité nous ont permis de réduire les coûts opérationnels de 25 %. Les pipelines sur notre infrastructure héritée prenaient auparavant des heures à traiter. Maintenant, ils s'exécutent 2 à 5 fois plus vite. — Evan Cherney, Senior Data Science Manager chez Unilever

Les approches traditionnelles de mise à l'échelle automatique reposent sur des règles statiques et des seuils réactifs, qui ne parviennent souvent pas à saisir ces nuances. En conséquence, les clusters sont fréquemment sous-provisionnés ou sur-provisionnés, entraînant inefficacité, instabilité, ou les deux.

La mise à l'échelle automatique sans serveur adopte une approche plus adaptative. En analysant continuellement les modèles de charge de travail et les signaux à l'échelle du système, l'autoscaler positionne chaque charge de travail sur la courbe coût-performance optimale, là où la plupart des clusters configurés manuellement échouent, offrant des performances moindres et des coûts plus élevés en raison de la difficulté à dimensionner correctement les systèmes distribués. Il ajuste dynamiquement la capacité de calcul en effectuant une mise à l'échelle horizontale et verticale selon les besoins, prévenant les échecs de mémoire insuffisante et maintenant la stabilité à mesure que les charges de travail augmentent. Lorsqu'une tâche rencontre une erreur de mémoire insuffisante, l'autoscaler la détecte automatiquement, redémarre la tâche sur une VM plus grande et poursuit le job sans intervention manuelle ni échec du job.

L'impact est mesurable. CKDelta a signalé des jobs se terminant en 20 minutes qui prenaient auparavant 4 à 5 heures. Unilever a constaté des pipelines s'exécutant 2 à 5 fois plus vite avec des coûts opérationnels réduits de 25 %. HP a réalisé des économies de cloud de plus de 32 % et a diminué le temps d'exécution combiné des jobs de 36 %.

Ensemble, Spark Connect, la passerelle et l'autoscaler permettent un modèle de fonctionnement fondamentalement différent pour Spark. Les charges de travail sont isolées, placées intelligemment et dotées de ressources dynamiques sans intervention de l'utilisateur. En abordant la stabilité au niveau architectural, le calcul sans serveur peut offrir de solides performances tout en maintenant la fiabilité, permettant aux utilisateurs de se concentrer sur la création de charges de travail de données et d'IA plutôt que sur la gestion de l'infrastructure.

¹ Justin Breese et al., "Blink Twice : Épinglage automatique des charges de travail et détection des régressions pour Apache Spark sans version à l'aide de tentatives," SIGMOD/PODS '25, p. 103–106. https://doi.org/10.1145/3722212.3725084

Commencez votre parcours sans serveur dès aujourd'hui

• Inscrivez-vous à un compte Databricks sans serveur
• Calcul sans serveur pour les notebooks, les tâches Lakeflow et les pipelines déclaratifs Spark
• Guide du praticien pour le calcul sans serveur

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