Instanzverwaltung

Instanzen sind die Grundbausteine von App Engine. Sie stellen alle Ressourcen bereit, die für ein erfolgreiches Hosting Ihrer Anwendung erforderlich sind. Dazu gehören die Sprachlaufzeit, die App Engine APIs sowie der Code und Arbeitsspeicher Ihrer Anwendung. Jede Instanz beinhaltet eine Sicherheitsebene, die dafür sorgt, dass die Instanzen sich nicht versehentlich gegenseitig beeinträchtigen.

Instanzen sind die Recheneinheiten, mit denen App Engine eine Anwendung automatisch skaliert. Die Ausführung der Anwendung kann zu jeder Zeit auf einer oder mehreren Instanzen erfolgen. Im letzteren Fall werden Anfragen auf alle Instanzen verteilt.

Einführung in Instanzen

Instanzen sind entweder resident oder dynamisch. Eine dynamische Instanz wird je nach den aktuellen Anforderungen automatisch gestartet und heruntergefahren. Eine residente Instanz wird ständig ausgeführt, wodurch sich die Leistung Ihrer Anwendung verbessern kann. Sowohl dynamische als auch residente Instanzen instanziieren den in einer App Engine-Dienstversion enthaltenen Code.

Wenn Sie die manuelle Skalierung für eine Anwendung verwenden, erfolgt deren Ausführung auf residenten Instanzen. Bei Verwendung entweder der einfachen oder der automatischen Skalierung wird die Anwendung auf dynamischen Instanzen ausgeführt.

Bei der Konfiguration Ihrer Anwendung müssen Sie unter anderem festlegen, wie deren Dienste skaliert werden sollen. Dazu gehören:

  • die anfängliche Anzahl von Instanzen für einen Dienst
  • die Einstellung, wie neue Instanzen in Reaktion auf Traffic erstellt oder gestoppt werden sollen
  • das Zeitkontingent, das einer Instanz zur Verarbeitung einer Anfrage zur Verfügung steht

Der einem Dienst zugewiesene Skalierungstyp bestimmt, ob die Instanzen des Dienstes resident oder dynamisch sind:

  • Automatische Skalierungsdienste verwenden dynamische Instanzen.
  • Manuelle Skalierungsdienste verwenden residente Instanzen.
  • Einfache Skalierungsdienste verwenden dynamische Instanzen.

App Engine rechnen die Nutzung von Instanzen auf Stundenbasis ab. Die Instanznutzung lässt sich in der Google Cloud Platform Console auf der Seite "Instanzen" verfolgen. Wenn Sie eine Obergrenze für die Instanzkosten festlegen möchten, können Sie ein Ausgabenlimit setzen. Jeder in App Engine erstellte Dienst verhält sich wie ein Mikrodienst, der entsprechend seiner Konfiguration separat skaliert wird.

Dynamische Instanzen skalieren

App Engine-Anwendungen können je nach Umfang der eingehenden Anfragen von einer beliebigen Anzahl dynamischer Instanzen ausgeführt werden. Mit steigender Anzahl der Anfragen steigt auch die Zahl der dynamischen Instanzen.

Der App Engine-Planer legt fest, wie die einzelnen neuen Anfragen verarbeitet werden: von einer vorhandenen Instanz, die entweder inaktiv ist oder gleichzeitige Anfragen annimmt, durch Einfügen der Anfrage in eine Warteschlange für ausstehende Anfragen oder durch Starten einer neuen Instanz für die Anfrage. Dabei wird berücksichtigt, wie viele Instanzen verfügbar sind, wie schnell die Anwendung Anfragen bisher verarbeitet hat (also ihre Latenz) und wie lange es dauert, eine neue Instanz zu starten.

Mit der automatischen Skalierung können Sie das Verhalten des Planers optimieren, um das gewünschte Preis-Leistungs-Verhältnis zu erzielen. Dafür legen Sie entsprechende Werte für target_cpu_utilization, target_throughput_utilization und max_concurrent_requests fest.

Parameter für automatische Skalierung Beschreibung
CPU-Zielauslastung Legt den Schwellenwert für die CPU-Auslastung fest. Wenn die CPU-Nutzung diesen Schwellenwert überschreitet, werden mehr Instanzen zur Verarbeitung des Traffics gestartet.
Zieldurchsatz – Auslastung Legt den Durchsatz-Schwellenwert für die Anzahl von gleichzeitigen Anfragen fest, ab dem mehr Instanzen zur Verarbeitung des Traffics gestartet werden.
Maximale Anzahl gleichzeitiger Abfragen Legt die maximale Anzahl gleichzeitiger Anfragen fest, die eine Instanz annehmen kann, bevor der Planer eine neue Instanz erzeugt.

