Dieser Leitfaden bietet eine Einführung in die flexible Umgebung für alle, die mit der Standardumgebung vertraut sind. Darin werden die Gemeinsamkeiten und Hauptunterschiede zwischen den beiden Umgebungen erläutert sowie allgemeine Architekturempfehlungen für Anwendungen gegeben, die beide Umgebungen verwenden.
Unter Dienste von der Standardumgebung zur flexiblen Umgebung migrieren finden Sie eine Zuordnung der Dienste der Standardumgebung zu den entsprechenden Diensten in der flexiblen Umgebung.
Gemeinsamkeiten und Hauptunterschiede
Beide Umgebungen stellen die Infrastruktur von App Engine zur Bereitstellung, Unterstützung und Skalierung zur Verfügung. Die Hauptunterschiede bestehen in der Art und Weise, wie die jeweilige Umgebung Anwendungen ausführt, wie Anwendungen auf externe Dienste zugreifen und wie Anwendungen lokal ausgeführt sowie skaliert werden. Unter Umgebung auswählen finden Sie eine ausführliche Zusammenfassung dieser Unterschiede.
Anwendungen ausführen
In der Standardumgebung wird eine Anwendung auf einer einfachen Instanz innerhalb einer Sandbox ausgeführt. Durch diese Sandbox werden die Möglichkeiten der Anwendung eingeschränkt. Zum Beispiel erlaubt die Sandbox nur, dass Ihre Anwendung eine begrenzte Anzahl von binären Bibliotheken verwendet, und verhindert, dass die Anwendung auf das Laufwerk schreibt. In der Standardumgebung bestehen außerdem nur begrenzte CPU- und Arbeitsspeicheroptionen für Ihre Anwendung. Aufgrund dieser Einschränkungen sind die meisten App Engine-Standardanwendungen tendenziell zustandslose Webanwendungen, die schnell auf HTTP-Anfragen antworten.
Im Gegensatz dazu führt die flexible Umgebung eine Anwendung in Docker-Containern auf virtuellen Maschinen (VMs) von Google Compute Engine aus, für die weniger Einschränkungen gelten. Beispielsweise können Sie eine beliebige Programmiersprache verwenden, in ein Laufwerk schreiben, eine beliebige Bibliothek verwenden und sogar mehrere Prozesse ausführen. In der flexiblen Umgebung haben Sie außerdem die Möglichkeit, einen beliebigen Compute Engine-Maschinentyp für Ihre Instanzen auszuwählen, damit Ihre Anwendung auf mehr Arbeitsspeicher und CPU-Ressourcen zugreifen kann.
Auf externe Dienste zugreifen
In der Standardumgebung greift Ihre Anwendung normalerweise über die eingebundenen google.appengine APIs auf Dienste wie Datastore zu. In der flexiblen Umgebung sind diese APIs jedoch nicht mehr verfügbar. Stattdessen können Sie die Google Cloud-Clientbibliotheken verwenden. Diese Clientbibliotheken sind überall einsatzfähig, d. h., Ihre Anwendung wird portabler. Bei Bedarf können Anwendungen, die in der flexiblen Umgebung ausgeführt werden, in der Regel ohne große Änderungen auch in Google Kubernetes Engine oder Compute Engine ausgeführt werden.
Lokale Entwicklung
In der Standardumgebung führen Sie Ihre Anwendung normalerweise lokal mit dem App Engine SDK aus. Das SDK verwaltet die Ausführung Ihrer Anwendung und emuliert die App Engine-Dienste. In der flexiblen Umgebung wird das SDK dagegen nicht mehr zur Ausführung von Anwendungen verwendet. Stattdessen müssen Anwendungen für die flexible Umgebung wie Standardwebanwendungen geschrieben werden, die überall ausgeführt werden können. Wie bereits erwähnt werden Anwendungen in der flexiblen Umgebung einfach in einem Docker-Container ausgeführt. Dies bedeutet, dass Sie für einen lokalen Test die Anwendung direkt ausführen müssen. Rufen Sie einfach python manage.py runserver auf, um beispielsweise eine Python-Anwendung mithilfe von Django auszuführen.
Ein weiterer zentraler Unterschied besteht darin, dass Anwendungen, die lokal in der flexiblen Umgebung ausgeführt werden, tatsächliche Cloud Platform-Dienste wie Datastore nutzen. Verwenden Sie deshalb für den lokalen Test ein separates Projekt und Emulatoren, sofern diese verfügbar sind.
Skalierungsmerkmale
Beide Umgebungen verwenden zwar die Infrastruktur von App Engine zur automatischen Skalierung, die Art der Skalierung ist aber unterschiedlich. In der Standardumgebung kann sehr schnell von null Instanzen auf bis zu Tausende von Instanzen skaliert werden. Dagegen muss in der flexiblen Umgebung mindestens eine Instanz für jede aktive Version ausgeführt werden. Außerdem kann das Hochskalieren als Reaktion auf gesteigerten Traffic länger dauern.
In der Standardumgebung wird ein benutzerdefinierter Algorithmus für die automatische Skalierung verwendet. In der flexiblen Umgebung hingegen wird die Autoscaling-Funktion von Compute Engine verwendet. Beachten Sie, dass die flexible Umgebung nicht alle Optionen der automatischen Skalierung unterstützt, die für Compute Engine verfügbar sind. App Engine berücksichtigt alle Compute Engine-VM-Reservierungen, die Sie bereits in einer Region haben, die Ihrer Konfiguration entspricht. Eine VM-Reservierung erhöht die Wahrscheinlichkeit, dass Sie während eines temporären Ressourcenmangels eine Ressourcenzuweisung erhalten.
Entwickler sollten daher das Verhalten ihrer Anwendungen unter verschiedenen Bedingungen testen. Sie sollten beispielsweise überprüfen, wie die automatische Skalierung reagiert, wenn eine CPU-gebundene Anwendung in Zeitspannen stärkerer Latenz durch Aufrufe von Remotediensten I/O-gebunden wird.
Systemdiagnosen
In der Standardumgebung wird nicht anhand von Systemdiagnosen bestimmt, ob Traffic an eine Instanz gesendet werden soll oder nicht. In der flexiblen Umgebung können Anwendungsentwickler eigene Systemdiagnose-Handler schreiben, mit denen der Load Balancer bestimmt, ob Traffic an eine Instanz gesendet und eine automatische Reparatur ausgeführt werden soll. Entwickler sollten beim Hinzufügen von Logik zu Systemdiagnosen vorsichtig sein. Ruft die Systemdiagnose beispielsweise einen externen Dienst auf, kann ein vorübergehender Ausfall dieses Dienstes bewirken, dass Fehler in allen Instanzen auftreten. Dies kann zu kaskadierenden Ausfällen führen.
Anfragen bei Überlastung löschen
Anwendungen können Anfragen bei Überlastung löschen. Mit dieser Strategie sollen kaskadierende Ausfälle vermieden werden. Diese Funktion ist in der Trafficweiterleitungsebene der Standardumgebung enthalten. Es wird empfohlen, dass Entwickler von Anwendungen mit einer hohen Abfragerate in der flexiblen Umgebung diese Funktion zum Löschen von Traffic bei Überlastung einschließen. Dies können sie durch Begrenzen der Anzahl gleichzeitiger Anfragen erreichen.
Sie können überprüfen, ob Ihre Anwendung für die flexible Umgebung in Bezug auf derartige Fehler nicht anfällig ist. Erstellen Sie dazu eine Version, in der die maximale Anzahl von Instanzen begrenzt wird. Steigern Sie dann kontinuierlich den Traffic, bis die Anfragen gelöscht werden. Sie sollten dafür sorgen, dass Systemdiagnosen Ihrer Anwendung bei Überlastung nicht fehlschlagen.
In Java können Java-Anwendungen, die die Jetty-Laufzeit verwenden, den Filter für die Dienstqualität so konfigurieren, dass Traffic bei Überlastung gelöscht wird. Sie können sowohl die maximale Anzahl von Anfragen festlegen, die von den Anwendungen gleichzeitig bearbeitet werden, als auch die Dauer, für die Anfragen mit dieser Funktion in die Warteschlange gestellt werden.
Instanzgrößen
Instanzen für die flexible Umgebung dürfen höhere CPU- und Speichergrenzen als Instanzen für die Standardumgebung haben. Dadurch können flexible Instanzen Anwendungen ausführen, die mehr Speicher und CPU benötigen. Dadurch werden jedoch u. U. Gleichzeitigkeitsfehler wahrscheinlicher, da die Anzahl der Threads in einer einzigen Instanz zunimmt.
Entwickler können eine SSH-Verbindung zu einer Instanz für eine flexible Umgebung herstellen und einen Thread-Dump abrufen, um diese Art von Problem zu beheben.
Wenn Sie die Java-Laufzeit verwenden, können Sie beispielsweise Folgendes ausführen:
$ ps auwwx | grep java $ sudo kill -3$ sudo docker logs gaeapp
Maximales Zeitlimit für Anfragen
Während sich das Zeitlimit für Anfragen in der Standardumgebung je nach ausgewähltem Skalierungstyp unterscheiden kann, gilt in der flexiblen Umgebung immer ein 60-minütiges Zeitlimit. So vermeiden Sie, dass Anfragen die gesamten 60 Minuten in Anspruch nehmen und möglicherweise alle Threads auf dem Webserver verwenden:
Wenn Sie externe Dienste aufrufen, geben Sie ein Zeitlimit an.
Implementieren Sie einen Servlet-Filter, um Anfragen zu beenden, die eine inakzeptabel lange Zeit in Anspruch nehmen, z. B. 60 Sekunden. Prüfen Sie, ob Ihre Anwendung wieder in einen konsistenten Zustand zurückkehrt, nachdem Ihr Filter eine Anfrage beendet hat.
Threadverwaltung
Vor Java 8 konnten Java-Laufzeiten in der Standardumgebung nur Threads verwenden, die mit dem App Engine-Standardumgebungs-SDK erstellt wurden. Entwickler, die eine Anwendung von einer Java-Standardumgebung der ersten Generation in eine flexible Umgebung portieren, müssen zu nativen Threadbibliotheken wechseln. Anwendungen, die eine sehr große Anzahl von Threads erfordern, lassen sich mit Threadpools möglicherweise effizienter als durch eine explizite Threaderstellung ausführen.
Trafficmigration
Die Standardumgebung bietet eine Trafficmigrations-Funktion, mit der der Datenverkehr schrittweise zu einer neuen Version verschoben wird, um Latenzspitzen zu minimieren. In den Dokumenten zur Trafficmigration wird beschrieben, wie Sie Latenzspitzen beim Verschieben des Traffics zu einer neuen Version vermeiden können.
Ausfälle einzelner Zonen
Anwendungen für die Standardumgebung sind Single-Homed. Das heißt, dass alle Instanzen der Anwendung in einer einzigen Verfügbarkeitszone vorhanden sind. Sollte die betreffende Zone ausfallen, startet die Anwendung neue Instanzen in einer anderen Zone in der gleichen Region und der Load Balancer leitet Traffic zu den neuen Instanzen weiter. Wegen des Ladens der Anfragen kommt es zu einer Latenzspitze. Außerdem wird der Memcache geleert.
Anwendungen für die flexible Umgebung verwenden regional verwaltete Instanzgruppen. Das heißt, dass Instanzen auf mehrere Verfügbarkeitszonen innerhalb einer Region verteilt werden. Bei Ausfall einer einzelnen Zone stellt der Load Balancer die Weiterleitung von Traffic in diese Zone ein. Wenn Sie die automatische Skalierung so eingerichtet haben, dass Ihre Instanzen mit möglichst hoher Priorität ausgeführt werden, tritt eine kurzfristige Überlastung auf, ehe die automatische Skalierung weitere Instanzen erstellt.
Kostenvergleich
Bei einem Kostenvergleich zwischen Arbeitslasten in Standardumgebungen und in flexiblen Umgebungen spielen viele Faktoren eine Rolle. Dazu gehören:
- Pro Mega-Prozessorzyklus bezahlter Preis.
- CPU-Plattformfunktionen, die sich auf die Arbeit auswirken, die pro Mega-Prozessorzyklus ausgeführt werden kann.
- Priorität, mit der Instanzen auf den einzelnen Plattformen ausgeführt werden können
- Kosten für Bereitstellungen, die auf jeder Plattform unterschiedlich und erheblich sein können, wenn Sie für Ihre Anwendung die kontinuierliche Bereitstellung verwenden
- Laufzeit-Overhead
Sie müssen experimentieren, um die Kosten Ihrer Arbeitslast auf den einzelnen Plattformen zu ermitteln. In der flexiblen Umgebung können Sie die Kosteneffizienz Ihrer Anwendung an den Abfragen pro Sekunde pro Kern ablesen, wenn Sie vorher durch Experimentieren herausfinden, ob sich Änderungen auf die Kosten auswirken. Die Standardumgebung bietet keinen solchen Mechanismus, um Echtzeitmesswerte zur Kosteneffizienz Ihrer Anwendung zu erhalten. Sie können lediglich eine Änderung vornehmen und warten, bis der tägliche Abrechnungszeitraum abgeschlossen ist.
Mikrodienste
Die Standardumgebung ermöglicht mithilfe des Anfrageheaders X-Appengine-Inbound-Appid eine sichere Authentifizierung zwischen Anwendungen. Die flexible Umgebung bietet kein solches Feature. Daher wird empfohlen, für die sichere Authentifizierung zwischen Anwendungen OAuth zu verwenden.
Bereitstellung
In der Standardumgebung ist im Allgemeinen eine schnellere Bereitstellung möglich als in der flexiblen Umgebung. In der flexiblen Umgebung ist das Hochskalieren einer vorhandenen Version schneller möglich als das Bereitstellen einer neuen Version. Dies liegt daran, dass die Netzwerkprogrammierung für eine neue Version bei einer Implementierung in der flexiblen Umgebung normalerweise am längsten dauert. Eine Strategie für schnelle Rollbacks in der flexiblen Umgebung besteht darin, eine stabile Version aufzubewahren, die auf nur eine Instanz herunterskaliert wurde. Sie können diese Version dann hochskalieren und den gesamten Traffic mithilfe von Traffic-Aufteilung dorthin weiterleiten.
Wann die flexible Umgebung zu empfehlen ist
Die flexible Umgebung soll die Standardumgebung ergänzen. Wenn eine vorhandene Anwendung in der Standardumgebung ausgeführt wird, ist es in der Regel nicht erforderlich, die gesamte Anwendung in die flexible Umgebung zu migrieren. Ermitteln Sie stattdessen die Teile Ihrer Anwendung, die mehr CPU, mehr Arbeitsspeicher, eine spezielle Bibliothek oder ein Programm eines Drittanbieters benötigen oder die Aktionen ausführen müssen, die in der Standardumgebung nicht möglich sind. Für solche Teile erstellen Sie dann kleinere App Engine-Dienste, die die flexible Umgebung nur zur Verarbeitung dieser Teile verwenden. Ihr vorhandener Dienst, der in der Standardumgebung ausgeführt wird, kann die anderen Dienste über HTTP, Cloud Tasks oder Cloud Pub/Sub aufrufen.
Wenn beispielsweise eine vorhandene Webanwendung in der Standardumgebung ausgeführt wird und Sie ein neues Feature zum Konvertieren von Dateien in PDFs hinzufügen möchten, können Sie einen separaten Mikrodienst schreiben, der in der flexiblen Umgebung ausgeführt wird und nur die Konvertierung in PDFs übernimmt. Dieser Mikrodienst kann ein einfaches Programm sein, das nur aus einem oder zwei Anfrage-Handlern besteht. Mit diesem Mikrodienst lässt sich jedes verfügbare Linux-Programm installieren und verwenden, das die Konvertierung unterstützt (z. B. unoconv).
Ihre Hauptanwendung verbleibt in der Standardumgebung und kann diesen Mikrodienst direkt über HTTP aufrufen. Wenn die Konvertierung voraussichtlich länger dauert, kann die Anwendung die Anfragen über Cloud Tasks oder Pub/Sub in die Warteschlange stellen.
Nächste Schritte
Dienste von der Standardumgebung zur flexiblen Umgebung migrieren