plataforma · aws
Análisis de sobrecarga de APIs
CloudWatch, logs del balanceador y p95 para encontrar el cuello de botella con datos, no con intuición.
- tipo
- profesional
- rol
- Análisis de tráfico y observabilidad
- stack
- cloudwatch · alb logs · s3 · python
- resultado
- Causa de la sobrecarga explicada con datos y servicio estable en horas punta
Encontré por qué una API en producción se saturaba en horas punta. No era solo más uso: cada sesión abierta lanzaba peticiones de fondo que multiplicaban la carga. Con eso, el escalado dejó de ser a ciegas y hubo un plan de mejora con datos.
El punto de partida
La plataforma se saturaba de forma recurrente en las franjas de más actividad. La CPU se mantenía alta y el servicio se degradaba justo cuando más gente lo usaba.
Lo fácil era subir la instancia y seguir. Pero escalar sin entender la causa solo compra tiempo y tapa el problema.
Qué hice
Me propuse explicar la sobrecarga con datos antes de tocar nada. Crucé las métricas de CloudWatch con los logs del balanceador (ALB) y con el comportamiento de la aplicación.
El objetivo no era apagar el fuego. Era poder justificar el escalado y abrir un plan de mejora con evidencia.
Cómo lo hice
Logs del ALB
Activé los logs del balanceador, que se guardan en S3. Ese volumen no se puede leer a mano, así que monté un pequeño flujo para tratarlos.
Agregación
Descargué los logs y los procesé con scripts. Agrupaban las peticiones y sacaban lo relevante: volumen, errores, reintentos y endpoints más usados.
Análisis
Con los datos agregados saqué los patrones de carga, las horas críticas, la latencia p95 y los endpoints más calientes. Todo salía de tráfico real que ya registraba la infraestructura.
Cierre del círculo
Con el sistema estable, crucé los registros de actividad de la aplicación con los picos de infraestructura. Así tuve la foto completa: qué hacían los usuarios y qué provocaba en la API.
Resultado
La causa quedó explicada y el servicio dejó de degradarse en horas punta.
En las horas punta, una acción del usuario no generaba una sola petición. La aplicación lanzaba en paralelo varias peticiones de fondo (notificaciones, chat, tareas pendientes), aunque el usuario no tocara esos módulos. Multiplicado por mucha gente a la vez, eso ahogaba la API. De ahí salieron tres decisiones:
- Software: incidencias concretas para reducir esas peticiones de fondo y limpieza de datos antiguos que añadían carga.
- Escalado justificado: como medida inmediata se subió el tipo de instancia, y el sistema se estabilizó mientras llegaban los cambios.
- Base para decidir: datos sólidos para planificar capacidad y optimización más adelante.
La sobrecarga era la suma de un crecimiento real del uso, un patrón de peticiones internas y una infraestructura sin margen.
Qué me llevo
La observabilidad sirve cuando pasa de «la CPU está alta» a «este tráfico, a estas horas, por este motivo». Con esa frase, escalar y arreglar el software dejan de competir y se apoyan.