Desde hace un par semanas que en Get on Board teníamos problemas de timeouts con las máquinas en cada deploy o restart que tenía nuestra app. Estos eventos sólo parecía solucionarse si forzábamos un nuevo restart.
Métricas básicas de Heroku
Cuando nos enfrentamos a uno de estos eventos, lo primero que hicimos fue dar una mirada general en las gráficas que te muestra Heroku, ver si había problemas de RAM, CPU u otra cosa. La DB y la memoria RAM lucían bien, pero la carga de los dynos y Puma estaban por los cielos. Ni hablar del throughput, el cual fue la primera pista que realmente nos decía algo. Se estaban realizando muchísimas transacciones que no se estaban resolviendo.
Los logs son el oráculo
Si hay una ley que me he impuesto desde que empecé en serio en la informática es que: los logs son el oráculo. Ellos son la única y mejor fuente de la verdad en prácticamente el 100% de las situaciones.
Cuando localizamos los logs en el horario del incidente, vimos que inmediatamente después del reinicio de los dynos aparecían largas listas de errores por peticiones de Action Cable no resueltas.
Notificaciones con Action Cable
En Get on Board tanto empresas como profesionales son usuarios que están siendo notificados constantemente de la actividad que ocurre dentro de un proceso de contratación. Cuando un usuario está en el browser, estas notificaciones son disparadas en tiempo “real” porque se está preguntando al backend “¿Ha pasado algo que deba notificar?”.
Es precisamente esa consulta la que estaba quedando colgada cada vez que un usuario tenía su sesión abierta en el browser mientras se realizaba el reinicio de los dynos.
La solución
Una revisión rápida de nuestra arquitectura y los servicios que incluye nuestro plan nos abrió los ojos del uso de Preboot, un servicio en el que Heroku se hace cargo de todo para levantar tu stack antes de apagar el que tienes en funcionamiento y garantizar un downtime prácticamente nulo.
Por supuesto esto tiene algunas desventajas, como que al realizar un deploy tus usuarios tardarán un par de minutos en recibir la última versión del código, pero creo que es algo con lo que la mayoría podemos vivir a cambio de mejorar el uptime.
La configuración es brutalmente fácil, dos lineas de comando, una para confirmar si tienes instalado este servicio y otro para habilitarlo.
Un poco de estrés para probar la solución
Una vez instalado el Preboot realizamos nuevamente el experimento de reiniciar los dynos mientras varios usuarios fantasmas estuvieran activos. Las peticiones de Action Cable dejaron de quedar “huérfanas” y la app se mantenía estable con un 100% de uptime.
¿Moraleja?
El 100% uptime y tener deploys o reinicios transparentes para tus usuarios no es un lujo que sólo se deban dar las compañias con millones de usuarios o que sea algo exclusivamente reservado para arquitecturas complejas. Downtime significa una mala experiencia para tus usuarios y en este caso también fue una ventana para que el problema se agrandara y esa mala experiencia se multiplicara.
Latest on Blog