Im Video zu den neuen Planereinstellungen von App Engine sehen Sie die Auswirkungen dieser Einstellungen.

Jede Instanz hat eine eigene Warteschlange für eingehende Anfragen. App Engine überwacht die Anzahl der Anfragen, die sich in der Warteschlange der jeweiligen Instanz befinden. Wenn App Engine feststellt, dass die Warteschlangen für eine Anwendung aufgrund eines Lastanstiegs zu lang werden, wird zur Bewältigung der Last automatisch eine neue Instanz der Anwendung erstellt.

Die Skalierung erfolgt in App Engine sehr schnell. Wenn Sie Anfragen in Batches an Ihre Dienste senden, beispielsweise zur Verarbeitung an eine Aufgabenwarteschlange, wird in kurzer Zeit eine große Anzahl von Instanzen erstellt. Zur Steuerung dieses Vorgangs sollten Sie die Rate der pro Sekunde gesendeten Anfragen möglichst begrenzen. Bei einer App Engine-Aufgabenwarteschlange können Sie beispielsweise die Rate steuern, mit der Aufgaben per Push übertragen werden.

App Engine skaliert Instanzen auch in umgekehrter Richtung, wenn das Anfragevolumen abnimmt. Die Skalierung gewährleistet, dass alle laufenden Instanzen einer Anwendung so effizient und kosteneffektiv wie möglich genutzt werden.

Wenn eine Anwendung überhaupt nicht verwendet wird, deaktiviert App Engine die zugehörigen dynamischen Instanzen, lädt sie jedoch sofort wieder, sobald sie benötigt werden. Durch das wiederholte Laden der Instanzen können auch Anfragen geladen und kann die Latenz für Nutzer erhöht werden.

Sie können eine Mindestanzahl von inaktiven Instanzen festlegen. Wenn Sie anhand des Anfrageaufkommens eine geeignete Anzahl von inaktiven Instanzen für Ihre Anwendung festlegen, können die einzelnen Anfragen mit niedriger Latenz ausgeführt werden, die nur bei einer ungewöhnlich hohen Anzahl von Anfragen zunimmt.

Instanzskalierung

Beim Hochladen der Version eines Dienstes werden über die Datei app.yaml ein Skalierungstyp und eine Instanzklasse festgelegt, die für alle Instanzen dieser Version gelten. Der Skalierungstyp steuert die Erstellung von Instanzen. Die Instanzklasse bestimmt die Rechenressourcen (Speichergröße und CPU-Geschwindigkeit) sowie den Preis. Es gibt drei Skalierungstypen: manuell, einfach und automatisch. Die verfügbaren Instanzklassen hängen vom Skalierungstyp ab.

Manuelle Skalierung
Ein Dienst mit manueller Skalierung verwendet residente Instanzen. Hierbei wird die angegebene Anzahl von Instanzen unabhängig von der Arbeitslast kontinuierlich ausgeführt. Dadurch sind Aufgaben wie komplexe Initialisierungen und Anwendungen möglich, die vom Zustand des Arbeitsspeichers im Zeitablauf abhängen.
Automatische Skalierung
Automatische Skalierungsdienste verwenden dynamische Instanzen, die auf Basis von Anfrageraten, Antwortlatenzen und anderen Anwendungsmesswerten erstellt werden. Wenn Sie jedoch eine Mindestzahl von inaktiven Instanzen angeben, wird diese angegebene Anzahl von Instanzen als residente Instanzen ausgeführt, während alle weiteren Instanzen dynamisch sind.
Einfache Skalierung
Ein Dienst mit einfacher Skalierung verwendet dynamische Instanzen. Einzelne Instanzen werden erstellt, wenn die Anwendung eine Anfrage empfängt. Die Instanz wird heruntergefahren, wenn die Anwendung inaktiv wird. Die einfache Skalierung ist ideal für sporadische Arbeitslasten oder Lasten, die auf der Nutzeraktivität basieren.

Die folgende Tabelle vergleicht die Leistungsmerkmale der drei Skalierungstypen:

