Warteschlangenrouting, ‑limits und ‑wiederholungen konfigurieren

Mit Cloud Tasks können Sie die Aufgabenausführung verwalten, indem Sie das Routing, die Ratenbegrenzungen für die Weiterleitung und das Wiederholungsverhalten auf Warteschlangenebene definieren. Sie können diese Einstellungen beim Erstellen einer Warteschlange oder beim Aktualisieren einer vorhandenen Warteschlange konfigurieren.

Sowohl gcloud tasks queues create als auch gcloud tasks queues update verwenden dieselben Flags, um Warteschlangenparameter festzulegen. gcloud tasks queues update unterstützt außerdem --clear-*-Flags, um Parameter auf ihre Standardwerte zurückzusetzen.

Wenn Sie die Authentifizierung auf Warteschlangenebene konfigurieren, wird die Authentifizierung auf Aufgabenebene überschrieben. Weitere Informationen finden Sie unter HTTP-Zielaufgaben mit Authentifizierungstokens verwenden.

Routing auf Warteschlangenebene konfigurieren

Wenn Sie das Routing auf Warteschlangenebene konfigurieren, wird das Routing auf Aufgabenebene überschrieben. Das ist nützlich, wenn Sie Cloud Tasks als Puffer vor Ihrem Zieldienst verwenden möchten oder wenn Sie das Routing für alle Aufgaben in einer Warteschlange ändern müssen.

Das Routing auf Warteschlangenebene gilt für:

  • Aufgaben in der Warteschlange
  • Aufgaben, die der Warteschlange hinzugefügt werden, nachdem das Routing auf Warteschlangenebene festgelegt wurde

Beschränkungen

Das Routing auf Warteschlangenebene ist nicht mit vom Kunden verwalteten Verschlüsselungsschlüsseln (CMEK) des Cloud Key Management Service (Cloud KMS) kompatibel. Wenn CMEK aktiviert ist, können Sie Folgendes nicht tun:

  • Aufgaben in einer Warteschlange mit Routing auf Warteschlangenebene erstellen
  • Routing auf Warteschlangenebene anwenden

Routing auf Warteschlangenebene für HTTP-Aufgaben konfigurieren

Sie können eine Warteschlange so konfigurieren, dass das Routing auf Aufgabenebene entweder beim Erstellen oder beim Aktualisieren der Warteschlange überschrieben wird. Wenn Sie das Routing auf Warteschlangenebene konfigurieren möchten, legen Sie für den Parameter uriOverride der Warteschlange die gewünschte Route fest. Standardmäßig (uriOverrideEnforceMode ist auf ALWAYS festgelegt) überschreibt das Routing auf Warteschlangenebene das Routing auf Aufgabenebene. Sie können auch uriOverrideEnforceMode auf IF_NOT_EXISTS setzen, damit das Routing auf Warteschlangenebene nur dann angewendet wird, wenn eine Aufgabe keine eigenen URI-Komponenten angibt.

