Comment Uber a migré des milliers de microservices vers une plateforme multi-cloud

• "Up: Portable Microservices Ready for the Cloud"
• Uber déploie plus de 4 000 fois par semaine 4 500 microservices stateless, via 4 500 ingénieurs et de nombreux systèmes automatisés
• Ces services sont développés, déployés et exploités par des centaines d’équipes distinctes travaillant de manière indépendante à travers le monde
• Ces services varient en taille, en forme et en fonction : certains sont petits et utilisés pour des tâches internes, d’autres sont volumineux et servent à de vastes calculs en temps réel

Historique des services stateless chez Uber

• En 2014, Uber utilisait un monolithe écrit en Python, stockant ses données dans une seule base PostgreSQL
• Avec la croissance, l’entreprise a recruté davantage d’ingénieurs et est passée à une architecture de microservices
• À mesure que le nombre de services augmentait, Uber a créé un outil appelé µDeploy pour déployer le code de manière centralisée et à grande échelle
  • Tous les services stateless ont été conteneurisés, avec une abstraction de la gestion des hôtes et du placement
  • Cela permettait au groupe infrastructure de gérer les flottes d’hôtes indépendamment des microservices des unités métier
  • Mais la gestion et le placement des services restaient encore manuels
• L’infrastructure d’Uber suit un modèle où des groupes de zones forment des régions
• La latence entre les zones d’une même région est suffisamment faible pour rendre efficace la communication synchrone entre services au sein de cette région
• Chaque zone peut être soit un cluster de machines appartenant à Uber, soit un cluster d’un fournisseur de cloud public, mais une zone donnée appartient toujours à un seul fournisseur
• En général, tous les microservices doivent pouvoir appeler d’autres services sans problème de latence tant qu’ils se trouvent dans la même région
• µDeploy ne centralisait pas le placement géographique des workloads, car les ingénieurs devaient toujours gérer le placement physique au niveau des Availability Zones
• Autrement dit, les ingénieurs de service devaient encore décider non seulement si un service devait tourner dans une zone on-premise, mais aussi dans quelle zone précise il devait s’exécuter
• En exploitant ses propres datacenters, Uber a dû faire face à des délais d’approvisionnement allongés à cause de la pénurie de puces et des problèmes de chaîne logistique
• Le 13 février 2023, Uber a annoncé des partenariats avec Oracle et Google pour réduire son exposition aux problèmes de chaîne d’approvisionnement et se diversifier
• Il était impossible de mettre en œuvre cette stratégie sans disposer d’« un système capable d’abstraire l’infrastructure sous-jacente » pour les milliers d’ingénieurs Uber développant des centaines de services différents au service de l’activité

Se préparer à migrer Uber vers le cloud

• Migrer 4 500 services stateless vers le cloud tout en continuant à faire tourner l’activité demandait une coordination et des efforts considérables
• Il était clair dès le départ que cette tâche serait sujette aux erreurs et presque impossible à gérer via une coordination manuelle
• Pour maintenir et gérer des microservices stateless à grande échelle, il fallait transformer les services afin qu’ils puissent être gérés automatiquement par un système de déploiement centralisé, sans intervention humaine
• Au-delà du stateless : la portabilité
  • À partir du modèle Region/Zone, Uber a introduit le concept de « portabilité »
  • Un service portable est un service capable de s’exécuter dans n’importe quelle zone d’une région et d’être déplacé automatiquement vers une nouvelle zone par la plateforme d’infrastructure, sans intervention humaine
  • Cela inclut les déplacements entre fournisseurs de cloud public, ainsi que vers et depuis des zones on-premise
  • Certains services n’étaient généralement pas portables, car ils dépendaient de la configuration des zones ou de préférences liées aux ressources de zone
  • Pour réaliser une migration automatique vers le cloud, tous les services devaient devenir portables

Rendre Uber portable

