Reducción del MTTR - Disponibilidad y más allá: Descripción y mejora de la resiliencia de los sistemas distribuidos en AWS

Reducción del MTTR

Una vez detectado un error, lo que queda de tiempo medio de reparación o de recuperación (MTTR) se destina a la reparación real o a la mitigación del impacto. Para reparar o mitigar un error, hay que saber qué es lo que está mal. Hay dos grupos clave de métricas que proporcionan información durante esta fase: 1/las métricas de evaluación del impacto y 2/las métricas del estado operativo. El primer grupo indica el alcance del impacto durante un error y mide el volumen o el porcentaje de clientes, recursos o cargas de trabajo afectados. El segundo grupo ayuda a identificar por qué se produce un impacto. Una vez identificado el motivo, los operadores y sistemas de automatización pueden responder al error y solucionarlo. Consulte Apéndice 1: Métricas fundamentales del MTTD y el MTTR para obtener más información sobre estas métricas.

Regla 9

La observabilidad y la instrumentación son fundamentales para reducir los tiempos medios de detección y de recuperación (MTTD y MTTR, respectivamente).

Cómo sortear los errores

El enfoque más rápido para mitigar el impacto es mediante subsistemas que responden rápido a los errores y los sortean. Este enfoque utiliza la redundancia para reducir el MTTR al trasladar rápidamente el trabajo de un subsistema con errores a uno de repuesto. La redundancia puede abarcar desde procesos de software hasta instancias de EC2, múltiples zonas de disponibilidad (AZ) y múltiples regiones.

Los subsistemas de repuesto pueden reducir el MTTR prácticamente a cero. El tiempo de recuperación es lo único que se necesita para redirigir el trabajo al equipo de reserva o de repuesto. Esto suele ocurrir con una latencia mínima y permite que el trabajo se complete dentro del acuerdo de nivel de servicio (SLA) definido, manteniendo la disponibilidad del sistema. Esto produce retrasos leves, incluso imperceptibles, en lugar de períodos prolongados de falta de disponibilidad.

Por ejemplo, si su servicio utiliza instancias de EC2 detrás de un equilibrador de carga de aplicación (ALB), puede configurar las comprobaciones de estado en un intervalo de tan solo cinco segundos y requerir solo dos comprobaciones de estado fallidas antes de que un objetivo se marque como en mal estado. Esto significa que, en 10 segundos, se puede detectar un error y dejar de enviar tráfico al host en mal estado. En este caso, el MTTR es prácticamente el mismo que el MTTD, ya que tan pronto como se detecta el error, también se mitiga.

Esto es lo que intentan lograr las cargas de trabajo de alta disponibilidad o disponibilidad continua. Queremos sortear rápidamente los errores en la carga de trabajo mediante la detección rápida de los subsistemas con errores, los marcamos como tal, dejamos de enviarles tráfico y, en su lugar, lo enviamos a un subsistema redundante.

Tenga en cuenta que el uso de este tipo de mecanismos que responden rápido a los errores hace que la carga de trabajo sea muy sensible a los errores transitorios. En el ejemplo que mostramos, asegúrese de que las comprobaciones de estado del equilibrador de carga se realicen de forma superficial o de manera dinámica y local para solamente la instancia, y de que las pruebas no se lleven a cabo para dependencias y flujos de trabajo (a menudo denominadas comprobaciones de estado exhaustivas). Esto ayudará a evitar la sustitución innecesaria de instancias durante errores transitorios que afecten a la carga de trabajo.

La observabilidad y la capacidad de detectar errores en los subsistemas son fundamentales para evitarlos de manera satisfactoria. Hay que conocer el alcance del impacto para que los recursos afectados puedan marcarse como en mal estado o con errores, y que queden fuera de servicio para poder sortearlos. Por ejemplo, si una única AZ sufre una interrupción parcial del servicio, su instrumentación deberá poder identificar que existe un problema localizado en la AZ para poder distribuir todos los recursos de esa AZ hasta que se recupere el servicio.

