Best Practices für die Auswahl der Region in Compute Engine

In diesem Artikel werden die Kriterien beschrieben, die bei der Auswahl der Google Cloud-Regionen für Compute Engine-Ressourcen zu berücksichtigen sind. Diese Entscheidung wird normalerweise von Cloud-Architekten oder vom Engineering-Management getroffen. Das Dokument konzentriert sich in erster Linie auf den Latenzaspekt des Auswahlprozesses und bezieht sich auf Anwendungen, auf die Verbraucher zugreifen, wie z. B. mobile Apps, Webanwendungen oder Spiele. Viele der Konzepte können jedoch auch auf andere Anwendungsfälle angewendet werden.

Google bietet weltweit mehrere Regionen für die Bereitstellung von Compute Engine-Ressourcen an. Bei der Auswahl der Regionen spielen verschiedene Faktoren eine Rolle:

  • Regionsspezifische Einschränkungen
  • Vom Nutzer wahrgenommene Latenz nach Region
  • Latenzanforderungen der Anwendung
  • Umfang der Kontrolle über die Latenz
  • Ausgewogenheit zwischen niedriger Latenz und Einfachheit

Terminologie

Region
Ein unabhängiger geografischer Bereich, in dem Sie Ressourcen ausführen. Jede Region besteht aus Zonen, in der Regel mindestens drei Zonen.
Zone
Ein Bereitstellungsbereich für Google Cloud-Ressourcen innerhalb einer Region. Wenn Sie Ressourcen in verschiedenen Zonen in einer Region platzieren, verringern Sie das Risiko von Infrastrukturausfällen, die alle Ressourcen gleichzeitig betreffen.
Compute Engine-Ressourcen
Ressourcen in Compute Engine, beispielsweise VM-Instanzen, werden in einer Zone innerhalb einer Region bereitgestellt. Andere Produkte wie Google Kubernetes Engine und Dataflow verwenden Ressourcen der Compute Engine und können daher in denselben Regionen oder Zonen bereitgestellt werden.
Umlaufzeit (round-trip time – RTT)
Zeit, die erforderlich ist, um ein IP-Paket zu senden und die Bestätigung zu erhalten.

Wann müssen Compute Engine-Regionen ausgewählt werden?

Entscheiden Sie sich bereits bei der Architekturplanung für eine Anwendung, wie viele und welche Regionen von Compute Engine verwendet werden sollen. Diese Wahl kann die Anwendung beeinflussen, zum Beispiel:

  • Die Architektur der Anwendung kann sich ändern, wenn Sie einige Daten zwischen Kopien synchronisieren, da dieselben Nutzer zu unterschiedlichen Zeiten über verschiedene Regionen eine Verbindung herstellen können.
  • Die Preise sind je nach Region unterschiedlich.
  • Das Verschieben einer Anwendung und ihrer Daten zwischen Regionen ist umständlich und manchmal kostspielig. Daher sollte dies vermieden werden, sobald die Anwendung aktiv ist.

Bei der Auswahl von Regionen zu berücksichtigende Faktoren

Im Allgemeinen stellen Personen Anwendungen in der Region bereit, in der sie sich selbst befinden, ohne jedoch zu berücksichtigen, ob sie damit den höchsten Nutzungskomfort bieten. Angenommen, Sie befinden sich in Europa, haben Nutzer aus der ganzen Welt, möchten aber eine Anwendung in nur einer Region bereitstellen. Die meisten Personen würden den Einsatz in einer Region in Europa in Betracht ziehen. Allerdings wäre es besser, diese Anwendung in einer der Regionen in den USA zu hosten, da die USA am besten mit anderen Regionen verbunden sind.

Die Entscheidung, wo Sie eine Anwendung bereitstellen, hängt von mehreren Faktoren ab:

Latenz

Der zu berücksichtigende Hauptfaktor ist die Latenz, mit der die Nutzer konfrontiert werden Dies ist jedoch ein komplexes Thema, da die vom Nutzer wahrgenommene Latenz von mehreren Aspekten beeinflusst wird, z. B. von Mechanismen für das Speichern im Cache oder den Lastenausgleich.

