Google preemptible VM´s, una opción a tener en cuenta.
La computación sin garantía de uso continuo obedece a un conjunto condiciones como tiempo de funcionamiento, precio o lo que se disponga y puede desencadenar la pérdida de recursos unilateralmente por parte del proveedor.
Ahora más baratas.
Si bien puede parecer una auténtica locura, la reducción de precio de esas instancias (entre un 30 – 80 % del precio original) y un sistema de “aviso” que nos alerta de una inminente pérdida hacen que sea interesante dedicarle una entrada a este blog.
Así, en el verano 2016 Google Cloud Platform ha iniciado a ofrecer máquinas virtuales en su versión “preemptible”. Este producto no es nuevo y hace años que el líder de IaaS, Amazon Web Service, ofrece sus EC2 en modalidad Spot.
¿Pero cómo y dónde incorporar este tipo de computación? La respuesta es delicada ya que este tipo de máquinas virtuales son iguales a las estándar pero podemos perder parte de la infraestructura durante la ejecución de una serie de tareas.
Tareas de computación no críticas y asíncronas.
La verdad es que existen un montón de tareas de las que nadie depende para seguir con la misión principal del sistema. Se deben realizar en un tiempo indeterminado y no dependen de ningún proceso adicional.
Tareas de limpieza de directorios y arquitecturas, compresión, análisis de datos durante la noche o días completos, escaneo de virus en lotes viejos de archivos, búsqueda de patrones, scripts de batch, transcoding y recoding, lotes de análisis de datos científicos… que cada cual añada los suyos.
Yo he visto hasta tareas de business intelligence y data mining, tareas de concentración y compactación de base de datos, búsquedas de duplicados o datos redundantes y en un proyecto ciertos tipos de backup.
Este es el terreno natural para este tipo de computación porque merece la pena no destinar recursos caros para realizar este tipo de tareas. ¿Podemos esperar 6 horas? si es sí, reduciremos un 60% el precio de computación de procesos que no tienen una misión crítica.
Tareas tolerantes a fallos, la clave.
Estaréis de acuerdo conmigo que si mis servidores ejecutan tareas síncronas o aplicaciones críticas mejor utilizar una máquina virtual que tendremos asignada mientras la paguemos.
La necesidad de sincronía produce un error de servicio si se pierde la infraestructura subyacente ya que existe un proceso que depende de su resultado o ejecución.
Pero qué pasa con los sistemas tolerantes a fallos, esto es, una aplicación que es capaz de por balanceo, arquitectura o programación ser tolerante a cierto nivel de fallos de arquitectura. ¿Podríamos abaratar considerablemente alguna parte de esta aplicación utilizando este tipo de computación?
Una de las partes donde empieza a utilizarse este tipo de máquinas es en el backoffice, pues las tareas de backoffice con frecuencia son críticas pero asíncronas. Análisis de imágenes, computación dedicada a análisis de bigdata… y sobretodo digestores o workers que consumen tareas singulares desde un Queue Manager como RabbitMQ o AWS SQS…
Si pierdo una máquina y su tarea, no hay problema. Puedo levantar otra máquina y reasignar su tarea bien por un tiempo indeterminado (GCP) bien a un precio algo mayor (AWS). Y además esto lo puedo hacer de manera automática con un grupo de escalado de instancias de este tipo, por ejemplo.
Aligerar la factura, pero no supeditarla.
La posibilidad de usar computación sin garantías en algunos puntos de misión crítica ha motivado realmente la escritura de este artículo. Una posibilidad entre líneas en la documentación de GCP y AWS.
Se propone su uso en grupos de balanceo extensos y pretende “aligerar” la factura (¡OJO! En un grupo de escalado hay que decidir qué tipos de máquinas van a utilizarse a priori, pero nada impide incluir otros tipos de máquinas en un balanceador). A lo que nos interesa, supongamos que nuestra batería de frontales está constituida con un par de servidores virtuales estándar que dan servicio a todas las peticiones con una carga media del 70%. Aligerar su carga puede ser beneficioso para la experiencia de usuario pero incluir perennemente un nuevo frontal puede elevar innecesariamente la factura, nada impide añadir a ese grupo de balanceo un servidor que a un precio descacharrante aligere temporalmente la carga y que su pérdida no provoque caídas ni cortes de servicio.
Yo creo que hay cierta letra pequeña, porque para que funcione bien el sistema debería ser orientado a microservicios y tolerante a fallos en los frontales y además stateless, además de que necesitaríamos el scripting necesario para incluir ese servidor en el balanceador y eliminarlo cuando el proveedor avise.
Yo tengo serias reservas pero cuando mi factura es elevada y/o mi aplicación muy dependiente de los recursos es algo a tener en cuenta. Una fórmula aproximada para verlo es si gastas más de 1000$ mensuales de IaaS para soportar 1.000 sesiones concurrentes en frontales, si es así empieza a mirar este tipo de computación con buenos ojos.