Wenn Sie das Routing auf Warteschlangenebene als Aktualisierung einer vorhandenen Warteschlange anwenden, pausieren Sie die Warteschlange, bevor Sie die Änderungen anwenden. Warten Sie nach dem Anwenden der Änderungen eine Minute, bevor Sie die Warteschlange fortsetzen.

  1. Pausieren Sie die Warteschlange mit dem folgenden Befehl:

    gcloud tasks queues pause QUEUE_ID \
    --location=LOCATION

    Ersetzen Sie Folgendes:

    • QUEUE_ID: die ID Ihrer Warteschlange.
    • LOCATION: der Standort Ihrer Warteschlange.

  2. Aktualisieren oder entfernen Sie das Routing auf Warteschlangenebene.

    • Wenn Sie das Routing auf Warteschlangenebene aktualisieren möchten, legen Sie den Parameter uriOverride auf die aktualisierte Route fest oder übergeben Sie das Flag --http-uri-override an gcloud tasks queues update.

    • So entfernen Sie das Routing auf Warteschlangenebene:

      • Google Cloud CLI: Führen Sie gcloud tasks queues update mit dem Flag --clear-http-uri-override aus:
      gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --clear-http-uri-override

      • REST API: Senden Sie eine patch-Anfrage für die Warteschlange mit einem leeren JSON-Objekt ({}) und dem Abfrageparameter updateMask, der auf httpTarget.uriOverride gesetzt ist (oder httpTarget, um alle HTTP-Zieleinstellungen auf Warteschlangenebene zu löschen).

      • RPC API: Senden Sie eine UpdateQueueRequest für die Queue, wobei queue.name angegeben, http_target.uri_override nicht festgelegt und der Parameter update_mask auf http_target.uri_override gesetzt ist (oder http_target, um alle HTTP-Zieleinstellungen auf Warteschlangenebene zu löschen).

    Im folgenden Beispiel wird die REST API verwendet, um den Host zu aktualisieren, an den Aufgaben weitergeleitet werden:

    curl -X PATCH -d @- -i \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  "https://cloudtasks.googleapis.com/v2/projects/PROJECT_ID/locations/LOCATION/queues/QUEUE_ID?updateMask=httpTarget.uriOverride" << EOF
{
  "httpTarget": {"uriOverride":{"host":"NEW_HOST"}}
}
EOF

    Ersetzen Sie Folgendes:

    • ACCESS_TOKEN: Ihr Zugriffstoken. Sie können sie abrufen, indem Sie in Ihrem Terminal Folgendes ausführen:

      gcloud auth application-default login
gcloud auth application-default print-access-token

    • PROJECT_ID: die ID Ihres Projekts in Google Cloud . Sie können diese abrufen, indem Sie in Ihrem Terminal Folgendes ausführen: 

      gcloud config get-value project

    • LOCATION: der Standort Ihrer Warteschlange.

    • NEW_HOST: der neue Host, an den die Warteschlange weitergeleitet werden soll.

  3. Warte eine Minute.

    Es kann bis zu einer Minute dauern, bis die neue Konfiguration wirksam wird. Wenn Sie mit der Fortsetzung der Warteschlange warten, wird verhindert, dass Aufgaben mit der alten Konfiguration gesendet werden.

  4. Setzen Sie die Warteschlange mit dem folgenden Befehl fort:

    gcloud tasks queues resume QUEUE_ID \
    --location=LOCATION

  5. Prüfen Sie mit dem folgenden Befehl, ob die Warteschlange erfolgreich konfiguriert wurde:

    gcloud tasks queues describe QUEUE_ID \
    --location=LOCATION

    Die Ausgabe sollte die von Ihnen festgelegte Routingüberschreibung httpTarget enthalten.

Routing auf Warteschlangenebene für App Engine-Aufgaben konfigurieren

Wenn Sie das Routing auf Warteschlangenebene für App Engine-Aufgaben konfigurieren möchten, legen Sie den Parameter appEngineRoutingOverride der Warteschlange auf den gewünschten App Engine-Dienst und die gewünschte Version fest.

  1. Richten Sie das Routing auf Warteschlangenebene ein und überschreiben Sie das Routing auf Aufgabenebene:

    gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --routing-override=service:SERVICE,version:VERSION

    Ersetzen Sie Folgendes:

    • QUEUE_ID: die Warteschlangen-ID (Kurzname).
    • LOCATION: der Standort der Warteschlange.
    • SERVICE: der App Engine-Worker-Dienst, der für die Aufgabenverarbeitung verantwortlich ist.
    • VERSION: die App-Version.

    Wenn Sie beispielsweise einen Worker-Dienst einrichten, der alle Aufgaben in einer Warteschlange verarbeitet, können Sie das Routing zu diesem Dienst und der Standardversion einrichten:

    gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --routing-override=service:SERVICE

  2. Prüfen Sie mit dem folgenden Befehl, ob die Warteschlange erfolgreich konfiguriert wurde:

    gcloud tasks queues describe QUEUE_ID \
    --location=LOCATION

    Die Ausgabe sollte in etwa so aussehen:

    appEngineRoutingOverride:
  host: SERVICE.PROJECT_ID.appspot.com
  service: SERVICE
