El caso
Una VM, y la campaña del Día del Padre tumbó la tienda. Cuatro VM, y una se detuvo a las 10h.
En la semana del Día del Padre, Isaac puso los cafés en oferta en la página principal. Los pedidos llegaron en minutos, la única VM se quedó sin memoria y el sitio estuvo fuera del aire durante cuarenta minutos.
A la semana siguiente, montó cuatro VM iguales. A las 10h de un martes, una de ellas dejó de responder. Solo se enteró cuando un cliente se quejó.
Este post parte de Máquinas virtuales: del servidor dedicado a la nube y de Compute Engine: máquinas virtuales en Google Cloud. Una VM ya sabemos crearla; lo que falta es hacer que varias trabajen como una sola.
El problema
Una VM es un punto único de falla
Una VM sola tiene dos límites. Cuando sube el tráfico, no da abasto, y quien tiene que tocarla es el equipo, a mano. Cuando se detiene, la tienda se detiene con ella.
Crear más VM resuelve la capacidad, pero plantea otra pregunta: ¿quién decide qué VM atiende a cada cliente, y quién nota que una de ellas está enferma?
La solución
Un grupo de VM iguales
Un grupo de instancias administrado (managed instance group, o MIG) es un conjunto de VM creadas a partir de la misma plantilla de instancia (instance template). La plantilla guarda la receta: tipo de máquina, imagen, disco y script de inicio. Cuando el grupo necesita una VM más, nace idéntica a las demás.
Con el grupo, describes el resultado, no cada máquina. Por ejemplo: "quiero entre dos y diez VM para el sitio, y más cuando el uso promedio de CPU supere el 70%". Google Cloud agrega o quita VM para cumplirlo. Eso es el autoescalado (autoscaling).
Recuperación
El grupo reemplaza la VM que se enfermó
El grupo puede verificar cada VM con una verificación de estado de la aplicación (health check): una solicitud periódica a una página o a un puerto de la aplicación. Si la respuesta no llega como se espera varias veces seguidas, el grupo borra la VM y crea otra a partir de la plantilla. Ese proceso es la autorreparación (autohealing).
Hay un detalle importante: una VM nueva tarda en arrancar, y una verificación hecha demasiado pronto daría una falsa alarma. Por eso la autorreparación tiene un retraso inicial (initial delay), durante el cual se ignoran las fallas mientras la máquina todavía se inicia.
En cuanto al alcance, el grupo puede ser zonal (todas las VM en una sola zona) o regional (VM distribuidas en varias zonas de una región). Si se cae una zona entera, el grupo regional sigue con las VM de las otras zonas.
Actualización
Cambiar la versión sin tumbar la tienda
Cuando el sitio recibe una nueva versión, no tiene sentido detener el grupo para reemplazar todas las VM de una vez. El grupo ofrece dos formas de actualizar:
- Actualización gradual (rolling update): las VM se reemplazan por lotes. Defines cuántas pueden estar fuera al mismo tiempo, y el grupo espera a que cada lote esté sano antes de seguir.
- Actualización canary: una parte pequeña de las VM recibe la nueva versión, y el resto sigue con la anterior. Si el comportamiento es bueno, todo el grupo pasa a la nueva versión. Si no lo es, solo hay que revertir la parte que cambió.
Para pedir un porcentaje de VM en el canary, el grupo necesita al menos diez instancias. Con un grupo más pequeño, eliges un número fijo de VM.
Quién recibe el pedido
El balanceador de carga
El grupo se ocupa de las VM, pero alguien tiene que recibir el pedido del cliente y entregarlo a una VM sana. Ese papel es del balanceador de carga (load balancer). En Google Cloud, el balanceador global tiene una única dirección IP (anycast), que atiende pedidos de todo el mundo y los encamina a los backends con el mejor camino.
Un servicio de backend (backend service) reúne los grupos de VM que reciben el tráfico. Cada backend tiene su propia verificación de estado. Cuando una VM deja de responder a la verificación, el balanceador deja de enviarle pedidos. No la borra: eso lo hace el grupo.
No confundas
Verificación del balanceador × autorreparación del grupo
Verificación del balanceador
“¿Adónde va el pedido?”
- Ejemplo
- La VM no responde, y el balanceador envía los pedidos a las demás.
- Foco
- Saca el tráfico de la VM enferma, sin borrarla.
Autorreparación del grupo
“¿Se reemplaza la VM enferma?”
- Ejemplo
- La VM no responde a varias verificaciones seguidas, y el grupo crea otra en su lugar.
- Foco
- Recrea la VM a partir de la plantilla de instancia.
En la práctica, los dos trabajan juntos: el balanceador protege al cliente mientras el grupo resuelve el problema.
En la práctica
Cuál elegir
Sitio de la tienda en un día pico
Grupo administrado con autoescalado y balanceador al frente. La capacidad acompaña los pedidos.
Nueva versión del sitio
Actualización canary: una parte de las VM recibe la nueva versión, y el equipo observa antes de liberar el resto.
Tienda que no puede quedar fuera del aire
Grupo regional, distribuido en varias zonas, con verificación de estado de la aplicación para la autorreparación.
Una VM para una prueba rápida
Ningún grupo. Un grupo para una sola VM es complicación sin beneficio.
Términos clave
Cinco términos para fijar
Toca la tarjeta para ver la definición.
Prueba rápida
Tres preguntas, estilo examen
01
Una de las VM del sitio responde con error, pero el grupo sigue considerándola sana. ¿Qué debe pasar para que se reemplace automáticamente?
02
La tienda debe seguir en línea si una zona entera deja de estar disponible. ¿Qué tipo de grupo elegir?
03
Quieres probar la nueva versión del sitio solo en una parte de las VM antes de liberarla a todo el grupo. ¿Qué actualización usar?
El escalado y el balanceo aparecen en cualquier nube: grupos de VM con autoescalado y balanceadores existen en AWS, Azure y Oracle Cloud, con otros nombres. La idea es la misma: la máquina que falla sale de la ruta, y la capacidad acompaña la demanda.