Optimización de Costos y Escalabilidad en Plataformas Multi-Marca con ECS

El problema fundamental de la computación que aborda este artículo es la gestión ineficiente de recursos en sistemas distribuidos multi-inquilino, donde la replicación completa de la infraestructura por cada inquilino (marca) conduce a una escalada lineal de costos y una baja utilización de recursos. Este desafío se agrava en entornos de alta variabilidad de tráfico, como las plataformas de pedidos de comida, donde los picos de demanda son impredecibles y la latencia en el escalado se traduce directamente en pérdidas de negocio.

La solución propuesta se centra en el concepto de aislamiento a nivel de aplicación, en contraste con el aislamiento a nivel de infraestructura. Esto permite la consolidación de recursos computacionales, logrando economías de escala sin comprometer la seguridad o la separación de datos entre inquilinos. La necesidad de esta aproximación se ha vuelto más crítica con el crecimiento exponencial de las plataformas SaaS y la madurez de las tecnologías de contenedores, que facilitan la abstracción y el empaquetado de servicios, pero requieren estrategias sofisticadas para la gestión de la tenencia.

Arquitectura del Sistema

La arquitectura evolucionada de OrderServ se basa en cuatro pilares principales. Primero, un clúster compartido de Amazon ECS con una 'tenancy library' de .NET Core para el aislamiento a nivel de aplicación. Esta biblioteca es crítica para resolver el contexto del inquilino (X-Tenant-Id header), enrutar el acceso a datos (DynamoDB, Aurora, Valkey), y propagar el contexto en llamadas de servicio a servicio y mensajes asíncronos (SQS/SNS). Utiliza AsyncLocal<T> para el almacenamiento de contexto por solicitud y sts:AssumeRole con session tags para adquirir credenciales con alcance de inquilino, reforzando el aislamiento a nivel de IAM.

Segundo, para el escalado, se migró de AWS Fargate a grupos de Auto Scaling de EC2 con 'warm pools' y Bottlerocket OS. Las instancias en el 'warm pool' se pre-inicializan y detienen, reduciendo el tiempo de arranque de 5-7 minutos a 30-60 segundos. Se implementa una estrategia de escalado de cinco capas: predictivo (machine learning, eventos programados), reactivo (Target Tracking en ALBRequestCountPerTarget), 'headroom' (capacidad objetivo del 80%), 'downstream' (ECS Service Connect RequestCount) y 'throttling' (API Gateway per-tenant rate limits).

Tercero, una 'crash observability pipeline' robusta. Los logs estructurados en JSON con X-Ray trace IDs se envían a un sidecar FireLens (Fluent Bit), que los enruta a CloudWatch Logs (Infrequent Access) y Amazon S3 para retención a largo plazo. Amazon EventBridge captura eventos de cambio de estado de tareas con metadatos completos. AWS Distro for OpenTelemetry (ADOT) proporciona trazas a X-Ray, y Amazon EFS persiste los 'mini dumps' de .NET Core para análisis forense post-crash.

Finalmente, la autenticación multi-inquilino se modernizó con 'passkeys' (WebAuthn) a través de Amazon Cognito. Cada marca utiliza un 'Cognito User Pool' distinto con un 'Relying Party ID' único para aislamiento criptográfico. Una función Lambda Post-Authentication mantiene un perfil de autenticación del cliente en DynamoDB, utilizando un hash del ID de marca y el número de teléfono como clave, asegurando que los datos de autenticación estén aislados por marca.

public static class TenantContext
{
    private static readonly AsyncLocal<string> _tenantId = new AsyncLocal<string>();

    public static string CurrentTenantId
    {
        get => _tenantId.Value;
        set => _tenantId.Value = value;
    }
}

null

Fundamentos Teóricos

El concepto de aislamiento a nivel de aplicación versus aislamiento a nivel de infraestructura resuena con los principios de diseño de sistemas distribuidos que buscan maximizar la utilización de recursos a través de la multiplexación, mientras se mantienen las garantías de seguridad y consistencia. Esto se relaciona con trabajos sobre 'resource management' y 'multi-tenancy' en entornos de 'cloud computing', donde la eficiencia operativa y la elasticidad son primordiales. Aunque no se cita un paper específico, la filosofía subyacente se alinea con la búsqueda de soluciones de 'software-defined networking' y 'software-defined storage' que abstraen la complejidad del hardware y permiten una gestión más granular y programática de los recursos.

La estrategia de 'warm pools' para el escalado rápido puede verse como una aplicación práctica de técnicas de 'resource provisioning' y 'scheduling' que buscan minimizar los tiempos de arranque ('cold start problem') en entornos elásticos. Esto tiene paralelos con la investigación en 'virtual machine placement' y 'container orchestration' que optimizan la asignación de recursos para satisfacer demandas variables con latencia mínima. La resiliencia de la 'observability pipeline' frente a fallos de contenedores, utilizando sidecars y almacenamiento duradero, refleja principios de 'fault tolerance' y 'eventual consistency' en la recolección de datos distribuidos, asegurando que la información crítica no se pierda incluso en condiciones de fallo.