Drei Fragen, die das Edge-State-Design erleichtern

Wenn Sie eine App in der Cloud erstellen möchten, können Sie sich dafür einen Leitfaden herunterladen.Tatsächlich sind solche Leitfäden so weit verbreitet, dass viele Fastly Kunden den Wunsch äußern, Code von anderen zu übernehmen, um ihn in ihre Business Logic einzufügen. Der Einstieg in Core Clouds ist so einfach, dass die meisten Entwicklerteams inzwischen direkt in der Cloud arbeiten. Die niedrigen Einstiegsbarrieren bei der Entwicklung von Web-Apps sorgen außerdem für schnellere Innovationen. 

Im Zuge der globalen Skalierung von Anwendungen und der Bemühungen, für immer mehr Performance und Sicherheit zu sorgen, entstehen jedoch enorme Skalierungs- und Verwaltungskosten, die den Einstieg erschweren. Was sich in einzelnen Regionen leicht bereitstellen ließ, erfordert nun spezielle Projekte für die globale Bereitstellung. So müssen z. B. Funktionstests und Performance-Metriken, die in einer Startregion bereitgestellt wurden, nun repliziert oder für weitere Standorte neu definiert werden, was mehr Entwicklungszeit in Anspruch nimmt. Außerdem kommt es bei Assets, Konfigurationen und anwendungskritischen Daten an zentralen Standorten selbst bei einfachen Abläufen zu globalen Round-Trip-Latenzen. Das Ergebnis: Der Code ist nicht nur eine Kombination aus vielen Regionen. Oft handelt es sich dabei um Spaghetti-Code mit unzuverlässiger Performance.  

Anstatt alte Monolithen in Edge-Frameworks zu zwingen, stellen viele Entwickler fest, dass es auf lange Sicht viel einfacher ist, ein System von Anfang an edgenativ zu gestalten. Das Design von edgenativen Anwendungen ist global ausgelegt und behebt viele der Probleme bei der Bereitstellung, Verwaltung und Datenreplikation, die Anwendungsentwickler heute in Core Clouds erleben. Aber wo werden Ihre Daten gespeichert? Welche Kompromisse müssen Sie bei unterschiedlichen Produkten eingehen? Edge-State-Management bedeutet einen langsameren Einstieg als mit Core-Cloud-Vorlagen, aber mit ein wenig Überlegung kann es letztendlich relativ unkompliziert sein und Ihnen eine Menge Kopfschmerzen bei der Skalierung ersparen.

In diesem Blogpost befassen wir uns mit drei Fragen, die Sie sich am Anfang der Anwendungsentwicklung stellen sollten, und geben entsprechende Empfehlungen, um später bei der Skalierung Zeit zu sparen. Indem wir die Lebensdauer, Replikation und Schreibfrequenz erörtern, können wir Kompromisse zwischen diesen Faktoren vorhersehen und Ihnen helfen, den richtigen Ausgangspunkt zu finden.

1. Lebensdauer: Dürfen diese Daten ablaufen? 

Warum mit der Datenlebensdauer beginnen? Unter all den Kriterien, die berücksichtigt werden müssen, lassen sich bei den Datengarantien die meisten möglichen Lösungen innerhalb von 30 Sekunden ausschließen.

Ja, Daten sind flüchtig

Flüchtige Datenspeicher wie Caches sind nützlich für temporäre Daten. Es ist oft günstiger, temporäre Daten zu speichern als Daten, auf die Sie garantierten Zugriff haben müssen. Sie zahlen schließlich immer nur für die Storage, die Sie auch tatsächlich nutzen. 

Flüchtige Storage kann nützlich sein, wenn eine Anwendung auch ohne Daten weiter funktioniert. Das ist zum Beispiel beim Caching von Assets im CDN ganz normal. Eine hohe Cache-Hitrate (CHR) wird bevorzugt, aber es gibt Möglichkeiten, mit Cache Misses umzugehen und den Cache wieder aufzufüllen.

Empfehlung: Sehen Sie sich verschiedene Cache-Lösungen an, um zu vermeiden, dass Sie zu viel Storage einkaufen.Flüchtige Lösungen sind oft kostengünstiger als andere Lösungen und normalerweise weniger restriktiv in Bezug auf Dateigröße und Schreibfrequenz. Beim Fastly Cache gibt es beispielsweise keine Einschränkungen bei der Dateigröße, während Edge Dictionaries sowohl eine maximale Anzahl von Elementen als auch eine maximale Wertelänge haben. 

Nein, Daten müssen erhalten bleiben

Diese Daten sind garantiert so lange im Datenspeicher vorhanden, bis sie ausdrücklich gelöscht werden.  Dabei kann es sich um die einzige Kopie einzelner Daten handeln. Vielleicht ist es aber auch einfacher, diese Daten auf der Edge zu speichern, als eine Replikation von einem zentralen Speicherort aus einzurichten. Typische Beispiele für dauerhafte Speichernutzung sind große Objektspeicher oder die Speicherung einer Konfigurationsdatei, die von mehreren Edge-Funktionen zur Entscheidungsfindung verwendet wird (zum Beispiel eine IP-Blockliste). 

