Cloud Tasks verstehen

Auf dieser Seite werden Cloud Tasks-Aufgaben und -Warteschlangen sowie deren Verwendung beschrieben. Mit Cloud Tasks können Sie Aufgaben, die unabhängig vom Hauptanwendungsablauf ausgeführt werden können, trennen und asynchron mit von Ihnen erstellten Handlern zur Verarbeitung senden. Diese unabhängigen Aufgaben werden als Aufgaben bezeichnet. Beispielsweise müssen Sie eine Datenbank im Rahmen der Verarbeitung einer Nutzeranfrage aktualisieren, aber Aktualisierungen können zeitaufwendig sein. Wenn Sie dieses Detail als Aufgabe auslagern, können Sie schneller von der Anfrage zurückkehren.

Hinweis:Der Cloud Tasks-Dienst ist auf asynchrone Aufgaben ausgelegt. Sie bietet keine starken Garantien für den Zeitpunkt der Aufgabenübermittlung und ist daher nicht für interaktive Anwendungen geeignet, bei denen ein Nutzer auf das Ergebnis wartet.

Die ausgelagerte Aufgabe wird einer Warteschlange hinzugefügt, die die Aufgabe so lange beibehält, bis sie erfolgreich ausgeführt wurde. Basierend auf Ihrer ursprünglichen Konfiguration kann die Warteschlange auch als Weiterleitungsflusssteuerung dienen. Sie erstellen und konfigurieren die Warteschlange, die dann vom Cloud Tasks-Dienst verwaltet wird. Sobald Aufgaben hinzugefügt wurden, werden sie von der Warteschlange weitergeleitet und von den Mitarbeitern zuverlässig verarbeitet. Die mit diesem Prozess verbundenen Kosten, wie z. B. Kosten für die Latenz des Nutzers, Serverabstürze, Beschränkungen des Ressourcenverbrauchs und die Verwaltung von Wiederholungen, werden vom Dienst verarbeitet.

Cloud Tasks bietet eine "mindestens einmalige" Zustellung. Wenn eine Aufgabe erfolgreich hinzugefügt wurde, wird sie von der Warteschlange mindestens einmal ausgeführt. In einigen seltenen Fällen ist eine mehrmalige Ausführung von Aufgaben möglich. Daher muss im Code sichergestellt sein, dass bei wiederholter Ausführung keine schädlichen Nebenwirkungen auftreten. Ihre Handler sollten idempotent sein.

Die Aufgaben selbst bestehen aus einem eindeutigen Namen und Konfigurationsinformationen sowie optional aus Daten aus der ursprünglichen Anfrage, der Nutzlast, die zur Verarbeitung der Anfrage erforderlich ist. Da die Nutzlast im Anfragetext gesendet wird, müssen Aufgaben, die Nutzlasten enthalten, POST oder PUT als HTTP-Methode verwenden.

Für den Zugriff auf den Cloud Tasks-Dienst über die Cloud Tasks API benötigen Sie ein Google Cloud-Projekt.

Anwendungsfälle

Zu den typischen Anwendungsfällen gehören:

• Beschleunigung von Nutzerreaktionszeiten durch Delegieren potenziell langsamer Hintergrundvorgänge wie Datenbankaktualisierungen an einen Worker
• Beibehaltung von Anfragen bei unerwarteten Vorfällen im laufenden Betrieb
• Ausgleich von Trafficspitzen durch Entfernen nicht nutzerbezogener Aufgaben aus der Hauptaufrufabfolge von Webseiten
• API-Aufrufraten von Drittanbietern verwalten

Cloud Tasks-Warteschlangen mit HTTP-Zielen

Bei generischen HTTP-Zielen leitet der Cloud Tasks-Dienst die Aufgabenanfrage je nach Konfiguration der Aufgabe an den Worker an einem beliebigen generischen HTTP-Endpunkt weiter. Dieser Endpunkt kann sich je nach Konfiguration der Aufgabe auf Cloud Functions, Cloud Run, GKE, Compute Engine oder sogar auf einem lokalen Webserver befinden. Diese Warteschlangen leiten Anfragen mit einer zuverlässigen, konfigurierbaren Rate weiter. Sie garantieren eine zuverlässige Aufgabenausführung: Bei Erfolg müssen alle Worker einen HTTP-Antwortcode (200-299) an den Cloud Tasks-Dienst senden, vor dem Standardzeitlimit von 10 Minuten und maximal 30 Minuten. Wird eine andere Antwort oder keine Antwort gesendet, wird die Aufgabe wiederholt.

