Traffic aufteilen

Regions-ID

REGION_ID ist ein abgekürzter Code, den Google anhand der Region zuweist, die Sie beim Erstellen Ihrer Anwendung ausgewählt haben. Der Code bezieht sich nicht auf ein Land oder eine Provinz, auch wenn einige Regions-IDs häufig verwendeten Länder- und Provinzcodes ähneln können. Bei Anwendungen, die nach Februar 2020 erstellt wurden, ist REGION_ID.r in den App Engine-URLs enthalten. Bei Anwendungen, die vor diesem Datum erstellt wurden, ist die Regions-ID in der URL optional.

Hier finden Sie weitere Informationen zu Regions-IDs.

Sie haben die Möglichkeit, Traffic prozentual auf zwei oder mehr Versionen innerhalb eines Dienstes aufzuteilen. Durch die Aufteilung des Traffics können Sie A/B-Tests zwischen Ihren Versionen ausführen und haben dadurch die Kontrolle über das Tempo, mit dem Funktionen eingeführt werden.

Die Trafficaufteilung wird auf URLs angewendet, die nicht explizit auf eine Version ausgerichtet sind. Die folgenden URLs teilen beispielsweise den Traffic auf, da sie auf alle verfügbaren Versionen innerhalb des angegebenen Dienstes abzielen:

  • https://PROJECT_ID.REGION_ID.r.appspot.com verteilt den Traffic auf Versionen des Dienstes default.
  • https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com verteilt den Traffic auf Versionen des Dienstes [SERVICE_ID]

Informationen dazu, wie Anfragen eine Version erreichen, finden Sie unter Anfragerouting.

Vorbereitung

Bevor Sie den Traffic für eine Version konfigurieren, prüfen Sie, ob Ihr Nutzerkonto die erforderlichen Berechtigungen hat.

Caching-Probleme vermeiden

Bevor Sie die Trafficaufteilung aktivieren, sollten Sie potenzielle Caching-Probleme berücksichtigen. Caching-Probleme können bei jeder App Engine-Anwendung auftreten, insbesondere bei der Bereitstellung einer neuen Version. Durch die Trafficaufteilung treten geringfügige Caching-Probleme oft deutlicher hervor.

Gehen wir beispielsweise davon aus, dass Sie den Traffic zwischen den zwei Versionen A und B aufteilen und dass eine externe cachefähige Ressource, zum Beispiel eine CSS-Datei, zwischen den Versionen geändert wurde. Nehmen wir weiter an, dass ein Client eine Anfrage stellt und die Antwort einen externen Verweis auf die im Cache gespeicherte Datei enthält. Unabhängig davon, welche Version der Datei im Cache gespeichert ist und welche Version der Anwendung die Antwort gesendet hat, ruft der lokale HTTP-Cache die Datei ab, wenn sie sich im Cache befindet. Die im Cache gespeicherte Ressource ist möglicherweise nicht mit den Daten kompatibel, die in der Antwort gesendet wurden.

So vermeiden Sie Caching-Probleme:

  • Legen Sie für dynamische Ressourcen die Header Cache-Control und Expires fest. Diese Header teilen Proxys mit, dass es sich um eine dynamische Ressource handelt. Es empfiehlt sich, beide Header festzulegen, da nicht alle Proxyserver den HTTP/1.1-Header Cache-Control fehlerfrei unterstützen.

    Weitere Informationen zum Caching im Allgemeinen finden Sie im Abschnitt zu Headerfeldern in HTTP/1.1 RFC und in der Übersicht zum HTTP-Caching in Web Fundamentals.

  • Bei cachefähigen statischen Ressourcen, die nach Version unterschiedlich sind, ändern Sie die URL der Ressource für die Versionen. Wenn die statischen Ressourcen von verschiedenen URLs bereitgestellt werden, können beide Versionen problemlos in Proxyservern und Browser-Caches nebeneinander bestehen.

