Tentar novamente solicitações com falha

Nesta página, descrevemos as práticas recomendadas para repetir solicitações com falha para a API Identity and Access Management (IAM).

Para solicitações que podem ser repetidas, use a espera exponencial truncada com instabilidade introduzida.

Visão geral da espera exponencial truncada

Cada solicitação para a API IAM pode ser bem-sucedida ou não. Se o aplicativo repetir solicitações com falha sem esperar, ele poderá enviar um grande número de tentativas para o IAM em um curto período. Como resultado, pode haver exceção de cotas e limites que se aplicam a todos os recursos do IAM no projeto do Google Cloud.

Para evitar o acionamento desse problema, use a espera exponencial truncada com a instabilidade introduzida, que é uma estratégia padrão de tratamento de erros para aplicativos de rede. Nessa abordagem, um cliente repete de maneira periódica uma solicitação com falha, com atrasos exponencialmente crescentes entre as novas tentativas. Um pequeno atraso aleatório, conhecido como instabilidade, também é adicionado entre as novas tentativas. Esse atraso aleatório ajuda a evitar uma onda sincronizada de novas tentativas de vários clientes, também conhecido como problema de excesso de acionamentos.

Algoritmo de espera exponencial

O algoritmo a seguir implementa a espera exponencial truncada com instabilidade:

  1. Envie uma solicitação para o IAM.
  2. Se a solicitação falhar, aguarde 1 + random-fraction segundos e repita a solicitação.
  3. Se a solicitação falhar, aguarde 2 + random-fraction segundos e repita a solicitação.
  4. Se a solicitação falhar, aguarde 4 + random-fraction segundos e repita a solicitação.
  5. Continue esse padrão, aguardando 2n + random-fraction segundos após cada nova tentativa, até o máximo de maximum-backoff.
  6. Depois de deadline segundos, pare de repetir a solicitação.

Use os seguintes valores ao implementar o algoritmo:

  • Antes de cada nova tentativa, o tempo de espera é de min((2n + random-fraction), maximum-backoff), com n a partir de 0 e incrementado em 1 para cada nova tentativa.
  • Substitua random-fraction por um valor fracionário aleatório menor ou igual a 1. Use um valor diferente para cada nova tentativa. Adicionar esse valor aleatório evita que os clientes sejam sincronizados e enviem um grande número de novas tentativas ao mesmo tempo.
  • Substitua maximum-backoff pelo tempo máximo, em segundos, para aguardar entre as novas tentativas. Os valores típicos são 32 ou 64 (25 ou 26) segundos. Escolha o valor ideal para seu caso de uso.
  • Substitua deadline pelo número máximo de segundos para continuar enviando novas tentativas. Escolha um valor que reflita seu caso de uso. Por exemplo, em um pipeline de integração/implantação contínuas (CI/CD) que não seja altamente urgente, defina deadline como 300 segundos (5 minutos).

Tipos de erros para tentar novamente

Use essa estratégia de repetição para todas as solicitações à API IAM que retornam os códigos de erro 500, 502, 503 ou 504.

Como opção, é possível usar essa estratégia de nova tentativa para solicitações à API IAM que retornam o código de erro 404. As leituras do IAM têm consistência eventual. Como resultado, os recursos podem não estar visíveis imediatamente após a criação, o que pode gerar erros 404.

Além disso, use uma versão modificada dessa estratégia de repetição para todas as solicitações à API IAM que retornam o código de erro 409 e o status ABORTED. Esse tipo de erro indica um problema de simultaneidade. Por exemplo, talvez você esteja tentando atualizar uma política de permissão que outro cliente já substituiu. Para esse tipo de erro, você deve sempre repetir toda a série de solicitações read-modify-write, usando a espera exponencial truncada com instabilidade introduzida. Se você repetir somente a operação de gravação, a solicitação continuará com erros.

A seguir