¿Puedes ejecutar más de una instancia de una aplicación? Lista de verificación

Qué cambia con el escalado horizontal y qué no resuelve

El escalado horizontal consiste en ejecutar más de una instancia de una aplicación para ofrecer el mismo servicio. Puede servir para añadir capacidad o cumplir un objetivo de disponibilidad, pero añadir instancias no demuestra por sí solo que la aplicación pueda funcionar de forma segura de ese modo.

Considera la compatibilidad como la primera cuestión y la capacidad del servidor como otra distinta. Son importantes las instrucciones de despliegue de la aplicación, el diseño del estado compartido, las tareas en segundo plano y el proceso de actualización. Si no has confirmado estos puntos, añadir más réplicas podría aumentar la complejidad operativa sin resolver la limitación que realmente tienes.

• Identifica el motivo para considerar réplicas: más demanda, un cuello de botella concreto o un requisito de disponibilidad.
• Comprueba si el proveedor de la aplicación documenta explícitamente que admite varias instancias de la aplicación.
• Usa la configuración actual de una sola instancia como punto de comparación. Una instancia única de mayor tamaño puede ser más sencilla si la aplicación no está documentada ni probada para ejecutarse con réplicas.

Comprueba la compatibilidad documentada de la aplicación con varias instancias

Busca instrucciones de despliegue que describan varias réplicas de la aplicación prestando servicio a un mismo despliegue, no simplemente varios entornos, proyectos o instalaciones. Expresiones parecidas pueden referirse a configuraciones distintas. Por ejemplo, la página de Retool titulada [«Multi-instance deployment»](https://docs.retool.com/self-hosted/self-managed/concepts/multi-instance-deployment) describe la definición de varios entornos dentro de una sola instancia; esa descripción, por sí sola, no demuestra que se admitan réplicas.

Da prioridad a la documentación oficial de la aplicación concreta y del modelo de despliegue que utilizas. Anota los requisitos, las limitaciones y la topología admitida que se indiquen. Si la documentación no aborda el tema o resulta ambigua, consulta al proveedor o a los responsables de mantenimiento antes de considerar que las réplicas están admitidas.

La [lista de verificación de preparación para producción de Temporal autoalojado](https://docs.temporal.io/self-hosted-guide/production-checklist) abarca escalado, métricas, pruebas de carga y versionado de flujos de trabajo. No es una lista universal para otras aplicaciones, pero ilustra por qué la orientación de producción propia de cada aplicación es un mejor punto de partida que las suposiciones basadas únicamente en la infraestructura.

• ¿La documentación describe explícitamente varias instancias de la aplicación prestando servicio al mismo despliegue?
• ¿Hay requisitos previos, como un servicio compartido específico o un modo de despliegue determinado?
• ¿La guía distingue entre instancias de la aplicación, procesos de trabajo o entornos separados?
• ¿La guía corresponde a la versión de la aplicación y al método de instalación que utilizas realmente?

Traza el estado compartido entre las réplicas

Haz un inventario del estado que la aplicación lee o escribe durante un flujo de trabajo habitual de un usuario. Para cada elemento, consulta las instrucciones oficiales de despliegue para determinar si se espera que las instancias lo compartan, lo mantengan localmente o accedan a él mediante un servicio independiente. No des por hecho que compartir una base de datos entre réplicas sea la única cuestión relacionada con el estado compartido.

Comprueba por separado las sesiones, los archivos cargados, las cachés y las conexiones a la base de datos. Los requisitos pueden variar según la aplicación; la documentación de la aplicación y tus propias pruebas deben determinar qué corresponde a tu despliegue.

Una prueba útil consiste en iniciar un flujo de trabajo en una instancia y continuarlo en otra, si tu entorno de prueba permite dirigir las solicitudes de ese modo. Verifica que el resultado coincida con el comportamiento documentado de la aplicación, incluido el acceso a los archivos y cualquier paso que dependa de la sesión.

• Sesiones: determina si un usuario puede continuar una sesión cuando las solicitudes sucesivas llegan a instancias distintas.
• Archivos cargados: confirma dónde se almacenan y si todas las instancias que los necesitan pueden acceder a ellos.
• Cachés: averigua si son locales o compartidas y si la aplicación documenta requisitos de coherencia.
• Conexiones a la base de datos: comprueba la configuración documentada de las conexiones y considera la configuración combinada de todas las instancias.
• Configuración y secretos: confirma que las réplicas usen ajustes compatibles, sin exponer credenciales en las notas de prueba ni en los registros.

Coordina los procesos en segundo plano y las tareas programadas

Averigua qué procesos gestionan el trabajo en cola, las tareas recurrentes y otras tareas que pueden ejecutarse fuera de una solicitud de usuario. La cuestión clave es si la aplicación espera que esos procesos se ejecuten una sola vez, en cada instancia o en un rol gestionado por separado.

No deduzcas cómo funciona la programación de tareas solo porque una aplicación se inicie correctamente en varias instancias. En un entorno de prueba, utiliza una tarea inocua e identificable y comprueba cuántas veces se ejecutó, si se omitió algún trabajo y qué ocurre si una instancia se detiene mientras hay trabajo pendiente.

Documenta la forma admitida por la aplicación para coordinar los procesos de trabajo y las tareas programadas antes de aumentar el número de instancias. Si la guía oficial no lo explica, considera que el comportamiento aún no está resuelto en vez de confiar en una suposición.

• Enumera todas las tareas programadas y los procesos en segundo plano habilitados en el despliegue.
• Consulta las instrucciones del proveedor para saber qué instancia o proceso debe ejecutar cada tarea.
• Prueba si se producen ejecuciones duplicadas, tareas omitidas y recuperación tras reiniciar una instancia.
• Registra los resultados esperados y los observados, usando datos de prueba en lugar de trabajo de producción.

Revisa el enrutamiento del tráfico, las comprobaciones de estado y las conexiones de larga duración

Un despliegue con varias instancias necesita un método definido para dirigir el tráfico entrante y retirar una instancia del servicio cuando corresponda. Confirma que el comportamiento del enrutamiento y de las comprobaciones de estado coincida con las necesidades documentadas de la aplicación; no des por sentada una configuración concreta.

Pregunta qué endpoint o condición indica que una instancia está lista para atender solicitudes de la aplicación y si esta utiliza conexiones de larga duración que requieran un tratamiento especial. Prueba el comportamiento en lugar de suponer que el inicio correcto de un proceso significa que los usuarios pueden completar sus flujos de trabajo.

Airbip automatiza el enrutamiento y los certificados TLS mediante Traefik y Let’s Encrypt para sus despliegues de aplicaciones gestionadas. Esta capacidad de infraestructura no debe interpretarse como una garantía de que todas las aplicaciones admitan varias réplicas o tengan un comportamiento determinado de comprobación de estado o de conexiones.

• Confirma cómo se asigna el tráfico a las instancias y qué ocurre cuando una deja de estar disponible.
• Identifica el método de disponibilidad o comprobación de estado admitido por la aplicación, si está documentado.
• Prueba los flujos de trabajo habituales de los usuarios, incluidas las conexiones que permanecen abiertas durante un periodo prolongado.
• Verifica el comportamiento del enrutamiento y de TLS para el dominio y el modelo de despliegue que planeas utilizar.

Planifica las migraciones y los cambios de versión

Antes de desplegar varias instancias, averigua cómo espera la aplicación que se gestionen los cambios de esquema y las versiones de la aplicación. Las preguntas importantes de compatibilidad dependen de cada aplicación: si las instancias pueden ejecutar temporalmente versiones distintas, qué secuencia de migración está admitida y qué implica revertir los cambios.

No des por hecho que un método de despliegue que actualiza una instancia cada vez sea seguro para todas las aplicaciones. Sigue las instrucciones oficiales de actualización de la aplicación y, cuando sea posible, ensaya la secuencia prevista con una copia de datos representativos.

La lista de verificación de preparación para producción de Temporal incluye el versionado de flujos de trabajo entre sus temas. Esto es pertinente a la orientación de Temporal y no demuestra que otra aplicación utilice el mismo modelo de versionado.

• Anota el orden documentado para detener, actualizar, migrar e iniciar los componentes de la aplicación.
• Confirma si se admiten versiones mixtas durante una actualización o si todas las instancias deben cambiar a la vez.
• Prueba la ruta documentada de reversión o recuperación antes de depender de ella.
• Comprueba que todas las réplicas utilicen versiones de la aplicación y configuraciones compatibles tras el despliegue.

Prueba flujos de trabajo representativos, fallos y recuperación

Una prueba útil de preparación sigue flujos de trabajo reales, en lugar de comprobar únicamente si se inicia cada instancia. Elige acciones que pongan a prueba el inicio de sesión, la gestión de archivos, las tareas en segundo plano y cualquier otra función con estado de la que dependa tu equipo. Antes de realizar la prueba, registra qué debería ocurrir.

Incluye casos controlados de fallo y recuperación en un entorno que no sea de producción. Por ejemplo, comprueba qué experimentan los usuarios si una instancia deja de estar disponible durante un flujo de trabajo y si el trabajo o las sesiones pueden continuar como indica la documentación de la aplicación. Evita probar modos de fallo con datos de producción o procesos empresariales en curso.

Mide los resultados que necesitas para tomar una decisión, pero no consideres una prueba breve como prueba del comportamiento ante cualquier carga o fallo. La lista de verificación de Temporal incluye explícitamente métricas y pruebas de carga; consulta la [guía de preparación para producción de Temporal](https://docs.temporal.io/self-hosted-guide/production-checklist) y busca recomendaciones equivalentes específicas de cada aplicación.

• Ejecuta un flujo de trabajo que comience en una instancia y continúe mediante la ruta de enrutamiento habitual.
• Prueba la carga y recuperación de un archivo, si la aplicación admite flujos de trabajo con archivos.
• Comprueba si se omiten o duplican tareas programadas y en cola.
• Simula el reinicio o la retirada de una instancia en un entorno de prueba y observa la recuperación.
• Compara los resultados con las expectativas documentadas y anota cualquier comportamiento que el proveedor no haya especificado.

Elige réplicas, una instancia única de mayor tamaño u otra arquitectura

Elige varias réplicas cuando la guía de la propia aplicación las admita y tus pruebas confirmen que el estado compartido, las tareas en segundo plano, el enrutamiento y las actualizaciones se comportan según lo necesario. Si no se cumplen esas condiciones, añadir instancias podría crear nuevos modos de fallo en vez de una mejora fiable.

Una instancia única de mayor tamaño puede ser la opción más sencilla cuando la aplicación está diseñada o documentada para funcionar con un solo proceso de aplicación y la necesidad inmediata es disponer de más capacidad. También puede ser un paso razonable mientras averiguas qué componente limita el despliegue. Se trata de un marco para tomar una decisión, no de una garantía de que el escalado vertical vaya a resolver un cuello de botella concreto.

Si tus requisitos exigen réplicas, pero la documentación de la aplicación no las admite, considera un modelo de despliegue documentado por el proveedor o pide orientación a los responsables de mantenimiento. El alojamiento gestionado puede simplificar las operaciones de infraestructura, pero no elimina la responsabilidad del cliente respecto a la adecuación de la aplicación, los datos, el acceso y las decisiones de gobernanza.

Airbip ofrece despliegue gestionado de un catálogo público de aplicaciones empresariales, de publicación, analítica, colaboración e IA, como cargas de trabajo de Docker en servidores en la nube de Airbip. Incluye copias de seguridad configurables diarias, semanales y mensuales, comprobaciones de DNS, gestión del ciclo de vida de los servicios y enrutamiento y TLS automatizados. Estas capacidades pueden facilitar las operaciones de infraestructura, pero no demuestran que una aplicación concreta admita varias instancias. Consulta el sitio web actual de Airbip para conocer los planes y condiciones vigentes.

• Elige una sola instancia o el escalado vertical cuando satisfaga la necesidad y mantenga más sencillo el modelo operativo.
• Elige réplicas solo después de confirmar que están admitidas en la documentación y validar los flujos de trabajo importantes.
• Elige otra arquitectura de despliegue si el modelo admitido por la aplicación no cumple tus requisitos de disponibilidad o capacidad.
• Toma la decisión basándote en requisitos explícitos y resultados de pruebas, no solo en el número de réplicas.