Gestionando límites en la nube

Written by: Elton Peixoto, Diogo Dantas.

El Nubank Engineering Meetup #10 puso el foco en una de las áreas más críticas y a la vez menos comentadas de la infraestructura moderna en la nube: la gestión de límites para garantizar un crecimiento sostenible.

Realizado en São Paulo, el evento reunió a entusiastas de la tecnología, especialistas en la nube y desarrolladores de software de todos los niveles, interesados en descubrir cómo Nubank escala su plataforma financiera global sin sacrificar rendimiento ni confiabilidad.

Desde la administración de capacidad en AWS hasta la orquestación de Kubernetes y las mejores prácticas de sharding, el meetup ofreció una inmersión profunda en las estrategias y los marcos que mantienen los sistemas de Nubank ágiles y con costos controlados.

Si buscas preparar tu arquitectura en la nube para el futuro, aprovechar implementaciones multi-tenant o simplemente perfeccionar tus técnicas de observabilidad y optimización de costos, sigue leyendo para conocer las lecciones clave y las soluciones de vanguardia que se presentaron durante la sesión.

La escala de Nubank

Nubank ya atiende a más de 110 millones de clientes en Brasil, Colombia y México, lo que nos sitúa en el panorama global de servicios financieros digitales. Para respaldar esta enorme base de usuarios, nuestra infraestructura debe manejar decenas de miles de pods, miles de millones de mensajes en Kafka y una red de microservicios en constante evolución.

Este nivel de escala no se logra de la noche a la mañana. En sus inicios, nuestros equipos de ingeniería se basaron en gran medida en AWS para computación, almacenamiento y redes. A medida que creció nuestra base de clientes, también lo hizo nuestra dependencia de una infraestructura en la nube escalable para dar soporte a los picos de transacciones.

Hoy en día, orquestamos más de 4.000 microservicios con Kubernetes, procesamos 72.000 millones de eventos diarios a través de Kafka y manejamos millones de solicitudes por segundo de forma rutinaria. Cada día, monitoreamos cuidadosamente el uso de recursos para asegurarnos no solo de estar preparados para la próxima ola de crecimiento, sino también de optimizar costos a largo plazo.

Descubre las oportunidades

De “Pangea” a arquitecturas multi-cuenta

Cuando Nubank era más pequeño, nuestra infraestructura se agrupaba en unas pocas cuentas gigantes en AWS. Internamente, lo llamábamos “Pangea”, evocando la imagen de un supercontinente único. Con el tiempo, sin embargo, surgieron varios problemas.

Un incidente menor podía provocar una indisponibilidad mayor, ya que todo estaba vinculado a un número limitado de cuentas. Además, aislar entornos como staging y producción se hacía cada vez más difícil, lo que ralentizaba los despliegues.

En respuesta, adoptamos una estrategia de múltiples cuentas, a la que nos referimos como “deriva continental”. Cada dominio o equipo ahora tiene su propia cuenta en AWS, lo que facilita el aislamiento y la administración de los servicios a un nivel más detallado.

Este cambio redujo drásticamente lo que llamamos el “radio de explosión”: el riesgo de que un problema puntual se convierta en una falla a gran escala. También permitió que cada dominio evolucionara de forma independiente, mejorando enormemente la confiabilidad y acelerando la salida al mercado.

Sharding en todo: Datomic, Kafka y más

Con varias cuentas de AWS como base, también implementamos un modelo de sharding en nuestros datos y servicios. Por lo general, el sharding se asocia con bases de datos, donde se dividen grandes conjuntos de datos en porciones más pequeñas y manejables.

Nubank llevó esta idea un paso más allá al aplicar sharding no solo en las bases de datos, sino también en servicios clave e incluso en clusters completos de microservicios.

Nuestra base de datos principal, Datomic, se ejecuta en múltiples transactors dentro de Kubernetes, cada uno manejando un subconjunto de los datos. El mismo patrón se aplica a Kafka: mantenemos varios clusters de Kafka para distintos shards, lo que distribuye la carga de mensajes.

Este enfoque cumple dos objetivos fundamentales: en primer lugar, evita que los problemas locales se propaguen, ya que cada shard es relativamente independiente; en segundo lugar, nos permite prever la capacidad de manera más acertada en unidades más pequeñas. Al analizar el uso en un shard, podemos proyectar con mayor precisión el comportamiento de los demás.

Gestión de capacidad y límites de AWS

