MicroVMs behandeln nun Anfragen für Netlify’s Edge Functions, und das Unternehmen teilt mit, dass die Änderung die Latenz bei Medianwerten um etwa 5x reduziert und gleichzeitig die Zuverlässigkeit verbessert. Das Update hat keinen Einfluss darauf, wie Entwickler die Funktionen schreiben oder nutzen.
Jeden Tag laufen etwa eine Milliarde Edge Functions durch das System und bedienen Kunden wie Sunweb und Loto-Québec. Diese Funktionen verwalten Personalisierung, Routing und Authentifizierung. Bis vor nicht allzu langer Zeit wurde jede Anfrage an einen gehosteten Ausführungsdienst gesendet. Heute laufen sie in MicroVMs innerhalb von Netlify’s eigenem Edge-Netzwerk.
Die Änderung bringt eine willkommene Antwortzeit von etwa 5–6 ms im mittleren Bereich mit sich, nachdem sie im vorherigen System von 25–40 ms auf 9 ms gesunken ist. Kaltstarts, bei denen zuerst Bilder abgerufen werden müssen, liegen im Durchschnitt bei etwa 9 ms. Die neue Anordnung sendet Edge-Funktionsaufzeichnungen 5-mal schneller zurück und bietet eine Zuverlässigkeitsgarantie von 99,998 %.
Wie die Anfrage ihren Weg findet
Die Anfrage findet ihren Weg zum nächstgelegenen Netlify-Edge-Knoten, der sie dann verarbeitet. Dieser Knoten beendet die TLS-Verbindung und führt eine Prüfung durch, indem er den Pfad der Anfrage mit den Edge-Functions-Routen des Deployments abgleicht.
Wenn keine Route übereinstimmt, wird die Anfrage an den Cache und dann an den Origin-Server weitergeleitet. Wenn jedoch eine Route übereinstimmt, würde die Anfrage im alten Aufbau das Netlify-Netzwerk vollständig verlassen. Sie ging über das Internet, führte die Edge-Funktion aus und kehrte zu Netlify zurück, um sie weiterzuleiten.
Die Anfrage bleibt währenddessen innerhalb von Netlify’s Netzwerk eingeschlossen. Anstatt ihr Ziel direkt zu erreichen, wird sie an einen Compute-Knoten innerhalb dieses Netzwerks übergeben. Dieser Knoten leitet die Anfrage dann an eine MicroVM weiter, die möglicherweise bereits von einem vorherigen Aufruf ausgeführt wird oder für einen neuen Aufruf frisch erstellt wird, je nachdem, ob der Aufruf warm oder kalt ist.
Die Maschinenspezifikation
Bevor die Anfrage weitergeleitet wird, generiert der Edge-Knoten eine Spezifikation für die Maschine, die mit der Ausführung der Funktion beauftragt ist. Diese Spezifikation identifiziert drei Images anhand ihres Namens: die Laufzeitumgebung, Netlify’s Plattform-Image und das Edge-Funktions-Image. Außerdem werden die CPU-, Speicher- und Verbindungsbegrenzungen festgelegt.
Bei jeder Ausführung transportiert die Anfrage die Spezifikation mit sich. Der Hash der Spezifikation, kombiniert mit standortspezifischen Details, bildet eine Service-ID, die zwei Bereitstellungen mit unterschiedlichem Code oder unterschiedlichen Umgebungsvariablen als unterschiedliche Dienste voneinander unterscheidet. Sie landen niemals in derselben MicroVM.
Am wichtigsten ist es, zu verhindern, dass Unternehmensfehler überhaupt erst möglich werden. Eine Bereitstellung, die möglicherweise kompromittiert worden wäre, läuft stattdessen in ihrer eigenen isolierten MicroVM, sodass sie auch dann, wenn sie irgendwie aus der Laufzeit ausbricht, nicht andere Kunden oder die zugrunde liegende Compute-Schicht schädigen kann.
V8-Isolate bieten unabhängig von ihrem Namen dieses Isolationsniveau nicht.
Auswahl eines Compute-Knotens
Compute-Knoten liegen hinter jeder Region, und der Edge-Knoten wählt einen mithilfe von Rendezvous-Hashing aus, sodass dieselbe Dienstleistung immer auf demselben Knoten landet. Diese Verlässlichkeit ist das, was Netlify seiner Cache-Strategie verleiht, da Anfragen, die gleichmäßig über den Schwarm verteilt sind, andernfalls zu einer höheren Anzahl von Kaltstarts führen würden.
Der schnellste Weg, Anfragen an eine Funktion zu senden, ist es, sie alle an einen Compute-Knoten zu leiten. Das ist aber auch der Weg zur Erzeugung eines Engpasses – wenn eine stark genutzte Funktion um Ressourcen kämpft gegen alles andere, das auf derselben Maschine läuft. Wenn eine Dienstleistung einen großen Teil des Traffics einer Region abfängt und auf einem einzigen Knoten verbleibt, füllt sie diesen Knoten auf und benachteiligt andere Dienstleistungen.
Erstellung des Dienstes
Der Compute-Knoten empfängt eine Anfrage, die eine Maschinenspezifikation zusammen mit einer Service-ID enthält. Er beginnt damit, zu prüfen, ob eine Dienstleistung mit dieser ID bereits eingerichtet wurde. Sollte eine Übereinstimmung gefunden werden, wird die Anfrage dann an diese Dienstleistung weitergeleitet, damit diese ihre eigene Anfrage an die MicroVM senden kann.
Netlify kann mehrere MicroVMs über einen Dienst mit den Edge Functions einer einzelnen Website verknüpfen und erlaubt das Festlegen von Parametern für das Hoch- und Runterfahren von MicroVMs. Jede Dienstleistung ist so eingerichtet, dass eine MicroVM nach der Bearbeitung einer festen Anzahl von Anfragen heruntergefahren wird, wodurch verhindert wird, dass MicroVMs unbegrenzt aktiv bleiben.
Dieselben Signale weisen das System an, eine neue MicroVM im Voraus zu starten, bevor eine bestehende herunterfährt.
Wenn kein Dienst für die Edge-Funktionen des Standorts auf dem Compute-Knoten existiert, wird einer erstellt. Der Knoten untersucht dann, ob er alle im Maschinen-Spezifikationsdokument aufgeführten Bilder auf der Festplatte vorhält. Fehlende Bilder werden vom Edge-Knoten heruntergeladen und auf der Festplatte gespeichert. Diese Methode stellt sicher, dass Netlify nur die Edge-Funktionsbilder herunterlädt, die tatsächlich in dieser Region verwendet werden.
Was Entwickler sehen
Es hat sich nichts an der Erstellung oder Verwendung von Edge-Funktionen geändert. Alles funktioniert weiterhin wie gehabt: URL-Importe, npm-Pakete, Node-Built-Ins, netlify.toml-Deklarationen und lokale Entwicklung. Der einzige Unterschied ist, dass die Funktionen selbst jetzt schneller und widerstandsfähiger sind.
Die Zahlen hinter der Umstellung
Hier sind die von Netlify gemeldeten Zahlen, und die Zahlen sprechen für sich.
- ~5–6 ms am Median (p50), gegenüber 25–40 ms auf der vorherigen Infrastruktur
- 47,4 % schnellere p99-Aufrufe
- 99,998 % Verfügbarkeit
- 5-fach schnellere Edge-Funktions-Protokollübermittlung
Kalte Aufrufe finden bei etwa 1,2 % aller Aufrufe statt und dauern durchschnittlich 9 ms. Das Unternehmen sagt, dass die Umstellung auch die Sicherheit und Zuverlässigkeit verbessert und weitere Möglichkeiten für die Ausführung komplexer Berechnungen am Edge eröffnet.
Was das für Kunden bedeutet
Die Verfügbarkeitszahl ist hier die eigentliche Geschichte, obwohl die Senkung der Medianlatenzzeit im Vordergrund steht. Ein verteiltes System, das 99,998 % Verfügbarkeit verspricht, bietet ein solides Zuverlässigkeitsversprechen.
Routing- und Personalisierungsfunktionen, die auf Edge Functions basieren, sind auf die Verfügbarkeit dieser Dienste angewiesen. Wenn diese ausfallen, wird der Anfragenfluss unterbrochen.
Die anfängliche Anfragenummer fällt ebenfalls ins Gewicht. Bei 1,2 % der Anfragen tritt das Problem auf, sodass es klein genug ist, damit der zuvor beschriebene Caching-Ansatz die meisten Anfragen bereit hält. Das Problem des Cold Starts, das noch 9 ms kostet, zeigt jedoch, dass der Plan eine gewisse Verzögerung als Teil der Funktionsweise akzeptiert.
Netlify’s Isolationsdesign verdient ebenfalls Beachtung. Jeder Deployment erhält sein eigenes MicroVM, was bedeutet, dass das Shared-Runtime-Problem, das bei vielen serverlosen Plattformen üblich ist, vermieden wird. Sollte ein Deployment kompromittiert werden, kann es nicht aus seinem Runtime ausbrechen und andere Kunden beeinträchtigen.
Das Hochfahren des Systems dauert länger als es sonst würde. Eine Cold-Invocation dauert durchschnittlich 9 ms, was für interaktive Anwendungen wichtig ist. Die Median-Latenz liegt bei 5–6 ms, sodass die meisten Anfragen schnell abgeschlossen werden. Die Verfügbarkeitszahl von 99,998 % zeigt, dass die Ausreißer selten auftreten, was auf eine zuverlässige Einrichtung hinweist.
Die Zusammenarbeit zwischen Netlify und Unikraft, wie vom Team von Unikraft beschrieben, deutet darauf hin, dass das Unternehmen diese Technologie nicht allein entwickelt. Der Übergang von einem gehosteten Ausführungsdienst zum Ausführen von MicroVMs innerhalb seines eigenen Netzwerks erfordert einen erheblichen Infrastrukturaufwand, was das ehrgeizige Ziel hinter dem Produkt widerspiegelt.
Es ist hervorzuheben, dass das Unternehmen seine eigenen Kompromisse beschreibt, einschließlich des Hotspot-Risikos und der Cold-Start-Verzögerung, anstatt nur die Vorteile darzustellen. Die meisten Cloud-Anbieter teilen nur ihre Best-Case-Szenarien. Netlify hat sich entschieden, sowohl die Vorteile als auch die Kosten zu veröffentlichen.
Das Ergebnis ist eine Edge-Functions-Plattform, die schneller wird und sich als zuverlässiger erweist, ohne dass Entwickler auch nur eine einzige Zeile Code ändern müssen. Die Kombination aus diesen beiden Aspekten – einer Leistungssteigerung, die mit keinem Aufwand für die Programmierer einhergeht – ist genau die Art von Upgrade, die Aufmerksamkeit erregt.
Jeder, der auf Netlify baut, wird feststellen, dass Edge Functions jetzt schneller und zuverlässiger laufen, ohne dass sich das Verhalten Ihres vorhandenen Codes ändert. Die darunterliegende Infrastruktur hat sich dramatisch verändert, während die Oberfläche vollständig unverändert blieb.
„5x schnellere Edge-Funktionen: V8 isoliert in Firecracker MicroVMs,“ netlify.com.
Das Notizbuch abonnieren.
Die besten Geschichten des Tages und jedes neue Urteil, in klarem Deutsch, um sieben im Postfach. Eine Mail am Tag, nicht mehr.