In Anwendungsfällen von Unternehmen ist die Latenz für lokale Systeme oder für eine bestimmte Untergruppe von Nutzern oder Partnern kritischer. Die Auswahl der Region, die Ihren Entwicklern oder lokalen, mit der Google Cloud verbundenen Datenbankdiensten am nächsten liegt, könnte der entscheidende Faktor sein.

Preise

Die Kosten für Google Cloud-Ressourcen unterscheiden sich je nach Region. Für Kostenschätzungen stehen folgende Ressourcen zur Verfügung:

Wenn Sie in mehreren Regionen bereitstellen, müssen Sie beachten, dass für Daten, die zwischen Regionen synchronisiert werden, Gebühren für die Datenübertragung anfallen.

Colocation mit anderen Google Cloud-Diensten

Führen Sie, wenn möglich, Ihre Compute Engine-Ressourcen mit anderen Google Cloud-Diensten zusammen. Die meisten latenzempfindlichen Dienste sind in allen Regionen verfügbar, einige andere Dienste jedoch nur an bestimmten Standorten.

Verfügbarkeit des Maschinentyps

Nicht alle CPU-Plattformen und Maschinentypen sind in jeder Region verfügbar. Die Verfügbarkeit bestimmter CPU-Plattformen oder bestimmter Instanztypen variiert je nach Region oder gar Zone. Wenn Sie Ressourcen mit bestimmten Maschinentypen bereitstellen möchten, informieren Sie sich über die zonale Verfügbarkeit dieser Ressourcen.

Ressourcenkontingente

Die Bereitstellung von Compute Engine-Ressourcen wird durch regionale Ressourcenkontingente begrenzt. Achten Sie daher darauf, ein ausreichendes Kontingent für die Regionen anzufordern, in denen Sie bereitstellen möchten. Wenn Sie eine besonders umfangreiche Bereitstellung planen, sollten Sie sich frühzeitig mit dem Vertriebsteam in Verbindung setzen, um die Auswahlmöglichkeiten für Regionen zu besprechen und die Verfügbarkeit eines ausreichenden Kontingents zu gewährleisten.

Prozentsatz kohlenstofffreier Energie

Für jede Google Cloud-Region nutzt Google Strom aus dem Netz, in dem sich die Region befindet. Dieser Strom erzeugt mehr oder weniger CO2-Emissionen, je nachdem, welche Art von Kraftwerken für dieses Netz Strom erzeugen und wann Google ihn verbraucht. Google hat vor Kurzem das Ziel gesetzt, bis 2030 eine klimaneutrale Stromversorgung Ihrer Anwendungen zur richtigen Zeit und am benötigten Standort zu gewährleisten – in jeder Google Cloud-Region, rund um die Uhr.

Bis dieses Ziel erreicht ist, wird jede Google Cloud-Region stündlich durch eine Mischung aus kohlenstoffbasierten und kohlenstofffreien Energiequellen versorgt. Diese Mischung wird durch einen Prozentsatz für kohlenstofffreie ENergiequellen (CFE) angegeben und für Google Cloud-Regionen veröffentlicht. Bei neuen Anwendungen in Google Cloud können Sie diese Tabelle verwenden, um die Klimabelastung bei Ihren Architekturentscheidungen zu berücksichtigen. Wenn Sie eine Region mit einem höheren CFE-%-Wert auswählen, wird Ihre Anwendung durchschnittlich zu einem höheren Prozentsatz mit kohlenstofffreier Energie betrieben, wodurch die BruttoCO2-Emissionen sinken.

Latenzanforderungen auswerten

Die Latenzzeit ist oft der Schlüsselfaktor für die Wahl der Region, da eine hohe Latenz beim Endnutzer den Nutzerkomfort beeinträchtigt. Einige Aspekte der Latenz können Sie beeinflussen, andere liegen jedoch außerhalb Ihrer Kontrolle.

Bei der Latenzoptimierung berücksichtigen viele Systemarchitekten nur die Netzwerklatenz oder die Entfernung zwischen dem Internetanbieter des Nutzers und der Instanz der virtuellen Maschine. Dies ist jedoch nur einer von vielen Faktoren, die sich auf die vom Nutzer wahrgenommene Latenz auswirken, wie das folgende Diagramm veranschaulicht.

Latenz bei der Auswahl der Region in Compute Engine bewerten