name: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID
rateLimits:
  maxBurstSize: 100
  maxConcurrentDispatches: 1000
  maxDispatchesPerSecond: 500.0
retryConfig:
  maxAttempts: 100
  maxBackoff: 3600s
  maxDoublings: 16
  minBackoff: 0.100s
state: RUNNING

  3. Führen Sie den folgenden Befehl aus, um das Routing auf Warteschlangenebene zu entfernen:

    gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --clear-routing-override

    Wenn das Routing auf Warteschlangenebene entfernt wird, wird das Routing auf Aufgabenebene auf Aufgaben in der Warteschlange und auf Aufgaben angewendet, die der Warteschlange in Zukunft hinzugefügt werden.

Definieren Sie Ratenlimits

Die Ratenbegrenzung bestimmt die maximale Rate im stabilen Zustand, mit der Aufgaben von einer aktiven Warteschlange gesendet werden können, unabhängig davon, ob es sich um den ersten Versuch oder eine Wiederholung handelt.

  1. Legen Sie die maximale Rate und Anzahl gleichzeitiger Aufgaben fest, die von einer Warteschlange gesendet werden können. Führen Sie dazu den folgenden Befehl aus:

    gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --max-dispatches-per-second=DISPATCH_RATE \
    --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES

    Ersetzen Sie Folgendes:

    • QUEUE_ID: die Warteschlangen-ID (Kurzname).
    • LOCATION: der Standort der Warteschlange.
    • DISPATCH_RATE: die Versandrate. Dies ist die Rate, mit der Tokens im Bucket aktualisiert werden. Unter Bedingungen, bei denen ein relativ gleichmäßiger Aufgabenfluss herrscht, entspricht dies der Rate, mit der Aufgaben gesendet werden.
    • MAX_CONCURRENT_DISPATCHES: die maximale Anzahl von Aufgaben in der Warteschlange, die gleichzeitig ausgeführt werden können.

    Wenn Sie beispielsweise eine Warteschlange ohne Parameter erstellt haben, können Sie die maximale Anzahl gleichzeitiger Aufgaben mit dem folgenden Befehl aktualisieren:

    gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES

  2. Prüfen Sie mit dem folgenden Befehl, ob die Warteschlange erfolgreich konfiguriert wurde:

    gcloud tasks queues describe QUEUE_ID \
    --location=LOCATION

    Die Ausgabe sollte in etwa so aussehen:

    name: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID
rateLimits:
  maxBurstSize: 100
  maxConcurrentDispatches: MAX_CONCURRENT_DISPATCHES
  maxDispatchesPerSecond: DISPATCH_RATE
retryConfig:
  maxAttempts: 100
  maxBackoff: 3600s
  maxDoublings: 16
  minBackoff: 0.100s
state: RUNNING

Methoden zum Festlegen von Verarbeitungsraten für Warteschlangen

Sie können die Verarbeitungsraten für Warteschlangen entweder mit der Cloud Tasks API oder durch Hochladen einer queue.yaml-Datei definieren. Beide Methoden führen zu Warteschlangen, die denselben zugrunde liegenden Mechanismus verwenden.

In beiden Fällen verwendet die Warteschlange den Token-Bucket-Algorithmus, um die Rate der Aufgabenausführung zu steuern. Jede benannte Warteschlange hat einen Bucket, der ihre Tokens enthält.

