Menta

Blog

Claves de la salud integral de tu aplicación web: consejos de optimizaciones y correcciones por un SRE

Conoce las señales que necesitas identificar para saber si tu aplicación está funcionando correctamente y cómo puedes optimizarlas y corregirlas en esta entrevista con el SRE Alfonso Sánchez.

Sabemos que existen ciertas métricas que nos pueden indicar si una aplicación está o no funcionando correctamente. Estas métricas pueden ser definidas como signos vitales. ¿Por qué los llamamos así?, porque cuando vas a una consulta con el doctor, éste revisa tu respiración, temperatura, frecuencia cardiaca y presión arterial. De manera análoga, si estás a cargo de una aplicación revisas la latencia, el porcentaje de errores, tráfico y la saturación.

Para tener una experiencia de primera mano, nos acercamos con Alfonso Sánchez, ingeniero de integridad tecnológica (SRE) en Menta Network. Él está encargado de diagnosticar problemas en cualquier plataforma tecnológica y determinar sus áreas de oportunidad, por lo cual nos dio algunos tips y consejos para detectar convenientemente si alguno de esto signos vitales está fallando y cómo podemos optimizarlo o corregirlo.

1. ¿Cuándo te detienes a analizar tu aplicación y por qué?

El objetivo de cualquier aplicación es dar un buen servicio a los usuarios. Por ello, las métricas, que son los signos vitales de cualquier aplicación, deben ser analizadas a partir del servicio que ofrezco a mis clientes. De este modo, si la respuesta es “no estoy dando un buen servicio a mi cliente“, debo investigar qué está fallando. Debemos recordar que, más que poner objetivos arbitrarios y decir: ‘mi latencia tiene que ser de equis cantidad. Mi throughput tiene que ser de tanto’, la idea es identificar los problemas del usuario y relacionarlos con alguna de métrica y decir ‘ok, los usuarios se quejan de que de 8 pm a 12 am el sitio está muy lento’. Con esta información, se analiza que en ese momento el througput sube y la latencia también. Esto significa que, para resolver el problema, debo conseguir que, con el mismo throughput, se reduzca la latencia. Es así como, a partir de un problema de los usuarios, es que detectamos que algo está fallando. En la analogía con el doctor. Te pregunta los síntomas que tienes, pero también te pregunta en qué circunstancias te duele la cabeza, por ejemplo. Quizá le respondas, ‘cuando corro, cuando me agito’. Después de esto te toma la presión y concluye te duele la cabeza cuando estás estresado, cuando estás haciendo actividad física y esto sube tu presión.

Tendríamos que escuchar al usuario y relacionar las métricas con situaciones en las que está sufriendo. Porque si hacemos un diagnóstico sin tener información, se hacen cambios en el sistema y luego te das cuenta de que el problema sigue sin resolverse. La métrica te ayuda a darte cuenta cuándo resolviste finalmente el problema. Sólo a partir de este análisis puedes concluir, por ejemplo, que se redujo en un 40% la latencia. Volviendo a la analogía del doctor: has estado a dieta, has hecho ejercicio, comes menos sal, entonces tu presión ha bajado y está ahora en parámetros normales. Es una herramienta de diagnóstico, y es el criterio de éxito, pero no es en sí la solución tener la métrica, ya que el número sin análisis no significa nada.

2. Si luego de un análisis se concluye que la latencia de tu aplicación está fallando ¿cómo puedes corregirla?

Depende mucho de la aplicación, pero, en general, el primer paso que yo reviso siempre es que el servidor de aplicaciones no esté procesando muchas veces lo mismo.Es decir, si la página principal es la misma para todos los usuarios, entonces guardo una copia y le mando la misma copia a todos. Muchas veces lo que veo que hace el servidor es que procesa la misma información dos mil veces para cada usuario y ocupa muchos recursos. La primera optimización es ver qué cosas está procesando de más para poder aliviar la carga del servidor. Ése es un tip muy sencillo y que aplica en muchos casos. Por ello, la latencia puede depender de muchos factores. Por ejemplo, más máquinas. Pensemos que un sitio fue lanzado hace 5 años y tiene un servidor de hace 5 años, que funcionaba para tener mil usuarios y ahora la página tiene cinco mil. Aquí la respuesta parece simple: se requiere más equipo. También existe la posibilidad de que la base de datos sea chica, pero tu servidor tarda en responder. En este caso, si no ha cambiado tu número de usuarios y ha cambiado su latencia, se debe revisar, ya que, seguramente, has hecho tu página más complicada. Esto último significa que, al querer darle más opciones a tus usuarios, se meten más botones, más interacciones y la página se alenta. Cuando esto ocurre, vale la pena preguntarse ¿qué es más importante para la usabilidad, darle muchas opciones a los usuarios o hacer que su experiencia base sea buena y esto se traduzca en poca latencia?