• En 2021 et 2022, Uber a mené un programme à l’échelle de l’ingénierie pour s’assurer que tous les services étaient portables
• Dans de nombreux cas, il suffisait d’une inspection du code recherchant l’usage de constantes de chaîne ou de noms de fichiers pour détecter des violations de portabilité
• Pour les cas simples, Uber a écrit des règles de lint mettant en évidence le code semblant codé en dur pour s’exécuter dans un emplacement physique spécifique
• Pour vérifier qu’un service était réellement portable, il fallait effectivement le déplacer entre plusieurs zones sans intervention humaine
• Uber a construit une suite d’outils de test permettant aux propriétaires de services d’initier le premier déplacement de leur service
  • Ces outils s’appuyaient sur les outils existants de déploiement progressif et sécurisé du code, ce qui permettait au propriétaire du service de revenir à tout moment à la zone d’origine et de corriger les problèmes détectés
  • Une fois le déplacement terminé avec succès, le service était marqué pour être déplacé automatiquement à l’avenir
• Au cours des années suivantes, Uber a répété ce processus pour tous ses services, jusqu’à le mener à terme pour l’ensemble de son parc
• Une fois ce travail achevé, il est devenu possible de modifier la topologie des zones sans intervention des ingénieurs de service
• Pour s’assurer que les services restent portables dans le temps, Uber les migre en continu entre les zones toutes les quelques semaines, afin de tester régulièrement cette capacité de déplacement
• Cela permet de détecter facilement les régressions, et avec le temps les ingénieurs se sont habitués à ne plus supposer un placement dans une zone particulière

Up: plan de contrôle fédéré multi-cloud et multi-tenant

• Uber a défini les objectifs initiaux suivants pour le système
  • Fournir un point d’entrée unique aux ingénieurs pour interagir avec les systèmes d’infrastructure
  • Gérer et appliquer les bonnes pratiques pour les services déployés directement sur le système, afin d’offrir un haut niveau de sécurité pendant les rollouts de code
  • Automatiser le placement des services entre les zones de disponibilité ; cela inclut la modification des placements vers de nouvelles zones lorsqu’elles deviennent disponibles, ainsi que la coordination centralisée des placements afin de soutenir globalement la haute disponibilité d’Uber
  • Automatiser les migrations d’infrastructure complexes, afin que les ingénieurs de service n’aient pas à y participer
• Architecture de haut niveau
  • Experience Layer:
    • Implémente les différentes façons dont les ingénieurs interagissent avec le système
    • UI, Continuous Delivery, robots chargés de maintenir le système en bon état, etc.
    • Un Balancer qui déplace en continu les workloads vers les clusters et zones les moins utilisés
    • Un Auto Scaler qui optimise en continu l’allocation de capacité pour chaque workload
  • Platform Layer:
    • Implémente les abstractions utilisées par la couche Experience pour interagir avec les services
    • Inclut les abstractions de service et d’environnement de service qui forment le modèle conceptuel des opérations de service, ainsi que l’API de niveau service elle-même
    • Dans la couche plateforme, les contraintes de service sont exprimées comme un état cible de haut niveau décrivant les propriétés souhaitées du déploiement réel
    • Elles peuvent inclure des contraintes sur les performances des machines à utiliser et sur la capacité totale de calcul allouée à un service par région
  • Federation Layer:
    • Implémente l’intégration avec les clusters de calcul
    • Organise tous les clusters selon leurs capacités et leur emplacement physique afin d’implémenter les abstractions de région et de zone utilisées par les couches supérieures
    • Prend l’état cible de haut niveau des services depuis la plateforme et le traduit en placements par zone et par cluster, en se basant sur les contraintes de l’état cible et sur l’état réel des clusters, y compris la capacité actuellement disponible et la capacité des clusters à satisfaire les contraintes auxiliaires
    • Le résultat de cette transformation peut évoluer dans le temps, et d’autres placements par zone et cluster peuvent devenir préférables plus tard
    • Tous les appels au Balancer et les autres actions initiées dans la couche Experience peuvent entraîner un nouveau calcul et une modification de ce placement
    • Pour garantir la sécurité du système et le bon état des services, un composant de gestion du changement met en œuvre un flux de rollout qui fait évoluer progressivement l’état global via des intégrations avec tous les systèmes qui surveillent la santé des services
    • Le processus de rollout comprend du canarying à l’échelle du système et la surveillance des signaux de santé ; si un problème est détecté, le système peut rapidement rollback le service vers sa configuration et son placement précédents
  • Regions
    • Les régions contiennent les instances réelles de clusters
    • Elles incluent des clusters Peloton et Kubernetes®
    • Ceux-ci sont externes à Up lui-même, mais constituent les cibles du placement réel de capacité et gèrent le placement des conteneurs sur les hôtes physiques