Merkmal Automatische Skalierung Manuelle Skalierung Einfache Skalierung
Zeitlimits Limit von 60 Sekunden für HTTP-Anfragen und von 10 Minuten für Warteschlangenaufgaben. Anfragen können bis zu 24 Stunden dauern. Eine manuell skalierte Instanz kann /_ah/start über viele Stunden hinweg zur Ausführung eines Programms oder Skripts verwenden, ohne einen HTTP-Antwortcode zurückzugeben. Warteschlangen-Aufgaben können bis zu 24 Stunden lang laufen. Entspricht der manuellen Skalierung.
Hintergrundthreads Nicht zulässig Zulässig Zulässig
Residenz Instanzen werden entsprechend ihren Nutzungsmustern aus dem Speicher entfernt. Instanzen bleiben im Speicher und der Status bleibt für alle Anfragen erhalten. Werden Instanzen neu gestartet, wird eine /_ah/stop-Anfrage in den Logs dokumentiert. Gibt es einen registrierten Shutdown-Hook, verbleiben 30 Sekunden für die Ausführung vor dem Herunterfahren. Instanzen werden entsprechend dem Parameter idle_timeout entfernt. Ist eine Instanz länger als idle_timeout inaktiv, etwa weil keine Anfrage eingegangen ist, wird die Instanz entfernt.
Starten und Herunterfahren Instanzen werden zur Verarbeitung von Anfragen nach Bedarf erstellt. Bei Inaktivität werden sie automatisch heruntergefahren. Instanzen wird automatisch eine Startanfrage von App Engine in Form einer leeren GET-Anfrage an /_ah/start gesendet. Wenn Sie eine Instanz manuell beenden, können auf dieser noch 30 Sekunden lang Anfragen verarbeitet werden, bevor die Instanz automatisch beendet wird. Instanzen werden zur Verarbeitung von Anfragen nach Bedarf erstellt. Bei Inaktivität werden sie automatisch auf Basis des Konfigurationsparameters idle_timeout heruntergefahren. Wie bei der manuellen Skalierung kann eine Instanz, die manuell beendet wird, 30 Sekunden lang noch Anfragen verarbeiten, bevor sie zwangsweise beendet wird.
Instanzadressierung Instanzen sind anonym. Die Instanz "i" der Version "v" des Dienstes "s" kann über die URL http://i.v.s.app_id.appspot.com adressiert werden. Wurde für eine benutzerdefinierte Domain eine Platzhalterzuordnung für Subdomains eingerichtet, kann ein Dienst oder eine seiner Instanzen auch über eine URL im Format http://s.domain.com oder http://i.s.domain.com adressiert werden. Der Status jeder Instanz lässt sich zuverlässig im Cache speichern und in nachfolgenden Anfragen abrufen. Entspricht der manuellen Skalierung.
Skalierung App Engine skaliert die Anzahl der Instanzen automatisch in Abhängigkeit vom Verarbeitungsvolumen skaliert. Diese Skalierung berücksichtigt die Einstellungen für automatic_scaling, die pro Version in der Konfigurationsdatei bereitgestellt werden. Die Anzahl der Instanzen für jede Version wird in der entsprechenden Konfigurationsdatei des Dienstes festgelegt. Die Anzahl der Instanzen entspricht in der Regel der Größe eines im Speicher verbliebenen Datasets oder dem gewünschten Durchsatz für Offline-Arbeiten. Sie können die Anzahl der Instanzen einer manuell skalierten Version sehr schnell anpassen, ohne aktuell ausgeführte Instanzen beenden zu müssen. Dazu verwenden Sie die Funktion set_num_instances der Modules API. Ein Dienst mit einfacher Skalierung wird konfiguriert, indem die maximale Anzahl von Instanzen für den Parameter max_instances innerhalb der Einstellung für basic_scaling festgelegt wird. Die Anzahl der aktiven Instanzen skaliert mit dem Verarbeitungsvolumen.
Kostenloses tägliches Nutzungskontingent 28 Instanzstunden 8 Instanzstunden 8 Instanzstunden

Lebenszyklus von Instanzen

Instanzstatus

Die Instanz eines automatisch skalierten Dienstes wird immer ausgeführt. Die Instanz eines manuell oder einfach skalierten Dienstes dagegen kann auch gestoppt werden. Alle Instanzen eines Dienstes und einer Version haben denselben Status. Sie können den Status der Instanzen durch Verwaltung der Versionen ändern. Sie haben folgende Möglichkeiten:

