En esta publicación, nos gustaría compartir los detalles de la interrupción del servicio que ocurrió en el norte de Virginia (US-EAST-1) el 25 de noviembre de 2020.
Amazon Kinesis recopila, procesa y analiza la transmisión de datos en tiempo real. Además del uso directo por parte de los clientes, participa en varios servicios de AWS. Estos servicios también sufrieron una interrupción. El desencadenante (pero no la razón principal) de este evento fue la adición relativamente pequeña de capacidad al servicio, que comenzó a las 2:44 a.m. PST y terminó a las 3:47 a.m.
Acerca del dispositivo Kinesis
Kinesis utiliza una gran cantidad de grupos de células "back-end" (células) que procesan flujos de datos. Estos son los caballos de batalla de Kinesis. Son responsables de la distribución, el acceso y el escalado de la transmisión. Los servidores de aplicaciones para el usuario distribuyen las transmisiones a los servidores de servicios de fondo mediante fragmentación. El clúster de backend "posee" muchos fragmentos y proporciona un escalado y aislamiento de fallas consistentes. El trabajo de front-end en nuestro caso es pequeño, pero importante. Es responsable de autenticar, limitar y enrutar las solicitudes a los fragmentos de subprocesos correctos en los clústeres de backend.
Estábamos agregando nuevas capacidades a la flota de máquinas frontales. Cada servidor de aplicaciones para el usuario crea una memoria caché de datos, incluida la información del propietario del fragmento y la membresía (entre los clústeres de back-end), formando un denominado mapa de fragmentos. Obtiene esta información enviando solicitudes al servicio que proporciona información de membresía y recuperando datos de configuración de DynamoDB.
Además, cada servidor procesa continuamente mensajes de otros servidores front-end de Kinesis. Para hacer esto, se crean subprocesos en el sistema operativo de cada máquina front-end para cada uno de los servidores front-end. Cuando se agregan nuevas capacidades, los servidores que ya están operando en el parque frontend aprenden acerca de los nuevos miembros y crean los flujos correspondientes. Cada servidor front-end existente tarda hasta una hora en conocer las máquinas nuevas.
Diagnóstico y resolución de problemas
A las 5:15 PST, aparecieron los primeros mensajes de error al escribir y recuperar registros de Kinesis. Nuestros equipos inmediatamente comenzaron a estudiar los registros. La sospecha recayó inmediatamente sobre las nuevas capacidades, pero algunos de los errores no tenían nada que ver con las nuevas máquinas y, muy probablemente, no habrían ido a ninguna parte, incluso si elimináramos todas las nuevas capacidades.
Sin embargo, como precaución, empezamos a eliminarlos, en el camino tratando de establecer la causa de otros errores. Su gran variedad ralentizó nuestro diagnóstico. Vimos errores en todos los aspectos de todo tipo de llamadas realizadas por miembros nuevos y existentes de la flota de front-end, y esto hizo que fuera bastante difícil separar los efectos secundarios de la causa raíz.
A las 7:51 a. M. PST, hemos reducido a los sospechosos a unos pocos candidatos y hemos determinado que cualquiera de las causas más probables requeriría un reinicio completo del front-end. El equipo de Kinesis sabía muy bien que este proceso debería ser lento y detallado.
El hecho es que llenar la tarjeta de fragmentos compite con el procesamiento de solicitudes entrantes para los recursos del servidor de aplicaciones para el usuario. Por lo tanto, volver a poner en línea los servidores front-end demasiado rápido creará un conflicto entre los dos procesos y dejará muy poco para procesar las solicitudes entrantes. El resultado es predecible: un aumento de las tasas de error y un aumento de las latencias. Además, los servidores front-end lentos pueden percibirse como un signo de mal estado, lo que puede hacer que se eliminen de la lista de servidores disponibles, lo que, a su vez, ralentizará aún más el proceso de recuperación.
Todas las posibles soluciones implicaron cambiar la configuración de cada servidor front-end y reiniciarlo. Si bien nuestro principal candidato para la fuente de nuestros problemas (un problema que parecía ejercer presión sobre la memoria) parecía prometedor, si nos equivocábamos corríamos el riesgo de duplicar el tiempo de recuperación, ya que tendríamos que volver a arreglar y reiniciar todo. Para acelerar el reinicio, en paralelo con la investigación, comenzamos a realizar cambios en la configuración de los servidores front-end, lo que le permite recibir datos directamente del almacén de metadatos en el momento del arranque, y no de los vecinos front-end.
razón principal
A las 9:39 p.m. PST, finalmente pudimos confirmar la causa raíz del bloqueo. Resultó que no está relacionado con la memoria. La adición de nuevas capacidades dio como resultado que el número de subprocesos en todos los servidores front-end excediera el máximo posible, permitido por la configuración del sistema. Debido a que se superó el límite, no se pudo crear la caché (tarjetas de fragmentos). Como resultado, los servidores de aplicaciones para el usuario no pudieron reenviar solicitudes a los clústeres de servicios de fondo.
No queríamos aumentar el límite de subprocesos en el sistema operativo sin pruebas preliminares, y dado que la capacidad adicional ya se había eliminado en ese momento, decidimos que el riesgo de exceder el límite del sistema en el número de subprocesos era mínimo y continuamos reiniciando los servidores. El primer grupo de frontends nuevos comenzó a aceptar tráfico de Kinesis a las 10:07 PST.
La flota de front-end consta de muchos miles de servidores y, por las razones descritas anteriormente, podríamos agregar servidores a una velocidad de no más de unos pocos cientos por hora. Continuamos agregando tráfico lentamente a la interfaz, notando una disminución constante en los errores de servicio de Kinesis desde el mediodía. El servicio se recuperó por completo a las 10:23 p.m. PST.
Que hemos aprendido
Hemos aprendido varias lecciones del incidente de Kinesis y estamos planeando hacer correcciones en un futuro cercano.
- , CPU . , , , . , . , .
- .
- , . , .
- -. - AWS ( CloudWatch) , -.
- (cellularization) ( , ). ( -) . Kinesis , , , . / , , .
El bloqueo también afectó a algunos servicios que utilizan Kinesis.
Amazon Cognito utiliza Kinesis Data Streams para recopilar y analizar patrones de acceso a la API. Si bien esta información es extremadamente útil para el funcionamiento del servicio Cognito, no se garantiza que se entregue (mejor esfuerzo) . Los datos se almacenan en búfer localmente para ayudar al servicio a hacer frente a la latencia o períodos cortos de indisponibilidad en el servicio Kinesis Data Streams.
Desafortunadamente, la prolongada falta de disponibilidad de Kinesis Data Streams reveló un error latente en el código de almacenamiento en búfer que hizo que los servidores web de Cognito comenzaran a bloquear los búferes de Kinesis Data Stream. Como resultado, los consumidores de Cognito enfrentaron fallas en la API y una mayor latencia para los grupos de usuarios y grupos de identidades de Cognito. Los usuarios externos no pudieron autenticarse ni obtener credenciales temporales de AWS.
En las primeras etapas de la interrupción, el equipo de Cognito intentó mitigar el impacto de los errores de Kinesis agregando capacidad adicional y, por lo tanto, aumentando las capacidades de almacenamiento en búfer de llamadas de Kinesis. Inicialmente, esto tuvo un efecto positivo en el servicio, pero a las 7:01 PST, la tasa de error había aumentado significativamente. Paralelamente, el equipo trabajó para reducir la dependencia de Cognito de Kinesis. A las 10:15 am, se implementó esta solución y la tasa de error comenzó a disminuir. A las 12:15 p. M., El número de errores había disminuido significativamente, ya las 2:18 p. M. PST, Cognito estaba funcionando normalmente. Para evitar que este problema vuelva a ocurrir, hemos modificado los servidores web de Cognito. Ahora pueden tolerar los errores de la API de Kinesis sin agotar sus búferes (lo que genera problemas para los usuarios).
CloudWatchutiliza Kinesis Data Streams para procesar métricas y registros. A partir de las 5:15 a.m., CloudWatch estaba experimentando errores y latencias cada vez mayores para las API PutMetricData y PutLogEvents, y las alertas se activaron
INSUFFICIENT_DATA. Si bien algunas métricas de CloudWatch continuaron procesándose durante la interrupción, la mayoría de ellas fueron víctimas de numerosos errores y una mayor latencia.
A las 5:47 p.m. PST, aparecieron los primeros signos de recuperación cuando la situación de Kinesis Data Stream mejoró, y a las 10:31 p.m. las métricas y alertas de CloudWatch se habían recuperado por completo. En las siguientes horas, continuó el procesamiento de métricas y registros retrasados. Mientras CloudWatch estaba luchando con errores, los clientes internos y externos no pudieron entregar datos de métricas a CloudWatch. Como resultado, existen lagunas en los datos de métricas de CloudWatch.
Por el momento, el servicio CloudWatch se basa en Kinesis para recopilar métricas y registros, pero su equipo pronto implementará un cambio, después del cual CloudWatch almacenará los datos durante tres horas en el almacenamiento local. Este cambio permitirá a los usuarios y servicios vinculados a las métricas de CloudWatch (incluido AutoScaling) acceder directamente a las métricas recién recopiladas (en el almacén de datos de CloudWatch local). Esta idea ya se implementó en la región US-EAST-1, y en las próximas semanas planeamos implementarla a nivel mundial.
Dos servicios más se convirtieron en rehenes de problemas con las métricas de CloudWatch:
- Primero, las políticas de AutoScaling basadas en métricas de CloudWatch experimentaron latencia hasta las 5:47 p.m., el punto en el que CloudWatch comenzó a recuperarse.
- -, Lambda. - CloudWatch. Lambda, , , CloudWatch . 6:15 PST , , -. : . 10:36 PST , .
CloudWatch Events y EventBridge experimentaron un aumento en los errores de API y la latencia en el procesamiento de eventos desde las 5:15 am ET. Después de mejorar la accesibilidad, Kinesis EventBridge reanudó la entrega de nuevos eventos a los destinatarios, procesando la acumulación de eventos en el camino.
Elastic Container Service (ECS) y Elastic Kubernetes Service (EKS) usan EventBridge en sus flujos de trabajo internos para administrar clústeres y tareas de clientes. Esto afectó el aprovisionamiento de nuevos clústeres, retrasó el escalado de los existentes y afectó el desaprovisionamiento de tareas. A las 4:15 p.m. PST, la mayoría de estos problemas se habían resuelto.
Notificacion al cliente
Además de las dificultades con los servicios, al comienzo del incidente, encontramos ciertos retrasos en la comunicación de información sobre el estado de los servicios a los clientes.
Tenemos dos formas de comunicarnos con los clientes durante los eventos operativos:
- Panel de estado del servicio : un panel de acceso público para alertar sobre problemas operativos importantes;
- Panel de salud personal : para notificar directamente a los clientes afectados.
Durante eventos como este, normalmente publicamos información en el Panel de estado del servicio. Sin embargo, en este caso, al comienzo del bloqueo, no pudimos actualizar la información en el Panel de estado del servicio, porque el Cognito bloqueado usa la herramienta que se usa para publicar actualizaciones.
Tenemos un método alternativo para actualizar el Panel de estado del servicio con dependencias mínimas del servicio. Funcionó según lo previsto, pero experimentamos algunos retrasos al publicar información en el Panel de estado del servicio al comienzo del evento. El punto es que esta herramienta de respaldo es mucho menos automatizada y menos familiar para los operadores del servicio de asistencia.
Para garantizar la entrega oportuna de actualizaciones a todos los clientes afectados, el equipo de soporte aprovechó el Panel de salud personal para alertarlos sobre posibles problemas de servicio. También colocamos un banner global con información actualizada en el Panel de estado del servicio para mantener a los usuarios lo más informados posible sobre el incidente. Hasta el final del bloqueo, continuamos usando una combinación de Service Health Dashboard (con resúmenes en banners globales y detalles sobre cómo funcionan los servicios específicos) y Personal Health Dashboard, donde tratamos de mantener actualizados a los clientes afectados por problemas con los servicios. Según nuestra experiencia, hemos introducido ejercicios obligatorios con un sistema alternativo para publicar mensajes en el Panel de estado del servicio en nuestra capacitación habitual de ingenieros de soporte.
...
Finalmente, me gustaría disculparme por el impacto negativo que este incidente ha tenido en nuestros clientes. Nos enorgullecemos de la alta disponibilidad de Amazon Kinesis y somos conscientes de la importancia que tienen este y otros servicios de AWS para nuestros clientes, sus aplicaciones / usuarios finales y sus negocios. Haremos todo lo posible para aprender de este incidente y utilizarlo para mejorar aún más la accesibilidad.
PD
Lea también en nuestro blog: