​

Descripción General de la Arquitectura AWS

​

Diagrama de Arquitectura

​

Componentes Principales

​

1. Capa de Red

​

Proveedor DNS

• Propósito: Resolución de nombres de dominio; funciona con cualquier proveedor (Route 53, Cloudflare, etc.)
• Dominios (use su propio dominio, ej. example.com):
  • app.example.com — Frontend Web
  • api.example.com — Backend FastAPI
  • automations.example.com — Servicio Automator
  • supabase.example.com — Supabase Kong (solo autoalojado)
  • signoz.example.com — Observabilidad SigNoz (opcional)
• Validación SSL: Registros CNAME requeridos para validación DNS de ACM

​

Balanceador de Carga de Aplicación (ALB)

• Propósito: Terminación SSL, balanceo de carga y enrutamiento basado en hostname
• Características:
  • Terminación SSL/TLS usando certificados ACM (wildcard o por servicio)
  • Redirección HTTP → HTTPS
  • Health checks para todos los grupos objetivo
• Administrado por: AWS Load Balancer Controller (chart Helm en helm-deployment/infrastructure)

​

VPC

• CIDR: Específico del entorno (ej. 10.x.0.0/16)
• Zonas de Disponibilidad: 3 AZs en la región elegida
• Subredes: 3 públicas (NAT Gateways) + 3 privadas (nodos EKS)
• Salida: NAT Gateway por AZ para salida de nodos

​

2. Capa de Cómputo

​

Cluster EKS

• Versión: Kubernetes 1.33
• Grupo de Nodos del Sistema: Grupo de nodos administrado ejecutando el controlador Karpenter (no en nodos administrados por Karpenter, según la mejor práctica de AWS)
• Add-ons: EBS CSI Driver, AWS Load Balancer Controller, CoreDNS, kube-proxy

​

Karpenter — Provisionamiento Dinámico de Nodos

• Propósito: Provisionamiento de nodos justo a tiempo y optimización de costos
• Clases de Nodos:
  • Propósito General: Instancias Spot para la mayoría de las cargas de trabajo
  • Intensivo en Cómputo: Instancias de alta CPU para tareas limitadas por CPU
  • Intensivo en Memoria: Instancias optimizadas en memoria para grandes conjuntos de datos
  • Base de Datos: Instancias bajo demanda para cargas de trabajo con estado/bases de datos
  • GPU: Instancias GPU para cargas de trabajo de IA/ML (opcional)
• Características: Priorización Spot, consolidación automática, manejo de interrupciones basado en SQS

​

KEDA — Autoescalado de Pods Basado en Eventos de Kubernetes

• Propósito: Autoescalado horizontal de pods basado en métricas de recursos
• Objetivos:

• Escala descendente: Ventana de estabilización de 30s para respuesta rápida

​

3. Servicios de Aplicación

​

Frontend Web

• Puerto: 3000
• Réplicas: 2–8 (administrado por KEDA)
• Propósito: Aplicación React que sirve la interfaz de usuario

​

Backend FastAPI

• Puerto: 8001
• Réplicas: 2–10 (administrado por KEDA)
• Propósito: Servidor de API REST que maneja la lógica de negocio y acceso a datos

​

Workers Celery

• Réplicas: 2–8 (administrado por KEDA)
• Propósito: Procesamiento de tareas en segundo plano (encolado vía RabbitMQ)

​

Servicio Automator

• Puerto: 80
• Réplicas: 2–8 (administrado por KEDA)
• Propósito: Automatización y orquestación de flujos de trabajo

​

Supabase Kong

• Puerto: 8000 (servicio interno del clúster)
• Propósito: Gateway API para todos los servicios de Supabase
• Enrutamiento: El tráfico externo llega a Kong a través del ingreso ALB definido en odin-services/main-ingress.yaml

​

SigNoz (opcional)