Résultats

• Uber a commencé à travailler sur Up en 2018, a livré un prototype fonctionnel début 2019, puis a officiellement lancé la plateforme à la mi-2020
• Depuis, plus de 4 000 services de toutes les lignes métier d’Uber ont été migrés depuis les anciennes plateformes de déploiement vers Up
• L’essentiel de cette migration ayant été automatisé, l’équipe a pu se concentrer sur les cas d’usage les plus avancés et aider les autres équipes dans leur migration
• Pendant cette période, la stabilité de la plateforme a été la priorité absolue, ce qui a permis d’exploiter l’activité de façon fiable alors que des millions d’utilisateurs utilisaient chaque jour les systèmes d’Uber
• La migration complète d’environ 2 000 000 de cœurs de calcul vers la nouvelle plateforme a duré environ deux ans et s’est achevée avec succès en 2022
• Grâce à cette migration, les efforts d’auto-scaling et d’optimisation ont restitué à l’activité l’équivalent de plusieurs dizaines de millions de dollars de capacité supplémentaire
• Des dizaines de milliers d’heures d’ingénierie auparavant consacrées aux mises à jour manuelles de services, à la création et au remplissage de nouvelles zones, et à l’apprentissage de la navigation dans l’environnement d’infrastructure complexe d’Uber ont été économisées, générant ainsi des économies substantielles

Et ensuite

• Après avoir achevé la migration de µDeploy vers Up, l’équipe peut désormais se concentrer sur la création de solutions applicables à l’ensemble des services de manière centralisée et automatisée, ainsi que sur l’expérience utilisateur autour de ces capacités
• Migration vers le cloud
  • Uber est en train de déplacer une part significative de sa flotte vers le cloud
  • Grâce à l’automatisation à grande échelle et à la couche d’abstraction fournie par Up, les équipes de service peuvent se détacher en grande partie des détails d’infrastructure requis par cette transition
• Continuous Delivery automatisée
  • L’objectif est d’automatiser complètement le déploiement du code jusqu’en production en utilisant des pipelines automatisés exécutant divers contrôles et tests avant la mise en production
  • Un point d’attention particulier pour 2023 est de maintenir les services « à jour », afin que tout le code exécuté en production bénéficie des dernières mises à jour de sécurité et de bibliothèques
• Sécurité des déploiements
  • Les données existantes montrent qu’une part importante des incidents observés est liée à des changements de code et de configuration
  • L’objectif est d’automatiser les aspects manuels du cycle de vie des services, comme l’exécution de tests pré-production ou la mise en place de politiques de rollout progressif, afin de réduire fortement la proportion de défauts atteignant réellement la production
• Plateforme
  • Regrouper toute la flotte de services stateless d’Uber sous une seule plateforme ombrelle permet de modéliser plus clairement les dépendances et interactions entre les produits de plateforme d’infrastructure
  • Cela permet non seulement de fournir un modèle unifié dans le code, mais aussi une expérience utilisateur entièrement intégrée au reste de l’organisation d’ingénierie
  • Le prochain grand objectif de l’équipe est de pouvoir observer et exploiter toute l’infrastructure depuis un seul endroit

Conclusion

• L’effort de construction de la plateforme Up représente désormais un changement culturel significatif : tous les services stateless sont progressivement déployés avec les mêmes bonnes pratiques et la même automatisation
• Des tâches qui demandaient auparavant plusieurs mois de travail, comme modifier des politiques de rollout ou créer une automatisation pour des rollouts massifs de bibliothèques, sont désormais possibles de manière centralisée
• Uber espère continuer à travailler étroitement avec les parties prenantes d’Up et les propriétaires de services afin de concrétiser la vision selon laquelle les ingénieurs Uber pourront se concentrer uniquement sur le code, sans se soucier de l’infrastructure