Monitorización del rendimiento de una aplicación heterogénea de GraphQL Mesh

¡Hola a todos! Estoy muy feliz de estar aquí para tener la oportunidad de compartir mis pensamientos y aprendizajes sobre performance con GraphQL específicamente en un service mesh. Permítanme presentarme rápidamente. Soy Robert Horslowski, trabajo en Instaun en la empresa IBM y en 2016 di una charla sobre GraphQL en Relay. Más tarde, en 2018, publiqué este curso en video sobre un clon completo de trailer basado en GraphQL. Desde entonces, en 2019, encontré un sutil problema de rendimiento en esta aplicación de demostración en vivo que lo desencadenó todo.

Pero primero, sumerjámonos y veamos qué queremos decir con malla distribuida. Entonces, en realidad no tenemos solo un servicio, sino que típicamente nuestro panorama desde una infraestructura se ve así. Por supuesto, puede haber una o dos máquinas que se caigan, etc. Pero esto se maneja típicamente. Pero ¿qué sucede a nivel de servicio? Y aquí también, esto es típicamente cómo se ve una malla de servicios cuando lo examinas y tienes una representación del tráfico de la comunicación. Y también aquí, por supuesto, hay muchas comunicaciones en ejecución y esto típicamente no es visible si no tienes una herramienta así. Pero primero, hagámonos la pregunta, ¿por qué es necesario el monitoreo de performance? Sí, es bastante simple. A los usuarios no les gusta esperar. Y típicamente, cuando hoy en día tenemos un service mesh o al menos se utiliza algún servicio. Tal vez este sea un servicio para un servicio de pago o algo así. Y típicamente, otros servicios dependen de eso. Y esto debe ser rastreado de alguna manera. Y en caso de una falla, por supuesto, debe ser fácilmente encontrado y solucionado. ¿Por qué es esto importante? Típicamente, hoy en día, cuando las APIs son el centro de un negocio, por ejemplo, también aquí, es muy importante que los tiempos sean los esperados. Nadie quiere esperar por algo y luego descubrir que no fue su culpa, sino de otra persona. E incluso mientras puede haber existido un contrato, llamado SLA, donde defines que un servicio específico debe responder en algún momento. Y si no lo hace, ahí es donde alguien tiene un problema y el negocio tiene un problema al final. Pero vamos a investigar un problema real de performance. Como mencioné, tuve un problema con mi demostración en vivo en ese momento. Es un simple tablero Kanban con algunas transacciones de base de datos o un backend donde se almacenan algunos datos, por supuesto, pero también, en ese momento, la comunicación de la base de datos era gráfica. Entonces, por alguna razón, era muy lento, pero otras veces era muy rápido. No podía decir dónde estaba el problema, pero a veces era realmente muy lento, y solo había una herramienta disponible, o estaba allí, se llamaba ApolloEngine. Era bastante simple agregar una clave de API en el servidor de Apollo al usar la biblioteca del servidor de Apollo, y luego automáticamente rastreaba estas métricas y las mostraba aquí en el tablero. Entonces puedes ver aquí, esta es la variación, digamos, o el espectro de los tiempos de respuesta, hasta 13 segundos para una llamada, lo cual, por supuesto, no es aceptable, y hay más información como en el lado derecho,

por lo que el número de consultas y demás. Esto fue hace un año. Mientras tanto, mejoraron su servicio y también tienen algún seguimiento incorporado, que también se puede habilitar muy fácilmente y para servicios freemium específicos también es bastante fácil y no cuesta nada. Pero esto, en ese momento, también me dio un poco de información y también tuve la oportunidad de usar Instana, e Instana combina estas trazas para la comunicación de servicios junto con métricas de infraestructura y también con UEM, es decir, monitoreo de usuarios finales. Y por cierto, implementa telemetría abierta, el último estándar en esta área. Entonces, ¿cómo llegamos allí? Es bastante simple al final. Finalmente, para obtener toda la información del usuario y lo que está haciendo el usuario, solo tienes que inyectar tu fragmento UEM en el sitio web, luego la consulta GraphQL puede recopilar todos los datos, incluso errores de JavaScript y demás. E incluso las solicitudes específicas se pueden encontrar aquí, y luego rastreando, encontramos algunas trazas del backend al final, también muestra la consulta GraphQL. Y en el lado derecho puedes ver alguna información adicional de la operación y demás. Y también podemos realizar más análisis sobre el recuento de consultas y demás. Pero en la actualidad, mi aplicación también se ejecuta en funciones de Netlify, que a su vez se ejecutan en AWS Lambda. Entonces, ¿cómo podemos rastrear eso? Es bastante fácil, solo usando aquí este instanawrapper. Y con esto, pude monitorear el servidor de aplicaciones Apollo aquí como vimos en la diapositiva anterior.

Entonces, finalmente, ¿cuál fue el problema real? Al final, descubrí que el verdadero problema era que en ese momento estaba usando un backend de servicio GraphQL que usaba este plan premium. Ese fue el único problema. En resumen, es bastante fácil. Apollo Studio es excelente para administrar el esquema de GraphQL, y se realiza como una observabilidad completa con todas estas características adicionales, y permite el desplazamiento hacia la izquierda para brindar a los desarrolladores un contexto completo de su aplicación en ejecución en producción. Esto también hace que sea muy eficiente encontrar cualquier causa raíz. Me gustaría decir, permítanme decir, muchas gracias por escuchar. Y para cualquier pregunta, por favor contáctenme en Twitter, en su hosts, o al correo electrónico robertoslofskaya.steiner.com. Y, por supuesto, espero verlos y conocerlos en el chat de la conferencia. Muchas gracias.