Entfernen Sie die Distanz Ihrer Web-App mit dem Volterra App Delivery Network (ADN)

Dieser Blog ist der Beginn einer neuen Blogserie zu realen Beispielproblemen von Unternehmen und beschreibt, wie das App Delivery Network (ADN) von Volterra die beschriebenen Probleme angeht. In diesem speziellen Blog wird eine zentrale Herausforderung im Hinblick auf die Leistung von Application beschrieben, mit der Online-Unternehmen auf der ganzen Welt täglich konfrontiert sind. Diese Herausforderung wird noch größer, da die meisten Verbraucher von zu Hause aus arbeiten. Ich beschreibe, wie Volterra Unternehmen dabei helfen kann, die Distanz zwischen ihren Web-Apps zu verringern und so eine Verbesserung der Application um 77 % zu erreichen, ohne dass die Application neu geschrieben werden muss.

Was ist die Leistung von Web-Apps?

Die Leistung einer Web-App wird normalerweise daran gemessen, wie lange es dauert, bis der Seiteninhalt aus der Sicht des Endbenutzers sichtbar wird. Webentwickler verwenden verschiedene Metriken, um die Leistung ihrer Web-Apps zu messen, z. B. First Contentful Paint, Largest Contentful Paint oder Document Complete. In diesem Blog habe ich die Metrik „Dokument vollständig“ als Maß für die Leistung meiner Web-App verwendet. Webentwickler messen diese Metriken mit Tools wie Web Page Test, Google Lighthouse oder Rigor.

Warum ist die Leistung von Web-Apps wichtig?

Eine leichte Verschlechterung der Leistung der Web-App hat enorme Auswirkungen auf das Benutzererlebnis und folglich auf die Verkäufe über das Online-Portal. Der E-Commerce-Riese Amazon meldete, dass eine einsekündige Verschlechterung der Application zu einem Umsatzverlust von 1,6 Milliarden Dollar führt. Eine ähnliche wirtschaftliche Auswirkung beobachten Online-Unternehmen in mehreren Branchen, wie in diesem etwas älteren Bericht von Akamai berichtet wird. Google und Microsoft melden ähnliche Zahlen zu den wirtschaftlichen Auswirkungen.

Diese Datenpunkte bestätigen eindeutig, dass die Leistung von Web- Application für Online-Unternehmen oberste Priorität hat.

Was ist die Herausforderung?

Betrachten wir das konkrete Beispiel eines Online-Unternehmens im Bereich E-Commerce. Viele E-Commerce-Unternehmen haben ihre Application in einem oder wenigen Rechenzentren und diese Rechenzentren existieren nicht in allen Ländern, in denen die Benutzer der E-Commerce-Unternehmen leben. Wenn sich der Benutzer in einem anderen Land/einer anderen Region als das Rechenzentrum befindet, führt eine hohe Netzwerklatenz vom Benutzer zum Rechenzentrum zu langsamen Seitenladezeiten von fast 6–12 Sekunden. Wie oben erwähnt, steigt die Wahrscheinlichkeit eines Absprungs auf 90 %, wenn die Seitenladezeit 5 Sekunden überschreitet.

Lassen Sie uns den Seitenladevorgang einer Web-App wie in Abbildung 2 gezeigt dekonstruieren.

• Zunächst wird eine sichere SSL-Sitzung hergestellt, die sechs Nachrichten hin und her zwischen dem Browser des Benutzers und der Web-App erfordert.
• Als Nächstes verwendet die Webanwendung normalerweise die Cookies im Browser des Benutzers, um festzustellen, ob der Benutzer ein Konto beim E-Commerce-Anbieter hat.
• Basierend auf dem Cookie wird dem Benutzer eine Anmeldeseite angezeigt, wenn er über ein Konto verfügt. Andernfalls wird dem Benutzer eine Seite zum Bezahlen als Gast angezeigt.

Sechs Nachrichten nur zum Einrichten der sicheren SSL-Sitzung bei der Übertragung über Links mit hoher Latenz (möglicherweise transatlantische/transpazifische Links) wirken sich sicherlich auf die Seitenladezeiten aus und führen folglich zu einer schlechten Benutzererfahrung.

