Estrategia de reintentos

En esta página, se describen las prácticas recomendadas para reintentar solicitudes con errores a la API de Model Armor.

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 Model Armor puede completarse de forma correcta o fallar. Si tu aplicación reintenta las solicitudes fallidas sin esperar, es posible que envíe una gran cantidad de reintentos a Model Armor en un período breve. Como resultado, es posible que excedas las cuotas y los límites que se aplican a cada recurso de Model Armor en tu Google Cloud proyecto.

Para evitar activar este problema, te recomendamos que uses la retirada exponencial truncada con el jitter incorporado, que es una 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 Model Armor.
  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 Model Armor 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 Model Armor que muestran el código de error 429.