Este trabajo fue realizado en colaboración por varias personas increíbles (en orden alfabético): Amarilis Campos, Beca Maia, Caio Sousa, Daniel Cristian, Jade Costa, Maria Duarte, Otavio Valadares, Robert Cristiam y otros equipos dentro de Nu.

¿Por qué lo hicimos?

Creemos que detrás de toda solución técnica debe haber un problema de negocio claro que resolver. En este caso, nos enfrentábamos a desafíos relacionados con la estabilidad y la eficiencia de nuestro ecosistema de monitoreo. Con el rápido crecimiento de Nubank, nuestra infraestructura de logs existente comenzó a mostrar señales de presión, especialmente en términos de previsibilidad de costos y escalabilidad.

Considerando que la plataforma de logs es fundamental para dar soporte a todos los equipos de ingeniería durante la resolución de problemas y la mitigación de incidentes, no tener control total y visibilidad sobre sus datos de monitoreo es algo negativo. No hay nada peor que intentar depurar un problema en producción y descubrir que no puedes ver los logs de tu aplicación. En nuestro caso, dependíamos de una solución externa para la ingesta y el almacenamiento de nuestros logs, y teníamos poca observabilidad sobre ella (irónico). Una vez que creamos métricas para entender la situación real, nuestro análisis mostró que una parte significativa de los logs no se estaba reteniendo de punta a punta, lo que limitaba nuestra capacidad de actuar rápidamente en escenarios de respuesta a incidentes.

Además, nuestro contrato se estaba volviendo costoso (muy costoso). La única forma de mitigar nuestros problemas era comprando más licencias (pagando más), y no existía un modelo de precios claro para planificar nuestros gastos. Si teníamos problemas, teníamos que invertir más dinero. No era posible ninguna previsibilidad. Llegó a un punto en que el equipo analizó que podríamos contratar a Lionel Messi como ingeniero de software, pagando la misma cantidad que estábamos pagando por la solución externa.

Con este problema complejo y emocionante en mano, decidimos explorar alternativas, y la más eficiente parecía ser la creación de nuestra propia plataforma. De esta manera, tendríamos control total sobre nuestros datos, pipeline de ingesta, estrategia de almacenamiento y tiempo de ejecución de consultas.

Descubre las oportunidades

¿Cómo era la infraestructura de logs de Nubank?

Antes de migrar a una solución interna, la infraestructura de logs de Nubank era muy simple y estaba totalmente acoplada a la solución anterior.

En resumen, cada log de aplicación se enviaba directamente a las plataformas del proveedor a través de su propio forwarder. Además, teníamos muchas fuentes internas desconocidas que enviaban datos directamente a la API del proveedor.

Esta arquitectura le sirvió bien a Nubank durante muchos años, pero con nuestro crecimiento masivo e hiper escalable, hace algunos años, comenzamos a enfrentar sus limitaciones y el futuro con ella se convirtió en una preocupación.

Las principales preocupaciones y problemas que el equipo identificó con esta arquitectura y enfoque fueron:

  • Falta de observabilidad: No teníamos visibilidad sobre el flujo de ingesta y almacenamiento. Si algo sucedía, no contábamos con métricas confiables al respecto.
  • Alto acoplamiento: En ese momento, muchas de nuestras alertas y paneles de control (dashboards) se definían directamente en las interfaces del proveedor. Todos nuestros datos se almacenaban allí, y no teníamos la capacidad de cambiar de solución o migrar fácilmente.
  • Falta de control: No teníamos forma de filtrar, agregar, dirigir o aplicar lógica a los datos entrantes.
  • Altos costos: Los costos crecientes relacionados con la pila de logs eran una preocupación constante para las partes interesadas (stakeholders), y la tendencia era que seguirían creciendo si no tomábamos medidas.
  • Acoplamiento de los procesos de ingesta y consulta: Una alta carga en la ingesta impactaba directamente el rendimiento de las consultas, y viceversa.

Dividir y conquistar

Construir una plataforma de logs completa desde cero es difícil, ¡y en ese momento no teníamos nada construido!

Para resolver este problema, dividimos todo el proyecto en dos grandes etapas:

  • Flujo de Observabilidad (Observability Stream): Una plataforma de stream completa, capaz de ingerir y procesar señales de observabilidad de manera confiable y eficiente. Esto nos permitiría desvincularnos de la solución anterior y tener control total sobre nuestros datos.
  • Plataforma de Consulta y Almacenamiento: La plataforma que almacenaría los logs y los haría consultables para que los ingenieros pudieran usarlos en sus tareas diarias de resolución de problemas.

Para ambos proyectos, teníamos un conjunto diferente de requisitos y funcionalidades que debíamos construir, pero había tres exigencias en común:

  • Confiabilidad: La plataforma tenía que ser confiable incluso bajo alta carga o en escenarios inesperados para dar soporte a las operaciones de Nubank.
  • Escalabilidad: Ser capaz de escalar rápidamente al enfrentar picos en la ingesta y el uso, y a largo plazo, manejar el hipercrecimiento de Nubank.
  • Eficiencia de costos: Ser eficiente en costos siempre es importante en Nubank, y necesitábamos una plataforma que fuera económicamente viable a largo plazo, capaz de ingerir y almacenar todos nuestros datos generados a un precio menor que cualquier proveedor.

Con una lista clara de requisitos y expectativas, comenzamos el proyecto, primero enfocándonos en la ingesta y el procesamiento, y luego en la plataforma de consulta y almacenamiento.

El Flujo de Observabilidad (Observability Stream)

