Cloud Tasks-Warteschlangen konfigurieren

Sie können die Cloud Tasks-Warteschlange während ihrer Erstellung oder später konfigurieren. Die Konfiguration gilt für alle Aufgaben in dieser Warteschlange.

Beim Konfigurieren von Warteschlangen sind drei grundlegende Aspekte zu berücksichtigen:

Routing auf Warteschlangenebene konfigurieren

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

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, sind folgende Aktionen nicht möglich:

  • 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 überschrieben wird. Das ist entweder beim Erstellen oder beim Aktualisieren der Warteschlange möglich. Wenn Sie das Routing auf Warteschlangenebene konfigurieren möchten, legen Sie den Parameter uriOverride der Warteschlange auf die gewünschte Route fest.

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

  1. Pausieren Sie die Warteschlange, indem Sie den folgenden Befehl ausführen:

      gcloud tasks queues pause QUEUE_ID

    Ersetzen Sie QUEUE_ID durch die ID 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.

    • So entfernen Sie das Routing auf Warteschlangenebene mit der REST API oder der RPC API:

      • REST API:Sende eine patch-Anfrage für die Warteschlange mit einer leeren Nutzlast und dem Parameter updateMask auf httpTarget.

      • RPC API:Sende eine updateQueueRequest für die Warteschlange mit einer leeren Nutzlast und dem Parameter update_mask auf http_target.

    Im folgenden Beispiel wird der Host, an den Aufgaben weitergeleitet werden, mithilfe der REST API aktualisiert:

    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. Führen Sie dazu in Ihrem Terminal den folgenden Befehl aus:

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

    • PROJECT_ID: die ID Ihres Google Cloud Projekts. Führen Sie dazu in Ihrem Terminal den folgenden Befehl aus: 

      gcloud config get-value project

    • LOCATION: Der Speicherort Ihrer Warteschlange.

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

  3. Warten Sie eine Minute.

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

  4. Führen Sie den folgenden Befehl aus, um die Warteschlange fortzusetzen:

    gcloud tasks queues resume QUEUE_ID

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. So richten Sie ein Routing auf Warteschlangenebene ein und überschreiben alle Routingvorgänge auf Aufgabenebene:

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

    Ersetzen Sie Folgendes:

    • QUEUE_ID: die Warteschlangen-ID (Kurzname).
    • SERVICE: der für die Aufgabenverarbeitung zuständige App Engine-Worker-Dienst.
    • VERSION: die App-Version.

    Wenn Sie beispielsweise einen Worker-Dienst einrichten, um alle Aufgaben in einer Warteschlange zu verarbeiten, können Sie mit dem folgenden Befehl das Routing an diesen Dienst und die Standardversion konfigurieren:

    gcloud tasks queues update QUEUE_ID \
    --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

    Ersetzen Sie LOCATION durch den Speicherort der Warteschlange.

    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 \
    --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

Das Ratelimit gibt die maximale Rate an, mit der Aufgaben von einer Warteschlange weitergeleitet werden können, unabhängig davon, ob es sich um den ersten Versuch oder einen Wiederholungsversuch handelt.

  1. Mit dem folgenden Befehl können Sie die maximale Rate und die Anzahl gleichzeitiger Aufgaben festlegen, die von einer Warteschlange weitergeleitet werden können:

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

    Ersetzen Sie Folgendes:

    • QUEUE_ID: die Warteschlangen-ID (Kurzname).
    • DISPATCH_RATE: die Auslieferungsrate. Das ist die Rate, mit der Tokens im Bucket aktualisiert werden. Bei Bedingungen mit einem relativ gleichmäßigen Aufgabenfluss entspricht dies der Rate, mit der Aufgaben weitergeleitet werden.
    • MAX_CONCURRENT_DISPATCHES: die maximale Anzahl von Aufgaben in der Warteschlange, die gleichzeitig ausgeführt werden können.

    Wenn Sie beispielsweise eine Warteschlange erstellt haben, ohne Parameter festzulegen, können Sie die maximale Anzahl gleichzeitiger Aufgaben aktualisieren, indem Sie folgenden Befehl ausführen:

    gcloud tasks queues update QUEUE_ID \
    --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

    Ersetzen Sie LOCATION durch den Speicherort der Warteschlange.

    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: 500.0
retryConfig:
  maxAttempts: 100
  maxBackoff: 3600s
  maxDoublings: 16
  minBackoff: 0.100s
state: RUNNING