Starten

Jede Dienstinstanz wird als Reaktion auf eine Startanfrage erstellt, wobei es sich um eine leere HTTP-GET-Anfrage an /_ah/start handelt. App Engine sendet diese Anfrage, um eine Instanz zu erstellen. Nutzer können keine Anfrage an /_ah/start senden. Manuelle und einfache Skalierungsinstanzen müssen erst auf die Startanfrage antworten, bevor sie eine weitere Anfrage verarbeiten können. Die Startanfrage kann für zwei Zwecke verwendet werden:

  • Zum Starten eines für unbestimmte Zeit ausgeführten Programms, ohne weitere Anfragen zu akzeptieren
  • Zum Initialisieren einer Instanz, bevor weiterer Traffic eingeht

Manuelle, einfache und automatische Skalierungsinstanzen werden unterschiedlich gestartet. Wenn Sie eine manuelle Skalierungsinstanz starten, sendet App Engine sofort die Anfrage /_ah/start an jede Instanz. Wenn Sie die Instanz eines einfachen Skalierungsdienstes starten, lässt App Engine Traffic zur Instanz zu. Die Anfrage /_ah/start wird aber erst dann an die Instanz gesendet, wenn diese ihre erste Nutzeranfrage empfängt. Mehrere einfache Skalierungsinstanzen werden nur bei Bedarf gestartet, um zusätzlichen Traffic zu verarbeiten.ss Instanzen mit automatischer Skalierung erhalten keine Anfrage /_ah/start.

Wenn eine Instanz auf die Anfrage /_ah/start mit dem HTTP-Statuscode 200–299 oder 404 antwortet, wird davon ausgegangen, dass sie erfolgreich gestartet wurde und zusätzliche Anfragen verarbeiten kann. Andernfalls beendet App Engine die Instanz. Manuelle Skalierungsinstanzen werden sofort neu gestartet, während einfache Skalierungsinstanzen nur dann neu gestartet werden, wenn sie zum Verarbeiten von Traffic benötigt werden.

Herunterfahren

Das Herunterfahren kann durch viele geplante und ungeplante Ereignisse wie die folgenden ausgelöst werden:

  • Sie beenden eine Instanz manuell.
  • Sie stellen eine aktualisierte Version des Dienstes bereit.
  • Die Instanz überschreitet den maximalen Arbeitsspeicher für die konfigurierte instance_class.
  • Ihre Anwendung hat das Stundenkontingent der Instanz verbraucht.
  • Ihre Instanz wird auf eine andere Maschine verschoben, entweder weil die aktuelle Maschine, auf der die Instanz ausgeführt wird, neu gestartet wird oder weil App Engine die Instanz zur Verbesserung der Lastverteilung verschoben hat.
Eine App hat zwei Möglichkeiten, um festzustellen, ob eine manuelle Skalierungsinstanz demnächst heruntergefahren wird. Mit der Methode is_shutting_down() von google.appengine.api.runtime wird true zurückgegeben. Sie können aber auch einen Shutdown-Hook registrieren. Dies ist die bevorzugte Methode und wird unten beschrieben.

Wenn App Engine eine Instanz herunterfährt, bleiben 30 Sekunden zum Abschließen vorhandener Anfragen. Bei neuen Anfragen wird sofort der Fehler 404 zurückgegeben. Verarbeitet eine Instanz gerade eine Anfrage, pausiert App Engine diese und führt den Shutdown-Hook aus. Wenn keine aktive Anfrage vorhanden ist, sendet App Engine die Anfrage /_ah/stop, um den Shutdown-Hook auszuführen. Die Anfrage /_ah/stop umgeht die normale Verarbeitungslogik und kann nicht von Nutzercode verarbeitet werden. Sie dient einzig dazu, den Shutdown-Hook aufzurufen. Wenn in Ihrem Shutdown-Hook bei Verarbeitung einer anderen Anfrage eine Ausnahme ausgelöst wird, taucht sie in der Anfrage auf, wo Sie sie abfangen können.

Wenn Sie durch Angabe von threadsafe: true in app.yaml (Standardeinstellung) gleichzeitige Anfragen aktiviert haben und ein Shutdown-Hook eine Ausnahme auslöst, wird diese Ausnahme in alle Threads kopiert. Der folgende Beispielcode veranschaulicht einen einfachen Shutdown-Hook:

