Überblick und Einblicke in Metas Hyperscale-Infrastruktur

• Metas Engineering-Kultur betont schnelle Umsetzung, technologische Offenheit, Forschung in der Produktionsumgebung und eine gemeinsame Infrastruktur
• Zur Steigerung der Produktivität der Entwickler setzt Meta auf Continuous Deployment und ermöglicht so mehr Entwicklern, serverlose Funktionen statt klassischen Service-Codes zu schreiben
• Zur Senkung der Hardwarekosten nutzt Meta Hardware-Software-Co-Design im Rechenzentrumsmaßstab und optimiert die Ressourcenzuweisung automatisch über Rechenzentren weltweit hinweg, statt sie auf einzelne Cluster zu beschränken
• Metas AI-Strategie co-designt den gesamten Stack – von PyTorch über AI-Beschleuniger und Netzwerke bis hin zu ML-Modellen wie Llama

# [Engineering-Kultur]

Schnelle Umsetzung (Move Fast)

• Meta pflegt weiterhin eine „Move Fast“-Kultur, die Agilität und schnelle Iteration betont
• Das Unternehmen unterstützt nachdrücklich Continuous Deployment, also die Bereitstellung des neuesten Codes in der Produktion so schnell wie möglich
• Produktingenieure schreiben zustandslose serverlose Funktionen in Sprachen wie PHP, Python und Erlang
• Prioritäten können auch ohne lange Planungsphasen geändert werden, und unsichere Probleme werden durch iterative Umsetzung gelöst
• Dieser Ansatz ermöglicht schnelle Reaktionen auf den Markt und zügige Produkt-Launches

Technologische Offenheit (Technology Openness)

• Interne Offenheit: Meta verwendet einen Monorepo-Ansatz, bei dem der Code aller Projekte in einem einzigen Repository gespeichert wird
  • Das erleichtert Codesuche, Wiederverwendung und teamübergreifende Zusammenarbeit
  • In den meisten Projekten gibt es keine strikten Einschränkungen beim Code Ownership, sodass Entwickler frei beitragen können
• Externe Offenheit: Meta teilt aktiv Open-Source-Hardware- und -Softwareprojekte
  • Über das Open Compute Project werden Hardware-Designs offengelegt
  • Meta betreibt verschiedene Open-Source-Softwareprojekte wie PyTorch, Llama, Presto, RocksDB und Cassandra
  • Über Forschungspapiere werden Infrastrukturtechnologien geteilt

Forschung in der Produktion (Research in Production)

• Meta betreibt Forschung in realen Produktionsumgebungen, ohne ein eigenes Systemforschungslabor
• Die Teams, die Produktionssysteme entwickeln, verfassen selbst Forschungsarbeiten und lösen reale Probleme und liefern Lösungen, die in großskaligen Betriebsumgebungen validiert sind
• Dieser Ansatz ist praxisnah und erfüllt die zentralen Kriterien erfolgreicher Systemforschung

Gemeinsame Infrastruktur (Common Infrastructure)

• Anstatt einzelnen Teams zu erlauben, frei ihren Technologie-Stack zu wählen, priorisiert Meta Standardisierung und globale Optimierung
• Hardware:
  • Alle Server werden aus einem gemeinsamen Server-Pool zugewiesen
  • Für Nicht-AI-Compute-Workloads gibt es einen einzigen Servertyp (grundsätzlich 1 CPU, 256 GB DRAM), um die Komplexität der Servertypen zu reduzieren
• Software:
  • Früher wurden verschiedene Key-Value-Stores wie Cassandra, HBase und ZippyDB genutzt, inzwischen wurde dies auf ZippyDB konsolidiert
  • Softwarebereitstellung, Konfigurationsmanagement, Service Mesh, Performance-Tests und Ähnliches sind in gemeinsamen Tools vereinheitlicht
• Bevorzugung wiederverwendbarer Komponenten:
  • Meta hat eine Kette wiederverwendbarer Komponenten aufgebaut, bestehend aus Tectonic Dateisystem → ZippyDB (Metadatenspeicherung) → Shard Manager (Verwaltung des Daten-Shardings) → ServiceRouter (Shard-Erkennung und Request-Routing) → Delos (hochzuverlässiger Datenspeicher)
  • Statt monolithischer Systeme wie HDFS werden modulare, wiederverwendbare Komponenten eingesetzt, um die Skalierbarkeit zu maximieren

Kultur-Fallstudie: Entwicklung der Threads-App (Culture Case Study: The Threads App)

• Der Entwicklungsfall der Threads-App zeigt Metas Engineering-Kultur anschaulich
• Die technische Arbeit wurde in nur fünf Monaten abgeschlossen, und nach einer Vorankündigung zwei Tage vorher war das Infrastrukturteam bereit für das Produktions-Deployment
• In den meisten Großunternehmen ist es schon schwierig, in zwei Tagen überhaupt einen Projektplan zu schreiben. Meta richtete jedoch einen War Room zur Problemlösung in Echtzeit ein und reagierte schnell
• Das Ergebnis: 100 Millionen Nutzer in nur fünf Tagen nach dem Launch, womit Threads zur am schnellsten wachsenden App der Geschichte wurde
• Threads konnte durch Wiederverwendung bestehender Infrastruktur schnell skalieren:
  • Instagrams Python-Backend
  • Metas gemeinsame Infrastruktur (Social-Graph-Datenbank, Key-Value-Store, serverlose Plattform, ML-Plattform, Konfigurationsmanagement für mobile Apps usw.)
