Wie Uber Tausende von Microservices auf eine Multi-Cloud-Plattform migriert hat

• "Up: Portable Microservices Ready for the Cloud"
• Bei Uber stellen 4.500 Ingenieur:innen und zahlreiche automatisierte Systeme jede Woche mehr als 4.000 Deployments von 4.500 zustandslosen Microservices bereit
• Diese Services werden von Hunderten einzelner Teams entwickelt, bereitgestellt und betrieben, die weltweit unabhängig voneinander arbeiten
• Die Services unterscheiden sich in Größe, Form und Funktion: Einige sind klein und werden für interne Aufgaben genutzt, andere sind groß und für umfangreiche Echtzeitberechnungen im Einsatz

Die Geschichte von Ubers zustandslosen Services

• 2014 bestand Uber aus einem in Python geschriebenen Monolithen, der seine Daten in einer einzigen PostgreSQL-DB speicherte
• Mit dem Wachstum stellte das Unternehmen mehr Ingenieur:innen ein und wechselte zu einer Microservice-Architektur
• Als die Zahl der Services zunahm, entwickelte Uber ein Tool namens µDeploy, um Code zentral und in großem Maßstab auszurollen
  • Es containerisierte alle zustandslosen Services und abstrahierte Host-Verwaltung und Platzierung
  • Dadurch konnte die Infrastrukturgruppe die Host-Flotte unabhängig von den geschäftsbezogenen Microservices verwalten
  • Das Service-Management und die Platzierung blieben jedoch weiterhin manuell
• Ubers Infrastruktur folgt einem Modell, bei dem Gruppen von Zonen eine Region bilden
• Die Latenz zwischen Zonen innerhalb einer Region ist kurz genug, dass synchrone Kommunikation zwischen Services in derselben Region effizient ist
• Jede Zone kann entweder ein Cluster aus Maschinen sein, die Uber selbst besitzt, oder aus einer Public-Cloud-Umgebung stammen; eine einzelne Zone gehört jedoch immer nur zu einem einzigen Anbieter
• Grundsätzlich sollten alle Microservices andere Services ohne Latenzprobleme aufrufen können, solange sie sich in derselben Region befinden
• Mit µDeploy war die geografische Platzierung von Workloads im System nicht zentralisiert, weil Ingenieur:innen die physische Platzierung weiterhin auf Ebene der Availability Zone verwalten mussten
• Das heißt, Service-Ingenieur:innen mussten nicht nur entscheiden, ob ein Service in einer On-Premises-Zone läuft, sondern auch in welcher konkreten Zone er ausgeführt wird
• Beim Betrieb eigener Rechenzentren führten Chipmangel und Probleme in der Lieferkette zu langen Vorlaufzeiten
• Am 13. Februar 2023 ging Uber Partnerschaften mit Oracle und Google ein, um die Abhängigkeit von Lieferkettenproblemen zu verringern und sich breiter aufzustellen
• Ohne ein "System, das die zugrunde liegende Infrastruktur abstrahieren kann", wäre die Umsetzung dieser Strategie mit Tausenden Uber-Ingenieur:innen, die Hunderte unterschiedlicher Services für das Geschäft entwickeln, unmöglich gewesen

Vorbereitung auf Ubers Wechsel in die Cloud

• Die Migration von 4.500 zustandslosen Services in die Cloud bei laufendem Geschäftsbetrieb erforderte enorme Koordination und Anstrengung
• Von Anfang an war klar, dass diese Arbeit fehleranfällig ist und sich mit manuell koordinierten Maßnahmen kaum bewältigen lässt
• Um zustandslose Microservices in großem Maßstab zu betreiben und zu verwalten, mussten die Services so weiterentwickelt werden, dass ein zentrales Deployment-System sie automatisch und ohne menschliches Eingreifen verwalten kann
• Über Stateless hinaus zu Portability
  • Auf Basis des Modells aus Regionen und Zonen entstand das Konzept der "Portability"
  • Portability bezeichnet Services, die in jeder Zone einer Region laufen können und vom Infrastruktur-Framework ohne menschliches Eingreifen automatisch in neue Zonen verschoben werden können
  • Dazu gehören Wechsel zwischen Public-Cloud-Anbietern ebenso wie Verschiebungen in und aus On-Premises-Zonen
  • Einige Services waren im Allgemeinen nicht portabel, weil sie von Zonenkonfigurationen und Präferenzen für Zonenressourcen abhingen
  • Um eine automatische Migration in die Cloud durchzuführen, mussten alle Services portabel werden

Uber portabel machen

