Postmortem de la caída de 73 horas de Roblox del año pasado

(blog.roblox.com)

16 puntos por outsideris 2022-01-31 | 1 comentarios | Compartir por WhatsApp

Resumen de la caída

La caída duró 72 horas
Hubo 2 causas raíz
- Al activar la nueva función de streaming de Consul en una situación con una carga de lectura/escritura anormalmente alta, se produjo una contención excesiva y degradación del rendimiento
- Se desencadenó un problema de rendimiento en BoltDB, el proyecto open source que Consul usa para administrar el write-ahead-log de la elección de líder y la replicación de datos bajo ciertas condiciones de carga
Un solo clúster de Consul agravó el impacto de estos problemas
La caída se prolongó porque tomó tiempo encontrar estos dos problemas aparentemente no relacionados, ocultos en la implementación de Consul
También fue más difícil encontrar la causa porque el sistema de monitoreo, que debía ofrecer mejor visibilidad sobre el origen de la caída, dependía de sistemas afectados como Consul

En ese momento, Roblox actualizó Consul de 1.9 a 1.10 para poder usar la función de streaming.

El 18 de octubre por la tarde, el rendimiento de Vault cayó y la carga de CPU de un servidor de Consul subió.

Aumentó la latencia de escritura en las métricas del clúster de Consul
Se sospechó inicialmente de una degradación de hardware y se empezó a reemplazar uno de los nodos del clúster de Consul
Personal de HashiCorp se sumó y empezaron a trabajar juntos
Incluso después del cambio de hardware, el rendimiento de Consul siguió cayendo y a las 16:35 la cantidad de jugadores bajó al 50% de lo normal
Como Consul se usaba para service discovery y Nomad y Vault también dependían de Consul, Consul era un SPoF.
En ese momento surgió una nueva hipótesis: que el tráfico era la causa. Se pensó que Consul ya no podía manejar la carga por el alto tráfico
Se reemplazaron todos los nodos del clúster de Consul por sistemas más potentes (el doble de núcleos, SSD NVME más rápidos)
La migración de Consul estaba casi terminada, pero el clúster no volvió a la normalidad

Se decidió volver a un snapshot del clúster de Consul previo a la caída
Se consideró aceptable que los datos de usuario estuvieran bien aunque se perdiera parte de los datos del sistema
Tras restaurar el snapshot, se bloqueó el acceso con iptables por temor a que la carga de los sistemas que seguían comunicándose con Consul causara problemas después de la recuperación
Después de restaurar el snapshot, los indicadores parecían buenos, pero al quitar el bloqueo de iptables se volvió al mismo estado de falla anterior

Se bloqueó el tráfico externo y se eliminaron usos no esenciales, reduciendo servicios que corrían en cientos de instancias a solo una cantidad de un dígito
Se intentó recuperar el servicio otra vez, pero Consul volvió a quedar en un estado anormal
Se entendió que había algo más además del factor de degradación de rendimiento que se había supuesto al principio, y se empezó a mirar dentro de Consul en sí, no solo desde la perspectiva de Roblox

Después de 10 horas más de análisis, se descubrió que las escrituras en Consul quedaban bloqueadas durante largos periodos
Aunque no se conocía la causa de la contención, se concluyó que el cambio inicial de CPU de 64 a 128 núcleos la había empeorado aún más
Se decidió volver a 64 núcleos, pero no ayudó

La función de streaming de Consul ya estaba activada desde meses antes y se estaba implementando gradualmente porque había reducido el uso de CPU y el ancho de banda de red.
El día antes de la caída, el 27 a las 14:00, esta función se activó en el backend de enrutamiento de tráfico.
Como se había activado el día anterior y parecía funcionar bien, no se pensó en ella como causa
Tras analizar el rendimiento, se confirmó evidencia de que el código de streaming estaba provocando alto uso de CPU
Se desactivó el streaming y, una vez completado el despliegue, se confirmó que la latencia de escritura KV de Consul disminuyó (¡por fin!)
HashiCorp explicó que, aunque el streaming es más eficiente, en su implementación se usaron menos elementos de control de concurrencia (canales de Go) que con long polling -> bajo alta carga, la contención en un solo canal de Go empeoró y redujo la eficiencia
Hubo un avance, pero todavía se detectaban elecciones de líder intermitentes, y algunos líderes seguían mostrando problemas de latencia similares a los anteriores
Bajo la premisa de que el clúster estaría normal siempre que no se eligieran ciertos líderes, se enfocaron en devolver el servicio a un estado normal
Después, HashiCorp siguió investigando la causa raíz y descubrió que el problema de lentitud de algunos líderes se debía a BoltDB

Tras 54 horas de caída, ya estaban listos para recuperar el servicio
Durante la caída, la base de datos estuvo bien, pero el sistema de caché que procesa mil millones de solicitudes por segundo estaba en un estado anormal.
Después de restaurar esta caché y confirmar que estaba normal, ya habían pasado 61 horas desde el inicio de la caída.

El día 31 a las 5 empezaron a preparar el regreso del servicio y terminaron a las 10.
Se fue aumentando gradualmente la cantidad de jugadores que accedían mediante DNS mientras se monitoreaba la situación
Después de 73 horas, todos los jugadores pudieron volver a acceder.

HashiCorp y Roblox desarrollaron un proceso de "compresión" para resolver el problema de rendimiento
Mejora de telemetría: había una dependencia circular entre el sistema de telemetría y Consul, por lo que cuando Consul tenía problemas faltaban datos. Se eliminó esa dependencia circular para que el sistema de telemetría no dependa de los sistemas que monitorea
Expansión de zonas de disponibilidad y centros de datos
Limpieza de datos KV innecesarios y de datos almacenados en Consul aunque existían otros almacenamientos disponibles.
Se está probando una nueva versión de Consul que reemplaza BoltDB por su sucesor, bbolt
Como el proceso de bootstrap retrasó la recuperación, se está automatizando y se están desarrollando nuevas herramientas y procesos

xguru 2022-02-01

Gracias por la traducción.

Una caída de 72 horas a esa escala de verdad da miedo.