• Interne Offenheit: Durch Nutzung des Monorepo konnten Teile des Instagram-Codes wiederverwendet und die Entwicklung beschleunigt werden
• Externe Offenheit: Mit ActivityPub wird Interoperabilität mit anderen Apps angestrebt
• Teilen von Entwicklungserfahrungen: Die Erfahrungen mit schneller Entwicklung und Bereitstellung wurden öffentlich geteilt

# [End-to-End-Flow von Nutzeranfragen (End-to-End User Request Flow)]

• Um Metas Infrastrukturtechnologien genauer zu betrachten, wird der gesamte Ablauf der Verarbeitung einer Nutzeranfrage beschrieben
• Metas Produkte werden von einer gemeinsamen Service-Infrastruktur unterstützt, die verschiedene zentrale Komponenten umfasst

Request-Routing

• Dynamisches DNS-Mapping (Dynamic DNS Mapping)
  • Wenn ein Nutzer facebook.com aufruft, gibt Metas DNS-Server dynamisch die IP-Adresse des nächstgelegenen PoP (Point of Presence) zurück
  • Ein PoP ist ein kleines Edge-Rechenzentrum, das die Netzwerklast in Nutzernähe verteilt
  • PoPs halten langfristige TCP-Verbindungen zu Metas Rechenzentren aufrecht, wodurch die Zeit für den TCP-Verbindungsaufbau reduziert und die Netzwerkleistung verbessert wird
  • Weltweit sind Hunderte von PoPs verteilt, wodurch den meisten Nutzern geringe Netzwerklatenzen geboten werden
• Caching statischer Inhalte (Static-Content Caching)
  • Statische Inhalte wie Bilder und Videos werden im PoP gecacht und können direkt ausgeliefert werden
  • Meta betreibt außerdem ein CDN (Content Delivery Network) und arbeitet mit ISPs (Internet Service Providern) zusammen, um CDN-Standorte aufzubauen
  • Wenn die Anfrage eines Nutzers facebook.com/image.jpg lautet, schreibt Meta sie zu CDN109.meta.com/image.jpg um, damit der Inhalt von einem nahegelegenen CDN-Standort ausgeliefert wird
  • Falls sich der Inhalt nicht im CDN befindet, wird die Anfrage an PoP → Load Balancer im Rechenzentrum → Speichersystem weitergeleitet
• Routing dynamischer Inhaltsanfragen (Dynamic-Content Request Routing)
  • Anfragen nach dynamischen Inhalten wie dem News Feed werden vom PoP an ein Rechenzentrum weitergeleitet
  • Traffic-Engineering-Tools wählen unter Berücksichtigung von Rechenzentrumskapazität und Netzwerklatenz das optimale Rechenzentrum aus
  • Der Traffic vom PoP zum Rechenzentrum wird über Metas privates WAN (Wide Area Network) übertragen
  • Der Traffic zwischen Rechenzentren ist deutlich höher als der Traffic zwischen Nutzer und PoP, was auf Datenreplikation und Interaktionen zwischen Microservices zurückzuführen ist

Infrastruktur-Topologie (Infrastructure Topology)

• Metas globale Infrastruktur besteht aus Infrastrukturkomponenten auf verschiedenen Ebenen
• Jede Komponente erfüllt eine bestimmte Rolle und wird in folgendem Umfang betrieben:
  • Datacenter-Region: Weltweit gibt es etwa 10 Datacenter-Regionen, und jede Region kann bis zu 1 Million Server betreiben
  • PoP (Point of Presence, Edge-Datacenter): Es gibt mehr als 100 PoPs, und jeder PoP umfasst in der Regel 100 bis 1.000 Server. Sie verarbeiten Traffic in der Nähe der Nutzer, um die Latenz zu verringern
  • CDN-Standort: Es gibt mehr als 1.000 CDN-Standorte, die in der Regel mehr als 10 Server umfassen; einige größere Standorte betreiben mehr als 100 Server. Sie cachen statische Inhalte (Bilder, Videos usw.) und liefern sie schnell aus
  • Datacenter: In jeder Datacenter-Region befinden sich mehrere Datacenter, und jedes Datacenter kann etwa mehr als 100.000 Server betreiben
  • MSB (Main Switchboard): Innerhalb eines Datacenters gibt es bis zu 12 MSBs, und jedes MSB ist für 10.000 bis 20.000 Server zuständig. Es übernimmt die Stromverteilung und fungiert als wichtiges Failure-Domain-Element im Datacenter. Fällt ein MSB aus, können bis zu 20.000 Server ausfallen
• Edge-Netzwerk:
  • PoPs sind mit mehreren Internet-Autonomous Systems (AS) verbunden und nutzen BGP (Border Gateway Protocol), um den optimalen Pfad zu wählen
• Datacenter-Netzwerk:
  • Die Server sind über eine dreistufige Clos-Topologie verbunden
  • Das Netzwerk ist so ausgelegt, dass es Staus vermeidet und maximale Bandbreite zwischen Servern bietet
