{"id":32459,"date":"2025-04-09T08:59:20","date_gmt":"2025-04-09T11:59:20","guid":{"rendered":"https:\/\/building.nu.com\/?p=32459"},"modified":"2025-04-16T13:33:02","modified_gmt":"2025-04-16T16:33:02","slug":"gestionando-limites-en-la-nube","status":"publish","type":"post","link":"https:\/\/building.nu.com\/es\/gestionando-limites-en-la-nube\/","title":{"rendered":"Gestionando l\u00edmites en la nube"},"content":{"rendered":"\n

Written by:<\/strong> Elton Peixoto<\/a>, Diogo Dantas<\/a>.<\/p>\n\n\n\n

El Nubank Engineering Meetup #10 puso el foco en una de las \u00e1reas m\u00e1s cr\u00edticas y a la vez menos comentadas de la infraestructura moderna en la nube: la gesti\u00f3n de l\u00edmites para garantizar un crecimiento sostenible.<\/p>\n\n\n\n

Realizado en S\u00e3o Paulo, el evento reuni\u00f3 a entusiastas de la tecnolog\u00eda, especialistas en la nube y desarrolladores de software de todos los niveles, interesados en descubrir c\u00f3mo Nubank escala su plataforma financiera global sin sacrificar rendimiento ni confiabilidad.<\/p>\n\n\n\n

Desde la administraci\u00f3n de capacidad en AWS hasta la orquestaci\u00f3n de Kubernetes y las mejores pr\u00e1cticas de sharding, el meetup ofreci\u00f3 una inmersi\u00f3n profunda en las estrategias y los marcos que mantienen los sistemas de Nubank \u00e1giles y con costos controlados.<\/p>\n\n\n\n

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

La escala de Nubank<\/h2>\n\n\n\n

Nubank ya atiende a m\u00e1s de 110 millones de clientes en Brasil, Colombia y M\u00e9xico, lo que nos sit\u00faa 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\u00f3n.<\/p>\n\n\n\n

Este nivel de escala no se logra de la noche a la ma\u00f1ana. En sus inicios, nuestros equipos de ingenier\u00eda se basaron en gran medida en AWS para computaci\u00f3n, almacenamiento y redes. A medida que creci\u00f3 nuestra base de clientes, tambi\u00e9n lo hizo nuestra dependencia de una infraestructura en la nube escalable para dar soporte a los picos de transacciones.<\/p>\n\n\n\n

Hoy en d\u00eda, orquestamos m\u00e1s de 4.000 microservicios con Kubernetes, procesamos 72.000 millones de eventos diarios a trav\u00e9s de Kafka y manejamos millones de solicitudes por segundo de forma rutinaria<\/strong>. Cada d\u00eda, monitoreamos cuidadosamente el uso de recursos para asegurarnos no solo de estar preparados para la pr\u00f3xima ola de crecimiento, sino tambi\u00e9n de optimizar costos a largo plazo.<\/p>\n\n\n\n

De \u201cPangea\u201d a arquitecturas multi-cuenta<\/h2>\n\n\n\n

Cuando Nubank era m\u00e1s peque\u00f1o, nuestra infraestructura se agrupaba en unas pocas cuentas gigantes en AWS. Internamente, lo llam\u00e1bamos \u201cPangea\u201d, evocando la imagen de un supercontinente \u00fanico. Con el tiempo, sin embargo, surgieron varios problemas.<\/p>\n\n\n\n

Un incidente menor pod\u00eda provocar una indisponibilidad mayor, ya que todo estaba vinculado a un n\u00famero limitado de cuentas. Adem\u00e1s, aislar entornos como staging y producci\u00f3n se hac\u00eda cada vez m\u00e1s dif\u00edcil, lo que ralentizaba los despliegues.<\/p>\n\n\n\n

En respuesta, adoptamos una estrategia de m\u00faltiples cuentas, a la que nos referimos como \u201cderiva continental\u201d. Cada dominio o equipo ahora tiene su propia cuenta en AWS, lo que facilita el aislamiento y la administraci\u00f3n de los servicios a un nivel m\u00e1s detallado.<\/p>\n\n\n\n

Este cambio redujo dr\u00e1sticamente lo que llamamos el \u201cradio de explosi\u00f3n\u201d: el riesgo de que un problema puntual se convierta en una falla a gran escala. Tambi\u00e9n permiti\u00f3 que cada dominio evolucionara de forma independiente, mejorando enormemente la confiabilidad y acelerando la salida al mercado.<\/p>\n\n\n\n

Sharding en todo: Datomic, Kafka y m\u00e1s<\/h2>\n\n\n\n

Con varias cuentas de AWS como base, tambi\u00e9n 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\u00e1s peque\u00f1as y manejables.<\/p>\n\n\n\n

Nubank llev\u00f3 esta idea un paso m\u00e1s all\u00e1 al aplicar sharding no solo en las bases de datos, sino tambi\u00e9n en servicios clave e incluso en clusters completos de microservicios.<\/p>\n\n\n\n

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

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\u00e1s acertada en unidades m\u00e1s peque\u00f1as. Al analizar el uso en un shard, podemos proyectar con mayor precisi\u00f3n el comportamiento de los dem\u00e1s.<\/p>\n\n\n\n

Gesti\u00f3n de capacidad y l\u00edmites de AWS<\/h2>\n\n\n\n

A pesar de la noci\u00f3n popular de que \u201cla nube es infinita\u201d, todos los proveedores de nube imponen l\u00edmites 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.<\/p>\n\n\n\n

La gesti\u00f3n de capacidad es una responsabilidad compartida entre nuestros equipos de ingenier\u00eda. Cualquier persona que inicie un nuevo microservicio debe considerar cu\u00e1ntos n\u00facleos de CPU, cu\u00e1nta memoria y qu\u00e9 tipo de recursos de AWS necesitar\u00e1.<\/p>\n\n\n\n

Si bien el equipo de Infraestructura proporciona mejores pr\u00e1cticas y monitoreo automatizado, los equipos de cada dominio participan activamente en el an\u00e1lisis de costos y capacidad. Esto evita aumentos inesperados en el consumo de recursos y garantiza que cada servicio est\u00e9 dimensionado correctamente para su carga de trabajo.<\/p>\n\n\n\n

Detecci\u00f3n temprana de problemas: AWS Limit Smoke Detector<\/h2>\n\n\n\n

Una de nuestras soluciones internas m\u00e1s 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\u00edmite cr\u00edtico.<\/p>\n\n\n\n

El pipeline se basa en diversas fuentes de AWS, incluidas Trusted Advisor, Service Quotas y CloudWatch, as\u00ed como en llamadas directas a la API cuando es necesario. Genera una visi\u00f3n hist\u00f3rica del uso, lo que nos permite pronosticar cu\u00e1ndo podr\u00edamos llegar a un l\u00edmite.<\/p>\n\n\n\n

Cuando el uso de una cuenta aumenta a gran velocidad, el Smoke Detector emite alertas a trav\u00e9s de dashboards y mensajes autom\u00e1ticos, impuls\u00e1ndonos a tomar medidas \u2014 ya sea solicitando un aumento en las cuotas o ajustando el consumo de recursos del servicio involucrado.<\/p>\n\n\n\n

Esta estrategia proactiva nos asegura que alcanzar un l\u00edmite de AWS no derive en un incidente cr\u00edtico del producto. Tambi\u00e9n aporta datos valiosos a nuestro equipo de Gesti\u00f3n de Costos, ya que indica d\u00f3nde podr\u00eda ser necesario ajustar presupuestos. En lugar de llevarnos sorpresas con la factura de AWS o quedarnos cortos en el \u00faltimo minuto, abordamos cualquier posible exceso con suficiente antelaci\u00f3n.<\/p>\n\n\n\n

Multi-tenant vs. Single-tenant: un enfoque equilibrado<\/h2>\n\n\n\n

A lo largo del meetup, discutimos c\u00f3mo 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\u00e1s eficiente de los recursos y, a menudo, reduce la sobrecarga operativa.<\/p>\n\n\n\n

Sin embargo, en algunos casos optamos por un modelo single-tenant. Algunas cargas de trabajo cr\u00edticas para el negocio, en especial aquellas con requisitos de rendimiento o seguridad muy espec\u00edficos, pueden necesitar su propio cluster o un entorno dedicado.<\/p>\n\n\n\n

Si bien el modelo single-tenant puede resultar m\u00e1s costoso, tambi\u00e9n ofrece un control y un aislamiento mucho m\u00e1s estrechos, adecuado para sistemas con necesidades muy sensibles de datos o con tr\u00e1fico intenso. Equilibrar ambos modelos \u2014y decidir estrat\u00e9gicamente qu\u00e9 servicios se ejecutan en cada uno\u2014 es un proceso continuo que mantiene nuestra plataforma flexible y con costos controlados.<\/p>\n\n\n\n

Mirando hacia el futuro<\/h2>\n\n\n\n

El enfoque de Nubank para gestionar los l\u00edmites en la nube destaca la importancia de la planificaci\u00f3n proactiva de capacidad, el aislamiento basado en sharding y las estrategias de m\u00faltiples cuentas en cualquier infraestructura de gran escala. A medida que la demanda contin\u00faa creciendo, asegurar un rendimiento estable mientras se contienen los costos va m\u00e1s all\u00e1 de ser un simple desaf\u00edo t\u00e9cnico: se convierte en una ventaja competitiva.<\/p>\n\n\n\n

Al combinar la orquestaci\u00f3n con Kubernetes, el monitoreo de cuotas de AWS y un modelo de responsabilidad compartida entre equipos, Nubank ofrece cada d\u00eda una experiencia resistente y fluida a millones de clientes.<\/p>\n\n\n\n

Tanto si eres una startup fintech emergente como una empresa ya establecida, los principios y las ideas pr\u00e1cticas del Nubank Engineering Meetup #10 pueden orientarte hacia operaciones en la nube m\u00e1s robustas, escalables y con mayor conciencia de costos. Mantente al tanto de los pr\u00f3ximos meetups, donde profundizaremos a\u00fan m\u00e1s en las tecnolog\u00edas y pr\u00e1cticas que impulsan la innovaci\u00f3n en Nubank y m\u00e1s all\u00e1.<\/p>\n\n\n\n

\n