Cloud Tasks-Warteschlangen konfigurieren

Auf dieser Seite wird beschrieben, wie Sie Cloud Tasks-Warteschlangen mit dem Befehl gcloud des Google Cloud SDK konfigurieren.

Cloud Tasks-Warteschlange 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 konfigurieren (nur App Engine-Warteschlangen)

Die Warteschlange muss den Namen und die Version des Dienstes kennen, der den entsprechenden Worker enthält. Dieser wird als Ziel bezeichnet. Es gibt drei Möglichkeiten, das Ziel festzulegen:

  • Legen Sie das Ziel nicht explizit fest. In diesem Fall wird der Standarddienst verwendet.
  • Deklarieren Sie das Ziel ausdrücklich in der Aufgabe selbst, indem Sie AppEngineRouting in AppEngineHttpRequest festlegen. Dies ist die bevorzugte Methode, wenn Sie ein anderes Ziel als das Standardziel verwenden möchten.
  • Leiten Sie alle Aufgaben in einer Warteschlange ausdrücklich an ein nicht standardmäßiges Ziel weiter, indem Sie appEngineRoutingOverride verwenden. Bei dieser Methode werden alle Routingvorgänge überschrieben, die möglicherweise in der Aufgabe festgelegt sind.

So verwenden Sie gcloud zum Einrichten dieses nicht standardmäßigen Routings auf Warteschlangenebene und damit zum Überschreiben von beliebigem Routing auf Aufgabenebene:

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

wobei

  • SERVICE ist der für die Aufgabenverarbeitung zuständige App Engine-Worker-Dienst.
  • VERSION ist die Version der App.

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

gcloud tasks queues update barbequeue \
    --routing-override=service:worker

Describe die Warteschlange:

gcloud tasks queues describe barbequeue

Die Ausgabe sollte etwa so aussehen:

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

Definieren Sie Ratenlimits

Sie können 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_RUNNING]

wobei

  • DISPATCH_RATE ist die Rate, zu der Tokens im Bucket aktualisiert werden. Bei Bedingungen mit einem relativ gleichmäßigen Aufgabenfluss entspricht dies der Rate, mit der Aufgaben weitergeleitet werden.
  • MAX_RUNNING ist die maximale Anzahl der Tasks in der Warteschlange, die gleichzeitig ausgeführt werden können.

Wenn Sie beispielsweise eine Warteschlange mit dem Namen barbequeue erstellt haben, ohne Parameter festzulegen, können Sie die maximale Anzahl gleichzeitiger Aufgaben aktualisieren, indem Sie Folgendes aufrufen:

gcloud tasks queues update barbequeue \
        --max-concurrent-dispatches=20

Describe die Warteschlange:

gcloud tasks queues describe barbequeue

Die Ausgabe sollte so aussehen:

name: projects/[PROJECT_ID]/locations/[LOCATION_ID]/queues/barbequeue
rateLimits:
  maxBurstSize: 100
  maxConcurrentDispatches: 20
  maxDispatchesPerSecond: 500.0
retryConfig:
  maxAttempts: 100
  maxBackoff: 3600s
  maxDoublings: 16
  minBackoff: 0.100s
state: RUNNING

Verarbeitungsraten mit gcloud-Befehlen im Vergleich zu queue.yaml definieren

Der Cloud Tasks API-Ansatz zum Definieren von Verarbeitungsraten für Warteschlangen unterscheidet sich geringfügig vom Upload von queue.yaml-Dateien, obwohl beide Methoden zu Warteschlangen mit demselben zugrunde liegenden Mechanismus führen.

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 mit den zugehörigen Tokens.

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

wie im Beispiel oben gezeigt. 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 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 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. Sie können die maximale Anzahl der Wiederholungen von fehlgeschlagenen Warteschlangenaufgaben, ein Zeitlimit für Wiederholungsversuche und das Intervall zwischen den Versuchen festlegen.

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

wobei

  • MAX_ATTEMPTS ist 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 unlimitedfestlegen.
  • MIN_INTERVAL ist die Mindestdauer der Wartezeit zwischen Wiederholungsversuchen. Der Wert muss ein String sein, der mit "s" endet, zum Beispiel 5s.
  • MAX_INTERVAL ist die Höchstdauer der Wartezeit zwischen Wiederholungsversuchen. Der Wert muss ein String sein, der mit "s" endet, zum Beispiel 5s.
  • MAX_DOUBLINGS ist die maximale Anzahl der Verdoppelungen des Intervalls zwischen fehlgeschlagenen Aufgabenwiederholungen, bevor der Anstieg konstant wird.
  • MAX_RETRY_DURATION ist die Höchstdauer für die Wiederholung einer fehlgeschlagenen Aufgabe. Der Wert muss ein String sein, der mit "s" endet, zum Beispiel 5s.

Prüfen Sie, ob die Warteschlange erfolgreich konfiguriert wurde:

gcloud tasks queues describe [QUEUE_ID]

Nächste Schritte