Get on Board no es un servicio gratis, así que lo mínimo que podemos hacer es ofrecer un SLA decente a nuestros clientes. El sábado sufrimos una caída de aproximadamente tres horas 🤦♂️, y si bien el incidente fue originado en el proveedor de nuestro proveedor[1] el haber tenido una arquitectura mínima de alta disponibilidad podría haber ayudado a sobrevivir la caída o al menos a una rápida recuperación. Hacemos mea culpa de haber descuidado ciertos aspectos en nuestra arquitectura para “garantizar” esto y en respuesta hicimos cambios dentro del limitado presupuesto que tenemos 💪.
El nuevo stack consiste en:
- 2 dynos web (Performance-M). Antes era un solo dyno tipo Performance-L. El cambio a dos dynos aumenta los chances de tener redundancia — no lo garantiza — al aumentar la probabilidad de que corran en diferente infraestructura física, dígase zona AWS.
- 1 dyno worker (2X). No le hicimos modificaciones pues no es un componente crítico. Este worker corre las tareas en background que pueden quedar guardadas en la base de datos redis mientras el dyno se recupera de la caída.
- Heroku Postgres HA. Nos mudamos a uno de los planes que brinda alta disponibilidad y mecanismo de auto-failover.
- Redis con alta disponibilidad y mecanismo de auto-failover. Acá no hicimos cambios pues ya el plan actual lo brinda.
- Cluster MemCache con alta disponibilidad. Acá tampoco hicimos cambios.
El nuevo cambio no garantiza 100% de disponibilidad (ni siquiera gigantes como AWS o Google Cloud pueden), pero esperamos que mitigue las caídas o nos permita una recuperación más rápida.
Como siempre felices de leer si tienes alguna sugerencia. Mándalas via comentario o correo a team at getonbrd dot com 🤗
**********************
[1] La cosa partió por problemas de conectividad en instancias EC2 y RDS en la zona AWS de N. Virginia / U.S que provocó las caídas en algunos dynos y servicios (entre ellos postgres) de Heroku deployados en esa zona.
Lo más reciente en Blog
