Repetir pedidos com falha

Esta página descreve as práticas recomendadas para repetir pedidos falhados à API Identity and Access Management (IAM).

Para pedidos que podem ser repetidos com segurança, recomendamos que use a retirada exponencial truncada com variância introduzida.

Vista geral da retirada exponencial truncada

Cada pedido à API IAM pode ser bem-sucedido ou falhar. Se a sua aplicação tentar novamente pedidos falhados sem esperar, pode enviar um grande número de novas tentativas para o IAM num curto período. Como resultado, pode exceder as quotas e os limites que se aplicam a todos os recursos do IAM no seu Trusted Cloud by S3NS projeto.

Para evitar acionar este problema, recomendamos vivamente que use o recuo exponencial truncado com instabilidade introduzida, que é uma estratégia de processamento de erros padrão para aplicações de rede. Nesta abordagem, um cliente tenta novamente periodicamente um pedido falhado com intervalos de tempo entre tentativas que aumentam exponencialmente. Também é adicionado um pequeno atraso aleatório, conhecido como jitter, entre as novas tentativas. Este atraso aleatório ajuda a evitar uma onda sincronizada de novas tentativas de vários clientes, também conhecida como o problema da manada em debandada.

Algoritmo de retirada exponencial

O seguinte algoritmo implementa a retirada exponencial truncada com jitter:

  1. Envie um pedido ao IAM.
  2. Se o pedido falhar, aguarde 1 + random-fraction segundos e, em seguida, repita o pedido.
  3. Se o pedido falhar, aguarde 2 + random-fraction segundos e, em seguida, repita o pedido.
  4. Se o pedido falhar, aguarde 4 + random-fraction segundos e, em seguida, repita o pedido.
  5. Continue este padrão, aguardando 2n + random-fraction segundos após cada nova tentativa, até um máximo de maximum-backoff vezes.
  6. Após deadline segundos, pare de repetir o pedido.

Use os seguintes valores à medida que implementa o algoritmo:

  • Antes de cada nova tentativa, o tempo de espera é de min((2n + random-fraction), maximum-backoff), com n a começar em 0 e a ser incrementado em 1 para cada nova tentativa.
  • Substitua random-fraction por um valor fracionário aleatório inferior ou igual a 1. Use um valor diferente para cada nova tentativa. A adição deste valor aleatório impede que os clientes fiquem sincronizados e enviem um grande número de novas tentativas ao mesmo tempo.
  • Substitua maximum-backoff pela quantidade máxima de tempo, em segundos, a aguardar entre novas tentativas. Os valores típicos são 32 ou 64 (25 ou 26) segundos. Escolha o valor mais adequado ao seu exemplo de utilização.
  • Substitua deadline pelo número máximo de segundos para continuar a enviar novas tentativas. Escolha um valor que reflita o seu exemplo de utilização. Por exemplo, numa pipeline de integração contínua/implementação contínua (CI/CD) que não seja muito sensível ao tempo, pode definir deadline como 300 segundos (5 minutos).

Tipos de erros a tentar novamente

Use esta estratégia de repetição para todos os pedidos à API IAM que devolvam os códigos de erro 500, 502, 503 ou 504.

Opcionalmente, pode usar esta estratégia de repetição para pedidos à API IAM que devolvam o código de erro 404. As leituras da IAM são eventualmente consistentes. Como resultado, os recursos podem não estar visíveis imediatamente após a criação, o que pode originar erros 404.

Além disso, use uma versão modificada desta estratégia de repetição para todos os pedidos à API IAM que devolvam o código de erro 409 e o estado ABORTED. Este tipo de erro indica um problema de simultaneidade. Por exemplo, pode estar a tentar atualizar uma política de permissão que outro cliente já substituiu. Para este tipo de erro, deve sempre tentar novamente toda a série de pedidos de leitura-modificação-escrita, usando uma nova tentativa exponencial truncada com instabilidade introduzida. Se repetir apenas a operação de escrita, o pedido continua a falhar.

O que se segue?