- Identificación del problema
- Se producían retrasos intermitentes en la respuesta del servidor de autenticación de Airbridge.
- Como la autenticación/autorización se realiza antes de las solicitudes API, la latencia del servidor de autenticación afecta directamente la estabilidad de todo el servicio.
- Según el monitoreo, las alertas por demoras de respuesta de más de 1 segundo se volvían cada vez más frecuentes → se inició el análisis de causas y el trabajo de optimización.
- Análisis de causas
- (1) Exceso de consultas a la BD: durante la verificación de permisos se ejecutaban demasiadas consultas a la BD por cada solicitud, lo que agotaba rápidamente el DB Connection Pool → se generaban retrasos en la respuesta.
- (2) Saturación del Connection Pool de HikariCP: al ejecutarse demasiadas consultas a la BD, el pool de HikariCP se saturaba → se confirmó una espera de hilos de más de 30 segundos.
- (3) Baja eficiencia de caché: TTL configurado demasiado corto, en 30 segundos, + lógica de caché ineficiente → alta probabilidad de que se repitieran las consultas a la BD.
- Estrategia de mejora
- (1) Mejora de la estructura de verificación de permisos y caché
- Se introdujo el método de consulta masiva a la BD (
findAllBy~) → las consultas a la BD se redujeron de 134 a 4 (-97%).
- Se aplicó caché basada en memoria de la aplicación con
mutableMap.
- Se aplicó el principio de responsabilidad única (SRP) → separación de métodos y definición de estrategias de caché por lógica subordinada.
- (2) Implementación de una estructura de caché de 2 capas
- Se aplicó una estructura mixta de Local Cache (Caffeine, L1) + Remote Cache (Redis, L2).
- La estrategia de caché se subdividió en L1-Only, L2-Only y Hybrid para mejorar la eficiencia operativa.
- Se analizó el uso de memoria de la caché → se estimaron 500 mil claves de Redis, con un requerimiento aproximado de 190MB de memoria, asegurando un margen de seguridad.
- (3) Invalidación de caché basada en Redis Pub/Sub
- Se dejó de depender del TTL y se sincronizó la caché en tiempo real cuando cambiaba la información de permisos.
- Si había un cambio en un servidor, el Local Cache de todos los servidores se invalidaba de forma sincronizada a través de un canal de Redis.
- (4) Ajuste fino del pool de conexiones de HikariCP
maximum-pool-size se amplió de 10 a 30.- Se optimizaron opciones detalladas como Connection Timeout, Idle Timeout y Max Lifetime → se alivió la contención de DB I/O.
- Pruebas de rendimiento y resultados: se mantuvo un rendimiento estable incluso con tráfico a gran escala.
- Efectos de la mejora en el entorno de operación
- Después del despliegue, desaparecieron las alertas por retrasos de respuesta y se estabilizó el tiempo de respuesta general.
- La confiabilidad del servicio y la estabilidad operativa mejoraron considerablemente.
- Optimización adicional: JVM Warm-Up
- Se detectó un problema de latencia en las respuestas iniciales causado por el retraso de la compilación JIT justo después del despliegue.
- Se introdujo un Warm-Up Runner:
- Ejecuta solicitudes dummy por adelantado al iniciar la aplicación.
- Durante el reemplazo de Pods en K8s, el tráfico se procesa después de completar el JIT → el tiempo de respuesta inicial se redujo de 1.07s a 94ms.
- Conclusión y efectos
- Se resolvió el problema de latencia en la respuesta + se aseguró una estructura capaz de responder a aumentos repentinos del tráfico.
- Mejoró la estabilidad y confiabilidad general del servicio de Airbridge.
- Se incrementó el aprovechamiento del servidor de autenticación, mejorando la productividad en el desarrollo de servicios de dominio.
2 comentarios
Parece que últimamente han aumentado las empresas que usan este servicio debido al cierre reciente del servicio de deep links de Google.
¡Espero que ofrezcan un servicio estable!
Eh... nuestra empresa también firmó recientemente aquí, así que veo que están trabajando duro para mejorar el rendimiento!!!