GitHub
IX. Desechabilidad
Hacer el sistema más robusto intentando conseguir inicios rápidos y finalizaciones seguras
Los procesos de las aplicaciones “twelve-factor” son desechables, lo que significa que pueden iniciarse o finalizarse en el momento que sea necesario. Esto permite un escalado rápido y flexible, un despliegue rápido del código y de los cambios de las configuraciones, y despliegues más robustos en producción.
Los procesos deberían intentar conseguir minimizar el tiempo de arranque. En el mejor de los casos, un proceso necesita unos pocos segundos desde que se ejecuta el mandato hasta que arranca y está preparado para recibir peticiones o trabajos. Mejorar el tiempo de arranque proporciona mayor agilidad en el proceso de distribución y escalado; y lo hace más robusto, porque el gestor de procesos puede mover procesos de forma segura entre máquinas físicas más fácilmente.
Los procesos se paran de manera segura cuando reciben una señal SIGTERM desde el gestor de procesos. Un proceso web para de manera segura cuando deja de escuchar el puerto asociado al servicio (así rechaza cualquier nueva petición), permitiendo que cualquier petición termine de procesarse y pueda finalizar sin problemas. Implícitamente, según este modelo, las peticiones HTTP son breves (no duran más de unos pocos segundos) y, en el caso de un sondeo largo, el cliente debería intentar reconectar una y otra vez cuando se pierda la conexión.
Para finalizar de manera segura, un trabajador (o “worker”) debe devolver el trabajo actual a una cola de trabajos. Por ejemplo, en RabbitMQ un trabajador puede mandar un NACK; en Beanstalkd, el trabajo se devuelve a una cola automáticamente en el momento en el que el trabajador finaliza. Los sistemas de exclusión mutua como Delayed Job necesitan estar seguros para liberar su candado en el registro de trabajos. Implícitamente, según este modelo, todos los trabajos son reentrantes, lo que se consigue normalmente generando los resultados de manera transaccional, o convirtiendo la operación en idempotente.
Los procesos deberían estar preparados contra finalizaciones inesperadas, como en el caso de un fallo a nivel hardware. Aunque es un caso más raro que una finalización mediante la señal SIGTERM, se puede dar el caso. Lo recomendable es usar un sistema de colas robusto, como Beanstalkd, que devuelve los trabajos a su cola cuando los clientes se desconectan o expira su tiempo de espera (“timeout”). En cualquier caso, una aplicación “twelve-factor” es una arquitectura que trata finalizaciones inesperadas y peligrosas. El diseño Crash-only lleva este concepto a su conclusión lógica.