Estrategias de lanzamiento: azul-verde y canario

(Sección: Tecnologías e Infraestructura)

Resumen breve

El azul-verde da un cambio instantáneo entre dos pilas completas (Azul/Verde) con el recorte más simple. Canary está incrementando gradualmente la proporción de tráfico a una nueva versión bajo el control de las puertas de SLO (latencia, tasa de error, métricas de negocio). Para iGaming es una forma de lanzar sin downtime en el pico de torneos y promociones, manteniendo una p99 estable y de calidad.

1) Cuándo elegir

Blue-green - lanzamientos rápidos, complejidad mínima, necesita un presupuesto de clúster/recursos «dual». Es bueno para API/front sin una migración state compleja.
Canary - lanzamientos de alto riesgo (nuevo flow, cambios críticos), permite «atrapar» la degradación en un 1-5% del tráfico. Requiere telemetría y gates automáticos.

2) Principios arquitectónicos

1. Enrutamiento a nivel L7: balanceador/Ingress/mesh de servicio (módulos de tráfico ponderado, cookie/flag-routing).
2. Dependencias aisladas: configuraciones, fichflags, secretos, cachés - separados para revisiones.
3. Compatibilidad de datos: migraciones de DB compatibles con el futuro (expand→migrate→contract).
4. Observabilidad: etiquetas/sellos individuales de las versiones en métricas/logs/tries.
5. Autogates: comparación p95/p99, error-rate, KPI de negocios; rollback automático.

3) Azul-verde: patrón básico

Flujo

1. Desplegar Green (copia azul) → calentar cachés/conexiones.
2. Ejecutamos pruebas de salud/humo.
3. Cambie el tráfico (DNS/LB/Ingress) a Green.
4. Mantenemos a Blue en un estado «cálido» como un fracaso hasta el final de la ventana.

Ejemplo: Cambiar en el nivel de Ingress (idea)

yaml
Annotated/Backend Option - In Prod, it is usually controlled by the spec operator/rollout:
rules:
- host: api. example. com http:
paths:
- path: /
backend:
service:
name: api-green # used to be api-blue port:
number: 80

Pros/contras

Reversión simple (devuelto Blue).
Tiempo de lanzamiento predecible.
Requiere recursos duplicados.
Riesgo de «big bang» sin medición canaria.

4) Canario: aumento gradual

Flujo

1. Correr el tráfico de sombras (opcional) → 1% de tráfico real → 5% → 25% → 50% → 100%.
2. En cada etapa - Gates por SLO/métricas de negocio.
3. En la degradación - auto-retroceso y la conservación de los artefactos de diagnóstico.

Ejemplo: Argo Rollouts (fragmento)

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: payments-api }
spec:
strategy:
canary:
canaryService: payments-canary stableService: payments-stable steps:
- setWeight: 5
- pause: { duration: 5m }
- analysis:
templates:
- templateName: slo-latency
- setWeight: 25
- pause: { duration: 10m }
- analysis:
templates:
- templateName: error-rate
- setWeight: 50
- pause: { duration: 20m }
- setWeight: 100

Ejemplo: Flagger + Istio/NGINX (idea)

yaml apiVersion: flagger. app/v1beta1 kind: Canary metadata: { name: games-api }
spec:
targetRef:
apiVersion: apps/v1 kind: Deployment name: games-api service:
port: 80 analysis:
interval: 1m threshold: 5 metrics:
- name: request-success-rate thresholdRange: { min: 99 }
- name: request-duration thresholdRange: { max: 300 }
webhooks:
- name: smoke url: http://tester/smoke

5) Calentamiento y control de la condición

Cachés/fuentes: calienta Redis/caché HTTP/CDN, prepara conexiones warm-pool a la DAB/PSP.
Modelos ML/LLM: descarga de pesos/índices/embebidos, caché KV, consultas primarias para «calentamiento».
Archivos/artefactos: contenido estático, plantillas, configuraciones - envíe por adelantado a volume/sidecar local.
Fichflags: rollout en 1-5% de audiencia/segmento, posibilidad de emergencia-kill.

6) Bases de datos: estrategia «expand → migrate → contract»

1. Expand: añadir nullable/nuevas columnas/índices, apoyar con ambas versiones.
2. Migrate: el código utiliza un nuevo esquema; los viejos caminos siguen siendo válidos.
3. Contrato: eliminamos los campos/índices antiguos después de la distribución completa.

En los registros, capture la versión del esquema y del cliente; todos los cambios son idempotentes.
Para las migraciones pesadas - jobs de fondo, throttling y «stop-the-world» ventanas de acuerdo.

7) Observabilidad y Gates (SLO/SLA)