• Regionales Netzwerk:
  • Datacenter sind über Fabric Aggregators verbunden, damit sie mit dem WAN kommunizieren können
  • Verwendet eine Fat-Tree-Topologie, um eine schrittweise Skalierung zu ermöglichen

Request-Verarbeitung (Request Processing)

• Online-Verarbeitung (Online Processing)
  • Nutzeranfragen werden über Load Balancer auf zehntausende serverlose Frontend-Funktionen (FrontFaaS) verteilt
  • Die Frontend-Funktionen können mehrere Backend-Services aufrufen und auch ML-Inferenz-Services (z. B. für Anzeigenempfehlungen oder Newsfeed-Inhaltsempfehlungen) nutzen
  • Während der Ausführung fügen die Frontend-Funktionen Ereignisse zu einer Event Queue hinzu, sodass ereignisgesteuerte serverlose Funktionen (XFaaS) asynchron ausgeführt werden
  • Das Serververhältnis von Frontend-Funktionen zu ereignisgesteuerten Funktionen liegt bei etwa 5:1
• Offline-Verarbeitung (Offline Processing)
  • Das Offline-Verarbeitungssystem unterstützt das Online-System und führt Datenanalyse sowie Machine-Learning-Training durch
  • Frontend-Funktionen und Backend-Services speichern verschiedene Log-Daten im Data Warehouse
    • ML-Training: Log-Daten werden genutzt, um Machine-Learning-Modelle zu aktualisieren
    • Stream Processing: Aktualisiert die meistdiskutierten Themen auf der Plattform und speichert sie in Datenbanken und Caches
    • Batch-Analyse: Aktualisiert mit Spark und Presto das System für Freundesempfehlungen
    • Ausführung ereignisgesteuerter serverloser Funktionen: Datenaktualisierungen dienen als Event-Trigger und führen automatisch serverlose Funktionen aus

# [Steigerung der Entwicklerproduktivität (Boosting Developer Productivity)]

• Metas gemeinsame Infrastruktur hat das Ziel, die Entwicklerproduktivität zu maximieren
• Dazu werden Continuous Deployment und serverlose Funktionen bis an die Grenzen genutzt

Continuous Deployment

• Meta ist darauf optimiert, Code- und Konfigurationsänderungen schnell auszurollen
• Neue Funktionen und Bugfixes werden sofort bereitgestellt, was schnelles Feedback und iterative Verbesserungen ermöglicht
• Konfigurationsänderungen (Configuration Changes)
  • Metas Konfigurationsmanagement-Tool spielt täglich mehr als 100.000 Echtzeitänderungen in die Produktion aus
  • Auf mehr als 10.000 Services und Millionen von Servern werden Konfigurationen automatisch aktualisiert
  • Load Balancing, Feature-Rollouts, A/B-Tests, Überlastschutz und viele weitere Aufgaben werden automatisch ausgeführt
  • Konfigurationsänderungen werden wie Codeänderungen geprüft und in das Code-Repository committet, und die Änderungen werden innerhalb von Sekunden im gesamten System verteilt
• Codeänderungen (Code Changes)
  • Metas Deployment-Tool betreibt mehr als 30.000 Deployment-Pipelines, um Software-Updates zu verwalten
  • 97 % der Services setzen auf vollständig automatisierte Deployments und werden ohne manuelle Eingriffe aktualisiert:
    • 55 % verwenden vollständiges Continuous Deployment (CD), sodass Codeänderungen automatisch in die Produktion gelangen
    • 42 % werden nach einem festen Zeitplan (täglich oder wöchentlich) automatisch ausgerollt
  • Frontend-Serverless-Funktionen (FrontFaaS) laufen auf mehr als 500.000 Servern, und mehr als 10.000 Entwickler führen täglich tausende Code-Commits durch
  • Selbst in dieser dynamischen Umgebung wird von allen serverlosen Funktionen alle 3 Stunden eine neue Version in die Produktion ausgerollt
• Updates für Netzwerk- und Infrastruktur-Software
  • Metas privates WAN (Private WAN) unterhält mehrere parallele Netzwerk-Planes, sodass neue Netzwerkalgorithmen unabhängig getestet werden können
  • Auch die Netzwerk-Switch-Software wird häufig aktualisiert; mithilfe der "Warm Boot"-Funktion der Switches kann Software aktualisiert werden, ohne den Netzwerk-Traffic zu unterbrechen
  • Häufige Updates von Code und Konfigurationsänderungen erhöhen das Risiko von Standortausfällen, daher investiert Meta stark in Tests, stufenweise Rollouts und Health Checks
    • Es wurde eine interne Kampagne durchgeführt, um die Automatisierung von Code-Deployments von 12 % auf 97 % zu steigern
    • Für alle Konfigurationsänderungen werden automatische Canary-Tests durchgeführt, um die Stabilität sicherzustellen

Serverless Functions

• Serverless Functions (oder FaaS, Function-as-a-Service) sind ein weiterer Schlüsselfaktor zur Steigerung der Entwicklerproduktivität
• Im Gegensatz zu traditionellen Backend-Services speichern Serverless Functions keinen Zustand und implementieren eine einfache Funktionsschnittstelle
• Jeder Funktionsaufruf wird unabhängig ausgeführt, während der Zustand über externe Datenbanken oder Cache-Systeme verwaltet wird
• Vorteile von Serverless Functions
  • Entwickler müssen nur die Produktlogik schreiben, ohne Infrastruktur zu verwalten
  • Code-Deployment und Auto-Scaling bei Lastschwankungen erfolgen automatisch
  • Hardwareverschwendung wird vermieden, und Entwickler müssen keine übermäßigen Ressourcen zuweisen