Pero, si contrario a lo anterior, lo que ocurre es que has tenido más usuarios y tu servidor tiene problemas al alojar esa cantidad, puede que el error sea de infraestructura y no de código. Eso es difícil determinarlo, pero es más sencillo si lo ves en relación a otras métricas. Es decir, cuando empiezas a correlacionar la latencia con el throughput. Si ves que la latencia desciende proporcionalmente al throughput entonces dirás ‘estoy teniendo problemas en atender a más usuarios, lo que significa que mi servidor me está quedando chico, entonces tengo que buscar más soluciones, ya sea a nivel de código o incluir más servidores’. Sin embargo, la latencia en sí no te dice exactamente cuál es el problema.

3. ¿Cómo podemos saber que existen problemas en la medida en la que aumenta el tráfico en una página web? ¿Hay forma de evitar que esto suceda?

Si el tráfico aumenta es generalmente una buena señal, porque significa que eres más popular. El problema viene cuando comienzas a tener picos en horas en las que ninguno de tus usuarios está conectado. Si tienes picos a las 4 am, muy probablemente no sean usuarios, sino un ataque contra tu sitio. En ese caso, tener más tráfico no es una buena señal, pero en general es algo bueno. Solo cuando sube el tráfico y otras métricas empeoran es cuando sabes que hay un problema.

El crecimiento también tienes que relacionarlo con otras métricas, para saber qué está pasando. Si monitoreas las fallas que tus usuarios reportaron a ciertas horas en específico, y revisas cuánto tráfico hubo, podrás determinar si el problema es ocasionado por una mayor cantidad de tráfico. Siendo así podrás definir cómo resolverlo, para que, cuando haya una cantidad similar de tráfico, o todavía más, esto no siga ocurriendo. Para esto, el servicio de medición de carga y estrés puede ser de gran utilidad, ya que muchas veces el tráfico no aumenta diariamente, sino en picos eventuales, por ejemplo, cada quince días o cuando hay un evento especial como el Hot Sale. Cuando esto ocurre, es complicado replicar las condiciones de esos eventos, por lo que estas pruebas pueden ayudarte a hacerlo.

4. ¿Por qué es importante saber cuál es el throughput de tu aplicación?, ¿cómo se mide, cómo se puede optimizar y corregir?

Es muy evidente cuando llegas a tu límite de capacidad de atención, ya que el tráfico sigue subiendo, pero el throughput se estanca y eso casi siempre es un problema de infraestructura. Como anécdota, los sitios a los que les metemos mucho tráfico sintético en las mediciones de carga suben hasta los 5,000 usuarios, pero generalmente como a los mil o dos mil usuarios el throughput de la aplicación se congela y ya no puede soportar más. Eso generalmente es un límite de infraestructura. Es decir, el servidor puede atender 2,000 máximo, por lo que tienes que incluir más servidores. También hubo un caso en el que el problema era que un cable solo podía mandar cierta cantidad de datos. Ahí es cuando llegas al límite absoluto del software o el hardware y es interesante porque generalmente no te das cuenta. Es como si tuvieras un estacionamiento. Cuando llega a trescientos coches ya no hay lugares y los encargados del estacionamiento cierran. Desactivan las plumas ponen un letrero de “Ya no hay lugar“. Si estás adentro del estacionamiento verás que hay trescientos coches y sabes que ese número responde a la capacidad de atención. Pero quizá no estás viendo que afuera hay mil coches esperando. Tú sólo sabes que en tu sistema puedes atender trescientos autos o dos mil usuarios, y ése es tu límite absoluto, probablemente hasta que no llega la primer gran venta, no te darás cuenta que dos mil usuarios es tu máximo. Siguiendo con el ejemplo anterior, la diferencia sería que, mientras en un estacionamiento sabes cuántos autos caben, en un servidor sólo puedes estimar cuántos usuarios puedes atender y cuántos crees que tu página puede aguantar. Por ello, si sólo estás viendo la información desde el servidor, podrías deducir: ‘lo máximo que he llegado a atender son dos mil usuarios, y nunca me han llegado más, porque no he visto que ese número aumente’. Sin embargo, podrías estar en un error, pues hay la posibilidad de que no estés viendo a los otros mil que se quedaron fuera. En este caso, lo maravilloso de estar en la nube es que puedes poner esos números de manera dinámica. Por ejemplo: de lunes a jueves tendré servidores para atender mil usuarios y los fines de semana lo duplicaré para poder atender hasta cuatro mil y en un Hot Sale voy a subirlo para poder atender hasta ocho mil usuarios. Entonces tú dinámicamente podrás ajustarlo, pero, incluso para eso, tienes que entender la correlación entre throughput y número de servidores o recursos y también tus estimados de tráfico.