Als Anwendungsarchitekt können Sie die Regionsauswahl und die Latenz der Anwendungen optimieren, haben jedoch keine Kontrolle über die sogenannte "letzte Meile" zum Nutzer und die Latenzzeit bis zu den nächstgelegenen Edge-POPs (Points of Presence) von Google.

Die Wahl einer Region kann nicht die gesamte Latenz, sondern nur die Latenz für den Compute Engine-Bereich beeinflussen. Je nach Anwendungsfall ist dies möglicherweise nur ein kleiner Teil der Gesamtlatenz. Wenn Ihre Nutzer z. B. hauptsächlich Mobilfunknetze verwenden, ist es möglicherweise nicht sinnvoll, die Regionen zu optimieren, da dies die Gesamtlatenz kaum beeinflusst.

Latenz der letzten Meile

Die Latenz dieses Segments unterscheidet sich je nach der für den Internetzugang verwendeten Technologie. Beispielsweise beträgt die typische Latenz bis zum Erreichen eines Internetanbieters in modernen Netzwerken 1 bis 10 ms. Umgekehrt betragen typische Latenzen in einem 3G-Mobilfunknetz 100 bis 500 ms. Der Latenzbereich bei DSL- und Kabelanbietern beträgt ca. 10 bis 60 ms.

Google Frontend- und Edge-POP-Latenz

Abhängig von Ihrem Bereitstellungsmodell ist auch die Latenz bis zum Edge-POP von Google wichtig. An diesen Punkten beenden globale Load-Balancing-Produkte TCP- und SSL-Sitzungen und von hier liefert Cloud CDN zwischengespeicherte Ergebnisse. Abhängig von den bereitgestellten Inhalten könnten viele Umläufe hier bereits enden, da nur ein Teil der Daten vollständig abgerufen werden muss. Diese Latenzzeit kann erheblich höher sein, wenn Sie die Standard-Netzwerkdienststufe verwenden.

Latenz für Compute Engine-Regionen berechnen

Nutzeranfragen erreichen das Google-Netzwerk am Edge-POP. Die Google Cloud-Ressourcen, die diese Anfragen verarbeiten, befinden sich hingegen in der Compute Engine-Region. Dieses Segment bestimmt die Latenzzeit zwischen der Region des Edge-POPs und der Compute Engine-Region und liegt vollständig innerhalb des globalen Google-Netzwerks.

Anwendungslatenz

Dies ist die Latenz der Anwendung bis zu ihrer Reaktion auf Anfragen, einschließlich der Zeit, die die Anwendung zum Verarbeiten der Anfrage benötigt.

Unterschiedliche Anwendungen haben unterschiedliche Latenzanforderungen. Je nach Anwendungstyp ist die Latenz für Nutzer mehr oder weniger relevant. Anwendungen, die asynchron arbeiten, oder mobile Apps, die mit einem hohen Latenzschwellenwert von 100 Millisekunden oder mehr interagieren, können in einer einzigen Region bereitgestellt werden, ohne den Nutzungskomfort zu beeinträchtigen. Bei Anwendungen wie Echtzeitspielen können bereits Latenzzeiten von wenigen Millisekunden eine größere Auswirkung auf diesen Nutzungskomfort haben. Stellen Sie daher solche Arten von Anwendungen in mehreren Regionen in der Nähe der Nutzer bereit.

Globale Bereitstellungsmuster

In diesem Abschnitt wird erläutert, wie verschiedene Bereitstellungsmodelle Latenzfaktoren beeinflussen.

Bereitstellung in einer Region

Die folgende Abbildung veranschaulicht die Bereitstellung für eine einzelne Region.

Latenz der Bereitstellung eines einzelnen Front-Ends

Selbst wenn eine Anwendung weltweit Nutzer hat, ist eine Region in vielen Fällen dennoch die beste Wahl. Die Vorteile der geringeren Latenz bei Bereitstellung in mehreren Regionen können die Nachteile der zusätzlichen Komplexität nicht überwiegen. Auch bei Bereitstellung in einer Region können Sie Optimierungen wie Cloud-CDN und globalen Lastausgleich verwenden, um die Wartezeiten der Nutzer zu reduzieren. Sie können eine zweite Region für Sicherungs- und Notfallwiederherstellungszwecke verwenden. Dies wirkt sich jedoch nicht auf den Bereitstellungspfad der Anwendung und somit auch nicht auf die vom Nutzer wahrgenommene Latenz aus.