from google.appengine.api import apiproxy_stub_map
from google.appengine.api import runtime

def my_shutdown_hook():
  apiproxy_stub_map.apiproxy.CancelApiCalls()
  save_state()
  # May want to raise an exception

runtime.set_shutdown_hook(my_shutdown_hook)

Alternativ ist im folgenden Beispielcode die Verwendung der Methode is_shutting_down() dargestellt:

while more_work_to_do and not runtime.is_shutting_down():
  do_some_work()
  save_state()

Ladeanfragen

Wenn App Engine eine neue Instanz für die Anwendung erstellt, muss die Instanz zuerst alle für die Verarbeitung der Anfrage erforderlichen Bibliotheken und Ressourcen laden. Dies geschieht während der ersten Anfrage an die Instanz, die als Ladeanfrage bezeichnet wird. Da die Anwendung während einer Ladeanfrage initialisiert wird, dauert die Anfrage länger.

Hier ein paar Tipps, um die Dauer von Ladeanfragen zu verkürzen:

  • Laden Sie nur den für den Start benötigten Code.
  • Greifen Sie so wenig wie möglich auf das Laufwerk zu.
  • Oft kann Code schneller aus einer ZIP- oder JAR-Datei als aus vielen einzelnen Dateien geladen werden.

Aufwärmanfragen

Aufwärmanfragen sind ein spezieller Typ von Ladeanfragen. Sie laden Anwendungscode in eine Instanz, bevor Liveanfragen durchgeführt werden. Manuelle oder einfache Skalierungsinstanzen erhalten keine /_ah/warmup-Anfrage.

Weitere Informationen zum Verwenden von Aufwärmanfragen finden Sie unter Aufwärmanfragen konfigurieren.

Instanzlaufzeit

App Engine versucht, Instanzen mit manueller und einfacher Skalierung auf unbegrenzte Zeit auszuführen. Derzeit kann die Betriebszeit von Instanzen mit manueller und einfacher Skalierung jedoch nicht garantiert werden. Hardware- und Softwarefehler, die zur vorzeitigen Beendigung oder zu wiederholten Neustarts führen, können ohne Vorwarnung auftreten und oft nur mit erheblichem Zeitaufwand behoben werden. Daher sollten Sie Ihre Anwendung so konfigurieren, dass diese Fehler toleriert werden.

Hier sind einige Vorgehensweisen, um Ausfallzeiten durch Instanzneustarts zu vermeiden:

  • Beschleunigen Sie den Neustart vorhandener Instanzen bzw. den Start neuer Instanzen.
  • Erstellen Sie bei lang laufenden Berechnungen regelmäßig Prüfpunkte, damit Sie den Vorgang beim jeweiligen Status fortsetzen können.
  • Ihre Anwendung sollte "zustandslos" sein. Es darf also nichts auf der Instanz gespeichert werden.
  • Führen Sie Aufgaben mithilfe von Warteschlangen asynchron aus.
  • Wenn Sie Ihre Instanzen für manuelle Skalierung konfigurieren:
    • Verwenden Sie ein Load-Balancing-Modul für mehrere Instanzen.
    • Konfigurieren Sie mehr Instanzen, als für die Verarbeitung des normalen Traffics erforderlich sind.
    • Schreiben Sie eine Fallback-Logik, die im Cache gespeicherte Ergebnisse verwendet, wenn eine manuelle Skalierungsinstanz nicht verfügbar ist.

Abrechnung von Instanzen

Im Allgemeinen wird die Betriebszeit von Instanzen minutengenau zuzüglich einer 15-minütigen Startgebühr abgerechnet (Einzelheiten finden Sie unter Preise). Es werden nur inaktive Instanzen bis zur maximalen Anzahl inaktiver Instanzen abgerechnet, die Sie für jeden Dienst festgelegt haben. Der Laufzeit-Overhead wird auf den Instanzarbeitsspeicher angerechnet. Bei Java-Anwendungen ist der Wert höher als bei Python.

Die Abrechnung unterscheidet sich bei residenten und dynamischen Instanzen geringfügig:

  • Bei residenten Instanzen endet die Abrechnung 15 Minuten nach dem Herunterfahren der Instanz.
  • Bei dynamischen Instanzen endet die Abrechnung 15 Minuten, nachdem die letzte Anfrage verarbeitet wurde.
Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

App Engine-Standardumgebung für Python 2