Strategia di ripetizione

Questa pagina descrive le best practice per riprovare le richieste non riuscite all'API Model Armor.

Per le richieste che possono essere riprovate in sicurezza, ti consigliamo di utilizzare il backoff esponenziale troncato con jitter introdotto.

Panoramica del backoff esponenziale troncato

Ogni richiesta all'API Model Armor può riuscire o non riuscire. Se la tua applicazione riprova le richieste non riuscite senza attendere, potrebbe inviare un numero elevato di tentativi a Model Armor in un breve periodo di tempo. Di conseguenza, potresti superare le quote e i limiti che si applicano a ogni risorsa Model Armor nel tuo progetto Google Cloud .

Per evitare di attivare questo problema, ti consigliamo vivamente di utilizzare il backoff esponenziale troncato con l'introduzione di jitter, una strategia standard di gestione degli errori per le applicazioni di rete. In questo approccio, un client ritenta periodicamente una richiesta non riuscita con ritardi esponenzialmente crescenti tra i tentativi. Tra i tentativi viene aggiunto anche un piccolo ritardo casuale, noto come jitter. Questo ritardo casuale contribuisce a evitare un'ondata sincronizzata di tentativi da più client, noto anche come problema della mandria fragorosa.

Algoritmo di backoff esponenziale

Il seguente algoritmo implementa il backoff esponenziale troncato con jitter:

  1. Invia una richiesta a Model Armor.
  2. Se la richiesta non va a buon fine, attendi 1 + random-fraction secondi, poi riprova.
  3. Se la richiesta non va a buon fine, attendi 2 + random-fraction secondi, poi riprova.
  4. Se la richiesta non va a buon fine, attendi 4 + random-fraction secondi, poi riprova.
  5. Continua questo schema, attendendo 2n + random-fraction secondi dopo ogni tentativo, fino a un massimo di maximum-backoff volte.
  6. Dopo deadline secondi, interrompi i tentativi di invio della richiesta.

Utilizza i seguenti valori durante l'implementazione dell'algoritmo:

  • Prima di ogni nuovo tentativo, il tempo di attesa è min((2n + random-fraction), maximum-backoff), con n che inizia da 0 e viene incrementato di 1 per ogni tentativo.
  • Sostituisci random-fraction con un valore frazionario casuale minore o uguale a 1. Utilizza un valore diverso per ogni nuovo tentativo. L'aggiunta di questo valore casuale impedisce ai client di sincronizzarsi e di inviare un numero elevato di tentativi contemporaneamente.
  • Sostituisci maximum-backoff con il tempo massimo, in secondi, da attendere tra i tentativi. I valori tipici sono 32 o 64 (25 o 26) secondi. Scegli il valore più adatto al tuo caso d'uso.
  • Sostituisci deadline con il numero massimo di secondi per continuare a inviare tentativi. Scegli un valore che rifletta il tuo caso d'uso. Ad esempio, in una pipeline di integrazione continua/deployment continuo (CI/CD) che non è particolarmente sensibile al tempo, potresti impostare deadline su 300 secondi (5 minuti).

Tipi di errori da riprovare

Utilizza questa strategia di ripetizione per tutte le richieste all'API Model Armor che restituiscono i codici di errore 500, 502, 503 o 504.

Se vuoi, puoi utilizzare questa strategia di ripetizione per le richieste all'API Model Armor che restituiscono il codice di errore 429.