Strategie für Wiederholungen

Auf dieser Seite werden Best Practices für die Wiederholung fehlgeschlagener Anfragen an die Model Armor API beschrieben.

Bei Anfragen, die sicher wiederholt werden können, empfehlen wir die Verwendung des abgeschnittenen exponentiellen Backoffs mit eingeführtem Jitter.

Abgeschnittener exponentieller Backoff

Jede Anfrage an die Model Armor API kann erfolgreich sein oder fehlschlagen. Wenn Ihre Anwendung fehlgeschlagene Anfragen ohne Wartezeit wiederholt, kann sie innerhalb kurzer Zeit eine große Anzahl von Wiederholungsversuchen an Model Armor senden. Infolgedessen können Sie Kontingente und Limits überschreiten, die für jede Model Armor-Ressource in Ihrem Google Cloud Projekt gelten.

Zur Vermeidung dieses Problems empfehlen wir dringend, den abgeschnittenen exponentiellen Backoff mit eingeführtem Jitter zu verwenden. Dies ist eine Standardstrategie zur Fehlerbehandlung für Netzwerkanwendungen. Bei diesem Ansatz wiederholt ein Client regelmäßig eine fehlgeschlagene Anfrage mit exponentiell zunehmenden Verzögerungen zwischen den Wiederholungen. Zwischen den Wiederholungen wird auch eine kleine, zufällige Verzögerung, die als Jitter bezeichnet wird, hinzugefügt. Diese zufällige Verzögerung verhindert, dass eine synchronisierte Welle von Wiederholungsversuchen von mehreren Clients entsteht, auch als Thundering-Herd-Problem bezeichnet wird.

Exponentieller Backoff-Algorithmus

Der folgende Algorithmus implementiert einen abgeschnittenen exponentiellen Backoff mit Jitter:

  1. Senden Sie eine Anfrage an Model Armor.
  2. Wenn die Anfrage fehlschlägt, wartet das System 1 + random-fraction Sekunden und wiederholt dann die Anfrage.
  3. Wenn die Anfrage fehlschlägt, wartet das System 2 + random-fraction Sekunden und wiederholt dann die Anfrage.
  4. Wenn die Anfrage fehlschlägt, wartet das System 4 + random-fraction Sekunden und wiederholt dann die Anfrage.
  5. Setzen Sie dieses Muster fort und warten Sie nach jedem Versuch 2n + random-fraction Sekunden bis zu einer Zeit von maximum-backoff.
  6. Beenden Sie das Wiederholen der Anfrage nach deadline Sekunden.

Verwenden Sie beim Implementieren des Algorithmus die folgenden Werte:

  • Vor jeder Wiederholung ist die Wartezeit min((2n + random-fraction), maximum-backoff), wobei n bei 0 beginnt und bei jeder Wiederholung um 1 erhöht wird.
  • Ersetzen Sie random-fraction durch einen zufälligen Bruchwert, der kleiner oder gleich 1 ist. Verwenden Sie für jede Wiederholung einen anderen Wert. Durch das Hinzufügen dieses zufälligen Werts wird verhindert, dass Clients synchronisiert werden und eine große Anzahl von Wiederholungsversuchen gleichzeitig gesendet werden.
  • Ersetzen Sie maximum-backoff durch die maximale Zeit in Sekunden, die zwischen Wiederholungen gewartet werden soll. Übliche Werte sind 32 oder 64 Sekunden (25 oder 26 Sekunden). Wählen Sie den Wert aus, der sich für Ihren Anwendungsfall am besten eignet.
  • Ersetzen Sie deadline durch die maximale Anzahl von Sekunden, die Wiederholungsversuche gesendet werden sollen. Wählen Sie einen Wert, der Ihren Anwendungsfall widerspiegelt. Beispiel: In einer CI/CD-Pipeline (Continuous Integration/Continuous Deployment), die nicht besonders zeitkritisch ist, können Sie deadline auf 300 Sekunden (5 Minuten) festlegen.

Arten von Fehlern, die wiederholt werden sollen

Verwenden Sie diese Wiederholungsstrategie für alle Anfragen an die Model Armor API, die die Fehlercodes 500, 502, 503 oder 504 zurückgeben.

Optional können Sie diese Wiederholungsstrategie für Anfragen an die Model Armor API verwenden, die den Fehlercode 429 zurückgeben.