Cómo Klever mantiene los ojos constantemente abiertos para garantizar un alto rendimiento y disponibilidad de los servicios, y cómo este monitoreo ayuda no solo a resolver problemas sino también a permitir una mejora continua del rendimiento.
Probablemente haya oído hablar de las prácticas de DevOps y de cómo ayuda a ofrecer continuamente mejores productos y servicios. Si no, te invito a leer este article, con una explicación un poco más profunda sobre esto.
Hoy hablaremos sobre la monitorización, que es una parte importante del ciclo de vida de las aplicaciones que se utilizan en DevOps.
Durante años, el monitoreo se pensó solo como una forma de descubrir cuándo ocurren los problemas y solo tenía una función: alertar al equipo responsable para que lo resolviera, los equipos generalmente trabajaban como bomberos y luego nadie hablaba de eso.
No creemos que sea una forma de trabajar de Klever, ya que la supervisión nos brinda muchos conocimientos y el solo hecho de usarlos durante la resolución de problemas es un desperdicio de datos e información valiosos.
En esta serie de artículos, nuestro objetivo no es (al menos por ahora 😉) escribir sobre cómo implementamos las prácticas de ingeniería de confiabilidad del sitio, sino mostrarle dos optimizaciones de rendimiento realizadas recientemente por el equipo de DevOps de Klever, entregadas al ecosistema de Klever y por qué solo fue posible con Observability.
Servicios distribuidos globalmente
Un método que usamos para monitorear la disponibilidad de nuestros servicios es probar cada uno de ellos con pruebas sintéticas.
El monitoreo sintético es una técnica que utiliza formas de emular el comportamiento del usuario para garantizar el funcionamiento de los sistemas monitoreados.
El flujo de acciones del usuario se emula a través de otro software, generalmente scripts, y se ejecutan repetidamente en intervalos de tiempo específicos para mediciones de rendimiento como: funcionalidad, disponibilidad y tiempo de respuesta.
En pocas palabras, tenemos "robots" en diferentes partes del mundo que emulan las funcionalidades de nuestra aplicación, y si algún bot no puede completar la tarea, se envía una alerta a nuestro equipo, que luego toma medidas proactivas.
Esto funciona muy bien para descubrir problemas en el momento en que ocurre, pero también nos da el tiempo de respuesta de nuestros servicios en todas las ubicaciones, y más, la herramienta de monitoreo también divide el tiempo invertido en cada parte de las transacciones HTTP.
- conectar
- procesando
- resolver
- tls
- transferir
Con estos datos pudimos observar que para algunas ubicaciones, las solicitudes estaban demorando demasiado en tres fases: conexión, tls y transferencia.
Solución al problema de latencia global
Reducir el tiempo de conexión y transferencia es un desafío. La solución es "mover" las aplicaciones de back-end lo más cerca posible de los clientes para reducir la latencia de la red.
Como Klever tiene una base de usuarios en todo el mundo y clientes en todas partes del mundo, replicar nuestros servicios para todas las regiones podría resultar costoso y difícil de mantener. Por este motivo, decidimos migrar de nuestro equilibrio de carga tradicional a GCLB de Google, que proporciona equilibrio de carga entre regiones con puntos de presencia (PoP) en todo el mundo.
Una vez que se establecen las conexiones en el PoP más cercano, todo el tráfico a nuestro backend de kubernetes y las bases de datos viajan en la red interna de Google, también trasladamos la terminación de TLS de ingress-nginx al balanceador de carga de borde para reducir el tiempo de TLS. Con este movimiento, el tiempo de respuesta promedio se redujo a la mitad, como se muestra en el cuadro a continuación.
Tiempo de respuesta de la API del swap
Esta optimización del tiempo de respuesta de la API de Klever Swap es inherentemente diferente del primer ejemplo, ya que no implica ningún cambio de infraestructura.
Nuestra pila de monitoreo nos ayudó a identificar los cuellos de botella y, junto con el equipo de Swap, hicimos cambios en el código fuente que dieron como resultado una mejora del 60% en el tiempo de respuesta para el método API más llamado, el que es responsable de la lista de pares de claves activos de Swap.
Con un movimiento de Klever y un menor consumo de CPU del servidor, la velocidad de todos los Swaps en Klever aumentó significativamente.
En arquitecturas de software distribuido como las que utiliza Klever para servir a nuestros usuarios en todo el mundo, a veces es difícil encontrar qué paso exacto en todo el proceso de computación distribuida es la causa principal de cualquier posible lentitud detectada.
Por esta razón, el seguimiento distribuido es fundamental para comprender cómo se mueve una solicitud a través de múltiples servicios, paquetes y componentes de infraestructura.
En este escenario específico, con el seguimiento distribuido, nos damos cuenta de que la API fue llamada constantemente, incluso sin una transacción Swap, y encontramos una solución.
Optimizando el tiempo de respuesta de la API del swap
Este es un caso típico de monolito en el que un servicio es responsable de más de un objetivo. Nuestra funcionalidad Swap es fantástica, fácil de usar y fue uno de nuestros primeros servicios en la aplicación. En ese momento, la funcionalidad para devolver los precios de las monedas se construyó dentro de la API de intercambio.
Con la evolución de nuestro producto, el crecimiento de usuarios y el aumento de monedas disponibles para Swap, nos dimos cuenta de que era necesario dividir esta funcionalidad en otro servicio. Esencialmente para separar y distribuir los precios y los servicios de intercambio para hacer que toda la función de intercambio sea más rápida, confiable y eficiente.
Después de este cambio, otras pantallas de la aplicación pueden consultar los precios actuales sin afectar el rendimiento general de Swap y pudimos escalar el servicio por separado según la demanda.
Conclusion
En este artículo presentamos dos ejemplos de cómo el monitoreo continuo de nuestros servicios nos ayuda a brindar productos de alta calidad y en constante evolución a nuestra comunidad de usuarios de Klever.
Por supuesto, la supervisión implica mucho más de lo que hemos cubierto hoy y los conceptos básicos también son muy importantes:
Asegurar que todos los servicios de Klever estén en funcionamiento es el corazón que mantiene nuestra sangre fluyendo.
Una buena estrategia de monitoreo reduce nuestro MTTA y MTTR y permite que nuestro equipo distribuido globalmente disponible las 24 horas del día, los 7 días de la semana, esté siempre al tanto de los posibles problemas y escale mejor para el futuro a través de medidas proactivas. Nuestro CTO Bruno habló un poco sobre esto en su artículo aquí.
Seguir rastreando los microservicios es un desafío en las arquitecturas de software distribuidas y el monitoreo es un ciclo de progreso continuo para el equipo de Klever DevOps. ¡Pero eso es una charla para otro momento!
Atentamente,
Kadu Relvas Barral
Klever’s Site Reliability Engineer
Kadu tiene más de 15 años de experiencia profesional en TI y pasó los últimos 10 años trabajando en compañías de seguros, telecomunicaciones y financieras tratando de encontrar lo que estaba averiado en sus sistemas antes de que otros se dieran cuenta. Maratonista en el tiempo libre, le gusta correr y mantener las aplicaciones en funcionamiento.