Investigación incidencia 06/01/2020
El problema
El día lunes 6 de enero del 2020 tuvimos una incidencia de aproximadamente 1 hora y 15 minutos entre las 10:41 y las 11:56. Desde fines de diciembre estamos en proceso de un profundo cambio de la infraestructura de Sytex. Actualmente, todos los requests de nuestros usuarios hacia Sytex, se atienden desde la nueva infraestructura, pero lamentablemente hay algunos casos donde la infraestructura tiene que escalar para atender las crecientes solicitudes y todavía estamos estabilizando estos procesos de escalado.
Sytex corre sobre un cluster de kubernetes en AWS. El servicio para cada uno de nuestros clientes se distribuye en el cluster de acuerdo a reglas de escalado, cada uno aislado a través de espacios de nombres de kubernetes.
El día de la incidencia, notamos un incremento considerable en la cantidad de respuestas HTTP 404 que se estaban emitiendo para uno de nuestros servicios. Un error 404 significa que el recurso que el usuario está solicitando no existe. Esto se puede dar por diferentes razones:
- El recurso fue eliminado y el cliente aún no tiene la versión actualizada
- Hay un error en la dirección del recurso que se está solicitando
- El usuario no tiene acceso al recurso solicitado
Muchas veces estos errores se dan naturalmente por las razones mencionadas, pero en este caso, el volumen de errores era llamativo e investigamos cuál era la razón.
El síntoma
Usamos datadog para monitorear todos nuestros servicios, tanto la infraestructura (hardware, cluster, contenedores y procesos) como la aplicación (tiempos que demora, consultas a las bases de datos, logs de todas las capas de la aplicación). Al recibir los reportes de que la aplicación estaba funcionando con problemas, analizamos los logs y encontramos el incremento atípico de errores 404.
Revisamos los logs de errores 404 que se estaban presentando.
Inmediatamente notamos que los errores se producían en el mismo nodo y en el mismo pod. Esto era consistente con los reportes de nuestros usuarios, de que los errores se presentaban de una manera "aleatoria". La aleatoriedad se debía a que solo se presentaba, si el balanceador de carga destinaba ese request a ese pod específico que estaba en falta.
Para intentar restablecer el servicio lo antes posible, borramos el pod que generaba el inconveniente, lo que obliga a kubernetes a generar un nuevo pod en el mismo deploy para mantener los parámetros de escalado.
Esta decisión restableció el servicio a su funcionamiento habitual, pero nos limitó en el troubleshooting post-mortem que podíamos hacerle al pod en falla.
De todas formas revisamos en detalle los logs del momento donde comenzó a ocurrir la incidencia. Encontramos que en un momento dado, el pod perdió la resolución de nombres interna del motor de base de datos. Esto hizo que cuando los workers del nodo se reiniciaron (lo hacen bajo condiciones establecidas para liberar memoria), no registraron las rutas.
Aún nos queda por encontrar la causa raíz por la que el pod perdió la capacidad de resolver el nombre interno del motor de base de datos, pero esto ya nos da una pista de acciones que podemos tomar para evitar el problema en el futuro.
Incidencia para los usuarios
¿Que significó esta incidencia para los usuarios de Sytex? Los usuarios de escritorio recibieron errores "aleatorios" (en la medida que el request era atendido por el pod afectado). Muchos de los errores de Sytex son genéricos y el usuario final no puede notar la diferencia entre un error 404 y otro tipo de error HTTP.
Los usuarios de la app móvil tuvieron dificultades principalmente para sincronizar respuestas de formularios. Si el request para atender la respuesta era atendido por el pod afectado, la respuesta terminaba en un error y el usuario podía ver el error como pendiente en la cola de sincronización.
Acciones tomadas y próximos pasos
Luego de restablecer el servicio, el primer paso fue agregar un monitor para detectar lo antes posible si se presenta una situación similar, junto con un gráfico para observar la evolución en nuestro tablero de control.
Estamos revisando si nuestra decisión de evitar la creación de rutas cuando existe un error con la conexión a la base de datos es correcta y la podemos modificar para que el error sea mas visible.
La sospecha principal con respecto a la pérdida de resolución de nombres es que en ocasiones de alto consumo de CPU, el cluster está limitando los recursos de coreDNS, que utilizamos para la resolución interna de nombres. Estamos trabajando con nuestro partner DinoCloud para ajustar los parámetros de recursos y escalado de la infraestructura de Sytex para que opere de la mejor manera.
Queremos pedir disculpas a nuestros usuarios por los inconvenientes y confirmar nuestro compromiso de trabajar para que Sytex sea cada vez mas robusto y ser un soporte confiable de la operación de nuestros clientes y usuarios.