Sie können auch den Header Vary: Cookie in Ihrer Anwendung festlegen. Dadurch wird die Eindeutigkeit einer Ressource durch Kombination der Cookies und der URL für die Anfrage berechnet. Bei dieser Vorgehensweise werden Cache-Server jedoch stärker belastet. Es gibt 1.000 mögliche Werte für GOOGAPPUID, also auch 1.000 mögliche Einträge für jede URL Ihrer Anwendung. Je nach Auslastung der Proxys zwischen Ihren Nutzern und Ihrer Anwendung kann dies dazu führen, dass die Anwendung weniger häufig ein im Cache gespeichertes Ergebnis bereitstellt. Darüber hinaus werden Nutzern, die einer Version in den letzten 24 Stunden neu hinzugefügt wurden, die im Cache gespeicherten Ressourcen möglicherweise weiterhin angezeigt. Die Verwendung von Vary: Cookie kann jedoch das Umbenennen statischer Ressourcen erleichtern, die sich von Version zu Version ändern.

Das Verfahren Vary: Cookie funktioniert nicht immer. Im Allgemeinen sollten Sie bei einer Anwendung, die Cookies für andere Zwecke verwendet, berücksichtigen, wie sich dies auf die Auslastung der Proxyserver auswirkt. Wenn codeninja ein eigenes Cookie mit 100 möglichen Werten hätte, nähme der Raum für alle möglichen Cache-Einträge einen sehr hohen Wert an (100 x 1.000 = 100.000). Im schlimmsten Fall gibt es für jeden Nutzer ein einzelnes Cookie. Zwei gängige Beispiele hierfür sind Google Analytics (__utma) und SiteCatalyst (s_vi). In diesen Fällen erhält jeder Nutzer eine einmalige Kopie, wodurch die Cache-Leistung stark beeinträchtigt wird und sich außerdem die von Ihrer Anwendung verbrauchten kostenpflichtigen Instanzstunden erhöhen können.

Traffic auf mehrere Versionen aufteilen

Wenn Sie zwei oder mehr Versionen für die Aufteilung angegeben haben, müssen Sie auswählen, ob der Traffic mithilfe der IP-Adresse eines Absenders oder eines HTTP-Cookies aufgeteilt werden soll. Es ist einfacher, eine Aufteilung nach IP-Adresse einzurichten, doch die Cookie-Aufteilung ist genauer. Weitere Informationen finden Sie unter Aufteilung nach IP-Adresse und Aufteilung nach Cookies.

Console

Um Traffic in der Cloud Console aufzuteilen, rufen Sie die Seite „Versionen“ auf:

Zur Seite „Versionen“

  1. Wählen Sie eine oder mehrere Versionen aus, auf die der Traffic aufgeteilt werden soll.
  2. Klicken Sie auf Traffic aufteilen und geben Sie Folgendes an:
    • Die Methode, die Sie zum Aufteilen des Traffics verwenden möchten
    • Den prozentualen Anteil des Traffics, der auf jede Version entfallen soll.

gcloud

Nach der Installation der Google Cloud CLI führen Sie den folgenden Befehl aus, um den Traffic auf mehrere Versionen aufzuteilen. Beispiel:

gcloud app services set-traffic [MY_SERVICE] --splits [MY_VERSION1]=[VERSION1_WEIGHT],[MY_VERSION2]=[VERSION2_WEIGHT] --split-by [IP_OR_COOKIE]

Weitere Informationen und zusätzliche Optionen finden Sie in der Referenz zu gcloud app services set-traffic.

API

Sie können die Admin API verwenden, um den Traffic programmatisch zu migrieren. Weitere Informationen finden Sie unter Traffic migrieren und aufteilen.

Aufteilung nach IP-Adresse

Wenn Sie sich entscheiden, den Traffic zu Ihrer Anwendung nach IP-Adresse des Absenders aufzuteilen, setzt die Anwendung bei Eingang einer Anfrage die IP-Adresse auf einen Wert zwischen 0 und 999 und verwendet diese Nummer zum Weiterleiten der Anfrage.

