Empecemos con lo que significa exactamente 4 9’s:

Cuatro nueves son 4,38 minutos de inactividad al mes, o 52,56 minutos al año.

Eso es probablemente más que aceptable para casi todos los servicios en Internet, no todos, pero casi todos. Así que tu correo electrónico se cae durante 4 minutos cada mes, no es el fin del mundo. Es decir, probablemente ni siquiera lo notarías. En el momento en que fueras a comprobar Twitter para ver si eres tú o no, estaría de nuevo en funcionamiento.

Típicamente, para conseguir un buen tiempo de actividad, pensamos en añadir redundancia y replicación, de modo que si un servidor falla, ya tienes otros en funcionamiento que se hacen cargo inmediatamente. El problema con este enfoque es que es complicado y caro. Se necesitan varios servidores, normalmente 3 o más, tanto para la aplicación como para la base de datos, además de un equilibrador de carga. Y luego tienes que gestionar/monitorear todas esas máquinas.

Y con la nueva tendencia de Microservicios donde la gente está dividiendo sus aplicaciones en servicios más pequeños, tienes que repetir estas complicadas configuraciones para cada servicio.

Si estás construyendo un Microservicio, cuanto menos «cosas» necesites para ejecutarlo, mejor. No quieres tener que ir a configurar una nueva base de datos replicada cada vez que quieras montar una pequeña API ¿verdad? Quiero ser súper productivo, quiero ser capaz de crear un servicio rápidamente sin tener que lidiar con todas las cosas complicadas y que hacen perder el tiempo.

Así que me puse a pensar, «bueno, ¿y si hay una manera de ser… lo suficientemente fiable?» Quiero decir, ¿cuántas de las cosas que construyes realmente necesitan estar altamente disponibles? ¿Cuántos servicios no pueden permitirse el lujo de estar fuera de servicio durante unos minutos aquí y allá o perder un poco de datos de vez en cuando debido a un fallo fatal del servidor? Incluso si usted arquitecto el infierno fuera de su servicio, es probable que todavía tiene el tiempo de inactividad de todos modos por alguna razón. Así que por qué no mantenerlo simple.

Primero, algunos números: digamos que en promedio, una instancia de AWS EC2 falla cada seis meses. Creo que es mucho menos que eso hoy en día, pero nadie lo sabe realmente, así que seremos conservadores. Eso nos da aproximadamente 26,5 minutos para recuperar la aplicación cada seis meses, mientras que todavía tiene 4 9 de tiempo de actividad.

Aquí es cómo se puede obtener 4 9 en una sola máquina.

Paso 1) Lanzamiento del servidor, despliegue de la aplicación y cambio de DNS Script

Lo primero que necesitamos es un simple script que puede lanzar una nueva instancia, iniciar la aplicación (Docker hace esto fácil) y cambiar los DNS para apuntar a la nueva instancia. No voy a entrar en detalles sobre este paso en este post, pero si usted puede hacer un script de una línea que puede hacer esos pasos, usted es bueno. Service fails: run script.

Paso 2) Base de datos con Auto Backup y Auto Recover

Si puedes asegurarte de que tienes copias de seguridad muy recientes de tu base de datos y que están almacenadas en una ubicación de fácil acceso como S3, entonces puedes crear una app que pueda recuperarse a sí misma cuando se inicie. El uso de una base de datos incrustada hace que todo sea más sencillo ya que sólo necesitas desplegar una sola cosa: tu app.

Últimamente he estado usando mucho BoltDB, sobre todo porque escribo mucho en Go y Bolt es una simple base de datos incrustada disponible en un paquete Go que usas como cualquier otra dependencia. Así que no tienes que ejecutar una base de datos separada a la que te conectas y tienes que lidiar con mantenerla en funcionamiento. Sólo usas la librería y los datos se escriben en tu disco local.

Ahora ese es también el problema con Bolt, los datos están sólo en tu máquina local junto a tu aplicación. Si la máquina falla, pierdes todos tus datos.

¿Qué tal si haces una copia de seguridad cada minuto o dos? He creado una librería que hace precisamente esto, llamada Bolt Backup, y con sólo cambiar la línea de inicialización de BoltDb, hará automáticamente una copia de seguridad de tu base de datos en S3 y, mejor aún, cuando inicies la aplicación, se recuperará de la copia de seguridad más reciente.

Puedes probar esto fácilmente añadiendo datos a tu base de datos Bolt, matando tu aplicación, borrando el archivo de datos Bolt, y luego reiniciando tu aplicación. Continuará donde lo dejó, sin importar que vuelvas a iniciar tu app.

Aquí tienes una app de ejemplo que utiliza esto y que puedes probar: https://github.com/treeder/bolt-backup/tree/master/example

Conclusión

Con los sencillos conceptos anteriores, puedes recuperar tu app en menos de 26 minutos y, por tanto, conseguir 4 9’s o más de tiempo de actividad. Sólo asegúrese de que todo está automatizado con un script de lanzamiento y la recuperación automática de la base de datos como la biblioteca Bolt Backup mencionada anteriormente.

El valor de la simplicidad a veces puede perderse cuando nos entusiasmamos con la «escala web», pero a menudo usted puede ahorrarse mucho tiempo y dolor si mantiene las cosas simples. Y mucho dinero.