• Metas Serverless-Plattform
  • Bei Meta gibt es unter den mehr als 10.000 Entwicklern 50 % mehr Entwickler, die Serverless Functions schreiben, als solche, die traditionellen Service-Code schreiben
  • Metas Serverless-Entwicklungsumgebung (IDE) unterstützt den einfachen Zugriff auf die Social-Graph-Datenbank und verschiedene Backend-Systeme und bietet Continuous-Integration-Tests (CI), die schnelles Feedback ermöglichen
• Metas Serverless-Plattform: FrontFaaS und XFaaS
  • FrontFaaS: PHP-basierte Frontend-Serverless-Functions, die auf mehr als 500.000 Servern laufen
    • Die PHP-Runtime bleibt dauerhaft aktiv, sodass Anfragen ohne Cold-Start-Probleme sofort verarbeitet werden können
    • Bei geringer Serverlast werden durch Auto-Scaling einige Server freigegeben und für andere Aufgaben genutzt
  • XFaaS: ereignisbasierte Serverless Functions, die asynchron ausgeführt werden
    • Sie verarbeiten Hintergrundaufgaben, die keine unmittelbare Antwort benötigen
    • Um stark belastende Aufgaben zu vermeiden, werden Ausführungen verzögert oder Global Load Balancing sowie quotenbasiertes Throttling angewendet
• Metas Serverless-Innovationen
  • Seit den späten 2000er-Jahren wird der Serverless-Ansatz als grundlegendes Entwicklungsparadigma verwendet
  • Unterschiede zu Serverless-Plattformen in der Public Cloud:
    • In der Public Cloud wird für starke Isolation eine virtuelle Maschine pro Funktion verwendet
    • Meta hingegen maximiert die Hardwareeffizienz, indem mehrere Funktionen gleichzeitig in einem einzigen Linux-Prozess ausgeführt werden können

# [Hardwarekosten senken (Reducing Hardware Costs)]

• Metas gemeinsam genutzte Infrastruktur steigert nicht nur die Entwicklerproduktivität, sondern spielt auch eine wichtige Rolle bei der Senkung der Hardwarekosten
• Dafür wird eine Strategie genutzt, die Hardwareeffizienz durch Softwareoptimierung maximiert

Alle globalen Rechenzentren wie einen Computer betreiben (All Global Datacenters as a Computer)

• In herkömmlichen Cloud-Umgebungen mussten Nutzer die Anzahl der Service-Replikate (replica), Bereitstellungsregionen usw. selbst festlegen
• Diese Form manueller Verwaltung verursacht Probleme wie Ressourcenverschwendung, Lastungleichgewichte und unzureichende Migration zwischen Rechenzentren
• Meta hat den bestehenden Ansatz "Datacenter as a Computer" (DaaC), bei dem ein Rechenzentrum wie ein Computer betrieben wird, weiterentwickelt und Global-DaaC umgesetzt, bei dem "weltweite Rechenzentren wie ein einziger Computer betrieben werden"
• Wesentliche Merkmale von Global-DaaC:
  • Wenn Nutzer einfach eine globale Bereitstellung anfordern, entscheidet die Infrastruktur automatisch über die optimale Anzahl von Replikaten, Bereitstellungsregionen, Hardwaretypen und das Traffic Routing
  • Der Standort von Services wird bei Bedarf verändert, wodurch Angebots- und Laständerungen flexibel angepasst werden kann
  • Anders als in der Public Cloud betreibt Meta alle Anwendungen selbst und kann Workloads daher flexibler verschieben
• Umsetzung von Global-DaaC
  • Automatisierung der Ressourcenzuweisung auf globaler, regionaler und einzelner Serverebene:
    • Globale Kapazitätsmanagement-Tools: Sie analysieren mit RPC-Tracing Abhängigkeiten zwischen Services und bestimmen per Mixed-Integer Programming (MIP) die optimale Kapazitätsverteilung
    • Regionale Kapazitätsmanagement-Tools: Sie weisen Rechenzentrumsressourcen zu und bilden virtuelle Cluster (Virtual Cluster)
    • Container-Management-Tools: Sie platzieren Container innerhalb virtueller Cluster und sorgen durch verteilte Platzierung über mehrere Rechenzentren für Fault Tolerance
    • Kernel-Management-Techniken: Sie teilen und isolieren Speicher- und I/O-Ressourcen zwischen Containern angemessen
• Anwendungsfälle von Global-DaaC
  • Datenbanken und zustandsbehaftete Services:
    • Jeder Container hostet mehrere Daten-Shards (shard), um die Effizienz zu maximieren
    • Global Service Placer (GSP) bestimmt die optimale Anzahl an Shard-Replikaten und deren Platzierungsregionen
    • Das Sharding-Framework weist darauf basierend Shards Containern zu und migriert sie dynamisch
  • Machine-Learning-(ML)-Workloads:
    • ML-Inferenz-Workloads verwalten Modellreplikate ähnlich wie Daten-Shards
    • Beim ML-Training müssen Daten und GPU im selben Rechenzentrum platziert sein
    • Nach Erhalt global zugewiesener GPU-Kapazität führt der ML-Trainings-Scheduler die optimale Datenreplikation und GPU-Platzierung durch