Métricas SRE: p50/p95/p99, error-rate, saturation (CPU/GPU/IO), queue-depth, tiempo de inicio en frío.
Métricas de negocio: conversión de pagos, tasa de éxito, tiempo de retiro (TTW), respuestas promocionales.
Calidad de contenido/LLM: tokens/s, longitud de respuesta, toxicidad, RAG-score.
Gates: auto-promoción/retroceso al salir de los umbrales y/o al caer la «métrica útil».

gate:
p95_latency_ms <= 250 error_rate %  <= 1. 0 payment_conv  >= baseline - 0. 3%
action:
promote      rollback

8) Lanzamiento-orquestación e integración con CI/CD

GitOps: cambios de versión/peso - vía PR en el repositorio de manifiesto.
Verificaciones automáticas: smoke/e2e antes de iniciar el tráfico.
Plan de lanzamiento: programación de pasos canarios, responsables, canales de ChatOps, ventanas de retroceso.
Archivado de artefactos: confecciones de enrutamiento, sombreados, registros de comparación de métricas.

9) Multirregión y edge

Orden: primero la región «menos crítica »/RR, luego la principal.
Ruta Latency-based: siga los SLO locales; no mezcle el tráfico sin una razón.
Visión DR: Blue en la región-A puede convertirse en un sitio de DR para Green en la región-B.

10) Seguridad y cumplimiento del lanzamiento

Imágenes/listas firmadas, SBOM; validación de firmas en políticas admission.
Secretos: sólo los gerentes externos; versiones independientes para Blue/Green.
PII/regionalidad: no desvíe el tráfico de PII a través de una región «ajena»; enmascarar los registros cuando se comparan.
Auditoría: quién promovió, qué gates funcionaron, dónde se dio la vuelta.

11) Ejemplos de configuraciones

NGINX: rama canaria por cookie/título (idea)

nginx map $http_x_canary $canary {
default 0;
"1"   1;
}

upstream api_stable { server stable:80; }
upstream api_canary { server canary:80; }

server {
location / {
if ($canary) { proxy_pass http://api_canary; }
proxy_pass http://api_stable;
}
}

Feature-flag «fractional rollout» (pseudo)

yaml feature: new_checkout rollout:
percentage: 5 criteria:
country: ["TR", "BR", "MX"]
cohort: "new-users"
kill_switch: true

12) Runbooks (scripts tipo)

Crecimiento p99 en Canarias: detener la promoción → aumentar el batch/timeout, desactivar los fiches pesados a través de banderas → reiniciar parte de las podas.
Caída en la conversión de pagos: comparar rutas/fichas PSP, habilitar lógica de sombras, retroceder a estable.
Problema con la migración de BD: congelar el tráfico de escritura, activar el modo sólo lectura, revertir esquemas (si es posible), reparaciones de jobs de emergencia.
Incidente PII: cortar la versión canaria, revocación de secretos, informe y auditoría.

13) Lista de verificación de implementación

1. Definir la política: dónde está el azul-verde, dónde está el canario; lo que se considera «crítico».
2. Configure el enrutamiento ponderado (Ingress/mesh/router).
3. Fije las puertas de umbral SLO y los patines automáticos.
4. Implemente expand→migrate→contract para la DAB; pruebas de migración.
5. Active el calentamiento de cachés/modelos y las conexiones warm-pool.
6. Introduzca GitOps y registre todas las actividades de lanzamiento.
7. Visualice la comparación métrica (canario vs estable).
8. Pase el día del juego: imite el retroceso/fallo de la puerta/problema de la DB.
9. Documenta runbooks y el «botón rojo» (kill-switch).
10. Planifique versiones multirregionales por turnos, no simultáneamente.

14) Anti-patrones

Un lanzamiento canario sin gates y telemetría → la detección tardía de degradaciones.
Mezclar esquema DB: migraciones destructivas antes de distribuir el código.
Una caché/cola compartida para Blue y Green sin aislamiento → influencia mutua.
Conmutación DNS con baja TTL sin verificación - «flapping» del tráfico.
Los secretos/confecciones comunes a ambas revisiones → un retroceso complicado.
El tráfico en prod sin shadow/smoke es un riesgo de «big bang».
Sin kill-switch/feature-flag para apagar rápidamente.

los Totales

Blue-green ofrece conmutación instantánea y fácil, canario - riesgo manejable y detección temprana de problemas. En iGaming, ambos patrones se combinan: canario en cambios «agudos» + azul-verde como mecanismo básico sin downtime. Agregue gates SLO, GitOps, calentamiento, compatibilidad con DB y aislamiento de dependencias - y las versiones serán predecibles, las revoluciones serán rápidas y las métricas de p99 y negocios serán estables incluso durante los períodos pico.