View a markdown version of this page

Detección de errores por el interruptor de circuito de implementación de Amazon ECS - Amazon Elastic Container Service
Failure threshold

Detección de errores por el interruptor de circuito de implementación de Amazon ECS

El disyuntor de implementación es el mecanismo de actualización continua que determina si las tareas alcanzan un estado estable. El interruptor de implementación tiene una opción que revertirá automáticamente una implementación con errores a la implementación con el estado COMPLETED. Puede personalizar la forma en que el disyuntor cuenta las fallas y el umbral de activación, de modo que el comportamiento de reversión coincida con las características de inicio de la aplicación y con su tolerancia a los errores de las tareas.

Cuando una implementación de servicio cambia de estado, Amazon ECS envía un evento de cambio de estado de implementación del servicio a EventBridge. Esto proporciona una forma programática de monitorear el estado de las implementaciones de servicios. Para obtener más información, consulte Eventos de cambio de estado de implementación de servicios de Amazon ECS. Recomendamos que cree y supervise una regla de EventBridge con un eventName de SERVICE_DEPLOYMENT_FAILED para que pueda tomar medidas manuales para iniciar la implementación. Para obtener más información, consulte Introducción a EventBridge en la Guía del usuario de Amazon EventBridge.

Cuando el disyuntor de implementación determina que una implementación tiene errores, este busca la implementación más reciente que se encuentre en un estado COMPLETED. Esta es la implementación que utiliza como implementación restaurada. Cuando se inicia la reversión, la implementación cambia de COMPLETED a IN_PROGRESS. Esto significa que la implementación no es apta para otra reversión hasta que alcance el estado COMPLETED. Cuando el disyuntor de implementación no encuentra ninguna implementación que esté en estado COMPLETED, no inicia nuevas tareas y la implementación se detiene.

Al crear un servicio, el programador hace un seguimiento de las tareas que no se pudieron iniciar en dos etapas.

  • Fase 1: el programador supervisa las tareas para comprobar si pasan al estado EN EJECUCIÓN.

    • Éxito: la implementación tiene posibilidades de pasar al estado COMPLETADO porque hay más de una tarea que ha pasado al estado EN EJECUCIÓN. Se omite el criterio de fallo y el disyuntor pasa a la fase 2.

    • Error: Por defecto, las tareas consecutivas que no pasan al estado EN EJECUCIÓN se tienen en cuenta al calcular el umbral de error (resetOnHealthyTask es true). Cuando resetOnHealthyTask es false, todos los errores de las tareas se acumulan independientemente de si se inician tareas en buen estado entre un fallo y otro.

  • Fase 2: la implementación entra en esta etapa cuando hay al menos una tarea en ejecución. El disyuntor comprueba las comprobaciones de estado de las tareas de la implementación actual que se están evaluando. Las comprobaciones de estado validadas son Elastic Load Balancing, las comprobaciones de estado del servicio AWS Cloud Map y las comprobaciones de estado de los contenedores.

    • Correcto: hay al menos una tarea en ejecución cuyas comprobaciones de estado se han superado.

    • Error: Las tareas que se reemplazan debido a errores en las comprobaciones de estado han alcanzado el umbral de error.

Tenga en cuenta lo siguiente cuando utilice el método del interruptor de implementación en un servicio. EventBridge genera la regla.

  • La respuesta de DescribeServices proporciona información sobre el estado de una implementación, el rolloutState y el rolloutStateReason. Cuando se inicia una nueva implementación, el estado de despliegue comienza en el estado IN_PROGRESS. Cuando el servicio alcanza un estado estable, el estado de implementación pasa a COMPLETED. Si el servicio no alcanza un estado estable y el interruptor está activado, la implementación pasará al estado FAILED. Una implementación en estado FAILED no lanzará ninguna tarea nueva.

  • Además de los eventos de cambio de estado de implementación del servicio que Amazon ECS envía para implementaciones que se han iniciado y completado, Amazon ECS también envía un evento cuando falla una implementación con interruptor activado. Estos eventos proporcionan detalles acerca de por qué falló una implementación o si se inició debido a una restauración. Para obtener más información, consulte Eventos de cambio de estado de implementación de servicios de Amazon ECS.

  • Si se inicia una nueva implementación porque se produjo un error en una implementación anterior y causó una restauración, el campo reason del evento de cambio de estado de implementación del servicio indica que la implementación se inició debido a una restauración.

  • El interruptor de implementación solo es compatible con los servicios de Amazon ECS que utilizan el controlador de implementación de actualización continua (ECS).

  • Debe utilizar la consola de Amazon ECS o la AWS CLI cuando utilice el interruptor de implementación con la opción CloudWatch. Para obtener más información, consulte Creación de un servicio a partir de los parámetros definidos y create-service en la Referencia de la AWS Command Line Interface.

En los siguientes ejemplos de la AWS CLI de create-service, se muestra cómo crear un servicio de Linux cuando se usa el interruptor de implementación con la opción de restauración.

aws ecs create-service \
     --service-name MyService \
     --deployment-controller type=ECS \
     --desired-count 3 \
     --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}" \
     --task-definition sample-fargate:1 \
     --launch-type FARGATE \
     --platform-family LINUX \
     --platform-version 1.4.0 \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"

En el siguiente ejemplo de AWS CLI create-service, se muestra cómo crear un servicio con una configuración de disyuntores de implementación personalizada que utiliza un recuento fijo de fallos de 5 y un seguimiento de los errores acumulados.

aws ecs create-service \
     --service-name MyService \
     --deployment-controller type=ECS \
     --desired-count 10 \
     --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true,resetOnHealthyTask=false,thresholdConfiguration={type=COUNT,value=5}}" \
     --task-definition sample-fargate:1 \
     --launch-type FARGATE \
     --platform-family LINUX \
     --platform-version 1.4.0 \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"

