Vuelve a intentar con las solicitudes que fallaron

En esta página, se describen las prácticas recomendadas para reintentar solicitudes con errores a la API de Identity and Access Management (IAM).

En el caso de las solicitudes que sean seguras para reintentarse, recomendamos usar una retirada exponencial truncada con el jitter ingresado.

Descripción general de la retirada exponencial truncada

Cada solicitud a la API de IAM puede completarse de forma correcta o fallar. Si tu aplicación reintenta las solicitudes que fallaron sin esperar, es posible que envíe una gran cantidad de reintentos a IAM en un período corto. Como resultado, es posible que excedas las cuotas y límites que se aplican a cada recurso de IAM en tu proyecto de Google Cloud.

Para evitar activar este problema, te recomendamos que uses la retirada exponencial truncada con el jitter incorporado, que es un a estrategia de manejo de errores estándar para aplicaciones de red. En este enfoque, un cliente vuelve a intentar una solicitud con errores de forma periódica, cada vez con más demoras entre los reintentos. También se agrega un pequeño retraso aleatorio, conocido como jitter, entre los reintentos. Esta demora aleatoria ayuda a evitar un conjunto sincronizado de reintentos de varios clientes, también conocido como problema de activación simultánea.

Algoritmo de retirada exponencial

El siguiente algoritmo implementa una retirada exponencial truncada con jitter:

  1. Envía una solicitud a IAM.
  2. Si la solicitud falla, espera 1 + random-fraction segundos y vuelve a intentar la solicitud.
  3. Si la solicitud falla, espera 2 + random-fraction segundos y vuelve a intentar la solicitud.
  4. Si la solicitud falla, espera 4 + random-fraction segundos y vuelve a intentar la solicitud.
  5. Continúa este patrón. Espera 2n + random-fraction segundos después de cada reintento hasta un tiempo de maximum-backoff.
  6. Después de deadline segundos, deja de reintentar la solicitud.

Usa los siguientes valores cuando implementes el algoritmo:

  • Antes de cada reintento, el tiempo de espera es min((2n + random-fraction), maximum-backoff), con n a partir de 0 y, luego, incrementado en 1 para cada reintento.
  • Reemplaza random-fraction por un valor fraccionario aleatorio menor o igual que 1. Usa un valor diferente para cada reintento. Agregar este valor aleatorio evita que los clientes se sincronicen y envíen grandes cantidades de reintentos al mismo tiempo.
  • Reemplaza maximum-backoff por la cantidad máxima de tiempo, en segundos, para esperar entre reintentos. Los valores típicos son 32 o 64 (25 o 26) segundos. Elige el valor que mejor se adapte a tu caso de uso.
  • Reemplaza deadline por la cantidad máxima de segundos para seguir enviando reintentos. Elige un valor que refleje tu caso de uso. Por ejemplo, en una canalización de integración continua/implementación continua (CI/CD) que no es urgente, puedes configurar deadline como 300 segundos (5 minutos).

Tipos de errores para reintentar

Usa esta estrategia de reintento en todas las solicitudes a la API de IAM que muestren los códigos de error 500, 502, 503 o 504.

De forma opcional, puedes usar esta estrategia de reintento para las solicitudes a la API de IAM que muestran el código de error 404. Las lecturas de IAM tienen coherencia eventual. Como resultado, es posible que los recursos no sean visibles de inmediato después de crearlos, lo que puede generar errores 404.

Además, usa una versión modificada de esta estrategia de reintento para todas las solicitudes a la API de IAM que muestran el código de error 409 y el estado ABORTED. Este tipo de error indica un problema de simultaneidad; por ejemplo, es posible que estés intentando actualizar una política de permisos que otro cliente ya reemplazó. Para este tipo de error, siempre debes volver a intentar toda la serie de solicitudes de lectura-modificación-escritura, usando la retirada exponencial truncada con el jitter ingresado. Si solo reintentas la operación de escritura, la solicitud seguirá fallando.

¿Qué sigue?