Empfehlung: Sehen Sie sich zunächst verschiedene Konfigurationslösungen oder Objektspeicher an, um die Verfügbarkeit der gespeicherten Daten gewährleisten zu können. Diese bieten oft bekannte Key/Value-Interaktionsmodelle.Wählen Sie die Lösung, die am besten zu der benötigten Objektgröße und der regionalen Verfügbarkeit passt, und achten Sie dabei besonders auf eine eventuelle Begrenzung der Schreibfrequenz. 

2. Replikation: Wo werden diese Daten benötigt? 

Wo werden diese Daten zur Verfügung gestellt? Wird weltweit darauf zugegriffen, oder werden sie nur auf demselben POP benötigt, auf den sie geschrieben wurden? In Verbindung mit der Lebensdauer kann die Beantwortung der Frage nach der Replikation helfen, die geeignete Lösung zu finden. 

Global

Unabhängig vom Schreibstandort werden zukünftige Prozesse auf der ganzen Welt Zugriff auf diese Daten benötigen. Das Cachen von Assets für den globalen Zugriff oder das Aktualisieren zahlreicher globaler WAF-Regeln sind gute Beispiele für Edge-State-Anwendungen, die eine globale Replikation erfordern. 

Empfehlung: Für kurzfristigen Speicherbedarf ist ein globaler Cache höchstwahrscheinlich die beste Lösung. Stellen Sie aber dennoch sicher, dass Sie die ausdrückliche Kontrolle über Ihren Cache haben und hohe CHRs erzielen. Für die dauerhafte Speicherung gibt es je nach Nutzung verschiedene Optionen. Versuchen Sie es zunächst mit einem Objektspeicher und achten Sie auf eventuelle Obergrenzen für die Schreibfrequenz. 

Lokal 

Es wird davon ausgegangen, dass auf diese Daten nur von dort aus zugegriffen werden kann, wo sie erstellt wurden. Mittels lokaler Replikation kann ein Edge-State-Speicher wie ein gemeinsamer Speicher für Edge-Funktionen fungieren und für standortspezifische Interaktionen sorgen. Die Speicherung nutzerdefinierter Inhalte für die spätere Verwendung in einem bestimmten Gebiet ist ein gutes Beispiel für eine lokale Replikation.

Empfehlung: Auch hier sind Caches aufgrund ihrer hohen Performance eine gute erste Option, wenn das Interaktionsmodell passt. Wenn die Langlebigkeit von entscheidender Bedeutung ist, ist es empfehlenswert, sich mit den Möglichkeiten für standortspezifische Storage zu befassen. 

3. Schreibfrequenz: Wie oft werden diese Daten aktualisiert? 

Edge-State-Lösungen sind oft mit Kompromissen in puncto Langlebigkeit, Replikation und Schreibfrequenz verbunden. Wenn dauerhafte Storage in globalem Maßstab mit schnellen Replikationsgeschwindigkeiten benötigt wird, wird dies wahrscheinlich auf Kosten einer geringeren Schreibfrequenz gehen. Alle diese globalen Speicher zu aktualisieren ist kosten- und zeitintensiv.Es stellt sich also die Frage, ob Sie Daten oft oder weniger oft aktualisieren müssen. 

Oft

Es muss mehrmals pro Sekunde auf einen bestimmten Eintrag im Speicher geschrieben werden. Hochfrequente Schreibvorgänge sind äußerst effizient und können für Sicherheitsanwendungen und neuartige gemeinsame Weberlebnisse wie geteilte Spielstände, genutzt werden. 

Empfehlung: Beginnen Sie bei vorübergehenden Anwendungen und Anwendungen mit lokalem Status mit der Option mit dem bequemsten Interaktionsmodell (expliziter Cache oder Key/Value-Modell). Wenn eine globale Replikation erforderlich ist, müssen Sie hier Kompromisse eingehen oder vielleicht mehrere Lösungen in einem mehrschichtigen Ansatz kombinieren, der die erforderliche Kombination von Attributen ermöglicht. 

Weniger oft

Die einzelnen Assets oder Keys im Datenspeicher werden nicht oft aktualisiert. Ein guter Richtwert für eine niedrige Frequenz ist bis zu ein Schreibvorgang pro Sekunde auf einen beliebigen Schlüssel. Aktualisierungen mit geringer Frequenz eignen sich gut für Konfigurationszwecke wie große Listen von URL-Umleitungen oder WAF-Regeln sowie für die Speicherung großer Bestände. 

Empfehlung: Eine niedrige Schreibfrequenz ermöglicht mehr Flexibilität bei der Auswahl einer Lösung. Beginnen Sie mit der empfohlenen Lösung, die der erforderlichen Langlebigkeit entspricht (Cache oder Objektspeicher). Es ist wahrscheinlicher, dass eine Anwendung wächst und eher mehr Schreibvorgänge erfordert als weniger.

Zusammenfassung

Mit ein wenig Vorausplanung fällt das Design von Edge-First-Anwendungen relativ leicht. Außerdem können Sie sich jede Menge Zeit und Energie bei fehlgeschlagenen POC-Implementierungen sparen. Es gibt natürlich mehr als nur drei Fragen zu beantworten (Dateigröße oder Replikationszeitpunkt sind zwei Beispiele dafür). Die drei Fragen, mit denen wir uns hier befasst haben, sind aber besonders effektiv, um Designentscheidungen in die richtige Richtung zu lenken. Wir hoffen, dass sie Ihnen etwas Zeit und Kopfzerbrechen ersparen, wenn weitere Native-State-Produkte auf der Edge auftauchen und es immer mehr Lösungen gibt.