Hardware-Software-Co-Design

• Auf Ebene einzelner Server ist Hardware-Software-Co-Design üblich, Meta skaliert diesen Ansatz jedoch auf globale Größenordnung und überwindet die Grenzen kostengünstiger Hardware durch Software-Optimierung
• Kostengünstige Fehlertoleranz (Low-Cost Fault Tolerance)
  • Public Clouds bieten hochverfügbare Hardware, Meta setzt jedoch auf einen softwarebasierten Umgang mit Ausfällen und nutzt dadurch günstigere Hardware
  • Zentrale Unterschiede:
    • In Public Clouds verwenden Server-Racks Dual-Netzteile und Dual-ToR-(Top-of-Rack-)Switches, während Meta einzelne Stromversorgung und einen einzelnen ToR-Switch verwendet
    • Virtuelle Maschinen (VMs) in Public Clouds verwenden netzwerkgebundenen Block Storage und können dadurch live migriert werden, während Metas Container kostengünstige lokale SSDs nutzen
  • Softwarebasierte Strategien zur Ausfallbewältigung:
    • Ressourcenzuweisungstools: Verteilen Container eines Dienstes und Daten-Shards auf verschiedene Failure Domains innerhalb des Rechenzentrums
    • Kooperative Protokolle: Ermöglichen es Anwendungen, in das Lifecycle-Management von Containern einzugreifen, um zu verhindern, dass Replikate von Daten-Shards gleichzeitig ausfallen
    • Sicherstellung von Haltbarkeit über mehrere Rechenzentren hinweg: Das System ist so ausgelegt, dass der Dienst selbst beim Ausfall einer ganzen Region weiterläuft, und die Zuverlässigkeit wird regelmäßig durch realitätsnahe Tests überprüft
• Kostenreduktion durch Wegfall von Routing-Proxys (Eliminating Routing Proxy Costs)
  • Herkömmliche Service Meshes verwenden Sidecar-Proxys zum Routing von RPC-Anfragen, Meta verarbeitet jedoch 99 % der RPC-Anfragen per direktem Client-Server-Routing
  • Dadurch lassen sich etwa 100.000 Proxy-Server einsparen
  • Allerdings besteht die Herausforderung, die Routing-Bibliothek in mehr als 10.000 Services zu kompilieren und auszurollen, was Meta mit seinen Tools für Software-Deployment und Konfigurationsmanagement löst
• Tiered Storage und Nutzung lokaler SSDs (Tiered Storage and Local SSDs)
  • Storage wird nach Datenzugriffshäufigkeit und Latenzanforderungen differenziert, um die Kosteneffizienz zu maximieren:
    • Hot Data: Speicherung im Arbeitsspeicher und auf SSDs (z. B. Social-Graph-Datenbanken)
    • Warm Data: Speicherung in HDD-basierten verteilten Dateisystemen (z. B. Videos, Bilder, Log-Daten)
    • Cold Data: Speicherung auf HDD-Servern mit hoher Kapazität (z. B. ältere hochauflösende Videos)
      • Betrieb im Energiesparmodus zur Kostensenkung
  • Nutzung lokaler SSDs:
    • Einige Workloads liefern auf lokalen SSDs bessere Performance als auf gemeinsam genutztem Remote Storage
    • Allerdings besteht das Risiko, dass die SSD-Auslastung durch unausgewogene Lastverteilung sinkt
    • Mit Metas gemeinsamem Sharding-Framework wird das Ungleichgewichtsproblem gelöst und die SSD-Effizienz maximiert

Eigenes Hardware-Design

• Meta entwickelt Rechenzentren, Server, Netzwerk-Switches und AI-Chips selbst, um Kosten- und Energieeffizienz zu verbessern
• Da Energie die am stärksten begrenzte Ressource im Rechenzentrum ist, betreibt Meta Automatisierungstools zur Optimierung des Stromverbrauchs
• Kosten- und Energieeinsparungen durch Hardware-Software-Co-Design:
  • Optimierung der SRAM-Nutzung bei AI-Chips
  • Entfernung kompressorbasierten Kühl-Equipments im Rechenzentrum
• Meta entwickelt auch Netzwerk-Switches und Software selbst, wodurch regelmäßige Updates möglich sind, und stellt den Großteil seiner Hardware-Designs über das Open Compute Project als Open Source bereit

# [Entwurf skalierbarer Systeme (Designing Scalable Systems)]

• In einer Hyperscale-Infrastruktur ist der Entwurf skalierbarer Systeme ein zentrales Element
• Verteilte Systeme aus dem Internetumfeld (BGP, BitTorrent, DHT usw.) sind zwar hoch skalierbar, im Rechenzentrumsumfeld können zentralisierte Controller jedoch höhere Skalierbarkeit und Effizienz bieten

Abschaffung dezentraler Controller (Deprecating Decentralized Controllers)

• Meta hat sich für einen Wechsel von dezentralen zu zentralisierten Controllern entschieden
• Als Ausnahme bleiben Netzwerk-Switches bei BGP, sind jedoch so ausgelegt, dass ein zentraler Controller bei Verkehrsüberlastung oder Link-Ausfällen Routen neu setzen kann
• Zentralisierte Controller ermöglichen besseren Lastausgleich und schnellere Reaktion auf Störungen und sind für Rechenzentrumsumgebungen besser geeignet