Ser capaz de sortear un error también puede requerir herramientas adicionales en función del entorno. Si utilizamos el ejemplo anterior, en el que las instancias de EC2 se encuentran detrás de una ALB, imagine que las instancias de una AZ están pasando las comprobaciones de estado locales, pero un error aislado de la AZ hace que no puedan conectarse a su base de datos en una AZ diferente. En este caso, las comprobaciones de estado del equilibrio de carga no dejarán esas instancias fuera de servicio. Se necesitaría un mecanismo automatizado diferente para eliminar la AZ del equilibrador de carga o forzar que las instancias no superen las comprobaciones de estado, lo que depende de haber identificado que el alcance del impacto es una AZ. En el caso de las cargas de trabajo que no utilizan un equilibrador de carga, se necesitaría un método similar para evitar que los recursos de una AZ específica acepten unidades de trabajo o eliminen completamente la capacidad de la zona.

En algunos casos, el traslado del trabajo a un subsistema redundante no se puede automatizar, como la conmutación por error de una base de datos principal a una secundaria, en la que la tecnología no elige a su propio líder. Este es un escenario común en las arquitecturas de varias regiones de AWS. Dado que estos tipos de conmutación por error requieren cierto tiempo de inactividad, no se pueden revertir de forma inmediata y dejan la carga de trabajo sin redundancia durante un período de tiempo, es importante contar con una persona que participe en el proceso de toma de decisiones.

Las cargas de trabajo que pueden adoptar un modelo de coherencia menos estricto pueden lograr un MTTR más corto si utilizan la automatización de la conmutación por error de varias regiones para evitar los errores. Características como la replicación entre regiones de Amazon S3 o las tablas globales de Amazon DynamoDB brindan prestaciones de varias regiones a través de una replicación eventualmente coherente. Además, si tenemos en cuenta el teorema CAP, es beneficioso utilizar un modelo de coherencia relajado. Cuando se producen errores de red que afectan a la conectividad con los subsistemas activos, si la carga de trabajo elige la disponibilidad en lugar de la coherencia, puede seguir proporcionando respuestas sin errores, lo que supone otra forma de sortear los errores.

Los errores pueden sortearse con dos estrategias diferentes. La primera estrategia consiste en implementar la estabilidad estática mediante el aprovisionamiento previo de recursos suficientes para gestionar toda la carga del subsistema con errores. Puede tratarse de una única instancia de EC2 o de toda la capacidad de una AZ. Tratar de aprovisionar nuevos recursos durante un error aumenta el MTTR y se añade una dependencia al plano de control en la ruta de recuperación. Sin embargo, conlleva un costo adicional.

La segunda estrategia consiste en enrutar parte del tráfico del subsistema con errores a otros y desbordar la carga con el exceso de tráfico que no pueda ser gestionado por la capacidad restante. Durante este período de degradación, se pueden escalar verticalmente nuevos recursos para sustituir la capacidad fallida. Este enfoque tiene un MTTR más prolongado y crea una dependencia de un plano de control, pero cuesta menos si se trata de capacidad de reserva y en espera.

Vuelta a un estado válido conocido

Otro enfoque habitual de mitigación durante la reparación consiste en devolver la carga de trabajo a un estado válido conocido anterior. Si un cambio reciente pudo haber provocado el error, revertir ese cambio es una forma de volver al estado anterior.

El error también podría deberse a condiciones transitorias, en cuyo caso, reiniciar la carga de trabajo podría mitigar el impacto. Vamos a analizar ambos escenarios.

Durante una implementación, minimizar el MTTD y el MTTR se basa en la observabilidad y la automatización. El proceso de implementación debe vigilar continuamente la carga de trabajo para detectar la introducción de un aumento en los índices de error, un aumento de la latencia o la aparición de anomalías. Una vez se detectan estos problemas, el proceso de implementación debería interrumpirse.