• 2021 und 2022 wurde unternehmensweit ein Programm durchgeführt, um sicherzustellen, dass alle Services portabel sind
• In vielen Fällen ließ sich ein Verstoß gegen die Portabilität bereits durch Code-Inspektion erkennen, etwa durch die Prüfung auf String-Konstanten und Dateinamen im Code
• Für einfache Fälle wurden Linter-Regeln geschrieben, die Code hervorheben, der offenbar fest auf die Ausführung an einem bestimmten physischen Standort verdrahtet ist
• Um zu testen, ob ein Service tatsächlich portabel ist, musste er tatsächlich ohne menschliches Eingreifen zwischen mehreren Zonen verschoben werden
• Es wurde ein Test-Toolset aufgebaut, mit dem Service-Eigentümer die erste Verschiebung ihres Service anstoßen konnten
  • Es basierte auf vorhandenen Tools für sichere und schrittweise Code-Rollouts, sodass Service-Eigentümer Deployments jederzeit in die ursprüngliche Zone zurücksetzen und Probleme beheben konnten, falls welche gefunden wurden
  • Wurde die Verschiebung erfolgreich abgeschlossen, wurde der betreffende Service künftig für automatische Verschiebungen markiert
• In den folgenden Jahren wiederholte Uber diesen Prozess für alle Services, bis schließlich alle vollständig abgeschlossen waren
• Nach Abschluss der Arbeiten konnten Zonentopologien ohne Eingriff von Service-Ingenieur:innen geändert werden
• Damit Services ihre Portabilität dauerhaft behalten, werden alle Services alle paar Wochen kontinuierlich zwischen Zonen migriert, um die Verschiebbarkeit regelmäßig zu testen
• Dadurch lassen sich Regressionen leicht erkennen, und mit der Zeit gewöhnten sich Ingenieur:innen daran, für ihre Services keine feste Zonenplatzierung mehr vorauszusetzen

Up: Multi-Cloud Multi-Tenant Federation Control Plane

• Es wurden folgende anfängliche Systemziele festgelegt
  • Bereitstellung eines Single Point of Entry, über den Ingenieur:innen mit dem Infrastruktursystem interagieren können
  • Verwaltung und Durchsetzung von Best Practices für direkt im System bereitgestellte Services, um ein hohes Maß an Sicherheit bei Code-Rollouts zu gewährleisten
  • Automatisierung der Service-Platzierung über Availability Zones hinweg; dazu gehört auch, Platzierungen zentral zu koordinieren und bei Verfügbarkeit neuer Zonen auf diese umzuschalten, um Ubers hohe Verfügbarkeit zu unterstützen
  • Automatisierung aufwendiger Migrationen auf Infrastrukturebene, sodass Service-Ingenieur:innen nicht an Migrationen beteiligt sein müssen
• Architektur auf hoher Ebene
  • Experience Layer:
    • Implementiert die verschiedenen Wege, über die Ingenieur:innen mit dem System interagieren
    • Dazu gehören UI, Continuous Delivery und Bots, die das System in gutem Zustand halten
    • Ein Balancer verschiebt Workloads kontinuierlich in weniger ausgelastete Cluster und Zonen
    • Ein Auto Scaler optimiert fortlaufend die Kapazitätszuweisung für jeden Workload
  • Platform Layer:
    • Implementiert die Abstraktionen, die der Experience Layer zur Interaktion mit Services nutzt
    • Enthält die Abstraktionen für Services und Service-Umgebungen, die das konzeptionelle Modell des Service-Betriebs bilden, sowie die Service-Level-API selbst
    • In der Platform Layer werden Service-Constraints als übergeordneter Zielzustand ausgedrückt, der die gewünschten Eigenschaften realer Service-Platzierungen beschreibt
    • Dazu können Constraints hinsichtlich der Leistung der auszuführenden Maschinen und der gesamten Compute-Kapazität für Services in einer Region gehören
  • Federation Layer:
    • Implementiert die Integration mit Compute-Clustern
    • Um die in den oberen Schichten verwendeten Abstraktionen von Regionen und Zonen bereitzustellen, werden alle Cluster nach Funktion und physischer Platzierung organisiert
    • Sie übernimmt den hochrangigen Zielzustand von Services aus der Platform und übersetzt ihn in Zonen- und Cluster-Platzierungen; diese Übersetzung basiert auf den Constraints des Zielzustands und dem realen Zustand der Cluster, einschließlich aktuell verfügbarer Kapazität und der Cluster, die Cluster- und Nebenbedingungen erfüllen können
    • Das Ergebnis dieser Übersetzung kann sich im Laufe der Zeit ändern, und später können andere Zonen- und Cluster-Platzierungen wünschenswerter sein
    • Jede Ausführung des Balancers und andere vom Experience Layer angestoßene Aufgaben können diese Platzierung neu berechnen und ändern
    • Damit das System sicher bleibt und Services in gutem Zustand bleiben, implementiert eine Change-Management-Komponente über Integrationen mit allen Systemen zur Überwachung des Service-Zustands einen Rollout-Ablauf, der den globalen Zustand schrittweise verändert
    • Der Rollout-Prozess umfasst Canarying und die Überwachung von Health-Signalen im gesamten System; werden Probleme erkannt, rollt das System den Service schnell auf die Konfiguration und Platzierung zurück, die vor Beginn der Änderung aktiv waren
  • Regions
    • Regionen enthalten die tatsächlichen Cluster-Instanzen
    • Dazu gehören Peloton- und Kubernetes®-Cluster
    • Sie liegen außerhalb von Up selbst, sind aber das Ziel der tatsächlichen Kapazitätsplatzierung und verwalten die Container-Platzierung auf physischen Hosts

