Rastreo distribuido en la práctica

Prólogo

Los seres humanos han luchado por comprender el software de producción exactamente desde que los seres humanos tienen software de producción. Tenemos estas máquinas maravillosamente rápidas, pero no hablan nuestro idioma y, a pesar de su velocidad y de todo el bombo y platillo sobre la inteligencia artificial, siguen siendo totalmente irreflexivas y opacas.

Durante muchas (muchas) décadas, nuestros esfuerzos por comprender el software de producción se redujeron en última instancia a dos tipos de datos de telemetría: datos de registro y estadísticas de series temporales. Los datos de series temporales -también conocidos como métricas- nos ayudaban a comprender que "algo terrible" estaba ocurriendo dentro de nuestros ordenadores. Si teníamos suerte, los datos de registro nos ayudarían a comprender específicamente qué era esa cosa terrible.

Pero entonces todo cambió: nuestro software necesitaba algo más que un ordenador. De hecho, necesitaba miles de ellos.

Dividimos el software en servicios minúsculos, operados independientemente, y distribuimos esos servicios fragmentados por todo el planeta, atomizados entre los millones de ordenadores alojados en centros de datos masivos. Y con tantos procesos implicados en cada solicitud del usuario final, los registros y estadísticas de las máquinas individuales sólo contaban una parte de la historia. Parecía que volábamos a ciegas.

Empecé a trabajar en el rastreo distribuido a principios de 2005. Por aquel entonces, yo era un ingeniero de software de 25 años que trabajaba -de mala gana, si he de ser sincero- en un servicio lejano dentro de la infraestructura de backend de Google AdWords . Al igual que el resto de la empresa, intentaba escribir un software capaz de soportar una carga punitiva procedente del mundo exterior (en ese momento, Google ya era un verbo y nos habíamos adentrado en un territorio inexplorado para el hardware básico). Estábamos ejecutando microservicios antes de que se hubiera inventado ese término, y cuando necesitábamos alguna nueva capa de abstracción o infraestructura, casi siempre nos veíamos obligados a escribirla internamente (para empezar, GitHub ni siquiera se había incorporado todavía).

Para abreviar, mantuvimos el barco a flote... pero era un desastre. Y nadie, salvo los veteranos supergenios (léase: yo no), tenía ni idea de dónde estaban enterrados los cadáveres ni de cómo encajaba todo.

Fue entonces cuando conocí a Sharon Perl, realmente por accidente. Había sido investigadora científica en el Centro de Investigación de Sistemas de DEC en los años 90 (es decir, ¡cuando estaba de moda!) y llegó a Google en sus primeros días: 2001, si no recuerdo mal. En aquella breve conversación improvisada con Sharon, le pregunté en qué estaba trabajando, y me enumeró una lista de interesantes proyectos de software de sistemas: un almacén de blobs distribuido, un servicio de identidad a escala de Google, un servicio de bloqueo distribuido... y luego una cosa llamada Dapper. Dapper era "un sistema de rastreo distribuido", fuera lo que fuera.

Ni que decir tiene que nunca había oído hablar de un sistema de rastreo distribuido -en 2005, casi ningún no académico lo había hecho-, pero sonaba fascinante. Por aquel entonces, Dapper no era más que un prototipo que Sharon había codesarrollado con Mike Burrows y Luiz Barroso. Habían parcheado el subsistema RPC interno de Google y los paquetes de flujo de control para propagar unos cuantos GUID junto a cada solicitud a medida que ésta rebotaba de un servicio a otro. No era totalmente operativo, pero una primera prueba de concepto demostró que los fundamentos eran sólidos. Por primera vez, un ingeniero normal de Google tenía alguna esperanza de comprender lo que ocurría con una solicitud web individual en los 150 milisegundos que tardaba en tocar cientos o miles de microservicios distintos.

Estaba enganchado. Aquí había algo realmente novedoso, potente y -desde un punto de vista personal- ¡sumamente falto de personal! Así que empecé a profundizar en el código base de Dapper, a limpiar cosas, a redondear perímetros y a lidiar con más de mi parte de burocracia interna (entre otras cosas, Dapper tenía un demonio ejecutándose con privilegios de root en cada pieza de hardware de producción de Google y, sabiamente, pusieron algún proceso en torno a ese tipo de cosas). Baste decir que, tras un año o dos de tiempo en el muro y un trabajo fenomenal de un equipo de ingenieros, pudimos implementar Dapper en todo el software backend de Google. Que yo sepa, era la primera vez que una organización ejecutaba el rastreo distribuido de forma continua para un sistema de producción a escala.

...y así implementamos Dapper en todo Google, y resolvimos la observabilidad.

¡Ojalá! La verdad es que Dapper era una solución puntual a algunos problemas dolorosos pero aislados. En los primeros días, era difícil conseguir que la gente siquiera lo utilizara, y mucho menos que se beneficiara de él. El KPI de mi equipo era el número de inicios de sesión semanales, y recuerdo cuando la cifra rondaba los dos dígitos bajos, mes tras mes. Soñábamos con ingeniosas funciones analíticas, las implementábamos, esperábamos a las estruendosas manadas de usuarios entusiastas y luego nos sentíamos decepcionados.