A pesar de la noción popular de que “la nube es infinita”, todos los proveedores de nube imponen límites o cuotas, que van desde balanceadores de carga e instancias EC2 hasta la capacidad total de almacenamiento. A la escala de Nubank, esas cuotas pueden convertirse en cuellos de botella si no se supervisan con cuidado.

La gestión de capacidad es una responsabilidad compartida entre nuestros equipos de ingeniería. Cualquier persona que inicie un nuevo microservicio debe considerar cuántos núcleos de CPU, cuánta memoria y qué tipo de recursos de AWS necesitará.

Si bien el equipo de Infraestructura proporciona mejores prácticas y monitoreo automatizado, los equipos de cada dominio participan activamente en el análisis de costos y capacidad. Esto evita aumentos inesperados en el consumo de recursos y garantiza que cada servicio esté dimensionado correctamente para su carga de trabajo.

Detección temprana de problemas: AWS Limit Smoke Detector

Una de nuestras soluciones internas más destacadas es el AWS Limit Smoke Detector. En pocas palabras, es un pipeline de ETL que recolecta datos de uso, cuotas y costos de todas las cuentas de AWS de Nubank y los agrega en BigQuery. Al comparar continuamente el uso real con las cuotas asignadas, esta herramienta identifica posibles problemas mucho antes de alcanzar un límite crítico.

El pipeline se basa en diversas fuentes de AWS, incluidas Trusted Advisor, Service Quotas y CloudWatch, así como en llamadas directas a la API cuando es necesario. Genera una visión histórica del uso, lo que nos permite pronosticar cuándo podríamos llegar a un límite.

Cuando el uso de una cuenta aumenta a gran velocidad, el Smoke Detector emite alertas a través de dashboards y mensajes automáticos, impulsándonos a tomar medidas — ya sea solicitando un aumento en las cuotas o ajustando el consumo de recursos del servicio involucrado.

Esta estrategia proactiva nos asegura que alcanzar un límite de AWS no derive en un incidente crítico del producto. También aporta datos valiosos a nuestro equipo de Gestión de Costos, ya que indica dónde podría ser necesario ajustar presupuestos. En lugar de llevarnos sorpresas con la factura de AWS o quedarnos cortos en el último minuto, abordamos cualquier posible exceso con suficiente antelación.

Multi-tenant vs. Single-tenant: un enfoque equilibrado

A lo largo del meetup, discutimos cómo la arquitectura de Nubank combina los modelos multi-tenant y single-tenant. Las plataformas multi-tenant permiten que varios equipos internos compartan la misma infraestructura; por ejemplo, varios microservicios pueden reutilizar el mismo cluster de Kubernetes o los mismos pools de brokers de Kafka. Este modelo favorece un uso más eficiente de los recursos y, a menudo, reduce la sobrecarga operativa.

Sin embargo, en algunos casos optamos por un modelo single-tenant. Algunas cargas de trabajo críticas para el negocio, en especial aquellas con requisitos de rendimiento o seguridad muy específicos, pueden necesitar su propio cluster o un entorno dedicado.

Si bien el modelo single-tenant puede resultar más costoso, también ofrece un control y un aislamiento mucho más estrechos, adecuado para sistemas con necesidades muy sensibles de datos o con tráfico intenso. Equilibrar ambos modelos —y decidir estratégicamente qué servicios se ejecutan en cada uno— es un proceso continuo que mantiene nuestra plataforma flexible y con costos controlados.

Mirando hacia el futuro

El enfoque de Nubank para gestionar los límites en la nube destaca la importancia de la planificación proactiva de capacidad, el aislamiento basado en sharding y las estrategias de múltiples cuentas en cualquier infraestructura de gran escala. A medida que la demanda continúa creciendo, asegurar un rendimiento estable mientras se contienen los costos va más allá de ser un simple desafío técnico: se convierte en una ventaja competitiva.

Al combinar la orquestación con Kubernetes, el monitoreo de cuotas de AWS y un modelo de responsabilidad compartida entre equipos, Nubank ofrece cada día una experiencia resistente y fluida a millones de clientes.

Tanto si eres una startup fintech emergente como una empresa ya establecida, los principios y las ideas prácticas del Nubank Engineering Meetup #10 pueden orientarte hacia operaciones en la nube más robustas, escalables y con mayor conciencia de costos. Mantente al tanto de los próximos meetups, donde profundizaremos aún más en las tecnologías y prácticas que impulsan la innovación en Nubank y más allá.