Ritenta le richieste non riuscite

In questa pagina vengono descritte le best practice per ritentare le richieste non riuscite all'account API Identity and Access Management (IAM).

Per le richieste per le quali è possibile eseguire nuovamente i tentativi, consigliamo di utilizzare il backoff esponenziale troncato con jitter introdotto.

Panoramica del backoff esponenziale troncato

Ogni richiesta all'API IAM può avere esito positivo o negativo. Se l'applicazione riprova le richieste non andate a buon fine senza attendere, potrebbe inviare un numero elevato di tentativi di nuovo a IAM in un breve periodo di tempo. Di conseguenza, potresti superare le quote e i limiti che si applicano a ogni risorsa IAM nel tuo progetto Google Cloud.

Per evitare di attivare questo problema, ti consigliamo vivamente di utilizzare il backoff esponenziale troncato con jitter introdotto, che è una strategia di gestione degli errori standard per le applicazioni di rete. Con questo approccio, un cliente riprova periodicamente una richiesta non riuscita con ritardi in aumento esponenziale tra un nuovo tentativo e l'altro. Un piccolo ritardo casuale, noto come jitter, viene aggiunto anche tra i nuovi tentativi. Questo ritardo casuale consente di evitare nuovi tentativi da parte di più clienti, noti anche come problema di gregge di tuni.

Algoritmo di backoff esponenziale

Il seguente algoritmo implementa il backoff esponenziale troncato con tremolio:

  1. Invia una richiesta a IAM.
  2. Se la richiesta non va a buon fine, attendi 1 + random-fraction secondi e riprova.
  3. Se la richiesta non va a buon fine, attendi 2 + random-fraction secondi, quindi riprova.
  4. Se la richiesta non va a buon fine, attendi 4 + random-fraction secondi e riprova.
  5. Continua questo schema, aspettando 2n + random-fraction secondi dopo ogni riprova, fino a un massimo di maximum-backoff volte.
  6. Dopo deadline secondi, interrompi la ripetizione della richiesta.

Utilizza i seguenti valori mentre implementi l'algoritmo:

  • Prima di ogni nuovo tentativo, il tempo di attesa è min((2n + random-fraction), maximum-backoff), con n a partire da 0 e incrementato di 1 per ogni tentativo.
  • Sostituisci random-fraction con un valore frazionario casuale minore o uguale a 1. Utilizza le funzionalità di un valore diverso per ogni tentativo. L'aggiunta di questo valore casuale impedisce ai client di diventare sincronizzati e inviare un numero elevato di nuovi tentativi contemporaneamente.
  • Sostituisci maximum-backoff con il tempo massimo, in secondi, di attesa tra un nuovo tentativo e l'altro. 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 i nuovi tentativi. Scegli un valore che rifletta il tuo caso d'uso. Ad esempio, in un'integrazione continua di deployment (CI/CD) non altamente sensibile al tempo, potresti Da deadline a 300 secondi (5 minuti).

Tipi di errori da riprovare

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

Facoltativamente, puoi utilizzare questa strategia di ripetizione per le richieste al API IAM che restituisce il codice di errore 404. Le letture IAM sono coerenti alla fine; come come risultato, le risorse potrebbero non essere visibili subito dopo averle create, può causare 404 errori.

Inoltre, utilizza una versione modificata di questa strategia di ripetizione per tutte le richieste l'API IAM che restituisce il codice di errore 409 e lo stato ABORTED. Questo tipo di errore indica un problema di concorrenza. Ad esempio, potresti provare ad aggiornare un criterio di autorizzazione già sovrascritto da un altro client. Per questo tipo di errore, devi sempre riprovare per intero di richieste di read-modify-write, utilizzando il backoff esponenziale troncato con il jitter introdotto. Se riprovi solo a eseguire l'operazione di scrittura, la richiesta continuano a non riuscire.

Passaggi successivi