Wie kann Volterra ADN die App-Leistung verbessern?

Es gibt viele Techniken zur Verbesserung der Leistung von Web-Apps durch Optimierung der Application , z. B. durch Komprimieren von Bildern oder Optimieren von Abhängigkeiten, um die Seitenladezeiten zu verkürzen. Diese Optimierungen sind häufig nicht möglich, weil die Application von geschäftlichen Anforderungen bestimmt wird. Selbst wenn diese Optimierungen möglich sind, handelt es sich möglicherweise nicht um eine praktikable Option, weil die Entwickler, die die App geschrieben haben, nicht mehr im Unternehmen arbeiten oder mit der Entwicklung neuer Dienste beschäftigt sind. Daher legen DevOps-Teams in E-Commerce-Organisationen Wert auf Lösungen, die die App-Leistung verbessern können, ohne dass Änderungen an der Application erforderlich sind.

Volterra bietet zwei Produkte an, VoltMesh und VoltStack, die in Kombination mit Volterras ADN die Application um bis zu 75 % verbessern können (siehe Demonstration im nächsten Abschnitt). Das VoltMesh-Produkt von Volterra ist ein weltweit verteiltes Netzwerk- und Sicherheitsprodukt, das bei Konfiguration auf dem ADN von Volterra auch Funktionen zur Application bietet. Das Produkt VoltStack von Volterra bietet verteilte Application und Lebenszyklusverwaltung, wodurch Benutzer Teile ihrer Applications auf das ADN von Volterra auslagern können, um die Application weiter zu verbessern.

VoltMesh und VoltStack verbessern die Leistung von Application bei E-Commerce-Unternehmen auf drei Arten

Lösung 1: SSL-Terminierung (auch bekannt als TLS-Offload) auf Volterra ADN

Die einfachste Lösung zur Verbesserung der Leistung von Web-Apps besteht darin, die SSL-Sitzung über das Global ADN von Volterra zu beenden. Der Satz von sechs Nachrichten zum Einrichten der SSL-Sitzung wird lokal an den globales Netzwerk im Land gesendet und durchquert keine transatlantischen oder transpazifischen Verbindungen. Es wird eine dauerhafte SSL-Sitzung zwischen der Remote-Site des globales Netzwerk und dem Ursprungsserver geben, was die Leistung weiter verbessert. Dies kann wie in Abbildung 3 dargestellt visualisiert werden.

Lösung 2: Verschieben Sie latenzempfindliche Verarbeitungsprozesse wie die Cookie-Verarbeitung auf Volterra ADN.

Um die Leistung weiter zu verbessern, können Unternehmen latenzempfindliche Teile ihrer Apps auf dem ADN bereitstellen. Beispiele für latenzempfindliche Teile der Web-App sind die Cookie-Verarbeitung oder GraphQL oder Backend-für-Front-End. In einem E-Commerce-Unternehmen verarbeiten sie beispielsweise Cookies typischerweise, um zu bestimmen, welche Seite dem Benutzer angezeigt werden soll. Wenn der Benutzer z. B. über ein Konto verfügt, wird die Anmeldeseite angezeigt, andernfalls eine Gastseite. Die Verarbeitung von Cookies auf unserem ADN verbessert die Leistung dramatisch im Vergleich zur Verarbeitung von Cookies in zentralisierten Rechenzentren oder in der Cloud am anderen Ende der Welt. Dies kann wie in Abbildung 4 dargestellt visualisiert werden.

Lösung 3: Verschieben Sie das Frontend der Web-App (z. B. den Produktkatalog) selbst an den Rand, d. h. in den physischen Laden

Viele Handelsanbieter wie Macy‘s, Home Depot und Target verfügen auch über Ladengeschäfte, in denen die Kunden im Ladengeschäft den Online-Produktkatalog durchsehen, um den Standort der Artikel zu prüfen und auf Sonderangebote/Coupons zuzugreifen. Um das Benutzererlebnis zu verbessern, könnten sie sich dafür entscheiden, nur das Front-End ihrer Web-App auf die In-Store-Computer zu verschieben. Alle übrigen Komponenten ihrer App, d. h. Datenbanken, könnten im Back-End-Rechenzentrum verbleiben, da auf diese nicht so häufig zugegriffen wird wie auf den Front-End-Produktkatalog. Dies kann wie in Abbildung 5 dargestellt visualisiert werden.