Beispiele für die Zentralisierung bestehender verteilter Systeme

• Privates WAN (Private WAN)
  • Früher wurde RSVP-TE (dezentrale Pfadsteuerung) verwendet, später erfolgte die Umstellung auf ein zentralcontrollerbasiertes System
  • Optimale Traffic-Pfade werden automatisch berechnet, und Backup-Pfade werden vorab festgelegt, um im Fehlerfall eine schnelle Wiederherstellung zu ermöglichen
• Key-Value-Store
  • Statt des bisherigen multihop-basierten Routings auf Basis von DHTs (Distributed Hash Tables) wurde auf ein Sharding-Framework mit zentralem Controller umgestellt
  • Der zentrale Controller passt die Neuzuordnung von Shards dynamisch an und optimiert so den Lastenausgleich
• Verteilung großer Datenmengen
  • Früher wurde BitTorrent (dezentrales P2P-Downloadmodell) verwendet, später erfolgte der Wechsel zu Metas zentralisiertem Verteilungssystem Owl
  • Download-Pfade werden zentral festgelegt, was deutlich höhere Download-Geschwindigkeiten ermöglicht
• Verteilung kleiner Metadatenmengen
  • Anfangs wurde eine dreistufige verteilte Baumstruktur (Java-basiert) verwendet, wegen Skalierungsproblemen erfolgte dann der Wechsel zu einer P2P-basierten Baumstruktur
  • Da jedoch die instabile Performance einiger Knoten die Gesamtleistung verschlechterte, kehrte man schließlich zu einer zentralisierten Proxy-Server-Architektur auf Basis von High-Performance-C++ zurück

Fallstudie: skalierbares Service Mesh (Scalable Service Mesh)

Meta betreibt ein eigenes Service Mesh namens ServiceRouter und
belegt mit diesem System die Wirksamkeit einer skalierbaren zentralisierten Architektur.

• Probleme herkömmlicher Service-Mesh-Architekturen
  • Typische Service Meshes routen RPC-Anfragen, indem jeder Service-Prozess einen L7-Sidecar-Proxy verwendet
  • In einer Hyperscale-Umgebung ist es jedoch ineffizient, wenn ein zentraler Controller Millionen von Sidecar-Proxys direkt verwalten muss
  • Meta ersetzte den Sidecar-Proxy-Ansatz durch eine Struktur, in der der Service das Routing selbst übernimmt
• Die ServiceRouter-Architektur von Meta
  • Routing-Metadaten werden vom zentralen Controller erzeugt, aber jeder L7-Router baut seine Routing-Tabelle selbst auf
  • Eine Paxos-basierte Datenbank (RIB, Routing Information Base) sorgt für Skalierbarkeit
    • Durch Sharding der Controller wird die Last verteilt, und mehrere Controller können Routing-Tabellen für bestimmte Services parallel berechnen
  • Die Distribution Layer nutzt Tausende von RIB-Replikaten, um Leseanfragen von Millionen von L7-Routern zu bedienen
  • Am Ende kann jeder L7-Router unabhängig konfiguriert werden, ohne direkten Eingriff des zentralen Controllers
• Wie ServiceRouter skaliert wird
  1. Einsatz zustandsloser Controller: Der Controller verwaltet keine bestimmten Router direkt, sondern hält lediglich globale Routing-Informationen vor
  2. Controller-Sharding: Mehrere Controller arbeiten unabhängig voneinander und können Routing-Informationen für verschiedene Services parallel verarbeiten
  3. Entfernung nicht essenzieller Funktionen: Funktionen zur Verwaltung einzelner L7-Router wurden aus dem Controller entfernt, sodass jeder Router sich selbst verwaltet
• Ergebnisse und Erkenntnisse
  • Eine Architektur, die zentralisierte Controller mit einer verteilten Data Plane kombiniert, bietet optimale Skalierbarkeit
  • Durch das Entfernen unnötiger Sidecar-Proxys werden Betriebskosten gesenkt und die Performance optimiert
  • Strategisches Sharding und zustandsloses Design ermöglichen die effektive Verwaltung von Service-Routing im Umfang von Millionen Instanzen

# [Ausblick (Future Directions)]

• Metas Hyperscale-Infrastruktur ist äußerst komplex, aber dieses Dokument bietet eine Zusammenfassung der wichtigsten technischen Erkenntnisse
• Abschließend wird ein Ausblick auf zukünftige Trends der Hyperscale-Infrastruktur gegeben

AI (Künstliche Intelligenz)

• AI-Workloads sind inzwischen die Workloads mit dem größten Anteil in Rechenzentren
• Es wird erwartet, dass noch vor 2030 mehr als die Hälfte des Stromverbrauchs von Rechenzentren für AI-Workloads verwendet wird
• Aufgrund von Hochleistungsnetzwerken und hohem Ressourcenverbrauch hat AI das Potenzial, bestehende Infrastrukturen grundlegend zu verändern
• In der Vergangenheit hat sich die Hyperscale-Infrastruktur vor allem durch Scale-Out (große Stückzahlen kostengünstiger Server) weiterentwickelt,
  künftige AI-Cluster dürften sich jedoch stärker in Richtung Scale-Up (Supercomputer-Architektur) entwickeln
  • Beispiel: Nutzung von RDMA-(Remote Direct Memory Access)-basierten Ethernet-Netzwerken, optimiert für groß angelegtes Machine-Learning-(ML)-Training
