Introducción al modulo de Balanceo y Auto escalamiento

Balanceo de Carga y Auto Escalamiento en AWS: Fundamentos para Alta Disponibilidad

En 2023, durante el lanzamiento de su nueva tarjeta de crédito sin comisiones, Nexia Bank experimentó un aumento repentino del 800% en el tráfico digital: usuarios solicitando la tarjeta, simulando beneficios y accediendo a promociones especiales. En un solo día, se procesaron miles de millones de solicitudes sin que el servicio sufriera ni un segundo de interrupción.

¿El secreto? Una arquitectura sólida basada en Elastic Load Balancer (ELB) y Auto Scaling de AWS. El balanceo de carga distribuyó eficientemente el tráfico entre múltiples instancias, mientras que el auto escalamiento ajustó dinámicamente la capacidad de procesamiento según la demanda.

Este ejemplo real demuestra cómo Nexia Bank construyó una plataforma digital resiliente y preparada para escalar automáticamente, garantizando disponibilidad y rendimiento incluso en los momentos de mayor presión operativa.

Balanceadores de Carga: Nivel 4 vs Nivel 7

Los balanceadores de carga en AWS se dividen principalmente en dos categorías según el nivel del modelo OSI en el que operan:

Network Load Balancer (NLB) - Nivel 4

El NLB opera en la capa de transporte, trabajando directamente con conexiones TCP/UDP. Esto significa que:

• Procesa millones de solicitudes por segundo con latencia ultra baja
• Mantiene una única dirección IP estática por zona de disponibilidad
• Es ideal para aplicaciones que requieren rendimiento extremo o protocolos no HTTP
• No inspecciona el contenido del paquete, solo dirige el tráfico basándose en IP y puerto

# Ejemplo de conexión a un NLB
tcp://nlb-example-12345678.us-east-1.elb.amazonaws.com:80

Application Load Balancer (ALB) - Nivel 7

El ALB opera en la capa de aplicación, lo que le permite:

• Analizar el contenido de las solicitudes HTTP/HTTPS
• Enrutar basándose en patrones de URL, encabezados, métodos HTTP
• Implementar enrutamiento basado en contenido (path-based routing)
• Soportar WebSockets y protocolos HTTP/2
• Integrar directamente con servicios como AWS WAF para seguridad adicional

# Ejemplo de regla de enrutamiento en ALB
IF path = "/api/*" THEN forward to target-group-api
IF path = "/images/*" THEN forward to target-group-images

La elección entre NLB y ALB depende de los requisitos específicos de la aplicación. El ALB es más versátil para aplicaciones web tradicionales, mientras que el NLB es preferible cuando se necesita rendimiento extremo o soporte para protocolos no HTTP.

Auto Scaling de EC2

Auto Scaling permite ajustar automáticamente la capacidad de procesamiento según la demanda. Esto se logra mediante la creación y terminación automática de instancias EC2.

Launch Templates vs Launch Configurations

Ambos definen la configuración de las instancias EC2 que Auto Scaling lanzará, pero con diferencias importantes:

• Launch Templates (recomendado):
  • Soporta versionamiento
  • Permite configuración parcial
  • Compatible con instancias Spot
  • Puede ser usado fuera de Auto Scaling
• Launch Configurations (legacy):
  • No se puede modificar una vez creada
  • No soporta versionamiento
  • Funcionalidad más limitada

// Ejemplo simplificado de Launch Template
{
  "ImageId": "ami-0abcdef1234567890",
  "InstanceType": "t3.micro",
  "SecurityGroupIds": ["sg-0123456789abcdef0"],
  "KeyName": "my-key-pair",
  "UserData": "IyEvYmluL2Jhc2gKZWNobyAiSGVsbG8gV29ybGQi"
}

Políticas de Cool-down

El período de cool-down es un tiempo de espera después de una actividad de escalado durante el cual Auto Scaling no inicia actividades adicionales. Esto evita fluctuaciones rápidas en el número de instancias:

• El valor predeterminado es 300 segundos (5 minutos)
• Se puede configurar a nivel de grupo o de política específica
• Permite que las métricas se estabilicen antes de tomar nuevas decisiones

# Ejemplo de configuración de cool-down
aws autoscaling put-scaling-policy \\
  --auto-scaling-group-name my-asg \\
  --policy-name my-scale-out-policy \\
  --cooldown 180

Durante eventos de alta demanda, un período de cool-down demasiado largo podría retrasar la respuesta a picos de tráfico, mientras que uno demasiado corto podría causar oscilaciones innecesarias en el número de instancias.