Wichtige architektonische Grundsätze, die bei jeder Lösung zu berücksichtigen sind

Bei diesem Problem handelt es sich grundsätzlich um ein verteiltes Computerproblem über mehrere heterogene Clouds hinweg. DevOps-Teams könnten den Do-it-yourself-Weg gehen, indem sie Stücklösungen von verschiedenen Anbietern wie öffentlichen Cloud-Anbietern, CDN-Anbietern oder Edge-Anbietern zusammenschustern, oder eine Komplettlösung von Anbietern verteilter Cloud-Serviceplattformen kaufen. Die Herausforderungen sind in Abbildung 6 hervorgehoben.

Hier sind die wichtigsten Architekturgrundsätze, die DevOps-Teams bei der Bewertung jeder Lösung berücksichtigen sollten.

1. Einheitliche Application über mehrere Clouds hinweg: Die Application der DevOps-Teams wird auf ihre Backend-Cloud (die ein privates Rechenzentrum oder eine öffentliche Cloud sein kann) und ihre Edge-Standorte und physischen Filialstandorte verteilt, wobei es sich bei all diesen Standorten um völlig unterschiedliche Application handeln kann. DevOps-Teams sollten unbedingt Lösungen in Betracht ziehen, die Kubernetes nutzen, um eine konsistente Application über alle diese verteilten Clouds hinweg bereitzustellen. Kubernetes homogenisiert die Clouds und erleichtert die einfache Verschiebung von Applications zwischen den Clouds.
2. Geolokalisierte Verkehrsführung: Da das Front-End der Application an unterschiedlichen Standorten (Cloud, Edge, Edge im physischen Geschäft) bereitgestellt werden kann, sollte jede Lösung sicherstellen, dass der Datenverkehr des Benutzers an den nächstgelegenen Standort umgeleitet wird, an dem der Front-End-Dienst bereitgestellt wird. Und welche Lösung auch immer in Betracht gezogen wird, es sollte für die DevOps-Teams nicht erforderlich sein, die Internet-Routing-Richtlinien zu ändern.
3. Globaler Lastenausgleich: Jede in Betracht gezogene Lösung sollte einen globalen Lastausgleich bieten, da sich die Backend-Dienste an mehreren Standorten auf der ganzen Welt befinden könnten.
4. Einheitliche Application und Netzwerksicherheitsrichtlinien über mehrere Clouds hinweg: Während der Standort der Application je nach Region variieren kann, sollte jede in Betracht gezogene Lösung die Möglichkeit bieten, eine einheitliche Application und Netzwerksicherheitsrichtlinie unabhängig davon anzuwenden, in welcher Cloud der Front-End-Dienst bereitgestellt wird.
5. Übersichtliche Überwachung mehrerer Clouds sowie über Application und Netzwerkkonnektivität hinweg: In einer verteilten Cloud-Umgebung ist es äußerst schwierig, Probleme zwischen Applications und der Konnektivität in mehreren Clouds zu beheben. Jede in Betracht gezogene Lösung sollte eine zentrale Übersicht über Konnektivität, Sicherheit und Application in mehreren Clouds bieten.

Mit den Lösungen von Volterra erzielte Ergebnisse

Versuchsaufbau

Mit dem im Folgenden beschriebenen Testaufbau konnten die Leistungsverbesserungen demonstriert werden, die die einzelnen im vorherigen Abschnitt beschriebenen Volterra-Lösungen bieten: 

• Die verwendete Web-App war Online Boutique , eine Cloud-native Microservices- Application von Google. Die Web-App besteht aus 11 Microservices, wie in Abbildung 7 dargestellt

• Die Leistung der Web-App wurde mit webpagetest.org gemessen.
• Die Metrik, die zur Bestimmung der Web-App-Leistung in webpagetest.org verwendet wurde, war „Dokument abgeschlossen“.
• Das Unternehmen ist ein europäisches E-Commerce-Unternehmen mit Rechenzentren in Paris
• Der Benutzer (oder Kunde) befindet sich immer in San Francisco.