• Namespace: monitoring
• Componentes: Plataforma SigNoz + agente DaemonSet k8s-infra
• Propósito: Traza distribuida, agregación de métricas, gestión de logs
• Habilitado por: ENABLE_SIGNOZ=true

​

4. Capa de Datos

​

ElastiCache Redis

• Propósito: Caché, almacenamiento de sesiones y broker/result backend de Celery
• Configuración:
  • Tipo de nodo: configurable (ej. cache.t3.micro)
  • Puerto: 6379
  • Cifrado en reposo y en tránsito
  • Multi-AZ para alta disponibilidad
• Habilitado por: ENABLE_AWS_SERVICES=true

​

Amazon MQ (RabbitMQ)

• Propósito: Cola de mensajes para procesamiento asíncrono de tareas
• Configuración:
  • Motor: RabbitMQ
  • Puertos: 5671 (AMQP/SSL), 15671 (Gestión/SSL)
  • Modo de despliegue: instancia individual o activo/en espera
• Habilitado por: ENABLE_AWS_SERVICES=true

​

Supabase — Opción A: Cloud (administrado)

• Propósito: PostgreSQL, Auth, Storage y Realtime administrados externamente
• Conexión: URL del proyecto Supabase y clave de servicio role configuradas en values/odin-services.yaml

​

Supabase — Opción B: Autoalojado en EKS

• Propósito: Stack completo de Supabase ejecutándose dentro del clúster
• Componentes:
  • Operador CloudNativePG (cnpg-system) — gestiona el ciclo de vida del clúster Postgres
  • DB HA de Supabase (ha-supabase-db) — Recurso Cluster de CloudNativePG con pooler PgBouncer
  • Aplicación Supabase (namespace supabase) — Kong, Auth, Storage (MinIO), Meta, Rest, Realtime, Studio
• Orden de despliegue: CloudNativePG → DB HA de Supabase → Aplicación Supabase
• Habilitado por: ENABLE_CNPG=true, ENABLE_HA_SUPABASE_DB=true, ENABLE_SUPABASE=true

​

PostgreSQL Automator

• Propósito: Base de datos PostgreSQL local para el servicio Automator
• Puerto: 5432
• Almacenamiento: Volumen persistente EBS
• Afinidad de nodo: Nodos dedicados a bases de datos

​

5. Seguridad e IAM

​

Roles IAM

​

Grupos de Seguridad

• ALB: Auto-creado por AWS Load Balancer Controller (80/443 entrada)
• Cluster EKS: Comunicación nodo a nodo y pod
• Redis: Puerto 6379 solo desde CIDR de VPC
• RabbitMQ: Puertos 5671, 15671 solo desde CIDR de VPC

​

SSL/TLS

• Terminación: A nivel de ALB (los pods ven HTTP plano internamente)
• Certificados: Certificados ACM — por servicio o un solo wildcard
• Validación: Validación DNS CNAME vía su proveedor de DNS
• Protocolo mínimo: TLS 1.2

​

6. Infraestructura como Código

​

Módulos Terraform

• modules/eks: Cluster EKS, VPC, grupos de nodos, Karpenter, IAM, releases de Helm
• Estado: Bucket S3 con versionado, tabla de bloqueo DynamoDB

​

Terragrunt

• Aislamiento de entornos: Un directorio por entorno bajo terragrunt/environments/
• Plantilla: env-template-folder — copiar y completar placeholders para crear un nuevo entorno
• Configuración DRY: root.hcl compartido con overrides por entorno
• Banderas de habilitación/deshabilitación: Servicios activados vía variables de entorno (ENABLE_*)

​

Charts Helm

​

Flujo de Datos

​

1. Flujo de Solicitud del Usuario

Usuario → DNS → ALB (terminación SSL) → Pod EKS (Frontend Web)
                                     → Pod EKS (Backend FastAPI)
                                     → Pod EKS (Supabase Kong)

1. El usuario accede a app.example.com
2. DNS resuelve al ALB
3. ALB termina SSL y enruta por hostname al grupo objetivo correcto
4. El Frontend Web sirve la aplicación React y realiza llamadas API a api.example.com
5. El Backend FastAPI procesa solicitudes y lee/escribe en servicios de datos