Das Ziel muss das Skalieren von Workern und das Bereinigen von Aufgaben verwalten, sobald diese abgeschlossen sind.

Wenn für Ihr Ziel eine Authentifizierung erforderlich ist, müssen Sie zwei Dienstkonten einrichten, eines für Ihre Anwendung, den Client, und eines für die Warteschlange selbst. Beide Konten müssen die erforderlichen Berechtigungen haben. Außerdem muss eine Kennzeichnung für das Client-Dienstkonto in der Aufgabenanfrage enthalten sein. Weitere Informationen finden Sie unter HTTP Target-Aufgaben erstellen.

Cloud Tasks-Warteschlangen mit App Engine-Zielen

Cloud Tasks ist mit den folgenden App Engine-Umgebungen kompatibel:

• Laufzeiten der App Engine-Standardumgebung der zweiten Generation
• Flexible App Engine-Umgebung

Nutzer von App Engine-Laufzeiten der ersten Generation, die derzeit die Task Queue API verwenden, können zu Cloud Tasks migrieren. Weitere Informationen finden Sie unter Gebündelte Legacy-Dienste migrieren. Nutzer von App Engine-Laufzeiten der ersten Generation, die nicht den gebündelten Aufgabendienst verwenden, können auf Laufzeiten der zweiten Generation upgraden, um Cloud Tasks verwenden zu können.

Bei App Engine-Zielen leitet der Cloud Tasks-Dienst die Aufgabenanfrage auch an den Handler weiter. Dieser Worker befindet sich jedoch in App Engine. Daher müssen alle Warteschlangen, die auf App Engine-Handler ausgerichtet sind, eine App Engine-Anwendung haben. Die Handler müssen in der Region ausgeführt werden, in der die App Engine-Anwendung ausgeführt wird. Diese Region dient auch als Parameter LOCATION_ID für Ihre Cloud Tasks-Anfragen.

Die Aufgaben werden entsprechend der Konfiguration der Aufgabe (oder seltener der Warteschlange selbst) weitergeleitet. Die Warteschlangen leiten Anfragen mit einer zuverlässigen, konfigurierbaren Rate weiter. Sie garantieren eine zuverlässige Aufgabenausführung. Im Anschluss müssen alle Worker einen HTTP-Antwortcode (200–299) an den Cloud Tasks-Dienst senden, in dieser Instanz vor einer Frist, die auf dem Typ der Instanzskalierung basiert: 10 Minuten bei automatischer Skalierung oder bis zu 24 Stunden bei manueller Skalierung. Wird eine andere Antwort oder keine Antwort gesendet, wird die Aufgabe wiederholt.

Da die Handler Teil der App Engine sind, kann der Cloud Tasks-Dienst selbst einen Großteil der Prozessverwaltung für die Aufgabe übernehmen. Er kann die Worker je nach Traffic hoch- und herunterskalieren und nach Abschluss Aufgaben löschen.

Hinweis: In Cloud Tasks-Befehlen werden zwei App Engine-Standorte europe-west und us-central in App Engine-Befehlen als europe-west1 bzw. us-central1 bezeichnet.

Unterstützte Regionen nach Ziel

Wenn Ihr Ziel ein HTTP/S-Endpunkt ist, ist Cloud Tasks in allen unterstützten Google Cloud-Regionen für Cloud Tasks verfügbar.

Wenn das Ziel eine App Engine-Anwendung im aktuellen Projekt ist:

• Eine auf App Engine ausgerichtete Aufgabe kann nur in der App Engine-Region des Projekts erstellt werden.

• Ein Google Cloud-Projekt kann nur eine App Engine-Anwendung enthalten. Die Region, in der sich die App Engine-Anwendung befindet, kann nach dem Erstellen der Anwendung nicht mehr geändert werden.

• App Engine ist regional. Das bedeutet, dass sich die Infrastruktur, in der die Anwendung ausgeführt wird, in einer bestimmten Region befindet. Wenn Sie Rechenvorgänge und Warteschlangen auf mehrere Regionen verteilen möchten, sollten Sie stattdessen einen HTTP/S-Endpunkt als Ziel verwenden.