• Meta arbeitet derzeit an einem Full-Stack-Co-Design, das PyTorch → ML-Modelle → AI-Chips → Netzwerk → Rechenzentren → Server → Storage → Stromversorgung und Kühlung umfasst

Domainspezifische Hardware

• In den 2000er-Jahren wurde Hardware zunehmend standardisiert,
  künftig wird jedoch ein Anstieg verschiedenster spezialisierter Hardware für AI-Training/-Inferenz, Virtualisierung, Video-Encoding, Verschlüsselung, Komprimierung, hierarchischen Speicher und mehr erwartet
• Hyperscale-Unternehmen können durch Massenproduktion wirtschaftlich maßgeschneiderte Hardware entwerfen und ausrollen
• Gleichzeitig wird diese zunehmende Hardware-Vielfalt die Komplexität des Software-Stacks erhöhen und neue Herausforderungen bei der Verwaltung heterogener Umgebungen schaffen

Edge-Rechenzentren

• Durch die Zunahme von Metaverse- und Internet-of-Things-(IoT)-Anwendungen wird eine Ausweitung von Edge-Rechenzentren erwartet
• Cloud Gaming rendert Grafiken nicht auf dem Endgerät des Nutzers, sondern auf GPU-Servern in Edge-Rechenzentren,
  wobei eine niedrige Netzwerklatenz von unter 25 ms essenziell ist
• Mit dem Wachstum von Anwendungen, bei denen Reaktionsfähigkeit in Echtzeit entscheidend ist, dürften Anzahl und Größe von Edge-Rechenzentren deutlich zunehmen
• Um diese effizient zu betreiben, muss Global-DaaC (das Konzept, weltweite Rechenzentren wie einen einzigen Computer zu betreiben) erweitert und so optimiert werden, dass Entwickler sich nicht mit komplexem Infrastrukturmanagement befassen müssen

Steigerung der Entwicklerproduktivität

• In den vergangenen 20 Jahren haben Automatisierungstools die Produktivität von Systemadministratoren stark verbessert, sodass das Verhältnis der von einem Administrator betreuten Server stark gestiegen ist
• Die Softwareentwicklung ist jedoch weiterhin arbeitsintensiv, und Produktivitätssteigerungen verlaufen vergleichsweise langsam
• Künftig dürfte die Entwicklerproduktivität durch zwei Faktoren stark zunehmen:
  1. Weiterentwicklung von Tools für AI-basierte Codegenerierung und Debugging
  2. Entstehung domainspezifischer, vollständig integrierter serverloser Programmierparadigmen
• Metas FrontFaaS ist ein Beispiel für diesen serverlosen Programmieransatz,
  und es wird erwartet, dass künftig neue Programmierparadigmen entstehen, die für bestimmte Branchen wie Finanzen oder Gesundheitswesen optimiert sind

Fazit

• Infrastrukturinnovationen mit AI im Zentrum werden sich in den kommenden zehn Jahren schnell beschleunigen
• Hyperscale-Unternehmen sollten durch das Teilen ihrer Erkenntnisse dazu beitragen, dass sich die gesamte Community schneller weiterentwickeln kann

[secret3056]

Das PoP dort ist entweder BGP4 oder TCP Anycast, und als Privatperson gibt es wohl keine Möglichkeit, das zu nutzen, oder..? T_T

[pribess]

Ich verstehe nicht genau, was mit der Aussage gemeint ist, dass ein PoP BGP4 oder TCP-Anycast sei. Wenn damit gemeint ist, ob ein eigenes AS betrieben wird, dann ja.
Übliche Multi-Region-Services nutzen meist Geolocation-basiertes Balancing zusammen mit Anycast-DNS.
Nein, derzeit gibt es das nicht. Wenn Sie einen Multi-Region-PoP benötigen, sollten Sie einen anderen Provider nutzen.

[GN⁺]

Hacker-News-Kommentare

• Nach der Entwicklung von Threads bekam das Infrastrukturteam nur zwei Tage Vorlauf, um den Launch vorzubereiten. Die meisten großen Organisationen brauchen mehr als zwei Tage allein, um einen Projektplan zu erstellen, der Dutzende voneinander abhängige Teams umfasst. Bei Meta wurden jedoch schnell War Rooms über verteilte Standorte hinweg eingerichtet, damit Infrastruktur- und Produktteams Probleme in Echtzeit lösen konnten. Die App erreichte nur fünf Tage nach dem Start 100 Millionen Nutzer und wurde damit zur am schnellsten wachsenden App der Geschichte

• Beeindruckend ist, dass sie die Fähigkeit bewahren, Produkte schnell auf den Markt zu bringen. Das erfordert viel Aufwand, damit die Bürokratie nicht zunimmt und Rechtsabteilung oder andere Bereiche keine Genehmigungs-Gates schaffen. Oder man braucht die Fähigkeit, über War Rooms schnell Dinge erledigt zu bekommen