Bei Aufteilung nach IP-Adresse sind einige wesentliche Einschränkungen zu beachten:

  • IP-Adressen von Absendern sind einigermaßen stabil, aber nicht von dauerhafter Natur. Bei Nutzern, die von einem Mobiltelefon aus eine Verbindung herstellen, ändert sich die IP-Adresse möglicherweise während einer einzigen Sitzung. Auch ein Laptop-Nutzer, der mal zu Hause, mal im Café und mal in seinem Büro arbeitet, hat wechselnde IP-Adressen. Dies kann dazu führen, dass der Nutzer die Leistung Ihrer Anwendung als schwankend wahrnimmt, wenn sich seine IP-Adresse ändert.
  • Da die IP-Adressen den Versionen unabhängig zugewiesen werden, weicht die resultierende Trafficaufteilung leicht von Ihrer Vorgabe ab. Allerdings kommt die tatsächliche Aufteilung Ihrem Ziel umso näher, je mehr Traffic Ihre Anwendung erhält. Nehmen wir an, Sie möchten 5 % des Traffics an eine alternative Version zustellen. Dabei kann der tatsächliche prozentuale Anteil des Traffics zu dieser Version anfangs 3–7 % betragen, liegt aber früher oder später im Durchschnitt näher an Ihrem Ziel von 5 %.
  • Wenn Sie interne Anfragen zwischen Anwendungen senden müssen, sollten Sie stattdessen die Aufteilung nach Cookies verwenden. Anfragen, die zwischen Anwendungen in der Cloud-Infrastruktur von Google gesendet werden, stammen von nur wenigen verschiedenen IP-Adressen, die wahrscheinlich alle derselben Version zugewiesen sind. Deshalb verhalten sich alle internen Anfragen möglicherweise ähnlich wie Anfragen, die von einer einzigen IP-Adresse gesendet werden. Dies bedeutet, dass diese Anfragen alle an dieselbe Version weitergeleitet werden. Interne Anfragen berücksichtigen deshalb nicht genau die prozentualen Anteile, die Sie für Ihre IP-basierten Trafficaufteilungen festgelegt haben. Wenn Sie beispielsweise eine Version so einstellen, dass sie 1 % des gesamten Traffics an Ihre Anwendung erhält und die Adressen der Cloud-Infrastruktur von Google dieser Version zufällig zugewiesen wurden, kann das tatsächliche Ergebnis 1 % weit überschreiten, da alle internen Anfragen immer an die zugewiesene Version weitergeleitet werden. Anfragen, die von außerhalb der Cloud-Infrastruktur von Google an Ihre Anwendung gesendet werden, funktionieren erwartungsgemäß, da sie in der Regel von breit gestreuten IP-Adressen stammen.

Wenn Sie den Traffic zur Anwendung nach Cookies aufteilen, sucht die Anwendung im HTTP-Anfrageheader nach einem Cookie mit dem Namen GOOGAPPUID, das einen Wert zwischen 0 und 999 enthält:

  • Wenn das Cookie vorhanden ist, wird der Wert zum Weiterleiten der Anfrage verwendet.
  • Wenn kein solches Cookie vorhanden ist, wird die Anfrage nach dem Zufallsprinzip weitergeleitet.

Wenn die Antwort das Cookie GOOGAPPUID nicht enthält, fügt die Anwendung erst das Cookie GOOGAPPUID mit einem zufälligen Wert zwischen 0 und 999 hinzu, bevor die Antwort gesendet wird.

Die Verwendung von Cookies zur Aufteilung des Traffics erleichtert die genaue Zuordnung zwischen Nutzern und Versionen. Die Genauigkeit des Traffic-Routings erhöht sich im Lauf der Zeit und kann sich bis auf 0,1 % an die Zielaufteilung annähern. Bei der Aufteilung nach Cookies sind jedoch folgende Einschränkungen zu beachten:

  • Unabhängig davon, ob Sie eine mobile App schreiben oder einen Desktopclient ausführen, die GOOGAPPUID-Cookies müssen verwaltet werden. Wenn zum Beispiel der Antwortheader Set-Cookie verwendet wird, müssen Sie das Cookie speichern und bei jeder nachfolgenden Anfrage einschließen. Browserbasierte Anwendungen verwalten Cookies bereits automatisch auf diese Weise.

  • Das Aufteilen interner Anfragen ist mit Mehraufwand verbunden. Für alle Nutzeranfragen, die aus der Cloudinfrastruktur von Google gesendet werden, müssen Sie das Cookie des Nutzers bei jeder Anfrage weiterleiten. Beispielsweise müssen Sie das Cookie des Nutzers in Anfragen weiterleiten, die von Ihrer Anwendung an eine andere Anwendung oder an die Anwendung selbst gesendet werden. Beachten Sie, dass das Senden interner Anfragen nicht empfohlen wird, wenn diese Anfragen nicht von einem Nutzer stammen.

Traffic-Aufteilung deaktivieren

Wenn Sie das Aufteilen des Traffics deaktivieren möchten, migrieren Sie ihn vollständig zu einer einzigen Version.