Jedes Mal, wenn Ihre Anwendung eine Aufgabe ausführt, wird ein Token aus dem Bucket entfernt. Die Warteschlange verarbeitet Aufgaben so lange, bis der Bucket keine Tokens mehr enthält. Das System füllt den Bucket kontinuierlich mit neuen Tokens auf, basierend auf der max_dispatches_per_second-Rate, die Sie für die Warteschlange angeben. Wenn Ihre Warteschlange zu verarbeitende Aufgaben enthält und der Bucket der Warteschlange Tokens enthält, verarbeitet das System gleichzeitig so viele Aufgaben, wie Tokens vorhanden sind, bis zu dem von Ihnen festgelegten max_concurrent_dispatches-Wert.

In einer aktiven Warteschlange, die bereits aufgewärmt ist, kann eine ungleichmäßige Last dazu führen, dass die Anzahl der Tokens im Bucket erheblich ansteigt. Dies kann zu Verarbeitungsspitzen führen, wenn eine große Anzahl von Anfragen eingeht. In diesem Fall kann es bei einer aktiven Warteschlange zu einer tatsächlichen Versandrate kommen, die vorübergehend die Rate max_dispatches_per_second überschreitet. Dadurch werden Systemressourcen verbraucht und es kommt zu Konflikten mit Anfragen, die für Nutzer bereitgestellt werden. Wenn Sie Warteschlangen verwenden, um die Versandraten basierend auf relativ langsamen SLAs für nachgelagerte Dienste zu verwalten, können diese Bursts zu Fehlern wie HTTP 429 (Too Many Requests) oder HTTP 503 (Service Unavailable) führen. Wenn eine Warteschlange jedoch neu erstellt, vor Kurzem fortgesetzt oder mehrere Minuten inaktiv war, wechselt sie in einen kalten oder inaktiven Zustand und wird schrittweise auf max_dispatches_per_second hochgefahren, anstatt sofort zu bursten. Weitere Informationen zum Hochfahren von kalten oder inaktiven Warteschlangen finden Sie unter Anfängliches Hochfahren der Warteschlange.

  • Wenn Sie eine Cloud Tasks API-Methode verwenden, haben Sie zwei Felder, um die Versandrate der Warteschlange zu definieren:

    • max_dispatches_per_second
    • max_concurrent_dispatches

    Ein drittes Feld, max_burst_size, wird vom System anhand des Werts berechnet, den Sie für max_dispatches_per_second festgelegt haben. Weitere Informationen finden Sie unter RateLimits-Nachrichten.

  • Wenn Sie die Methode queue.yaml verwenden, können Sie alle drei Elemente festlegen:

    • max_concurrent_requests, was max_concurrent_dispatches entspricht
    • rate, was max_dispatches_per_second entspricht
    • bucket_size, was max_burst_size entspricht

In den meisten Fällen führt die Verwendung der Cloud Tasks API-Methode und die Festlegung von max_burst_size durch das System zu einer sehr effizienten Rate für die Verwaltung von Anfragespitzen. In einigen Fällen, insbesondere wenn die erforderliche Rate relativ niedrig ist, können Sie jedoch mehr Kontrolle erhalten, wenn Sie entweder die Methode queue.yaml verwenden, um bucket_size manuell auf einen kleinen Wert festzulegen, oder wenn Sie max_concurrent_dispatches mit der Cloud Tasks API auf einen kleinen Wert festlegen.

Wiederholungsparameter festlegen

Wenn eine Aufgabe nicht erfolgreich abgeschlossen wird, wiederholt Cloud Tasks die Aufgabe mit einem exponentiellen Backoff gemäß den von Ihnen festgelegten Parametern. Nachdem eine Aufgabe erfolgreich ausgeführt wurde, wird sie aus der Warteschlange entfernt. In allen Fällen gilt auch das Limit für die maximale Aufbewahrungsdauer von Aufgaben.

