XFaaS: Metas serverlose Plattform, die täglich Billionen von Aufrufen verarbeitet

• Eine von Meta intern genutzte FaaS-Plattform
• Verarbeitet täglich Billionen von Funktionsaufrufen auf mehr als 100.000 Servern, verteilt über Dutzende Rechenzentrumsregionen
• Laut Meta effizienter als AWS Lambda und Azure Functions; vorgestellt im Paper „XFaaS: Hyperscale and Low Cost Serverless Functions“

Interessante Kennzahlen und Implikationen

• Die Kernaussage des Papers ist, dass sich die Serverless-Performance verbessern lässt, indem die Hardware-Nutzung per Software optimiert wird
• Meta erkannte die Verschwendung durch Startup-Overhead bei Serverless Functions und wollte einen Universal Worker emulieren, bei dem jeder Worker jede Funktion sofort ohne Start-Overhead ausführen kann
  • In dieser Größenordnung sind die Hardware-Kosten enorm, daher ist selbst ein sehr kleiner Prozentsatz relevant
• XFaaS wird nur für nicht nutzergerichtete Funktionen verwendet. Serverless Functions haben zu stark schwankende Latenzen, um sie konsistent für nutzergerichtete Funktionen einzusetzen
• XFaaS-Clients führen Funktionsaufrufe in sehr abrupten Lastmustern aus. Die Spitzennachfrage ist 4,3-mal höher als die Nachfrage außerhalb der Spitzenzeiten
  • Ein Beispiel: Innerhalb von 15 Minuten wurden auch schon 20 Millionen Funktionsaufrufe an XFaaS übermittelt
  • Meta stellte fest, dass selbst sprunghafte Funktionslasten Muster aufweisen, und nutzte dies, um Lastspitzen besser vorhersagbar zu machen

Wie effizient ist XFaaS?

• Erreicht eine durchschnittliche tägliche CPU-Auslastung von 66 %, deutlich über dem Branchendurchschnitt
• Verteilt Last effizient über Zeit (durch Funktionsverzögerung) und Raum (durch Weiterleitung an weniger ausgelastete Rechenzentren)

  Meta verlagert weiterhin viele Funktionen auf Zeiten mit geringerer Auslastung, in denen sich Last und Kosten besser vorhersagen lassen

• Als interne Cloud kann Meta mehrere spezielle Optimierungen umsetzen, etwa mehrere Funktionen mehrerer Nutzer im selben Prozess auszuführen
• Die meisten Funktionen laufen in weniger als einer Sekunde, aber nicht alle

Mit XFaaS gelöste Probleme

• Problem: lange Cold-Start-Zeiten
  • Wenn Container zu früh beendet werden, muss für den nächsten Aufruf der gesamte Container erneut initialisiert werden
  • Wenn Container zu spät beendet werden, bleiben sie untätig und verschwenden wertvolle Rechenressourcen
  • Lösung: XFaaS nähert dies an, indem es Methoden wie JIT-Kompilierung nutzt, damit jeder Worker jede Funktion sofort ausführen kann
• Problem: starke Lastschwankungen
  • Overprovisioning verursacht zusätzliche Hardware-Kosten, während Unterprovisionierung das System verlangsamt
  • Lösung: XFaaS verschiebt delay-tolerante Funktionsausführungen auf Zeiten geringer Auslastung und verteilt Funktionsaufrufe über Rechenzentrumsregionen weltweit
• Problem: Überlastung nachgelagerter Dienste
  • Beispiel: Ein Anstieg bei Aufrufen nicht nutzergerichteter Funktionen führte einmal zum Ausfall eines nutzergerichteten Online-Dienstes
  • Lösung: XFaaS steuert die Funktionsausführung mit einem Mechanismus ähnlich der TCP-Staukontrolle

Vergleich mit allgemeinem FaaS (AWS Lambda, Google Cloud Functions, Azure Functions)

• Public-Cloud-FaaS beschränkt Funktionsausführungen auf eine einzelne Rechenzentrumsregion, während XFaaS Funktionsaufrufe weltweit verteilen kann und damit das Load Balancing verbessert
• FaaS-Plattformen priorisieren in der Regel geringere Latenz und vernachlässigen dabei die Hardware-Auslastung. XFaaS legt den Schwerpunkt auf Hardware-Auslastung und den Durchsatz von Funktionsaufrufen
• XFaaS-Techniken, die auch für Public Clouds nützlich sein könnten
  • Dem Aufrufer erlauben, den Startzeitpunkt der Funktionsausführung festzulegen
  • Dem Funktionsverantwortlichen erlauben, ein Service-Level-Ziel (SLO) für die Fertigstellungsfrist festzulegen (bei niedrigerem SLO ist mehr Verzögerung für bessere Laufzeiten möglich)
  • Dem Funktionsverantwortlichen erlauben, eine Prioritätsstufe für die Funktion festzulegen
• Public Clouds können wie XFaaS nicht mehrere Funktionen mehrerer Nutzer im selben Prozess ausführen, aber große Cloud-Kunden könnten den XFaaS-Ansatz in einer Virtual Private Cloud übernehmen
• Einige wenige Meta-Teams verbrauchen einen erheblichen Teil der XFaaS-Kapazität. Ähnliche Großkunden in Public Clouds könnten ebenfalls von der XFaaS-Strategie profitieren

Hintergrund: Annahmen und Anforderungen

• Annahmen
  • Die zentrale Erkenntnis ist, dass die meisten XFaaS-Funktionen durch automatisierte Workflows ausgelöst werden und daher Latenz tolerieren können
  • Dadurch kann XFaaS Last über Zeit (durch Verzögern von Funktionen) und Raum (durch Weiterleitung an weniger ausgelastete Rechenzentren) verteilen
  • XFaaS unterstützt Laufzeitumgebungen für PHP, Python, Erlang und Haskell sowie eine allgemeine containerbasierte Laufzeit für alle Sprachen
  • Funktionen haben viele vom Entwickler festlegbare Eigenschaften, darunter Funktionsname, Argumente, Laufzeitumgebung, Priorität, Startzeitpunkt, Fertigstellungsfrist, Ressourcenquote, Parallelitätsgrenze und Retry-Policy; die Fertigstellungsfrist kann von Sekunden bis zu 24 Stunden gesetzt werden
  • Da XFaaS je nach Region über unterschiedliche Hardware-Kapazitäten verfügt, muss Load Balancing dies berücksichtigen
• Workload-Typen
  • Meta unterstützt in XFaaS drei Arten von Workloads
    • Queue-getriggerte Funktionen
    • Event-getriggerte Funktionen (Datenänderungsereignisse aus Data-Warehouse- und Data-Stream-Systemen)
    • Timer-getriggerte Funktionen (automatische Ausführung zu vorgegebenen Zeitpunkten)
  • XFaaS wird für nicht nutzergerichtete Funktionen wie asynchrone Empfehlungssysteme, Logging, Produktivitäts-Bots und Benachrichtigungen verwendet

Gesamtarchitektur

(Dieser Teil ist zu lang und übernimmt den Inhalt des Papers fast wörtlich, daher wird er ausgelassen.)