Observabilidad del salto de red oculto.
Este artículo fue publicado originalmente el 12 de febrero de 2020 en eng.lyft.com.
Métricas de series temporales en Envoy Mobile
La visión que guía a Envoy siempre ha sido:
La red debe ser transparente a las aplicaciones. Cuando ocurren problemas de red y aplicación debe ser fácil determinar el origen del problema.
La segunda parte de esta declaración ha jugado un rol importante en la creciente presencia de Envoy en el ámbito de sistemas distribuidos modernos. Envoy tiene el mejor repertorio de datos de observabilidad de su clase. Desde trazado distribuido, a logging, a métricas de series temporales, la información que Envoy provee permite a un operador entender su sistema.
Métricas de series temporales en el servidor
En Lyft, las métricas de series temporales emitidas por Envoy permiten a los ingenieros explorar diferentes condiciones del sistema. En efecto, es posible ver la concurrencia de un servicio en un punto específico de tiempo, o la cantidad de nodos saludables para un servicio en particular, o la latencia en p95. Los posibilidades son casi infinitas. Mientras que esta pila de métricas son muy poderosas, se puede argumentar que el aspecto más importante es la consistencia: los ingenieros pueden utilizar las mismas métricas y tableros para observar todos los sistemas de Lyft, sin importar en qué microservicio están enfocándose. Dado que Envoy se ejecuta en todos los nodos de la red, ¡cada nodo emite las mismas métricas! (Para más detalles sobre los tableros de Envoy que utilizamos en Lyft, puedes ver este post en nuestro blog en inglés).
El salto de red oculto
Hay un salto en la red mallada de Lyft que no cuenta con la misma consistencia en términos de observabilidad: el salto desde nuestros clientes móviles a la frontera de nuestra infraestructura de servidores. Este es un salto de red importante en nuestra red — quizás el más importante. En palabras de nuestro post anunciando Envoy Mobile:
Cumplir con un nivel de servicio del lado del servidor no importan si el usuario de una aplicación móvil sólo puede completar los flujos del producto una fracción de las veces.
Si no podemos observar este salto de red, no seremos capaces de mejorar la fiabilidad y resiliencia de nuestros clientes móviles. Entre las muchas razones explicadas en nuestras anteriores publicaciones en nuestro blog en inglés, la observabilidad de este salto de red era una razón muy importante por la cual decidimos invertir en Envoy Mobile. Al obtener el mismo stack de observabilidad usado en el resto de nuestra red, podemos obtener métricas consistentes con las obtenidas en nuestra infraestructura de servicios.
¡Envoy Mobile al rescate!
Anunciamos el lanzamiento de Envoy Mobile v0.2 en Noviembre. En ese anuncio mencionamos que Envoy Mobile reemplazó las librerías de red en la versión alfa de la aplicación de pasajeros de Lyft y que íbamos a realizar una integración de observabilidad en Envoy Mobile. El resto de este post describe cómo ejecutamos esto y los resultados que hemos obtenido gracias a esta información proveniente de nuestros clientes móviles incluso en Diciembre mismo.
Los puntos de extensión de Envoy
Una de las funcionalidades más poderosas de Envoy son todos sus puntos de extensión — probablemente solo después de su excelente observabilidad. Envoy puede ser extendido para agregar más filtros (tanto en L4 como L7), nuevos sockets de transporte, y nuevas verificaciones de nodos saludables. Lo más pertinente a nuestro trabajo en observabilidad es el hecho de que Envoy tiene una interfaz extensible de recolección de datos. Esto significa que los desarrolladores pueden crear nuevas maneras de exponer las series temporales de Envoy al crear nuevas interfaces de recolección de datos.
Una de las implementaciones de recolección de datos es “metrics service”. Esta implementación codifica métricas en el formato protobuf de Prometheus y los envía mediante gRPC a un servicio remoto. Este modelo encaja perfecto en Envoy Mobile porque no podemos instalar colectores de datos en teléfonos, ni rescatar métricas de un endpoint conocido.
Infraestructura de métricas para dispositivos móviles
La secuencia de recolección de métricas que Lyft utiliza para dispositivos móviles en Envoy Mobile se ve de la siguiente forma:
A la izquierda tenemos los clientes móviles utilizando Envoy Mobile como su librería de red. Las configuraciones de datos de Envoy nos permiten configurar dos aspectos importantes en nuestro entorno móvil:
- Intervalo de reporte de datos: dada la información de batería y red de datos, debemos refinar los intervalos de reporte de datos estadísticos en períodos largos de tiempo. Recientemente hemos modificado el reporte para que se ejecute en base a señales del sistema operativo, como el cierre o pase a segundo plano de la aplicación.
- Filtrado de emisión de métricas: Envoy emite cientos de métricas diferentes, y no todas ellas son útiles en un entorno móvil. Envoy nos permite configurar tanto un whitelist de tags de métricas, como qué familias de métricas deben ser emitidas.
Además, Envoy tiene una propiedad muy útil en su configuración de arranque: la propiedad node. Este campo es utilizado para identificar una instancia de Envoy. En Envoy Mobile, lo usamos para etiquetar al cliente móvil con información valiosa como qué sistema operativo está ejecutando (ej., “Android” o “iOS”). En el futuro, podremos enviar información aún más rica como la versión de la aplicación, la versión del sistema operativo, el identificador de usuario, etc.
La razón por la cual estos metadatos son útiles, es porque pueden ser utilizados en un servicio de agregación de métricas para enriquecer las métricas recolectadas desde nuestros clientes.
El Metrics Service es un servicio gRPC que construimos para recibir métricas de nuestros clientes (y está representado por el recuadro rojo en el próximo gráfico). En su versión mas básica el Metrics Service recibe métricas de nuestros clientes en un stream gRPC, lo transforma al formato statsd (utilizando la librería gostats de Lyft), y enviarlos a agregadores de statsd. Usando los metadatos del campo node, Metrics Service puede hacer también agregación online basada en parámetros de tiempo de ejecución. Por ejemplo, si quisiéramos agregar métricas basadas en un release específico del cliente para obtener información sobre un bug, ¡podríamos hacerlo! Se pueden construir mecanismos muy poderosos encima de esta agregación por demanda para reducir costos cuando las aguas están calmas, pero aún así permitiéndonos convertirla en una verdadera mina de datos cuando resulte necesario.
Resultados
Luego de que las métricas son agregadas, están disponibles para ser trazadas con las mismas interfaces descritas en el artículo en inglés sobre los tableros Envoy de Lyft. Esta consistencia permite a los responsables de cada servicio trabajar con las herramientas que están acostumbrados a utilizar. Uno de los momentos más impactantes que nuestros desarrolladores tuvieron luego de trabajar seis meses en Envoy Mobile fue poder comparar los siguientes dos gráficos lado a lado:
Esos dos gráficos están trazando la misma métrica de Envoy (upstream_rq.count es decir, el volumen de tráfico de red recibido por la plataforma de Lyft), en el mismo período de tiempo. El gran diferencial es que el gráfico superior está trazando métricas obtenidas desde nuestros clientes móviles (Envoy Mobile), y la inferior traza las métricas que vienen de nuestra frontera de infraestructura (Envoy Proxy). ¡El gráfico superior nos muestra el salto de red oculto por primera vez! Aún más, tenemos acceso a esta información mediante métricas con los mismos nombres que el resto de nuestra infraestructura. Esta consistencia resulta muy útil para reducir la carga cognitiva de los ingenieros backend que operan la infraestructura de Lyft, siendo capaces ahora de extenderlo a nuestros ingenieros mobile también. Es verdaderamente poderoso ver gráficos complementarios de esta manera. El tablero que ahora podemos construir nos dará perspectivas que no teníamos anteriormente, y fuimos capaces de hacerlo aprovechando Envoy Mobile y las métricas de infraestructura preexistentes de Lyft. Construimos una experiencia de red transparente y observable que finalmente incluye a nuestros clientes móviles.
Próximos pasos
Este es tan solo el primero de sus muchos otros tipos de posibilidades que estamos desbloqueando al usar una primitiva de red unificada en todas las plataformas, con Envoy Mobile en nuestros clientes móviles y Envoy Proxy en el servidor. Resalta el hecho de que podemos obtener beneficios aprovechando la infraestructura preexistente gracias a sus flexibles puntos de extensión y su gran caudal de información de observabilidad. Si estás interesado en leer más sobre Infraestructura de Red en Lyft o Envoy Mobile, puedes dirigirte a la sección de recursos adicionales en la documentación de Envoy Mobile.
Envoy Mobile fue creado completamente como un proyecto de código libre, con objetivos visibles públicamente. Si este proyecto te parece interesante, puedes unirte a nosotros: creando un nuevo issue para una funcionalidad que te gustaría utilizar, ¡o (mejor aún) un PR!
¡Lyft está contratando ingenieros de software increíbles de todos los orígenes! Revisa nuestra página de vacantes para más información.
