Estrategias de reintento de trabajos de servicio en AWS Batch - AWS Batch
Configuración de estrategias de reintentos

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Estrategias de reintento de trabajos de servicio en AWS Batch

Las estrategias de reintento de tareas de servicio permiten AWS Batch reintentar automáticamente las tareas de servicio fallidas en condiciones específicas.

Los trabajos de servicio pueden requerir varios intentos por varios motivos:

  • Problemas de servicio temporales: los errores de servicio internos, las limitaciones o las interrupciones temporales pueden provocar que los trabajos fallen durante el envío o la ejecución.

  • Fallos en la inicialización del entrenamiento: los problemas durante el inicio del trabajo, como los problemas de extracción de imágenes o los errores de inicialización, pueden resolverse al volver a intentarlo.

Al configurar las estrategias de reintentos adecuadas, puede mejorar las tasas de éxito en el trabajo y reducir la necesidad de intervención manual, especialmente en el caso de las cargas de trabajo de formación prolongadas.

nota

Los trabajos de servicio reintentan automáticamente ciertos tipos de errores, como los errores de capacidad insuficiente, sin consumir los reintentos configurados. La estrategia de reintentos se ocupa principalmente de otros tipos de errores, como los errores de algoritmo o los problemas de servicio.

Configuración de estrategias de reintentos

Las estrategias de reintentos de las tareas de servicio se configuran mediante ServiceJobRetryStrategy, lo que admite tanto el recuento simple de reintentos como la lógica de reintentos condicional.

Configuración de reintentos

La estrategia de reintentos más sencilla especifica el número de reintentos que se deben realizar si se produce un error en un trabajo de servicio:

{
  "retryStrategy": {
    "attempts": 3
  }
}

Esta configuración permite volver a intentar el trabajo de servicio hasta 3 veces si se produce un error.

importante

El attempts valor representa el número total de veces que se puede colocar el trabajo en ese RUNNABLE estado, incluido el intento inicial. Un valor de 3 significa que se intentará realizar el trabajo una vez al principio y, si se produce un error, se volverá a intentar hasta 2 veces más.

Vuelva a intentar la configuración con evaluateOnExit

Puede usar el evaluateOnExit parámetro para especificar las condiciones en las que se deben volver a intentar los trabajos o permitir que fallen. Esto resulta útil cuando distintos tipos de errores requieren un tratamiento diferente.

La evaluateOnExit matriz puede contener hasta 5 estrategias de reintento, cada una de las cuales especifica una acción (RETRYoEXIT) y condiciones en función de los motivos del estado:

{
  "retryStrategy": {
    "attempts": 5,
    "evaluateOnExit": [
      {
        "action": "RETRY",
        "onStatusReason": "Received status from SageMaker: InternalServerError*"
      },
      {
        "action": "EXIT",
        "onStatusReason": "Received status from SageMaker: ValidationException*"
      },
      {
        "action": "EXIT",
        "onStatusReason": "*"
      }
    ]
  }
}

Esta configuración:

  • Reintenta los trabajos que fallan debido a errores internos del servidor de la SageMaker IA

  • Falla inmediatamente los trabajos que encuentran excepciones de validación (errores del cliente que no se resuelven al volver a intentarlo)

  • Incluye una regla general para salir en caso de cualquier otro tipo de fallo

Coincidencia del patrón estado/motivo

El onStatusReason parámetro admite la coincidencia de patrones con un máximo de 512 caracteres. Los patrones pueden utilizar caracteres comodín (*) y coincidir con los motivos de estado indicados por la SageMaker IA.

En el caso de los trabajos de servicio, los mensajes de estado de la SageMaker IA llevan el prefijo «Estado recibido de SageMaker:» para distinguirlos de los mensajes generados por la AWS Batch IA. Entre los patrones habituales se incluyen los siguientes:

  • Received status from SageMaker: InternalServerError*- Coincide con los errores del servicio interno

  • Received status from SageMaker: ValidationException*- Coincide con los errores de validación del cliente

  • Received status from SageMaker: ResourceLimitExceeded*- Coincide con los errores del límite de recursos

  • *CapacityError*- Haga coincidir los fallos relacionados con la capacidad

sugerencia

Utilice una coincidencia de patrones específica para gestionar los diferentes tipos de errores de forma adecuada. Por ejemplo, vuelva a intentarlo con los errores internos del servidor, pero falle inmediatamente si se trata de errores de validación que indiquen problemas con los parámetros del trabajo.