Al final encontramos una forma de aumentar el uso y, por tanto, el valor organizativo para Google, pero no fue con nuevas funciones analíticas o visualizaciones perspicaces. De hecho, fue algo realmente básico que sólo requirió unos cientos de líneas de código: uno de mis colegas integró enlaces a rastros relevantes de Dapper en una herramienta que los ingenieros de Google ya utilizaban muchas veces al día. Resulta que una pequeña parte de la gente hacía clic en esos enlaces, y a veces encontraban algo realmente valioso al otro lado.

Eso era todo. Una simple integración en un flujo de trabajo existente. Más allá de los retos de ingeniería de datos e instrumentación, el rastreo distribuido es difícil porque a menudo se considera no sólo como un nuevo conjunto de telemetría, sino como una experiencia de producto distinta y segregada. Por muy convincente que sea esa experiencia de producto, los desarrolladores (como todas las personas) son criaturas de costumbres que no quieren aprender una nueva herramienta para comprobar proactivamente. Los datos de rastreo y las perspectivas deben encajar en el contexto de los flujos de trabajo preexistentes y las tareas por hacer. Ésta es la mejor manera de dar a las perspectivas orientadas al rastreo la exposición necesaria para justificar la inversión en una fuente de datos fundamentalmente nueva.

El rastreo distribuido aún está en pañales. Recordando los primeros días del proyecto Dapper, cuando apenas estaba avanzando en el código base, le pregunté a Luiz Barroso si podía dedicarme 30 minutos para ayudarme a entender algunas cosas. Luiz ya era bastante distinguido, pero era (y sigue siendo) humilde, amable y generoso con su tiempo, así que accedió. Cuando me reuní con él, debí de parecer un poco ingenuo, pero también estaba insondablemente entusiasmado con lo que quería hacerle a Dapper. Quería incorporar un mecanismo de muestreo "justo a tiempo", crear un lenguaje de programación declarativo para consultas definidas por el usuario que se ejecutaran a través de servicios de aplicación, integrar trazas del núcleo y mucho más. Le pregunté qué pensaba. Siempre la voz de la sabiduría, me dejó tranquilo y me explicó que simplemente poner Dapper en producción sería un gran logro y llevaría años. "Empieza por ahí", dijo.

Luiz tenía razón en eso. Quince años después, gran parte de nuestra industria no ha avanzado mucho más que eso, al menos en producción. El rastreo distribuido merece la pena, ¡pero es difícil! Aún así, es una disciplina muy joven, y la última sección de este libro ofrece una ventana a lo que está por venir. Dentro de otros 15 años, veremos el rastreo distribuido en torno a 2020 como algo tan crítico como primitivo. Si comprendemos hacia dónde se dirige la tecnología, estaremos en mejores condiciones de adaptarnos al paisaje dinámico que rodea al rastreo y a la observabilidad en general.

Dando un paso atrás, es importante recordar que nadie trabaja con "un solo microservicio".

Nuestra industria se pasó a los microservicios para que nuestros equipos de desarrollo pudieran operar con independencia, y hasta cierto punto, conseguimos nuestro deseo, al menos en lo que respecta a la integración continua y la implementación continua. Pero esta "independencia" era una ilusión; en producción, estos microservicios son de hecho muy interdependientes, y un fallo o ralentización en un servicio se propaga por toda la pila de microservicios, dejando a su paso caos y confusión (y muchos frenéticos mensajes de Slack).

Las trazas distribuidas deben formar parte de la solución a este problema. Son la única ventana que tenemos para ver cómo interactúan realmente los cientos de servicios de las arquitecturas de microservicios profundas y multicapa cuando satisfacen las peticiones de los usuarios de extremo a extremo. Puede que sean relativamente nuevos en el mundo de la telemetría en comparación con las estadísticas de series temporales y los registros de vainilla, pero también son los más vitales cuando se trata de comprender el sistema en su conjunto. Sin datos de rastreo, nos vemos reducidos a adivinar y comprobar a través de mares de datos de registro desorganizados y paneles de métricas.

Sin embargo, no es tan sencillo como añadir rastreo distribuido. Aunque una observabilidad saludable en los sistemas distribuidos debe implicar trazados distribuidos, aún tenemos que averiguar cómo. ¿Cómo hacemos que el rastreo distribuido sea útil? ¿Cómo lo adoptamos? ¿Cómo lo integramos en nuestros flujos de trabajo y procesos actuales? ¿Y cómo garantizamos el futuro de estos esfuerzos?

Son preguntas fascinantes y desafiantes, y son el tema de este libro. Esperamos que lo disfrutes.

Ben Sigelman

Cofundador y CEO de Lightstep

y cocreador de Dapper