Verteiltes Frontend in mehreren Regionen und Backend in einer einzelnen Region

Das folgende Diagramm zeigt ein Bereitstellungsmodell, bei dem Sie das Frontend auf mehrere Regionen verteilen, das Backend jedoch auf eine einzelne Region beschränken. Dieses Modell bietet den Vorteil geringerer Latenz für die Frontend-Server, ohne Daten über mehrere Regionen hinweg synchronisieren zu müssen.

Latenz der verteilten Frontend-Bereitstellung

Dieses Bereitstellungsmodell bietet eine niedrige Nutzerlatenz in Fällen, in denen die durchschnittliche Nutzeranfrage keine Datenanfragen oder nur wenige Datenanfragen an das zentrale Back-End umfasst, bevor die Anwendung ein Ergebnis generiert. Ein Beispiel hierfür ist eine Anwendung, die eine intelligente Caching-Ebene im Frontend bereitstellt oder Datenschreibvorgänge asynchron ausführt. Von diesem Modell könnte eine Anwendung, die viele Anfragen stellt, die einen vollständigen Umlauf an das Back-End erfordern, nicht profitieren.

Verteiltes Frontend und Backend in mehreren Regionen

Mit einem Bereitstellungsmodell, in dem Sie das Frontend und das Backend auf mehrere Regionen verteilen, können Sie die Wartezeiten der Nutzer minimieren, da die Anwendung jede Anfrage vollständig lokal verarbeiten kann. Dieses Modell ist jedoch komplexer, da alle Daten lokal gespeichert und abrufbar sein müssen. Damit alle Nutzeranfragen beantwortet werden können, müssen die Daten in allen Regionen vollständig repliziert werden.

Latenz der verteilten Mehrfachbereitstellung

Spanner, das weltweit einheitliche Angebot für verwaltete Datenbanken, bietet eine überregionale Option für drei Kontinente mit nicht schreibgeschützten Replikaten in den USA sowie einem schreibgeschützten Replikat jeweils in Europa und Asien. Diese Option bietet Lesezugriff mit geringer Latenz auf Daten, die auf Instanzen in den USA, in Europa oder Asien verarbeitet werden. Wenn Ihr Dienst vor allem in den USA genutzt wird, gibt es auch eine überregionale Option mit Replikation innerhalb der USA.

Wenn Sie einen eigenen Datenbankdienst auf der Compute Engine ausführen, replizieren Sie die Daten selbst. Diese Replikation ist ein komplexes Unterfangen, da die konsistente globale Synchronisierung der Daten schwierig ist. Die Verwaltung ist einfacher, wenn nur in einer Region asynchron in die Datenbank geschrieben wird und die anderen Regionen schreibgeschützte Replikate der Datenbank hosten.

Das Replizieren von Datenbanken in verschiedenen Regionen ist komplex. Daher empfehlen wir hierfür die Kooperation mit einem auf diesem Gebiet kompetenten Partner wie Datastax für Cassandra-Replikation.

Mehrere parallele Anwendungen

Je nach Art Ihrer Anwendung können Sie mit einer Variation des vorstehend beschriebenen Ansatzes die niedrige Nutzerlatenz beibehalten und gleichzeitig die Notwendigkeit einer ständigen Datenreplikation reduzieren. Wie in der folgenden Abbildung dargestellt, können parallel mehrere Anwendungen bereitgestellt werden, die alle jeweils aus einem Frontend und einem Backend bestehen, und die Nutzer werden zur jeweils richtigen Anwendung geleitet. Nur ein kleiner Teil der Daten wird standortübergreifend gemeinsam genutzt.

Latenz paralleler Anwendungen

Wenn Sie beispielsweise ein Einzelhandelsgeschäft betreiben, können Sie Nutzer in verschiedenen Regionen über verschiedene Länderdomains bedienen und in all diesen Regionen parallel Websites betreiben, wobei Produkt- und Nutzerdaten nur bei Bedarf synchronisiert werden. Die lokalen Websites haben jeweils eigene Lagerbestände und Nutzer stellen eine Verbindung zu einer lokal gehosteten Website her, indem sie die entsprechende Länderdomain auswählen. Wenn ein Nutzer eine Website mit einer anderen Länderdomain aufruft, wird er zu der korrekten Domain weitergeleitet.