Existen varias estrategias de implementación, como las implementaciones locales, las implementaciones azules/verdes o las implementaciones continuas. Cada una de ellas puede utilizar un mecanismo diferente para volver a un estado válido conocido. Puede restaurar automáticamente el estado anterior, devolver el tráfico al entorno azul o requerir una intervención manual.

CloudFormation ofrece la capacidad de restaurar automáticamente como parte de sus operaciones de creación y actualización de pilas, al igual que lo hace AWS CodeDeploy. CodeDeploy también admite implementaciones continuas y azules/verdes.

Para aprovechar estas capacidades y minimizar el MTTR, plantéese la posibilidad de automatizar todas las implementaciones de código e infraestructura a través de estos servicios. En los casos en los que no pueda utilizar estos servicios, considere la posibilidad de implementar el patrón saga con AWS Step Functions para restaurar las implementaciones con errores.

A la hora de plantearse el reinicio, existen varios enfoques diferentes. Estos van desde reiniciar un servidor (la tarea más larga) hasta reiniciar un subproceso (la tarea más corta). Esta tabla describe algunos de los métodos de reinicio y los tiempos aproximados para completarlos (representativos de diferencias de órdenes de magnitud; no son exactos).

Mecanismo de recuperación de errores MTTR estimado
Iniciar y configurar un servidor virtual nuevo 15 minutos
Reimplementar el software 10 minutos
Reiniciar el servidor 5 minutos
Reiniciar o iniciar el contenedor 2 segundos
Invocar una nueva función sin servidor 100 ms
Reiniciar el proceso 10 ms
Reiniciar el subproceso 10 μs

Al revisar la tabla, el uso de contenedores y funciones sin servidor ofrece algunas ventajas claras para el MTTR (por ejemplo, AWS Lambda). Su MTTR es más rápido que reiniciar una máquina virtual o iniciar una nueva. Sin embargo, utilizar el aislamiento de errores mediante la modularidad del software también conlleva una serie de ventajas. Si puede contener un error en un solo proceso o subproceso, recuperarse de ese error es mucho más rápido que reiniciar un contenedor o un servidor.

Como enfoque general para la recuperación, puede ir de abajo a arriba: 1/Reiniciar un componente, 2/Reiniciar el sistema completo, 3/Reinstalar imagen/Reimplementar, 4/Reemplazar. Sin embargo, una vez completado el proceso de reinicio del sistema completo, la solución al error suele ser más rápida (normalmente tarda entre 3 y 4 minutos como máximo). Por lo tanto, para mitigar el impacto de la forma más rápida posible tras un intento de reinicio, sortee el error y, en segundo plano, continúe con el proceso de recuperación para recuperar la capacidad de la carga de trabajo.

Regla 10

Concéntrese en la mitigación del impacto, no en la solución del problema. Recupere el funcionamiento normal por la vía más rápida.

Diagnóstico de errores

Parte del proceso de reparación después de la detección es el período de diagnóstico. Es el período de tiempo en el que los operadores tratan de determinar qué es lo que está mal. Este proceso puede implicar consultar registros, revisar métricas del estado operativo o iniciar sesión en los hosts para solucionar problemas. Todas estas medidas requieren tiempo, por lo que crear herramientas y manuales de procedimientos para agilizarlas también puede ayudar a reducir el MTTR.

Manuales de procedimientos y automatización

Del mismo modo, después de determinar qué es lo que está mal y qué medidas tomar para reparar la carga de trabajo, los operadores suelen tener que realizar una serie de pasos para completar el proceso. Por ejemplo, después de un error, la forma más rápida de reparar la carga de trabajo puede ser reiniciarla, lo que puede implicar varios pasos ordenados. El uso de un manual de procedimientos que automatice estos pasos o proporcione instrucciones específicas al operador agilizará el proceso y ayudará a reducir el riesgo de que se tomen medidas involuntarias.