​

2. Flujo de Solicitud API

Cliente → ALB → Backend FastAPI → Redis (caché) / RabbitMQ (cola) / Supabase (DB)

1. El cliente llama a api.example.com
2. ALB enruta al pod de FastAPI
3. El backend verifica la caché de Redis; en caso de miss, consulta la base de datos Supabase
4. Las tareas asíncronas se encolan en RabbitMQ y son procesadas por Workers Celery

​

3. Flujo de Procesamiento en Segundo Plano

FastAPI → RabbitMQ → Worker Celery → DB Supabase

1. FastAPI encola una tarea en RabbitMQ
2. Worker Celery desencola y procesa la tarea
3. Los resultados se escriben en la base de datos Supabase

​

4. Flujo de Automator

Automator → PostgreSQL (local) → Redis → APIs Externas

1. Automator recibe una solicitud de flujo de trabajo
2. El estado del flujo de trabajo se persiste en la instancia PostgreSQL local
3. Redis almacena en caché los resultados intermedios
4. Se llaman APIs externas como parte de la automatización

​

5. Flujo de Escalado

Métricas → KEDA → Escalado de pods → Karpenter → Provisionamiento de nodos

1. KEDA evalúa las métricas de CPU/Memoria contra los umbrales configurados
2. Los pods se escalan horizontalmente dentro del rango de réplicas configurado
3. Si la capacidad del clúster es insuficiente, Karpenter provisiona nuevos nodos EC2 (prefiriendo Spot)
4. Cuando la carga disminuye, KEDA reduce los pods; Karpenter consolida y termina nodos inactivos

​

6. Flujo de Seguridad

Internet → ALB (TLS 1.2+, ACM) → Grupos de Seguridad → Pods → Roles IAM IRSA → APIs AWS

1. Todo el tráfico externo termina TLS en el ALB
2. Los grupos de seguridad aplican acceso de red de menor privilegio
3. Los pods se comunican con servicios AWS vía IRSA (IAM Roles for Service Accounts)

​

Resumen de Alta Disponibilidad

​

Optimización de Costos

• Instancias Spot: Karpenter prioriza Spot para todas las cargas de trabajo que no sean de bases de datos
• Consolidación de nodos: Karpenter reclama automáticamente nodos subutilizados
• Dimensionamiento correcto de pods: KEDA reduce los pods durante períodos de baja actividad
• Solo bajo demanda donde se necesita: La clase de nodo de base de datos usa bajo demanda para estabilidad

​

Mantenimiento y Operaciones

​

Proceso de Despliegue

cd terragrunt/environments/<your-env-name>
# Establecer variables de entorno ENABLE_* y dominio/certificado requeridas
terragrunt apply
# Actualizaciones rolling: volver a aplicar después de actualizar etiquetas de imagen o archivos de valores

​

Estrategia de Respaldo

• Snapshots EBS: Snapshots automáticos para volúmenes persistentes (DB de Automator, MinIO de Supabase)
• CloudNativePG: Archivado continuo de WAL + respaldos base programados (si está configurado)
• Supabase Cloud: Respaldos diarios administrados (opción cloud)
• Estado IaC: Bucket S3 versionado

​

Recuperación ante Desastres

• Multi-AZ: Todos los servicios con estado abarcan múltiples zonas de disponibilidad
• HA de CloudNativePG: Failover automático entre el primario de Postgres y las réplicas
• Supabase Cloud: Redundancia multi-región (opción cloud)
• Estado de Terraform: El versionado de S3 permite revertir a cualquier estado anterior

​

Recursos Adicionales

• AWS Load Balancer Controller
• Documentación de Karpenter
• Documentación de KEDA
• Documentación de CloudNativePG
• Supabase Self-hosting
• Documentación de SigNoz
• Guía de Despliegue con Terragrunt