Ein anderes Beispiel sind Echtzeitspiele. Möglicherweise betreiben Sie nur einen globalen Lobby-Dienst, bei dem Nutzer einen Spielraum oder eine Spielwelt in der Nähe ihres Standorts auswählen und diese Räume oder Welten keine Daten austauschen.

Ein drittes Beispiel ist das Angebot von Software-as-a-Service (SaaS) in verschiedenen Regionen, in denen der Datenstandort bei der Kontoerstellung ausgewählt wird, entweder basierend auf dem Standort des Nutzers oder seiner Wahl. Nach der Anmeldung wird der Nutzer zu einer ortsspezifischen Subdomain umgeleitet und nutzt den Dienst regional.

Latenz zwischen Nutzern und Regionen optimieren

Unabhängig von Ihrem Bereitstellungsmodell können Sie Optimierungsmethoden kombinieren, um die vom Endnutzer wahrgenommene Latenz zu reduzieren. Einige dieser Methoden sind Google Cloud-Features, während Sie für andere Features Ihre Anwendung ändern müssen.

Netzwerk der Premium-Stufe verwenden

Google bietet erstklassige Premium- (Standard) und Standard-Netzwerkdienststufen an. Traffic der Standardstufe wird über Transit-Internetanbieter aus Google Cloud-Regionen bereitgestellt. Die Premium-Stufe bietet eine niedrigere Latenz, da der Traffic über das globale private Netzwerk von Google übertragen wird. Im Netzwerk der Premium-Stufe ist die Latenz beim Nutzer geringer, daher sollte es für alle Teile der Anwendung im Bereitstellungspfad verwendet werden. Auch für die Nutzung der globalen Lastenausgleichsprodukte von Google ist das Netzwerk der Premium-Stufe erforderlich.

Cloud Load Balancing und Cloud CDN verwenden

Cloud Load Balancing, wie HTTP(S) Load Balancing, TCP und SSL Proxy Load Balancing, ermöglichen die automatische Umleitung von Nutzern in die nächstgelegene Region, in der sich Back-Ends mit verfügbarer Kapazität befinden.

Auch wenn Ihre Anwendung in nur einer Region gehostet wird, führt die Verwendung von Cloud Load Balancing dennoch zu einer geringeren Latenz beim Nutzer, da TCP- und SSL-Sitzungen am Edge-POP beendet werden. Beenden Sie den Nutzertraffic unkompliziert mit HTTP/2 und Quick UDP Internet Connections (QUIC). Sie können Cloud CDN auch mit HTTP(S) Load Balancing verknüpfen, um statische Inhalte direkt vom Edge-POP aus bereitzustellen, wodurch die Latenz beim Nutzer weiter reduziert wird.

Lokal im Cache speichern

Wenn die Frontend-Standorte von den Backend-Standorten verschieden sind, sollten die Antworten der Backend-Dienste nach Möglichkeit im Cache gespeichert werden. Befinden sich die Frontend- und Backend-Dienste hingegen in derselben Region, verringert sich die Latenz der Anwendung, da auch zeitintensive Abfragen reduziert werden. Memorystore for Redis ist ein vollständig verwalteter, speicherinterner Datenspeicherdienst, den Sie verwenden können.

Appclient oder Web-Frontend optimieren

Clientseitig können Sie eine mobile App oder ein Web-Frontend nutzen, um die Latenz für den Nutzer zu reduzieren. Laden Sie beispielsweise einige Inhalte oder Cache-Daten innerhalb der Anwendung vorab.

Sie können auch die Methode optimieren, nach der die Anwendung Informationen abruft, indem Sie die Anzahl der Anfragen reduzieren und Informationen parallel abrufen, wann immer dies möglich ist.

Latenz beim Nutzer messen

Nachdem Sie Ihre Latenzanforderungen grundsätzlich definiert haben, können Sie anhand der Nutzerstandorte die optimale Platzierung Ihrer Google Cloud-Ressourcen bestimmen. Je nachdem, ob es sich um eine neue oder vorhandene Anwendung handelt, gibt es hierfür unterschiedliche Strategien.