Métricas de Escalado

Auto Scaling utiliza métricas para determinar cuándo escalar horizontal o verticalmente. Las métricas más comunes incluyen:

Métricas de CPU

• La más utilizada por su correlación directa con la carga
• Recomendación: escalar cuando el uso de CPU supera el 70% durante 2-3 períodos consecutivos

Métricas de Memoria

• Requiere configuración adicional con CloudWatch Agent
• Crítica para aplicaciones con uso intensivo de memoria como bases de datos en memoria

RequestCount por Target

• Mide el número de solicitudes completadas por instancia
• Ideal para aplicaciones web con cargas de trabajo predecibles

Métricas de Cola SQS

• Número de mensajes en cola
• Excelente para arquitecturas basadas en procesamiento asíncrono

# Ejemplo de política de escalado basada en CPU
aws autoscaling put-scaling-policy \\
  --auto-scaling-group-name my-asg \\
  --policy-name cpu-policy \\
  --policy-type TargetTrackingScaling \\
  --target-tracking-configuration file://config.json

# Contenido de config.json
{
  "TargetValue": 70.0,
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "ASGAverageCPUUtilization"
  }
}

También es posible crear métricas personalizadas para casos de uso específicos, como el tiempo de respuesta de la aplicación o la tasa de errores.

Diversificación de Costos: Instancias Spot y On-Demand

Una estrategia efectiva para optimizar costos es combinar diferentes tipos de instancias en el mismo grupo de Auto Scaling:

Instancias On-Demand

• Precio fijo y predecible
• Sin riesgo de interrupción
• Ideales para cargas de trabajo críticas y estables

Instancias Spot

• Hasta 90% de descuento sobre el precio On-Demand
• Pueden ser interrumpidas con 2 minutos de aviso
• Perfectas para cargas de trabajo tolerantes a fallos y flexibles en tiempo

Para implementar esta estrategia:

# Ejemplo de configuración de grupo mixto
aws autoscaling create-auto-scaling-group \\
  --auto-scaling-group-name mixed-instances-asg \\
  --mixed-instances-policy file://mixed-policy.json

# Contenido de mixed-policy.json (simplificado)
{
  "LaunchTemplate": {
    "LaunchTemplateSpecification": {
      "LaunchTemplateName": "my-template",
      "Version": "$Latest"
    }
  },
  "InstancesDistribution": {
    "OnDemandPercentageAboveBaseCapacity": 50,
    "OnDemandBaseCapacity": 2,
    "SpotAllocationStrategy": "capacity-optimized"
  }
}

Esta configuración mantiene un mínimo de 2 instancias On-Demand y distribuye el resto como 50% On-Demand y 50% Spot, utilizando la estrategia "capacity-optimized" para minimizar interrupciones.

Patrones de Alta Disponibilidad (Multi-AZ)

La implementación Multi-AZ es fundamental para garantizar la alta disponibilidad:

Distribución en múltiples Zonas de Disponibilidad

• Mínimo recomendado: 3 AZs
• Protege contra fallos de infraestructura a nivel de zona
• Los balanceadores de carga distribuyen el tráfico solo a instancias saludables

Configuración de Auto Scaling para Multi-AZ

# Ejemplo de configuración Multi-AZ
aws autoscaling create-auto-scaling-group \\
  --auto-scaling-group-name multi-az-asg \\
  --vpc-zone-identifier "subnet-1234abcd,subnet-5678efgh,subnet-9012ijkl" \\
  --availability-zones "us-east-1a,us-east-1b,us-east-1c"

Estrategias de balanceo entre AZs

• AZ-Aware Balancing: mantiene distribución uniforme entre zonas
• Cross-Zone Load Balancing: distribuye tráfico uniformemente entre todas las instancias independientemente de la zona

La combinación de balanceadores de carga y Auto Scaling configurados para operar en múltiples zonas de disponibilidad proporciona resiliencia contra diversos tipos de fallos, desde problemas de hardware en instancias individuales hasta interrupciones completas de una zona de disponibilidad.

Consideraciones Finales

El balanceo de carga y el auto escalamiento son pilares fundamentales para construir arquitecturas resilientes en AWS. Al implementar correctamente estos servicios, podemos crear aplicaciones que no solo resisten fallos, sino que también se adaptan dinámicamente a cambios en la demanda, optimizando tanto el rendimiento como los costos. Como arquitectos de soluciones, debemos entender las características y limitaciones de cada servicio para diseñar sistemas que cumplan con los principios del Well-Architected Framework, especialmente en términos de fiabilidad, rendimiento y optimización de costos.