Wirkung

• Die Arbeit an Up begann 2018, Anfang 2019 wurde ein funktionierender Prototyp geliefert, und Mitte 2020 wurde die Plattform offiziell eingeführt
• Seitdem wurden mehr als 4.000 Services aus allen Geschäftsbereichen von Uber von der bisherigen Deployment-Plattform auf Up migriert
• Da der Großteil dieser Migration automatisiert war, konnte sich das Team auf die fortgeschrittensten Anwendungsfälle konzentrieren und zugleich andere Teams bei ihren Migrationen unterstützen
• Während dieses Zeitraums hatte die Stabilität der Plattform höchste Priorität, sodass das Geschäft bei Millionen täglicher Nutzer:innen der Uber-Systeme zuverlässig weiterbetrieben werden konnte
• Die vollständige Migration von rund 2.000.000 Compute-Kernen auf die neue Plattform dauerte etwa zwei Jahre und wurde 2022 erfolgreich abgeschlossen
• Durch diese Migration konnten dem Geschäft über automatische Skalierung und Effizienzsteigerungen zusätzliche Kapazitäten im Wert von mehreren zehn Millionen Dollar zurückgegeben werden
• Außerdem wurden Zehntausende Stunden Engineering-Zeit eingespart, die zuvor für manuelle Service-Updates, das Einrichten und Befüllen neuer Zonen sowie das Erlernen des Umgangs mit Ubers komplexer Infrastrukturumgebung aufgewendet wurden, was erhebliche Kosten sparte

Was als Nächstes kommt

• Nach Abschluss der Migration von µDeploy zu Up kann sich das Team nun darauf konzentrieren, Lösungen und darauf aufbauende Nutzererfahrungen zu entwickeln, die sich zentralisiert und automatisiert auf den gesamten Service-Bestand anwenden lassen
• Cloud-Migration
  • Uber verlagert einen erheblichen Teil seiner Flotte in die Cloud
  • Dank groß angelegter Automatisierung und der von Up bereitgestellten Abstraktionsschicht können sich Service-Teams weitgehend von den für diesen Übergang nötigen Infrastrukturdetails lösen
• Automatisiertes Continuous Delivery
  • Ziel ist die vollständige Automatisierung von Code-Deployments bis in die Produktion, indem mit automatisierten Pipelines verschiedene Prüfungen und Tests ausgeführt werden, bevor Code in Produktion geht
  • Ein besonderer Schwerpunkt für 2023 ist es, Services "aktuell" zu halten, sodass aller in Produktion laufender Code durch die neuesten Sicherheits- und Bibliotheks-Updates auf dem neuesten Stand bleibt
• Deployment-Sicherheit
  • Vorhandene Daten zeigen, dass ein erheblicher Teil der beobachteten Incidents mit Änderungen an Code und Konfiguration zusammenhängt
  • Ziel ist es, manuelle Aspekte des Service-Lebenszyklus zu automatisieren, etwa Pre-Production-Tests oder Richtlinien für schrittweise Rollouts, um den Anteil von Fehlern, die tatsächlich Produktion erreichen, deutlich zu senken
• Plattform
  • Wenn Ubers gesamte Flotte zustandsloser Services unter einer einzigen übergreifenden Plattform organisiert wird, lassen sich Abhängigkeiten und Wechselwirkungen zwischen Infrastrukturplattform-Produkten klarer modellieren
  • Das ermöglicht nicht nur ein einheitliches Modell im Code, sondern auch eine vollständig integrierte Nutzererfahrung für den Rest der Engineering-Organisation
  • Das nächste große Ziel des Teams ist es, die gesamte Infrastruktur an einem Ort beobachten und betreiben zu können

Fazit

• Die Arbeit am Aufbau der Up-Plattform steht inzwischen für einen bedeutenden kulturellen Wandel, da nun alle zustandslosen Services schrittweise mit denselben Best Practices und derselben Automatisierung ausgerollt werden
• Änderungen an Rollout-Richtlinien oder der Aufbau von Automatisierung für groß angelegte Library-Rollouts, die früher Monate Arbeit erforderten, sind nun auf zentralisierte Weise möglich
• Man freut sich darauf, weiterhin eng mit den Stakeholdern von Up und den Service-Eigentümern zusammenzuarbeiten, um die Vision zu verwirklichen, dass Uber-Ingenieur:innen sich ausschließlich auf Code konzentrieren können, ohne sich um Infrastruktur sorgen zu müssen