Verwenden Sie die folgenden Strategien, um die Latenz bei Partneranwendungen zu messen, auf die Sie während der Anwendungsbereitstellung zugreifen, oder um die Latenz in Ihrem lokalen Netzwerk zu erfassen, das möglicherweise über Cloud VPN oder Dedicated Interconnect mit Ihrem Google Cloud-Projekt verbunden ist.

Latenz für neue Arbeitslasten schätzen

Wenn Sie keine vorhandene Anwendung mit ähnlicher Nutzerzusammensetzung wie die neue Anwendung haben, schätzen Sie die Latenz aus verschiedenen Google Cloud-Regionen anhand der ungefähren Standortverteilung Ihrer erwarteten Nutzer.

Veranschlagen Sie als Umlaufzeit für jeweils 100 zurückgelegte Kilometer auf 1 ms. Da Netzwerke nicht dem idealen Pfad von Quelle bis Ziel folgen, können Sie in der Regel davon ausgehen, dass die tatsächliche Entfernung das etwa 1,5- bis 2-Fache der auf einer Karte gemessenen Entfernung beträgt. In weniger dicht besiedelten Regionen können die Netzwerke einem möglicherweise noch ungünstigeren Pfad folgen. Die Latenz, die durch die aktive Ausrüstung in den Netzwerken der Internetanbieter noch hinzugefügt wird, kann bei der Betrachtung überregionaler Entfernungen in der Regel vernachlässigt werden.

Mithilfe dieser Zahlen können Sie die Latenz für Edge-POP- und Cloud-CDN-Knoten sowie für Compute Engine-Regionen auf der ganzen Welt schätzen, die auf der Netzwerkkarte verzeichnet sind.

Latenz für bestehende Nutzer messen

Wenn Sie bereits eine Anwendung mit einer ähnlichen Nutzerbasis haben, können Sie verschiedene Tools verwenden, um Latenzen besser zu schätzen.

  • Repräsentative Nutzer: Wenn Sie Nutzer oder Partner haben, die einen Querschnitt der geografischen Verteilung repräsentieren und bereit sind, mit Ihnen oder Mitarbeitern in diesen Ländern zusammenzuarbeiten, bitten Sie sie, die Latenz in verschiedenen Google Cloud-Regionen zu messen. Für solche Messungen können Websites von Drittanbietern wie Google Cloud-Ping genutzt werden.
  • Zugriffslogs: Wenn Sie eine aktive Anwendung außerhalb der Google Cloud gehostet haben, verwenden Sie Daten aus den Zugriffslogs, um sich einen groben Überblick über die Nutzerstandorte zu verschaffen. Die Logs enthalten möglicherweise Landes- oder Städteinformationen, mit denen Sie auch Latenzen abschätzen können.
  • IP-Adresse: Wenn Sie Zugriff auf die IP-Adressen Ihrer Nutzer haben, erstellen Sie Skripts, um die Erreichbarkeit und die Latenzen aus verschiedenen Google Cloud-Regionen zu testen. Wenn die Firewall Ihre Testläufe blockiert, versuchen Sie, das letzte IP-Oktett nach dem Zufallsprinzip zu wählen, um eine Antwort von einem anderen Gerät mit einer ähnlichen Latenz zu Ihrer Anwendung zu erhalten.

  • Latenzinformationen von Google Cloud: Wenn Sie bereits eine Anwendung in Google Cloud haben, gibt es mehrere Möglichkeiten, Latenzinformationen zu erfassen.

Globale Verbindungen

Beachten Sie bei der Schätzung der Latenz die Topologie des globalen Google-Netzwerks.

  • POPs: Orte, an denen der Nutzertraffic in das Netzwerk eintritt
  • Cloud-CDN-Knoten: Orte, an denen der Traffic im Cache gespeichert wird
  • Regionen: Mögliche Speicherstandorte Ihrer Ressourcen
  • Verbindung: Zwischen den POPs und Regionen

Suchen Sie nach einer Liste von Orten, an denen Google über PeeringDB mit anderen Internetanbietern verbunden ist.