• Als ich bei FB war, habe ich erlebt, wie stark die Infrastruktur ist. Produktingenieure bauten in wenigen Tagen Projekte im großen Maßstab. Ich arbeitete als Tech Lead für mehrere Teams, darunter einige der hier erwähnten Teams wie HBase und ZippyDB

• Es ist großartig, dass ZippyDB zum ersten Mal öffentlich erwähnt wurde. Ebenfalls sehr cool ist, dass die Verbesserung der Entwicklerproduktivität erwähnt wurde. Täglich werden 10.000 Services ausgerollt oder sämtliche Commits vorgenommen

• Nachdem ich FB verlassen hatte, konnte ich nichts Vergleichbares finden. Deshalb baue ich als Startup die Infrastruktur auf, die ich brauchte. Batteries Included

• Schade, dass es in diesen Kommentaren so viel Zynismus und negative Reaktionen gibt. Viele Leute mögen Meta nicht, aber der eigentliche Artikel erfüllt mich mit Staunen. Mir war nicht klar, wie umfangreich und komplex die Infrastruktur ist, die die moderne digitale Welt trägt. Diesen Artikel zu lesen und dieses Ausmaß zu sehen, ist beeindruckend

• Das Unternehmen mag in vielerlei Hinsicht schlecht sein, aber alles im Artikel ist für mich erstaunlich

• Ich bin kein Ingenieur wie ihr, deshalb sind die Inhalte dieses Artikels für euch vielleicht alte Nachrichten, aber ich konnte nicht anders, als „wow“ zu sagen

• Wenn man diesen Artikel Science-Fiction-Autoren aus der Vergangenheit zeigen würde, wären auch sie wohl staunend

• Erstaunlich. All diese beeindruckende Technologie und die besten Ingenieure der Welt werden nur dafür eingesetzt, noch mehr Werbung vor die Augen der Menschen zu bringen. Seufz

• Es ist interessant, das PHP-Web-Frontend als „serverless“- oder „Function-as-a-Service“-Architektur zu beschreiben. Scheint eine Frage der Perspektive zu sein. Es ist ein Service mit einer einzigen Codebasis, in der viele Endpunkte bereitgestellt werden. Aus Sicht der Maintainer dieser Endpunkte mag es „serverless“ sein, aber wie bei allen Abstraktionen gibt es Lecks

• In Rechenzentrumsumgebungen bevorzuge ich zentrale Controller wegen ihrer Einfachheit und der Möglichkeit, qualitativ hochwertige Entscheidungen zu treffen. In vielen Fällen ist ein hybrider Ansatz aus zentraler Control Plane und verteilter Data Plane am optimalsten

• Dieser Ansatz scheint eines der optimalen Designs für Software Networking (Service Mesh) und Storage (Datenbankbetrieb) in Organisationen mit sehr großen Serverzahlen zu sein. Erstaunlich ist, dass IP-Networking demselben Modell folgt, ohne sich hauptsächlich auf BGP zu stützen

• Es ist zu erwarten, dass lokales Caching genutzt wird, um die Last auf L7-Routern zu verringern und die Latenz bei Datenbankabfragen zu verbessern. Clients können den Cache invalidieren und nach einer angemessenen Zeitüberschreitung erneut über das Service Mesh nachschlagen

• Schnell entwickelte serverless Functions kombiniert mit Continuous Deployment und der Möglichkeit für jeden, die gesamte Codebasis zu bearbeiten, klingen wie ein dystopischer Albtraum. Die Menge an Logging, die für Debugging und Fehlersuche nötig ist, wäre extrem

• Erlang zum Schreiben serverloser Functions zu verwenden, wirkt so, als würde man alle großen Vorteile vermeiden, die BEAM bieten kann

• Produktingenieure schreiben ihren Code überwiegend als zustandslose serverless Functions in PHP, Python und Erlang. Das bringt Vorteile bei Einfachheit, Produktivität und Iterationsgeschwindigkeit

• Um die Entwicklerproduktivität zu steigern, setzt Meta flächendeckend auf Continuous Deployment und ermöglicht mehr Entwicklern, serverless Functions statt traditionellen Service-Code zu schreiben

• Für Nicht-AI-Compute-Workloads bieten sie nur einen einzigen Servertyp an, ausgestattet mit einer CPU und derselben Menge an DRAM (früher 64 GB, jetzt 256 GB). Ich frage mich, ob das branchenweit üblich ist oder nur bei Meta

• Wenn ein Bild nicht auf CDN109 zwischengespeichert ist und ein Nutzer es anfordert, leitet CDN109 die Anfrage an einen nahegelegenen PoP weiter. Der PoP leitet die Anfrage an den Load Balancer in der Rechenzentrumsregion weiter, und der Load Balancer holt das Bild aus dem Storage-System

• Wenn man ein 1-MB-Bild anfordert, wäre es bei einer langsamen Verbindung mit 100 ms Latenz nicht schneller, das 1-MB-Bild direkt auszuliefern, statt mehrere Roundtrips und steigende Latenz in Kauf zu nehmen?

• Wenn man annimmt, dass die Anfrage durch Metas System geht und letztlich im selben Rechenzentrum landet und dass es keine FTL-Technologie gibt

• Der explizite Vergleich mit Hyperscalern ist besonders interessant. Ich frage mich, ob das eine Vorbereitung auf den Start einer eigenen Public Cloud ist. Ich wünschte, jemand von Meta würde sich dazu äußern