Resumen

  • La ampliación de los servidores frontales de Kinesis hizo aumentar los hilos de comunicación de los servidores existentes, hasta superar el máximo configurado en el sistema operativo.
  • Reconstruir la información de encaminamiento competía con atender peticiones. La recuperación tuvo que admitir servidores poco a poco, aunque las máquinas ya estaban disponibles.

Entre las soluciones que AWS anunció tras la caída de Kinesis había una con poco atractivo para una presentación comercial: usar máquinas más potentes para necesitar menos servidores. En aquella flota, tener menos vecinos era una ventaja.

El 25 de noviembre de 2020, en Virginia del Norte, una ampliación relativamente pequeña había desencadenado el problema. Según el informe de AWS, toda la flota de servidores frontales superó un máximo de hilos establecido en la configuración del sistema operativo. La empresa distinguió el detonante —añadir capacidad— de la causa que lo convirtió en avería.

La distinción importa al comprar. El servidor nuevo trae capacidad de cálculo, pero también puede traer encargos para todos los que ya están trabajando. Conviene descontarlos antes de dar por buena la suma.

La lista de compañeros se hizo demasiado larga

Kinesis repartía el procesamiento de los flujos entre grupos de servidores organizados en células. Delante, otra flota autenticaba las solicitudes, regulaba su ritmo y las enviaba a las particiones correctas. Cada frontal guardaba un mapa con los miembros y las asignaciones de esas particiones.

Para mantenerlo, obtenía información de varios lugares, incluidos los mensajes de otros frontales. Cada servidor creaba hilos del sistema operativo para comunicarse con los demás miembros. Cuando llegaban máquinas nuevas, las antiguas tenían que reconocerlas y preparar la comunicación. Ese reconocimiento podía tardar hasta una hora.

Así, terminar la instalación y terminar de absorber su coste eran momentos distintos. Al agotarse los hilos, la construcción de los mapas dejaba de completarse. Había capacidad de procesamiento detrás, pero los encargados de repartir las peticiones se habían quedado sin un mapa utilizable.

Las células del procesamiento no encerraban por arte de magia el trabajo compartido en la entrada. Una frontera de aislamiento protege lo que queda dentro de ella. Un nombre tranquilizador en un esquema no amplía esa frontera.

Había máquinas; faltaba velocidad para reincorporarlas

AWS retiró la capacidad añadida. Tampoco quiso elevar el límite del sistema operativo sin hacer más pruebas. Una vez reducido el número de participantes, empezó el trabajo de reiniciar los frontales.

Pero reconstruir sus mapas y atender las peticiones de los clientes consumía los mismos recursos. Si volvían demasiados servidores a la vez, podían responder despacio, ser considerados defectuosos y quedar expulsados de nuevo. La prisa podía reducir el servicio recuperado.

El equipo cambió el arranque para obtener los datos directamente del almacén de metadatos de referencia, en vez de apoyarse en los vecinos. La flota tenía muchos miles de servidores; solo podían regresar unos cientos por hora. El primer grupo volvió a recibir tráfico a las 10:07, hora estándar del Pacífico. Kinesis recuperó su funcionamiento normal a las 22:23, con una reducción progresiva de errores durante la restauración.

Aquí aparece una capacidad que no suele ocupar la primera diapositiva: cuánta infraestructura puede volver a trabajar por unidad de tiempo. Encontrar el defecto no la devuelve de golpe. Corregirlo tampoco.

La recuperación además llega con compañía. Hay peticiones nuevas, trabajo pendiente y datos operativos por reconstruir. Una prueba de rendimiento con todo ya preparado puede dar un resultado excelente y dejar sin respuesta el problema de reunir otra vez esas condiciones.

Los servicios auxiliares se sentaron en la puerta

Cognito utilizaba Kinesis para analizar patrones de acceso a sus interfaces. El diseño contemplaba interrupciones temporales de la transmisión y disponía de un búfer local. La interrupción prolongada activó un fallo latente del código del búfer: la acumulación bloqueó servidores web. Algunos usuarios ya no podían autenticarse u obtener credenciales temporales.

El mecanismo destinado a observar la actividad había terminado frenando la actividad. El búfer había proporcionado un margen, pero su comportamiento una vez lleno decidía si ese margen era una separación eficaz o una espera antes del bloqueo.

CloudWatch también tuvo problemas al procesar métricas y registros. Algunas alarmas pasaron a indicar falta de datos, y las políticas reactivas de Auto Scaling que usaban esas métricas sufrieron retrasos. En Lambda, el almacenamiento temporal de métricas creó contención de memoria en los equipos de ejecución y aumentó los errores. Cada servicio llegó a su propio límite a través de la misma dependencia.

Hasta la herramienta habitual para publicar el estado de los servicios dependía de Cognito. La alternativa con menos dependencias funcionaba; el manejo más manual y menos familiar retrasó los primeros avisos. Un plan de respaldo también necesita personas que sepan utilizarlo sin estar aprendiendo durante la avería.

La factura de coordinar

AWS anunció más capacidad de CPU y memoria por máquina para reducir el número total de frontales y, con él, los hilos que cada uno debía mantener. Añadió vigilancia más detallada de su consumo, pruebas para elevar el límite y mejoras del arranque. Separar la caché, particionar los frontales de algunos grandes servicios y acelerar la organización de la entrada en células buscaba reducir lo que todos compartían.

La lista retrata bien el problema económico. Una parte de la inversión compra recursos; otra compra límites a las tareas que esos recursos se exigen mutuamente. Si la carga compartida crece con la flota, un servidor puede traer menos capacidad útil de la que anuncia su ficha.

La explicación de estabilidad estática de AWS propone que un servicio pueda seguir funcionando cuando falla una dependencia. Su documento sobre tolerancia y aislamiento de fallos recoge también el coste de reservar recursos de antemano. El margen ocioso tiene dueño y presupuesto. La espera durante una recuperación también, aunque la factura llegue al cliente.

El informe histórico no aporta los límites actuales de la flota ni una prueba reciente de reinicio completo. Una prueba con sus condiciones publicadas permitiría juzgar el presente. El episodio de 2020 ya permite exigir una respuesta concreta: además de cuántas solicitudes soporta el servicio, a qué velocidad puede volver a soportarlas.