Probleme und Einschränkungen

Mit Cloud Tasks können Sie robuste asynchrone Systeme erstellen, wenn Sie bestimmte Ausführungsverhaltensweisen für Warteschlangen und Dienstlimits berücksichtigen. Sie können Verarbeitungsengpässe und unerwartete Verzögerungen vermeiden, indem Sie die mindestens einmalige Zustellung, die Systemdrosselung und die Kapazität der Zielressourcen berücksichtigen.

Ausführungsreihenfolge

Mit Ausnahme von Aufgaben, deren Ausführung in der Zukunft geplant ist, spielt die Ausführungsreihenfolge in Aufgabenwarteschlangen keine Rolle. Die Ausführung von Aufgaben in einer bestimmten Reihenfolge kann weder garantiert noch erzwungen werden. Insbesondere gibt es keine Garantie, dass alte Aufgaben ausgeführt werden, solange eine Warteschlange nicht vollständig geleert wird. Es gibt eine Reihe von Fällen, in denen neuere Aufgaben vor älteren Aufgaben ausgeführt werden. Die diesbezüglichen Muster können sich ohne vorherige Mitteilung ändern.

Ausführungsverzögerung

Bei Cloud Tasks-Ausführungen kann es aufgrund interner Systemneustarts gelegentlich zu geringfügigen Verzögerungen kommen, die in der Regel einige Minuten dauern. Aufgaben werden verzögert, aber es gehen keine Aufgaben verloren. Dies sind Ereignisse auf Systemebene, für die es keine Problemumgehung gibt. Diese Ereignisse werden nicht protokolliert und es gibt keinen festgelegten Zeitplan für ihr Auftreten.

Doppelte Ausführung

Cloud Tasks folgt nach Möglichkeit der Regel der einmaligen Ausführung. Wenn jedoch ein Kompromiss zwischen garantierter und doppelter Ausführung erforderlich ist, entscheidet der Dienst zugunsten einer garantierten Ausführung. In diesem Fall treten doppelte Ausführungen auf. Sie sollten dafür sorgen, dass doppelte Ausführungen ordnungsgemäß verarbeitet werden und keine unerwarteten Fehler verursachen. In der Produktion werden über 99, 999% der Aufgaben nur einmal ausgeführt.

Ressourceneinschränkungen

Der gängigste Grund für Rückstände in unmittelbaren Verarbeitungswarteschlangen ist die Erschöpfung der Ressourcen auf den Zielinstanzen. Wenn Sie versuchen, auf Frontend-Instanzen, die nur zehn Anfragen pro Sekunde verarbeiten können, 100 Aufgaben pro Sekunde auszuführen, kommt es zu einem Rückstand. Dies äußert sich in der Regel auf eine von zwei Arten. Beides lässt sich normalerweise durch Erhöhen der Anzahl der Instanzen lösen, die Anfragen verarbeiten.

Backoff-Fehler und erzwungene Raten

Server können bei Überlastung Backoff-Fehler zurückgeben: 503 (für App Engine-Ziele) oder 429 oder 5xx (für externe Ziele). Als Reaktion auf diese Fehler verlangsamt Cloud Tasks die Ausführung, bis die Fehler behoben sind. Diese Systemdrosselung verhindert eine Überlastung des Workers. Ihre Einstellungen werden dabei nicht geändert.

Systemdrosselung tritt unter folgenden Umständen auf:

• Cloud Tasks führt bei allen Fehlern einen Backoff aus. Normalerweise wird der in angegebene Backoff rate_limits verwendet. Wenn der Worker jedoch 429 Too Many Requests oder 503 Service Unavailable zurückgibt oder die Fehlerrate hoch ist, verwendet Cloud Tasks eine höhere Backoff-Rate. Der im HTTP-Antwortheader Retry-After angegebene Wiederholungsversuch wird berücksichtigt.

• Um Traffic-Spitzen zu vermeiden und plötzliche Traffic-Anstiege zu glätten, werden Sendungen langsam erhöht, wenn die Warteschlange neu erstellt oder inaktiv ist und wenn plötzlich eine große Anzahl von Aufgaben zur Sendung verfügbar wird (aufgrund von Spitzen bei den Raten für die Aufgabenerstellung, der Aufhebung der Pausierung der Warteschlange oder vieler Aufgaben, die gleichzeitig geplant sind).

Latenzspitzen und maximale Gleichzeitigkeit

Auch die Latenz kann sich bei überlasteten Servern drastisch erhöhen. Anfragen bleiben in diesem Fall länger offen. Da in Warteschlangen eine maximale Anzahl von Aufgaben gleichzeitig ausgeführt wird, können Aufgaben gegebenenfalls nicht mit der erwarteten Rate ausgeführt werden. Wenn die max_concurrent_dispatches zu niedrig gewählt und die Rate somit künstlich begrenzt wurde, kann eine Erhöhung dieses Werts für die betroffenen Warteschlangen Abhilfe schaffen. Eventuell zugrunde liegende Ressourcenprobleme lassen sich durch eine Erhöhung von max_concurrent_dispatches aber meist nicht beheben.

Probleme mit der Erhöhung bei lang andauernden Aufgaben

Cloud Tasks-Warteschlangen erhöhen ihre Ausgabe teilweise anhand der Anzahl der zuvor erfolgreich weitergeleiteten Aufgaben. Wenn der Aufgaben-Handler einen erheblichen Zeitraum – in der Größenordnung von Minuten – benötigt, um eine Aufgabe abzuschließen und eine Erfolgsantwort zurückzugeben, kann es zu einer Verzögerung bei der Erhöhungsrate der Warteschlange kommen.

Mehr als 5.000 Aufgaben ansehen

Wenn Sie mehr als 5.000 Aufgaben haben, sind einige Aufgaben in der Google Cloud Console nicht sichtbar. Verwenden Sie die gcloud CLI , um alle Aufgaben anzusehen.

Maximale gemeldete Warteschlangentiefe

Die von Cloud Tasks gemeldete maximale Warteschlangentiefe ist auf 1.000.000 Aufgaben begrenzt. Dadurch soll die Leistung der zugrunde liegenden Aufgaben-Worker verbessert werden. Die Anzahl der Aufgaben, die an Ihre Warteschlange gesendet oder von ihr verarbeitet werden können, wird dadurch nicht beeinträchtigt. Aufgaben, die über dem Limit für die Warteschlangentiefe an die Warteschlange gesendet werden, werden weiterhin wie vorgesehen ausgeführt.

Wenn Sie die aktuelle Warteschlangentiefe über 1.000.000 Aufgaben hinaus abrufen möchten, können Sie die queues.tasks.list Methode verwenden. Diese Methode gibt alle Aufgaben mit Paginierung zurück, sodass Sie die Daten aggregieren und eine Zählung durchführen können. Je nach Größe der Warteschlangentiefe können jedoch bei der Methode Kontingentbeschränkungen auftreten.

Warteschlange mit demselben Namen neu erstellen

Wenn Sie eine Warteschlange aus der Google Cloud Console löschen, müssen Sie drei Tage warten, bevor Sie sie mit demselben Namen neu erstellen können. Diese Wartezeit verhindert unerwartetes Verhalten bei Aufgaben, die zum Zeitpunkt des Löschens ausgeführt werden oder auf die Ausführung warten. Außerdem werden Fehler bei internen Prozessen im Lösch- oder Neuerstellungszyklus vermieden.

Nicht unterstütztes Ziel bei Verwendung eines sicheren Perimeters

Wenn Sie mit VPC Service Controls einen sicheren Perimeter eingerichtet haben, werden HTTP-Anfragen von einer Cloud Tasks-Ausführung für nicht unterstützte Ziele blockiert und schlagen mit dem Fehlercode TARGET_TYPE_NOT_PERMITTED_FOR_VPC fehl. Weitere Informationen finden Sie unter Dienstperimeter mit VPC Service Controls einrichten.

Einschränkungen für Ressourcenstandorte

Cloud Tasks unterstützt die Einschränkung von Ressourcenstandorten. Für die folgenden Regionen gelten jedoch Einschränkungen:

• us-central1
• us-central2 (private Google Cloud region)

Wenn Sie eine der beiden Regionen in Ihrer Organisationsrichtlinie angeben, müssen Sie sowohl us-central1 als auch us-central2 angeben, auch wenn Sie in beiden Regionen keine Cloud Tasks-Ressourcen erstellen. Sie können die Region us-central2 in Ihre Organisationsrichtlinie aufnehmen, auch wenn Ihre Organisation keine privaten Regionen verwendet.