Berücksichtigen Sie bei der Auswahl der Regionen, in denen die Bereitstellung erfolgen soll, die überregionale Topologie. Wenn Sie beispielsweise eine Anwendung mit einer weltweiten Nutzerbasis in einer einzigen Region bereitstellen möchten, empfiehlt es sich, diese Anwendung in einer der Regionen in den USA zu hosten, da die USA mit den meisten anderen Regionen verbunden sind. Obwohl eine direkte Verbindung zwischen vielen Kontinenten besteht, gibt es Fälle, in denen sie beispielsweise zwischen Europa und Asien fehlt, sodass der Traffic zwischen Europa und Asien über die USA fließt.

Wenn Ihre Anwendung in mehreren Regionen gehostet wird und Sie Daten synchronisieren müssen, beachten Sie die Latenz zwischen diesen Regionen. Diese Latenz kann sich zwar mit der Zeit ändern, ist jedoch normalerweise stabil. Messen Sie die Latenz entweder selbst, indem Sie Testinstanzen in allen potenziellen Regionen einrichten, oder verwenden Sie Websites von Drittanbietern, um sich einen Überblick über die aktuellen Latenzen zwischen den Regionen zu verschaffen.

Zusammenfassung

Nachdem Sie die Latenzanforderungen, mögliche Implementierungsmodelle und die geografische Verteilung Ihrer Nutzerbasis betrachtet haben, wissen Sie, wie diese Faktoren die Latenz in bestimmten Regionen beeinflussen. Nun können Sie entscheiden, in welchen Regionen Sie Ihre Anwendung starten möchten.

Es gibt keinen allgemeingültig richtigen Weg, die verschiedenen Faktoren abzuwägen, die nachstehend beschriebene schrittweise Methode kann Ihnen jedoch bei der Entscheidung helfen:

  1. Prüfen Sie, ob es andere, nicht mit der Latenz zusammenhängende Ausschlussfaktoren für die Errichtung in bestimmten Regionen gibt, wie zum Beispiel Preise oder Colocation. Entfernen Sie diese aus der Liste der möglichen Regionen.
  2. Wählen Sie basierend auf den Latenzanforderungen und der allgemeinen Anwendungsarchitektur ein Bereitstellungsmodell für die Anwendung aus. Bei den meisten mobilen Apps und anderen nicht latenzkritischen Anwendungen ist die Bereitstellung in einer Region mit Cloud CDN-Bereitstellung im Cache speicherbarer Inhalte und SSL-Beendigung am Edge-POP die beste Wahl.

  3. Wählen Sie auf der Grundlage Ihres Deployment-Modells Regionen nach der geografischen Verteilung der Nutzer und Ihrer Latenzmessungen aus:

    • Für die Bereitstellung in einer Region:

      • Wenn Sie Zugriff auf Ihre Unternehmensumgebung mit geringer Latenz benötigen, erstellen Sie die Anwendung in der Region, die diesem Standort am nächsten liegt.
      • Wenn Ihre Nutzer hauptsächlich aus demselben Land oder derselben Region stammen, erstellen Sie die Anwendung in einer Region, die Ihren repräsentativen Nutzern am nächsten ist.
      • Wenn Sie eine globale Nutzerbasis haben, wählen Sie eine Region in den USA aus.

    • Für eine Bereitstellung in mehreren Regionen:

      • Wählen Sie Regionen in der Nähe Ihrer Nutzer basierend auf deren geografischer Verteilung und den Latenzanforderungen der Anwendung aus. Optimieren Sie die Anwendung je nach Typ für eine bestimmte mittlere Latenz oder achten Sie darauf, dass 95 bis 99 % der Nutzer mit einer bestimmten Ziellatenz bedient werden. Nutzer an bestimmten geografischen Standorten haben aufgrund ihrer Infrastrukturbeschränkungen häufig eine höhere Toleranz für Latenz.

  4. Wenn die Nutzerlatenz in mehreren Regionen ähnlich ist, kann die Preisfindung der entscheidende Faktor sein.

Bei der Auswahl von Compute Engine-Regionen ist die Latenz einer der wichtigsten zu berücksichtigenden Faktoren. Bewerten und messen Sie die Latenzanforderungen, um eine hohen Nutzerkomfort zu bieten, und wiederholen Sie den Vorgang, wenn sich die geografische Verteilung Ihrer Nutzerbasis ändert.

Nächste Schritte