Ejemplo:

La implementación 1 está en estado COMPLETED.

La implementación 2 no puede iniciarse, por lo que el disyuntor vuelve a la implementación 1. La implementación 1 pasa al estado IN_PROGRESS.

La implementación 3 se inicia y no hay ninguna implementación en estado COMPLETED, por lo que la implementación 3 no puede revertir ni iniciar tareas.

Failure threshold

El interruptor de implementación utiliza un umbral de fallos para determinar cuándo mover una implementación a un estado FAILED. Puede configurar el modo en que se contabilizan los fallos y el propio valor umbral.

Modo de recuento de fallos

La configuración resetOnHealthyTask controla la forma en que el disyuntor cuenta los errores en las tareas durante una implementación.

true (predeterminado)

El recuento de errores se restablece a 0 cada vez que una tarea alcanza un estado de buen estado. Solo los errores consecutivos cuentan para el umbral. Este modo es útil para las aplicaciones que pueden experimentar errores de inicio intermitentes antes de estabilizarse.

false

Los fallos en las tareas se van acumulando a lo largo de la implementación. El recuento de errores nunca se restablece, aunque se inicien tareas en buen estado entre un fallo y otro. Este modo proporciona una detección más rápida cuando cualquier patrón de errores indica una implementación problemática.

Configuración de umbral

El ajuste thresholdConfiguration define cuándo se activa el disyuntor. Contiene un type que determina cómo se calcula el umbral y un value que especifica el porcentaje o el recuento que se utilizará.

BOUNDED_PERCENT (predeterminado)

Amazon ECS multiplica value por el último recuento de servicios deseado para calcular el umbral de error. El resultado se limita a un mínimo de 3 y un máximo de 200. Este es el tipo predeterminado, con un valor de 50.

UNBOUNDED_PERCENT

Amazon ECS multiplica value por el último recuento de servicios deseado para calcular el umbral de error. El resultado no tiene ningún límite mínimo ni máximo. Utilice este tipo para los servicios con grandes recuentos deseados que necesiten un umbral proporcional sin el límite de 200.

COUNT

Amazon ECS utiliza value directamente como umbral de error. El umbral permanece fijo independientemente del número de servicios deseado. Utilice este tipo cuando desee conocer el número exacto de errores tolerados, por ejemplo, un umbral más bajo para que las reversiones sean más rápidas en los entornos de desarrollo.

Para los tipos porcentuales (BOUNDED_PERCENT y UNBOUNDED_PERCENT), el rango válido de value es de 1 a 100. Durante una implementación, Amazon ECS utiliza de forma continua el último recuento de servicios deseado en sus cálculos.

Cómo BOUNDED_PERCENT calcula el umbral

Cuando utiliza el tipo de umbral BOUNDED_PERCENT por defecto, el disyuntor de implementación calcula el umbral mediante la siguiente fórmula.

Minimum threshold (3) <= (value/100) * desired task count => Maximum threshold (200)

Cuando el resultado del cálculo es inferior a 3, el umbral se establece en 3. Cuando el resultado es mayor a 200, el umbral se establece en 200. De lo contrario, el umbral se establece en el valor calculado (redondeado al alza).

En la siguiente tabla se presentan ejemplos del uso del valor predeterminado de 50.

Recuento deseado de tareas Cálculo Umbral

1

 
3 <= 0.5 * 1 => 200
 3 (el valor calculado es inferior al mínimo)

25

 
3 <= 0.5 * 25 => 200
 13 (el valor se redondea hacia arriba)

400

 
3 <= 0.5 * 400 => 200
 200 (el valor calculado es mayor que el máximo)

800

 
3 <= 0.5 * 800 => 200
 200 (el valor calculado es mayor que el máximo)

Con UNBOUNDED_PERCENT, se aplica el mismo cálculo, pero sin los límites mínimo y máximo. Por ejemplo, un servicio con un recuento deseado de 800 y un valor de 50 tendría un umbral de 400.

Hay dos etapas para la comprobación del estado de la implementación.

  1. El disyuntor de despliegue supervisa las tareas que forman parte de la implementación y comprueba las tareas que se encuentran en el estado RUNNING. El programador ignora los criterios de error cuando una tarea de la implementación actual se encuentra en el estado RUNNING y pasa a la siguiente etapa. Cuando las tareas no alcanzan en el estado RUNNING, el disyuntor de implementación aumenta el recuento de error en uno. Cuando el recuento de errores es igual al umbral, la implementación se marca como FAILED.

  2. Se entra en esta etapa cuando hay una o más tareas en el estado RUNNING. El disyuntor de implementación realiza comprobaciones de estado de los siguientes recursos para las tareas de la implementación actual:

    • Balanceadores de carga de Elastic Load Balancing

    • AWS Cloud MapServicio de

    • Comprobaciones de estado de los contenedores de Amazon ECS

    Cuando falla una comprobación de estado de la tarea, el disyuntor de implementación aumenta el recuento de errores en uno. Cuando el recuento de errores es igual al umbral, la implementación se marca como FAILED.

Por ejemplo, cuando el umbral es 3, el disyuntor comienza con el recuento de fallos establecido en 0. Cuando una tarea no alcanza el estado RUNNING, el disyuntor de implementación aumenta el recuento de error en uno. Cuando el recuento de errores es igual 3, la implementación se marca como FAILED.

Para obtener más ejemplos acerca de cómo usar la opción de restauración, consulte Anuncio del interruptor de cirtcuito de implementación de Amazon ECS.