5. ¿Por qué existe un porcentaje de errores si mi aplicación está funcionando correctamente? ¿Qué indica ese porcentaje? ¿Hay forma de bajar ese número?

Eso depende mucho de la aplicación y se tiene que comparar con otras métricas. Por ejemplo, cuando tienes más usuarios sube la tasa de errores. Si tienes más usuarios siempre subirá la tasa de error. Sube el número porque si tienes 1% de error y esos son 10 por cada diez mil usuarios, entonces el número de usuarios aumentará y el número de errores también. Estamos hablando generalmente de porcentajes bajos, si tu aplicación está funcionando correctamente. Es decir, tu tasa de errores será de 1 o 2%. Muchas veces en el momento en el que estés tomando la métrica, tienes que asegurarte de que realmente sean errores que te importan, porque a veces son errores provocados por el usuario. Incluso pueden llegar a ser errores de un agente malicioso que está tratando de entrar a tu sitio o de probar cosas distintas. Una de las formas en las que tú puedes detectar vulnerabilidades es provocando o forzando errores en el sitio.

Una tasa de error siempre es esperada. Pero la sugerencia es ver cuáles son los momentos cuando se dispara, es decir, si está en 1% y de repente pasa a 2% sigue siendo bajo; sin embargo, se duplicó. Entonces ahí pasó algo. Vale la pena observarlo, sobre todo cuando se hacen cambios en el código. Pensemos que implementas una nueva funcionalidad y algo falló. Puede que el cambio sea muy vistoso para el usuario, pero “rompió otra cosa” durante la implementación. Puede indicar que hubo un problema en lo que hiciste. Es común que, cuando se presenta un cambio en el código o un cambio en infraestructura, se presente un error. Cuando esto ocurre, debes revisar el porcentaje de error y regresar a ver los cambios implementados. Lo bonito de los errores es que cuando los registras generalmente te dicen en qué parte del código están, por lo que es más fácil diagnosticarlos. Casi siempre son de código. Cuando llegas al límite de throughput regularmente es infraestructura. Errores casi siempre es código y es importante monitorearlos cuando se hace el lanzamiento.

6. ¿A qué se refiere la saturación?

Todos los demás síntomas implican fallas parciales. Es decir, si tienes una latencia alta tus usuarios ven el sitio lento, pero pueden entrar. Si llegaste a tu límite de capacidad de atención o throughput habrá un porcentaje de usuarios que no podrán entrar a tu sitio, pero habrá otro porcentaje que lo estará usando bien. Si hay errores, algunos usuarios también verán esos errores, pero otros estarán muy contentos. Generalmente cuando falla o se satura algo, cuando se te acaba el disco duro, cuando se te acaba la memoria, todo truena. Entonces el objetivo es prevenir que llegues al punto en donde alcances el límite de tus recursos y ahí la solución no es sencilla, pero es muy puntual: tener un sistema efectivo de alertas. Si tu memoria está llegando al 80% de uso, vale la pena enviar un correo de alerta que avise a algún responsable de tecnología que se está acabando la memoria. Que el disco duro está llegando al 95% de saturación. Esto permitirá tomar acciones, como borrar archivos que ya no se ocupan.

Lo anterior es muy crítico y binario, porque estás muy bien hasta el 99.9%, pero, cuando se te llena el disco duro, el sistema no sirve  (me ha pasado). Entonces la solución es, por un lado, tener un buen sistema de alertas que te diga en qué momento la métrica está traspasando cierto umbral y lo segundo es ver si se correlaciona alguna de estas métricas de saturación con el número de usuarios o con el throughput. De esta forma puedes planear tu infraestructura en relación al número de usuarios que esperas. Teniendo un histórico de métricas, puedes realizar estimaciones como: ‘si con mil usuarios ocupamos 64GB de RAM y con dos mil ocupamos 95 GB de RAM. Esto significa que podemos determinar cuántos usuarios somos capaces de recibir y cuánta Memoria RAM necesitamos. Lo importante para evitar problemas es tener alertas. Pero también tener un histórico de esta métrica y poder relacionarlo con otras métricas para planear la infraestructura correcta y no tener que recibir un correo urgente cuando estás en una fiesta, por ejemplo.

7. ¿Crees que hay que prevenir, pero también correlacionar las métricas entre sí para saber qué está fallando y cómo podemos corregirlo?

Cuando estás encargado de un sistema, haces diagnósticos constantemente, pero, cuando conoces estas métricas, es muy difícil vivir sin ellas, porque las empiezas a usar y a guardar. Creas un histórico. Ves y analizas diagnósticos. Es cuando recuerdas que tus análisis previos sin métricas, sólo metiéndote al código, eran hechos sin mucho fundamento. Las métricas no sólo son una herramienta de diagnóstico, sino también exhiben si un problema se corrigió o no. Te dejan experimentar y es muy bonito.

Recibirás un resumen semanal.