Optional können Sie eine Wiederholungskonfiguration auf Aufgabenebene angeben, die die Wiederholungskonfiguration auf Warteschlangenebene für die Aufgabe überschreibt. Weitere Informationen finden Sie unter Wiederholungsparameter für eine Aufgabe festlegen.

  1. Geben Sie die maximale Anzahl der Wiederholungen fehlgeschlagener Aufgaben in der Warteschlange an, legen Sie ein Zeitlimit für Wiederholungsversuche fest und steuern Sie das Intervall zwischen den Versuchen, indem Sie den folgenden Befehl ausführen:

    gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --max-attempts=MAX_ATTEMPTS \
    --max-retry-duration=MAX_RETRY_DURATION \
    --min-backoff=MIN_INTERVAL \
    --max-backoff=MAX_INTERVAL \
    --max-doublings=MAX_DOUBLINGS

    Ersetzen Sie Folgendes:

    • QUEUE_ID: die Warteschlangen-ID (Kurzname).
    • LOCATION: der Standort der Warteschlange.
    • MAX_ATTEMPTS: die maximale Anzahl von Versuchen für eine Aufgabe, einschließlich des ersten Versuchs. Wenn Sie unbegrenzte Wiederholungsversuche zulassen möchten, legen Sie hier -1 fest. MAX_RETRY_DURATION gilt auch dann, wenn MAX_ATTEMPTS erreicht oder auf -1 festgelegt ist.
    • MAX_RETRY_DURATION: die maximale Zeit für die Wiederholung einer fehlgeschlagenen Aufgabe, gemessen ab dem ersten Versuch. Der Wert muss ein String sein, der mit „s“ endet, z. B. 5s. Wenn Sie eine unbegrenzte Dauer angeben möchten, legen Sie hier 0s fest. MAX_ATTEMPTS gilt auch dann, wenn MAX_RETRY_DURATION erreicht oder auf 0s gesetzt ist.
    • MIN_INTERVAL: die Mindestzeit, die zwischen Wiederholungsversuchen gewartet werden muss. Der Wert muss ein String sein, der mit „s“ endet, z. B. 5s.
    • MAX_INTERVAL: die maximale Wartezeit zwischen Wiederholungsversuchen. Der Wert muss ein String sein, der mit „s“ endet, z. B. 5s.

    • MAX_DOUBLINGS: Die maximale Anzahl von Malen, die sich das Intervall zwischen fehlgeschlagenen Aufgabenwiederholungen verdoppelt, bevor die Erhöhung konstant wird. Das Wiederholungsintervall einer Aufgabe beginnt bei MIN_INTERVAL, verdoppelt sich dann MAX_DOUBLINGS-mal, steigt dann linear an und wird schließlich in Intervallen von MAX_INTERVAL bis zu MAX_ATTEMPTS-mal wiederholt.

      Wenn beispielsweise MIN_INTERVAL 10s ist, MAX_INTERVAL 300s ist und MAX_DOUBLINGS 3 ist, verdoppelt sich das Wiederholungsintervall 3-mal, erhöht sich linear um 2^3 * 10 s und wird dann in Intervallen von MAX_INTERVAL wiederholt, bis die Aufgabe MAX_ATTEMPTS-mal versucht wurde: 10 s, 20 s, 40 s, 80 s, 160 s, 240 s, 300 s, 300 s usw.

Weitere Informationen zu den Parametern finden Sie in der Ressourcenreferenz zu RetryConfig.

  1. Prüfen Sie mit dem folgenden Befehl, ob die Warteschlange erfolgreich konfiguriert wurde:

    gcloud tasks queues describe QUEUE_ID \
    --location=LOCATION

    Die Ausgabe sollte die von Ihnen festgelegten retryConfig-Parameter enthalten:

    retryConfig:
  maxAttempts: MAX_ATTEMPTS
  maxBackoff: MAX_INTERVAL
  maxDoublings: MAX_DOUBLINGS
  maxRetryDuration: MAX_RETRY_DURATION
  minBackoff: MIN_INTERVAL

Nächste Schritte