Alcanzar la verdadera Alta Disponibilidad para un SaaS de 850 dominios: La migración de Turisapps
El Reto: Escalar un SaaS multi usuario con estado
Turisapps es una robusta plataforma SaaS que ofrece presencia web personalizada y herramientas de gestión para el sector turístico y hotelero. Con más de 850 dominios personalizados distintos apuntando a su infraestructura, la plataforma se enfrenta a un conjunto único de retos arquitectónicos que los despliegues estándar en la nube no logran manejar de forma eficiente.
Operando sobre una infraestructura en la nube (DigitalOcean con HashiCorp Nomad), el entorno había alcanzado un límite crítico de escalabilidad. Los retos principales eran tres:
1. El problema de la Alta Disponibilidad con estado Turisapps ejecuta una aplicación con estado (stateful) que requiere acceso compartido de lectura y escritura a un directorio específico del sistema de archivos. Debido a que el almacenamiento en bloque de la nube (como AWS EBS o los volúmenes de DigitalOcean) es fundamentalmente de tipo ReadWriteOnce (RWO), la aplicación estaba encadenada a un único servidor. Si ese nodo específico caía, la aplicación entera se caía. Lograr una verdadera Alta Disponibilidad (HA) y eliminar este Punto Único de Fallo (SPOF) era la máxima prioridad.
2. Enrutamiento dinámico multi usuario Cuando una petición llega al balanceador de carga de Turisapps, no se dirige simplemente a un backend genérico. Las páginas de los clientes son renderizadas dinámicamente por entre 5 y 7 servidores de plantillas diferentes. La infraestructura necesitaba inspeccionar el nombre de dominio solicitado, consultar la configuración específica del cliente y enrutar dinámicamente el tráfico hacia el motor de plantillas correcto, todo ello en milisegundos.
3. La tormenta de bots y los falsos positivos Alojar más de 850 dominios independientes te convierte en un objetivo masivo para rastreadores web (scrapers) y bots. Dado que los bots ven esto como 850 sitios web separados, el tráfico agregado que golpeaba la infraestructura era intenso. Para proteger los servidores en la nube, se aplicaron estrictos límites de tasa de peticiones (rate limits). Desafortunadamente, esto generaba una experiencia de usuario degradada, marcando ocasionalmente el tráfico legítimo de los clientes como "abuso" (falsos positivos).
Turisapps necesitaba una reestructuración arquitectónica de nivel empresarial.
Una alianza estratégica a largo plazo
Este proyecto representa la segunda gran evolución de la infraestructura de Turisapps. En 2020, Nubosas lideró su migración inicial desde un único servidor físico hacia DigitalOcean, modernizando la plataforma con Docker y posteriormente con Nomad. Con el crecimiento de la plataforma hasta superar los 850 dominios, las necesidades de Alta Disponibilidad y eficiencia de costes exigieron este último salto hacia un entorno de Kubernetes Independiente.
La Solución: Kubernetes Independiente y OpenResty
Diseñamos un plan de migración para sacar a Turisapps de la restrictiva nube pública y llevarlo a un clúster de Kubernetes en servidores físicos (bare-metal) altamente resiliente alojado en Hetzner.
1. Desbloquear la Alta Disponibilidad con almacenamiento distribuido
Para resolver la limitación de la aplicación con estado, implementamos Rook-Ceph dentro del nuevo clúster de Kubernetes. Al agrupar discos NVMe físicos en múltiples servidores, proporcionamos a la aplicación volúmenes persistentes de tipo ReadWriteMany (RWX). Por primera vez, la aplicación con estado podía escalar horizontalmente a través de múltiples nodos de trabajo. El Punto Único de Fallo fue eliminado por completo.
2. Enrutamiento inteligente en el borde con OpenResty
Para manejar los complejos requisitos de enrutamiento dinámico de los más de 850 dominios, desplegamos una puerta de enlace (gateway) interna con OpenResty (Nginx + Lua).
Cuando llega una petición, OpenResty ejecuta una rápida petición HTTP previa hacia un microservicio interno, desencadenando una consulta ligera a la base de datos. Esta consulta determina exactamente qué cliente es dueño del dominio y qué configuración de servidor de plantillas requiere. A continuación, OpenResty redirige el tráfico de forma transparente hacia el pod del backend correcto. Esto desacopló la lógica de enrutamiento de la lógica de la aplicación, permitiendo que ambas escalen de forma independiente.
3. Automatización del ciclo de vida TLS para más de 850 dominios
En el entorno anterior, la gestión de los certificados SSL/TLS para más de 850 dominios dependía de una combinación frágil de scripts internos y certbot. Esto creaba una «caja negra» donde los fallos en los certificados a menudo solo se descubrían cuando un dominio ya había caducado.
Al migrar a Kubernetes, implementamos cert-manager. Sustituimos los scripts manuales por un ciclo de vida completamente automatizado que gestiona la emisión y renovación a través de Let's Encrypt. Lo más importante es que lo integramos con nuestro stack de observabilidad. Ahora disponemos de paneles en tiempo real que muestran el estado de renovación de cada dominio y alertas automatizadas que se activan si un certificado falla, mucho antes de su expiración. Cambiamos la ansiedad manual por visibilidad automatizada.
4. Potencia de cálculo frente a límites de peticiones
Al migrar a una arquitectura independiente en servidores físicos, multiplicamos la potencia de cálculo bruta disponible para la plataforma.
En lugar de depender de límites de peticiones (rate limits) agresivos que bloqueaban a usuarios legítimos, los nuevos nodos de trabajo físicos absorbieron fácilmente los fuertes picos de tráfico. Eliminamos las restricciones estrictas para las peticiones web habituales, erradicando por completo las detecciones de abuso (falsos positivos) en usuarios reales. Para mantener a raya a los rastreadores, implementamos un bloqueo selectivo por User-Agent directamente en la capa de Ingress de K8s, mientras evaluamos un WAF (Web Application Firewall) integral para futuras iteraciones.
La Ejecución: La transición de la base de datos
Migrar un SaaS con estado y un uso intensivo requiere una planificación meticulosa. La pieza más crítica del rompecabezas era la base de datos.
Ejecutamos una estrategia de migración entre proveedores:
- Aprovisionamos la nueva infraestructura en Hetzner y establecimos un túnel seguro hacia el antiguo entorno de DigitalOcean.
- Creamos una réplica de solo lectura de MySQL en el nuevo clúster de Hetzner, sincronizando datos de forma continua desde la base de datos de producción en DigitalOcean.
- El día de la transición, detuvimos las escrituras de la aplicación, promovimos la réplica de Hetzner a base de datos principal de Escritura y degradamos la antigua base de datos de DigitalOcean a solo lectura (deshabilitando la replicación).
- Finalmente, actualizamos los registros DNS de los más de 850 dominios para que apuntaran al nuevo Balanceador de Carga de Hetzner.
Aunque nuestro objetivo era evitar por completo el tiempo de inactividad, las realidades de la propagación de DNS y el estado de la aplicación resultaron en una ventana de mantenimiento de 30 minutos estrictamente controlada. La transparencia y la ejecución precisa garantizaron que el cliente y sus usuarios finales estuvieran plenamente informados y mínimamente afectados.
El resultado de negocio
La transición a una infraestructura independiente de Kubernetes transformó la realidad operativa del equipo de ingeniería de Turisapps.
- Despliegues sin tiempo de inactividad: Ahora que la aplicación funciona sin estado (stateless) a nivel de K8s (gracias a los volúmenes RWX de Ceph) y se ejecuta en verdadera Alta Disponibilidad, el equipo de ingeniería puede realizar actualizaciones continuas (rolling updates). El despliegue de nuevo código ya no requiere ventanas de mantenimiento ni interrupciones momentáneas.
- Experiencia de usuario sin fricciones: Al aprovechar el rendimiento de los servidores físicos para eliminar los agresivos límites de peticiones, las quejas de los clientes por bloqueos falsos positivos se redujeron a cero.
- Una base escalable: La capa de enrutamiento con OpenResty maneja sin esfuerzo los más de 850 dominios, proporcionando una base sólida para incorporar miles más sin cuellos de botella arquitectónicos.
- Confianza automatizada: Sustitución de la gestión manual de certificados por cert-manager, logrando un ciclo de vida TLS 100% automatizado y observabilidad en tiempo real para más de 850 dominios.
Turisapps ya no se preocupa de que el fallo de un servidor derribe las páginas web de sus clientes. Dejaron de alquilar su fiabilidad y empezaron a ser los dueños de ella.
¿Te enfrentas a retos de escalabilidad con una arquitectura SaaS? Contacta hoy con Nubosas para reservar un análisis de sobrecostes en la Nube y descubre cómo una infraestructura de Kubernetes independiente puede blindar tu plataforma.