Ritenta le richieste non riuscite

Questa pagina descrive le best practice per riprovare le richieste non riuscite all'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 riprove 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. In questo approccio, un client riprova periodicamente una richiesta non riuscita con ritardi esponenzialmente crescenti tra i nuovi tentativi. Tra i tentativi viene aggiunto anche un piccolo ritardo casuale, chiamato jitter. Questo ritardo casuale aiuta a evitare un'ondata sincronizzata di tentativi da parte di più client, noto anche come problema del branco in tempesta.

Algoritmo di backoff esponenziale

Il seguente algoritmo implementa il backoff esponenziale troncato con jitter:

  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 e 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 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 nuovo 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 contemporaneamente un numero elevato di tentativi.
  • Sostituisci maximum-backoff con il tempo massimo, in secondi, da attendere 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 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 è molto soggetta a vincoli di tempo, puoi impostare deadline su 300 secondi (5 minuti).

Tipi di errori per i quali ripetere l'operazione

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

Facoltativamente, puoi utilizzare questa strategia di ripetizione per le richieste all'API IAM che restituiscono il codice di errore 404. Le letture IAM sono eventualmente coerenti. Di conseguenza, le risorse potrebbero non essere visibili immediatamente dopo la loro creazione, il che può portare a errori 404.

Inoltre, utilizza una versione modificata di questa strategia di ripetizione per tutte le richieste all'API IAM che restituiscono 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 l'intera serie di richieste read-modify-write, utilizzando il backoff esponenziale troncato con jitter introdotto. Se riprovi solo l'operazione di scrittura, la richiesta continuerà a non andare a buon fine.

Passaggi successivi