¿Está bien mi lógica de autoescalado con AWS Lambda y SQS?

Traveler

Hola a todos, estoy diseñando un sistema de procesamiento de colas con AWS Lambda y SQS, pero tengo dudas sobre la lógica de autoescalado. Mi setup:

SQS estándar con un batch de 10 mensajes.
Lambda con un máximo de 1000 concurrencias reservadas.
Procesa mensajes que pueden tardar entre 1 y 30 segundos.

El problema: cuando la cola crece, Lambda escala rápidamente, pero a veces se dispara demasiado y luego baja de golpe, dejando mensajes sin procesar. Mi lógica actual es: si la cola tiene más de 1000 mensajes, aumento la concurrencia de Lambda en 100 cada minuto. Si baja de 100, reduzco en 50. ¿Ven algún problema? Acepto sugerencias de arquitectura o correcciones.

HipHop

Tu enfoque tiene un problema de histéresis: estás escalando linealmente pero los picos pueden ser abruptos. Considera usar AproximatedNumberOfMessagesVisible de CloudWatch con una alarma que escale basada en la tasa de cambio. Por ejemplo, si la cola crece un 20% en 5 minutos, escala un 30% de concurrencia. Además, evita escalar tan rápido (100 cada minuto) porque Lambda tiene límites de concurrencia que pueden causar throttling. Mejor usa ReservedConcurrency con un límite máximo y deja que AWS maneje el escalado automático si usas SQS como evento. ¿Has probado con una función Lambda que use el batch con visibilidad timeout dinámico?

Comedy

Estoy de acuerdo con el punto anterior. Otra opción es usar Step Functions para controlar el flujo y evitar el sobreescalado. Podrías tener un estado que evalúe la longitud de la cola y decida cuántas invocaciones hacer. También revisa tu lógica de reducción: reducir de 100 a 50 cuando baja de 1000 mensajes puede causar oscilaciones. Te sugiero usar un escalado basado en cola (por ejemplo, target de 100 mensajes por instancia) como lo harías con ASG. Implementa algo como:

if (queueDepth > 1000) { increaseConcurrencyBy(20%); } else if (queueDepth < 100) { decreaseConcurrencyBy(10%); } else { noop; }

Así evitas saltos bruscos.

Traveler

Gracias por las sugerencias. Lo del escalado basado en porcentaje tiene sentido para evitar los picos. Pero tengo una duda: si uso CloudWatch, ¿no hay latencia en las alarmas? He visto que a veces tardan hasta 2 minutos en dispararse. ¿Alguien ha probado con Lambda Extensions para monitorear SQS en tiempo real? Otra cosa, sobre el batch: ¿es mejor procesar mensajes de 1 en 1 o en batch de 10? He leído que batch reduce costos pero aumenta la complejidad si falla un mensaje.

Gamer

La latencia de CloudWatch es real, pero puedes mitigarla usando Amazon SQS Extended Client o midiendo la cola desde la propia Lambda (por ejemplo, con una llamada a getQueueAttributes al inicio de cada invocación). Sobre el batch: recomiendo batch de 10 con reportBatchItemFailures en la función Lambda para que los mensajes fallidos vuelvan a la cola. Así no pierdes mensajes y sigues siendo eficiente. En cuanto a escalado, prueba con Application Auto Scaling para funciones Lambda con SQS como fuente; ya trae políticas de target tracking basadas en cola.

Security

Ojo con el batch: si usas 10 mensajes y uno falla, todo el batch se considera fallido a menos que implementes reportBatchItemFailures. Además, si tus mensajes tienen tiempos de procesamiento variables (1-30 segundos), el batch puede aumentar la latencia general. En mi experiencia, para cargas burst, es mejor empezar con 1 mensaje por invocación y luego ir ajustando. También considera usar SQS FIFO si el orden es importante. ¿Tu lógica de autoescalado incluye métricas de backlog per instance? Porque sin eso, podrías estar escalando por volumen total, no por capacidad real.

Traveler

Buen punto lo del backlog per instance. Voy a investigar cómo implementar target tracking con Application Auto Scaling. Lo del reportBatchItemFailures no lo conocía, lo implementaré. Gracias a todos por las ideas, me han ayudado a replantear la arquitectura. Si alguien tiene un ejemplo de política de escalado con CloudFormation, se lo agradecería.

Transit

Ejemplo de política de target tracking en CloudFormation: Type: AWS::ApplicationAutoScaling::ScalingPolicy con TargetTrackingScalingPolicyConfiguration y métrica personalizada SQS:ApproximateNumberOfMessagesVisible. Para backlog per instance, divide esa métrica entre el número de invocaciones concurrentes (métrica CloudWatch ConcurrentExecutions). Te dejo snippet:

TargetTrackingScalingPolicyConfiguration: TargetValue: 10 PredefinedMetricSpecification: PredefinedMetricType: SQSBacklogPerInstance

¿Has considerado el coste de invocaciones fallidas con batch grande? Yo suelo usar batch de 5 con reportBatchItemFailures para balancear eficiencia y fiabilidad.