• Wenn Sie App Engine nicht als Ziel verwenden, müssen Sie keine App Engine-Anwendung bereitstellen. Außerdem können Sie vorhandene App Engine-Anwendungen deaktivieren.

Workflows

Dies ist der allgemeine Workflow:

1. Sie erstellen einen Worker, um die Aufgaben zu bearbeiten.
2. Sie erstellen eine Warteschlange.
3. Sie erstellen programmgesteuert Aufgaben und fügen sie zur Warteschlange hinzu.
4. Der Cloud Tasks-Dienst gibt eine Bestätigung an die ursprüngliche Anwendung zurück. Diese signalisiert, dass die Aufgabe erfolgreich in den Cloud Task-Speicher geschrieben wurde. Damit ist die Anfrage zur Aufgabenerstellung hochverfügbar und langlebig.
5. Die Aufgabe wird an den Worker übergeben.
6. Der Worker verarbeitet die Aufgabe.
7. Zum Abschließen der Sequenz gibt der Worker den Erfolgsstatuscode 2xx an den Cloud Tasks-Dienst zurück.

Sobald die Aufgabe an die Warteschlange übergeben wurde, werden der ursprünglichen Anfrage keine Daten mehr zur Verfügung gestellt.

Hinweis: Die Cloud Tasks API bietet eine Schnittstelle zum App Engine-Dienst für die Aufgabenwarteschlange. Diese Schnittstelle funktioniert unabhängig von App Engine. Warteschlangen, auf die mit dem App Engine SDK zugegriffen werden kann, sind auch über die Cloud Tasks API zugänglich und umgekehrt.

Features

Mit Cloud Tasks können Sie asynchrone Arbeitsaufgaben mit den folgenden Steuerelementen weiterleiten:

• Bestimmte Lieferzeiten planen
• Zustellungsraten verwalten
• Wiederholungsprozess konfigurieren
• Auf einzelne Aufgaben in einer Warteschlange zugreifen und verwalten
• Deduplizierung von Aufgaben aktivieren

Nutzungsbedingungen

Die folgende Tabelle enthält wichtige Begriffe zur Beschreibung bestimmter Aspekte von Cloud Tasks.

Begriff	Definition
Warteschlange	Eine Reihe von Aufgaben mit demselben Zieltyp, die von einer einzelnen Konfiguration verwaltet werden.
Zieltyp	Festlegung, wo und wie eine Aufgabe verarbeitet wird.
Worker	Ein Dienst, der Aufgaben verarbeitet.
Versuch	Ein Versuch, eine Aufgabe auszuführen.
Weiterleitung	Der Zeitpunkt, an dem eine Aufgabe von Cloud Tasks an ihr Ziel gesendet wurde.
Antwort	Eine Antwort von einem Worker, die angibt, ob die mit der Aufgabe verknüpfte Arbeit erfolgreich abgeschlossen wurde oder fehlgeschlagen ist.
Wiederholen	Mehrere Versuche, eine Aufgabe auszuführen. Die Anzahl der Wiederholungen wird RetryConfig festgelegt.
Ratenbegrenzungen	Die Ratenbegrenzungen für eine Warteschlange.

Messwerte

Die folgenden vordefinierten Google Tasks-Messwerte sind in Cloud Monitoring verfügbar.

Metriktyp Anzeigename Art, Typ, Einheit	Beschreibung Labels
api/request_count API-Anfragen DELTA, INT64, 1	Anzahl der Cloud Tasks API-Aufrufe api_method: Die aufgerufene API-Methode (z. B. CreateTask). response_code: Kanonischer Antwortcode als String (z. B. "ok").
queue/depth BETA-Warteschlangentiefe GAUGE, INT64, 1	Anzahl der Aufgaben in der Warteschlange Die Stichprobenerhebung erfolgt alle 60 Sekunden. Nach der Stichprobenerhebung werden bis zu 120 Sekunden keine Daten angezeigt.
queue/task_attempt_count Anzahl der Aufgabenversuche DELTA, INT64, 1	Anzahl der Aufgaben, die von der Warteschlange weitergeleitet werden sollen, aufgeschlüsselt nach Aufgabenantwortcode. response_code: Kanonischer Antwortcode als String (z. B. "ok").
queue/task_attempt_delays Verzögerungen bei Aufgabenversuchen DELTA, DISTRIBUTION, ms	Verzögerung zwischen dem Zeitpunkt des geplanten Versuchs und des tatsächlichen Versuchs