Unidades: ejecutar más de una copia de tu app
Un Workload es tu app en Zaroz. Se ejecuta como una o más unidades. Una unidad es una copia en ejecución de tu app: con su propio proceso, su propia CPU y memoria, y sus propios logs.
La mayoría de los Workloads solo necesitan una unidad, y es lo que viene por defecto. Puedes ignorar esta página hasta que tengas un motivo para querer una segunda copia. Aquí se explican esos motivos desde cero, sin suponer ninguna experiencia previa con escalado.
Una copia y sus límites
Con una sola unidad, todo lo que hace tu app ocurre en un único sitio. Es simple y barato, pero tiene tres límites:
- Capacidad. Una copia solo puede hacer una cantidad limitada de trabajo. Cuando una API web recibe más peticiones por segundo de las que una copia puede atender, las peticiones hacen cola y se ralentizan, y a partir de cierto punto fallan.
- Disponibilidad. Cuando la única copia se reinicia (un fallo, una actualización, un nodo en mantenimiento), tu app está caída hasta que vuelve. Con una sola copia no hay nadie que cubra el hueco.
- Carga desigual. El tráfico no es plano. Si dimensionas una copia para tu hora más cargada, pagas capacidad ociosa el resto del día.
Ejecutar más de una copia de la misma app se llama escalar hacia fuera, o escalar horizontalmente. Las unidades son la forma en que Zaroz lo hace por ti.
Qué te dan más unidades
- Más capacidad. Cuatro unidades pueden atender aproximadamente cuatro veces el tráfico de una, siempre que tu app no guarde un estado que solo una copia pueda tener (mira "Antes de añadir una unidad" más abajo).
- Cobertura durante los reinicios. Mientras una unidad se reinicia, las demás siguen respondiendo. Las actualizaciones pasan por las unidades de una en una en lugar de tirar la app entera.
- Pagar por la carga, no por el pico. Con una política autoescalada, las unidades extra existen solo mientras hay carga para ellas, y se facturan por horas (mira Facturación).
Cuándo usar más de una unidad
Buenos motivos:
- Un Workload web o de API cuya CPU se mantiene alta en las horas punta.
- Un worker de cola que no da abasto con el trabajo pendiente. Cada unidad toma trabajos de la misma cola, así que más unidades la vacían antes.
- Un Workload que debe seguir disponible durante reinicios y actualizaciones.
- Una carga que sigue un horario (una red de servidores de juego que se llena los fines de semana por la tarde).
Malos motivos:
- La app va lenta por un bug, o porque espera a una base de datos lenta. Más copias de algo lento es algo lento más caro.
- La app guarda en su propio disco algo que necesita cada petición. Mira más abajo.
Antes de añadir una unidad
Las unidades son copias sin estado. Cada una arranca desde la misma imagen y con los mismos ajustes, y nada de lo que una unidad guarde en memoria o en disco es visible para otra. Funciona bien cuando el estado vive en un sitio compartido: una base de datos, una caché, un almacén de objetos.
Si el Workload tiene un volumen compartido, queda limitado a exactamente una unidad, y la API lo indica con volume_locked: true. Zaroz se niega a escalarlo en lugar de dejar que dos copias escriban en el mismo disco.
También conviene saber:
- Todas las unidades ejecutan la misma imagen con el mismo entorno.
- Las peticiones al nombre del Workload dentro de tu proyecto se reparten entre todas las unidades listas (mira Nombres privados).
- Un puerto público va a una sola unidad, y un endpoint HTTPS se reparte entre ellas (mira Puertos públicos).
Las unidades que pagas
Cada plan incluye un número de unidades (normalmente una) en su precio. Las unidades por encima de ese número son unidades extra y se facturan por hora mientras se ejecutan. No se cobra nada por las unidades que no ejecutas. Lee Facturación para ver la aritmética con ejemplos.
Si nunca escalas, nunca lo ves
Un Workload con una sola unidad no muestra nada de unidades en la consola. Solo hay una línea en los ajustes del Workload que dice que ejecuta una copia y ofrece escalar. Todo lo de estas páginas aparece cuando decides activarlo.
A dónde ir ahora
- Políticas fija y autoescalada: cómo se decide el número de unidades.
- Puertos públicos y nombres privados: cómo llega el tráfico a tus unidades.
- Facturación: cuánto cuestan las unidades extra, con ejemplos.
- Logs y métricas: 30 días de historial, por unidad o todos juntos.
- Límites: los techos y qué pasa al llegar a ellos.
- Unidades que controla tu código: crear y parar unidades desde tu propio programa (próximamente).
- En la práctica: Despliega un Workload desde una imagen pública, escálalo, abre un puerto público, lee sus logs.