Testszenario und Ergebnisse

Die folgenden vier Szenarien wurden getestet und die Leistungsverbesserungen werden für jedes Szenario beschrieben.

Basisszenario: Zunächst stelle ich einen Basiswert für die Leistung der Web-App fest, wobei sich der Benutzer in San Francisco befindet und die Web-App vollständig im Pariser Rechenzentrum ausgeführt wird (siehe Abbildung 8). Die Leistung der Web-App wurde für das Basisszenario mit 3,5 Sekunden gemessen.

Lösung 1 Testszenario: Im Test für Lösung 1 befindet sich der Benutzer noch in San Francisco, die Web-App läuft noch im Pariser Rechenzentrum, die SSL-Sitzung wird jedoch auf dem VoltMesh-Reverse-Proxy beendet, der auf Volterra ADN in San Jose läuft. Dieses Szenario ist in Abbildung 9 dargestellt.

VoltMesh erstellt automatisch eine dauerhafte SSL-Sitzung zwischen dem im San Jose PoP ausgeführten Reverse-Proxy und der im Pariser Rechenzentrum ausgeführten Web-App. Die Leistung der Web-App verbesserte sich auf 2,9 Sekunden , eine Verbesserung von ~18 % .

Lösung 2 Testszenario: Im Test für Lösung 2 werden das Front-End und der Währungs-Microservice auf dem ADN in San Jose eingesetzt. Die restlichen Microservices und Datenbanken laufen weiterhin im Pariser Rechenzentrum. Dieses Szenario ist in Abbildung 10 dargestellt.

Der Grund dafür, nur die Front-End- und Währungs-Mikroservices zu verschieben, liegt darin, dass bei der gelegentlichen Browseraktivität der Benutzer nur diese Mikroservices beteiligt sind. Die Leistung der Web-App verbessert sich auf 2 Sekunden , eine Verbesserung um 31 % gegenüber den Ergebnissen von Lösung 1.

Lösung 3 Testszenario: Beim Test für Lösung 3 wurden das Front-End und der Währungs-Mikroservice auf einem handelsüblichen Intel NUC (4 virtuelle Kerne) im Edge-Bereich eines physischen Geschäfts bereitgestellt.

Der Grund dafür, nur die Front-End- und Währungs-Mikroservices zu verschieben, liegt darin, dass beim gelegentlichen Browsen der Benutzer im physischen Ladenbereich nur diese Mikroservices beteiligt sind. Die Leistung der Web-App verbessert sich auf 0,8 Sekunden , eine Verbesserung um 60 % gegenüber den Ergebnissen von Lösung 2.

Zusammenfassende Ergebnisse und wirtschaftlicher Wert

Eine Zusammenfassung der Testergebnisse und des sich daraus ergebenden wirtschaftlichen Werts ist in Abbildung 12 dargestellt. Der wirtschaftliche Wert lässt sich ermitteln, indem die Verbesserungen in Sekunden mit dem Wert jeder Sekunde der Verbesserung für das Unternehmen extrapoliert werden. Beispielsweise schätzt Amazon jede Verbesserung der Ergebnisse um eine Sekunde auf einen wirtschaftlichen Wert von 1,6 Milliarden US-Dollar. Daher bietet Lösung 3 gegenüber dem Ausgangswert einen wirtschaftlichen Wert von 4,3 Milliarden US-Dollar.

Wie aus diesen Ergebnissen hervorgeht, können DevOps-Teams mit den drei in diesem Blog vorgeschlagenen Optionen erhebliche Leistungsverbesserungen erzielen, ohne die Application neu zu schreiben, und gleichzeitig das gleiche Maß an Sicherheitsschutz für ihre Application aufrechterhalten. Wenn Sie mehr über echte Anwendungsfälle von Kunden erfahren möchten, die durch eine verteilte Cloud-Plattform gelöst werden können, oder wenn Sie echte Anwendungsfälle von Kunden haben, die Sie mit mir teilen möchten, können Sie mich gerne über LinkedIn oder Twitter erreichen.