La decisión fue construir primero la plataforma de ingesta. Esto nos permitió iniciar el proceso de migración sin grandes interrupciones en la experiencia del desarrollador, al mismo tiempo que desacoplábamos el entorno de transacciones del entorno de observabilidad. También nos permitió recopilar métricas sobre nuestros datos para tomar mejores decisiones, especialmente durante el desarrollo de la plataforma de almacenamiento.

El Flujo de Observabilidad fue construido pensando en la simplicidad, utilizando una combinación de proyectos de código abierto y sistemas desarrollados internamente.

En resumen, la arquitectura de ingesta se compone de tres sistemas distintos:

  • Fluent Bit: Optamos por un recolector y reenviador de datos (data forwarder) ligero, fácil de configurar y eficiente. Este proyecto de código abierto, respaldado por la CNCF, es un estándar confiable en la industria para esta tarea.
  • Servicio de Buffer de Datos: El servicio responsable de manejar todos los datos recibidos de los reenviadores y acumularlos en grandes bloques para que continúen en el pipeline con una arquitectura de micro-batching (procesamiento en pequeños lotes).
  • Servicio de Filtro y Procesamiento: Un sistema de alta escalabilidad desarrollado internamente, capaz de filtrar y procesar cualquier dato recibido de manera eficiente. Este sistema es el núcleo de nuestra plataforma de ingesta, siendo fácilmente extensible para añadir cualquier nueva lógica de filtro o procesamiento según sea necesario. También es responsable de recopilar métricas de los datos entrantes.

Con el Flujo de Observabilidad totalmente operativo, establecimos una base de confiabilidad y escalabilidad para nuestros procesos de ingesta de logs. Este sistema integral no solo resolvió nuestras necesidades inmediatas de entrada de datos de calidad, sino que también nos proporcionó información valiosa sobre nuestras actividades de registro. Además, desacopló nuestros procesos de ingesta del proceso de consulta, lo que nos brinda una mayor flexibilidad y la capacidad de intercambiar componentes fácilmente cuando sea necesario, una capacidad de la que carecíamos anteriormente debido al alto acoplamiento.

Plataforma de Consulta y Logs

Con una robusta plataforma de ingesta que garantiza confiabilidad y escalabilidad, nuestro siguiente desafío fue desarrollar una solución de consulta y almacenamiento capaz de manejar y recuperar eficazmente este enorme volumen de datos de logs.

Para ello, necesitábamos elegir un motor de consulta para buscar todos estos datos, y Trino fue la elección por varias razones:

  • La funcionalidad de particionamiento de Trino fue crucial. Al usarla, logramos mejorar el rendimiento de nuestras consultas al segmentar los datos en fragmentos manejables. Esto permite que las consultas se dirijan solo a subconjuntos de datos relevantes, mejorando los tiempos de respuesta y reduciendo el uso de recursos. La funcionalidad de particionamiento de Trino fue un factor clave en nuestra decisión de adoptarlo.
  • AWS S3 como almacenamiento: Almacenar todos nuestros datos en AWS S3 nos garantiza la alta confiabilidad de nuestros datos de manera rentable. Su gran escalabilidad está bien fundamentada para recibir esta enorme cantidad de datos, a la vez que puede escalar a largo plazo a medida que Nubank crece.

Para almacenar los logs, el formato elegido fue Parquet. Al utilizarlo, logramos el mejor rendimiento de búsqueda gracias a su almacenamiento en columnas, además de una tasa promedio de compactación del 95%. Esto nos ayuda a alcanzar el objetivo de tener todos nuestros datos almacenados de la manera más eficiente posible.

Para generar todos estos archivos Parquet, construimos una aplicación generadora de Parquet altamente escalable y extensible, capaz de transformar todos los datos masivos que provienen de la plataforma de ingesta. La decisión de construir nuestra propia infraestructura interna para esto también refuerza nuestro objetivo de tener una alternativa económica, al mismo tiempo que podemos extenderla y adaptarla según las necesidades de Nubank.

Con nuestra plataforma de consulta y logs totalmente integrada y operativa, hemos logrado redefinir cómo Nubank gestiona sus datos de log. La elección estratégica de Trino para las consultas, S3 para el almacenamiento y Parquet para el formato de los datos garantiza que nuestros logs no solo se almacenen de manera eficiente, sino que también estén fácilmente accesibles para el análisis y la resolución de problemas. Estas innovaciones no solo resolvieron los desafíos iniciales, sino que también equiparon a Nubank con una herramienta poderosa para el crecimiento futuro.

Reflexiones finales

Desde mediados de 2024, la plataforma de logs interna de Nubank se ha convertido en el estándar para el almacenamiento y la consulta de logs. Actualmente, ingesta 1 billón de logs diarios, lo que suma 1 PB de datos. Con un período de retención de 45 días, almacena 45 PB de datos consultables. La plataforma gestiona casi 15 mil consultas diarias, escaneando 150 PB de datos cada día.

Nubank desarrolló esta plataforma interna para lograr ahorros de costos significativos y una mayor eficiencia operativa, alejándose de la dependencia de proveedores externos. La plataforma está diseñada para soportar todas las operaciones actuales y futuras, escalando de manera eficiente y costando un 50% menos que las soluciones de mercado, según nuestros benchmarks.

Este enfoque también le proporciona a Nubank un control y una flexibilidad inigualables. Permite una iteración rápida, el desarrollo de funcionalidades personalizadas y una comprensión más profunda de los flujos de datos, lo que resulta en mejoras en el análisis, la resolución de problemas y la seguridad.

Desafiar el statu quo es un valor central de Nubank, y esta ambición impulsó la creación de una plataforma de logs completa desde cero, utilizando una combinación de proyectos de código abierto y desarrollo de software interno.

Descubre las oportunidades