Methoden zum Definieren von Verarbeitungsraten für Warteschlangen

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

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 weiterhin Aufgaben, bis keine Tokens mehr im Bucket vorhanden sind. Das System füllt den Bucket auf der Grundlage der max_dispatches_per_second-Rate, die Sie für die Warteschlange festlegen, kontinuierlich mit neuen Tokens auf. Wenn Ihre Warteschlange zu verarbeitende Aufgaben und der Bucket der Warteschlange Tokens enthält, verarbeitet das System gleichzeitig dieselbe Anzahl von Aufgaben und Tokens bis zu dem von Ihnen festgelegten Wert max_concurrent_dispatches.

Ein ungleichmäßiger Ladevorgang kann dazu führen, dass die Anzahl der Tokens im Bucket erheblich anwächst, was zu Bursts der Verarbeitung führen kann, wenn dann eine Reihe von Anfragen eingeht. In diesem Fall kann die Warteschlange eine tatsächliche Weiterleitungsrate aufweisen, die Ihre max_dispatches_per_second-Rate übersteigt, Systemressourcen verbraucht und mit Anfragen zur Nutzerverwaltung konkurriert. In Fällen, in denen Sie Warteschlangen zur Verwaltung von Weiterleitungsraten auf der Grundlage von relativ langsamen SLAs für nachgelagerte Dienste verwenden, kann dies zu HTTP-Fehlern wie 429 (zu viele Anfragen) oder 503 (Dienst nicht verfügbar) führen.

  • Wenn Sie eine Cloud Tasks API-Methode verwenden, haben Sie zwei Felder, um die Warteschlangen-Weiterleitungsrate zu definieren:

    • max_dispatches_per_second
    • max_concurrent_dispatches

    Ein drittes Feld, max_burst_size, wird vom System auf der Grundlage des Werts berechnet, den Sie für max_dispatches_per_second festgelegt haben.

  • Wenn Sie die queue.yaml-Methode 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 Einstellung des Systems auf max_burst_size zu einer sehr effizienten Rate für die Verwaltung von Anfrage-Bursts. In einigen Fällen, insbesondere wenn die gewünschte Rate relativ langsam ist, können Sie jedoch entweder bucket_size mit der Methode queue.yaml manuell auf einen kleinen Wert setzen oder max_concurrent_dispatches über die Cloud Tasks API auf einen kleinen Wert festlegen, um so mehr Kontrolle zu erhalten.

Wiederholungsparameter festlegen

Wenn eine Aufgabe nicht erfolgreich abgeschlossen wurde, wiederholt Cloud Tasks die Aufgabe mit exponentiellem Backoff gemäß den von Ihnen festgelegten Parametern.

  1. Sie können die maximale Anzahl der Wiederholungen von fehlgeschlagenen Warteschlangenaufgaben, ein Zeitlimit für Wiederholungsversuche und das Intervall zwischen den Versuchen festlegen. Führen Sie dazu den folgenden Befehl aus:

    gcloud tasks queues update QUEUE_ID \
    --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).
    • MAX_ATTEMPTS: Die maximale Anzahl der Versuche für eine Aufgabe, einschließlich des ersten Versuchs. Sie können unbegrenzte Wiederholungen zulassen, indem Sie dieses Flag auf -1 festlegen. Wenn MAX_ATTEMPTS auf -1 gesetzt ist, wird MAX_RETRY_DURATION trotzdem angewendet.
    • MAX_RETRY_DURATION: Die maximale Dauer, nach der eine fehlgeschlagene Aufgabe wiederholt werden kann, gemessen ab dem ersten Versuch. Der Wert muss ein String sein, der mit „s“ endet, z. B. 5s. Wenn der Wert auf 0 gesetzt ist, ist das Aufgabenalter unbegrenzt. Wenn MAX_RETRY_DURATION auf 0 festgelegt ist, wird MAX_ATTEMPTS weiterhin angewendet.
    • MIN_INTERVAL: die Mindestzeit, die zwischen den Wiederholungsversuchen vergehen soll. Der Wert muss ein String sein, der mit "s" endet, zum Beispiel 5s.
    • MAX_INTERVAL: die maximale Wartezeit zwischen den Wiederholungsversuchen. Der Wert muss ein String sein, der mit "s" endet, zum Beispiel 5s.

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

      Wenn MIN_INTERVAL beispielsweise 10s, MAX_INTERVAL 300s und MAX_DOUBLINGS 3 ist, wird das Wiederholungsintervall 3-mal verdoppelt, linear um 2 ³ * 10 s erhöht und 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 den RetryConfig-Einstellungen für die Queue-Ressource.

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

    gcloud tasks queues describe QUEUE_ID --location=LOCATION

    Ersetzen Sie LOCATION durch den Speicherort der Warteschlange.

    Die Ausgabe sollte die von Ihnen festgelegten Wiederholungsparameter enthalten.

Nächste Schritte