{"id":32450,"date":"2025-04-09T08:59:20","date_gmt":"2025-04-09T11:59:20","guid":{"rendered":"https:\/\/building.nubank.com\/?p=32450"},"modified":"2025-04-16T13:32:30","modified_gmt":"2025-04-16T16:32:30","slug":"gerenciando-limites-na-nuvem","status":"publish","type":"post","link":"https:\/\/building.nubank.com\/pt-br\/gerenciando-limites-na-nuvem\/","title":{"rendered":"Gerenciando limites na nuvem"},"content":{"rendered":"\n

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

O Nubank Engineering Meetup #10 lan\u00e7ou holofotes sobre uma das \u00e1reas mais cr\u00edticas e, ao mesmo tempo, pouco discutidas da infraestrutura moderna em nuvem: a gest\u00e3o de limites para garantir um crescimento sustent\u00e1vel.<\/p>\n\n\n\n

Realizado em S\u00e3o Paulo, o evento reuniu entusiastas de tecnologia, especialistas em nuvem e engenheiros de software de todos os n\u00edveis de senioridade, todos interessados em descobrir como o Nubank escala sua plataforma financeira global sem sacrificar desempenho ou confiabilidade.<\/p>\n\n\n\n

De estrat\u00e9gias de gerenciamento de capacidade na AWS a orquestra\u00e7\u00e3o de Kubernetes e pr\u00e1ticas de sharding, o meetup ofereceu um mergulho profundo nas abordagens que mant\u00eam os sistemas do Nubank \u00e1geis e com custos sob controle.<\/p>\n\n\n\n

Se voc\u00ea est\u00e1 buscando proteger sua arquitetura de nuvem para o futuro, aproveitar implanta\u00e7\u00f5es multi-tenant ou simplesmente aprimorar t\u00e9cnicas de observabilidade e otimiza\u00e7\u00e3o de custos, continue a leitura para conhecer as principais li\u00e7\u00f5es e solu\u00e7\u00f5es de ponta apresentadas durante a sess\u00e3o.<\/p>\n\n\n\n

A escala do Nubank<\/h2>\n\n\n\n

O Nubank j\u00e1 atende mais de 110 milh\u00f5es de clientes no Brasil, Col\u00f4mbia e M\u00e9xico, o que nos coloca em destaque no cen\u00e1rio global de servi\u00e7os financeiros digitais. Para dar suporte a essa enorme base de usu\u00e1rios, nossa infraestrutura precisa lidar com dezenas de milhares de pods, bilh\u00f5es de mensagens no Kafka e uma rede em constante evolu\u00e7\u00e3o de microsservi\u00e7os.<\/p>\n\n\n\n

Esse n\u00edvel de escala n\u00e3o acontece da noite para o dia. L\u00e1 atr\u00e1s, nossas equipes de engenharia contavam fortemente com a AWS para computa\u00e7\u00e3o, armazenamento e rede. \u00c0 medida que nossa base de clientes crescia, nossa depend\u00eancia de uma infraestrutura em nuvem escal\u00e1vel tamb\u00e9m aumentava para acomodar picos de transa\u00e7\u00f5es de usu\u00e1rios.<\/p>\n\n\n\n

Hoje, orquestramos mais de 4.000 microsservi\u00e7os com Kubernetes, processamos 72 bilh\u00f5es de eventos di\u00e1rios via Kafka e rotineiramente lidamos com milh\u00f5es de requisi\u00e7\u00f5es por segundo<\/strong>. A cada dia, monitoramos cuidadosamente o uso de recursos para garantir que estejamos n\u00e3o apenas preparados para o pr\u00f3ximo salto de crescimento, mas tamb\u00e9m otimizando custos a longo prazo.<\/p>\n\n\n\n

De \u201cPangeia\u201d \u00e0s arquiteturas multi-contas<\/h2>\n\n\n\n

Quando o Nubank era menor, nossa infraestrutura ficava concentrada em algumas contas enormes na AWS. Internamente, cham\u00e1vamos isso de \u201cPangeia\u201d, evocando a imagem de um supercontinente \u00fanico. Com o tempo, por\u00e9m, encontramos diversos problemas.<\/p>\n\n\n\n

Um incidente pequeno podia desencadear uma grande indisponibilidade, pois tudo estava vinculado a um conjunto limitado de contas. Al\u00e9m disso, isolar ambientes como staging e produ\u00e7\u00e3o ficava cada vez mais complicado, o que atrasava implanta\u00e7\u00f5es.<\/p>\n\n\n\n

Em resposta, migramos para uma estrat\u00e9gia de m\u00faltiplas contas, que chamamos de \u201cderiva continental\u201d. Cada dom\u00ednio ou equipe agora possui sua pr\u00f3pria conta na AWS, facilitando o isolamento e a gest\u00e3o de servi\u00e7os de forma mais granular.<\/p>\n\n\n\n

Essa mudan\u00e7a reduziu drasticamente o que chamamos de \u201craio de explos\u00e3o\u201d \u2014 o risco de que um problema pontual se transforme em uma falha de grande escala. Tamb\u00e9m deu a cada dom\u00ednio a liberdade de evoluir de forma independente, melhorando muito a confiabilidade e o time-to-market.<\/p>\n\n\n\n

Sharding de tudo: Datomic, Kafka e mais<\/h2>\n\n\n\n

Com v\u00e1rias contas AWS fornecendo a camada de base, tamb\u00e9m implementamos um modelo de sharding em nossos dados e servi\u00e7os. Normalmente, associamos sharding a bancos de dados, em que dividimos grandes conjuntos de dados em partes menores e mais gerenci\u00e1veis.<\/p>\n\n\n\n

O Nubank levou essa ideia al\u00e9m, aplicando sharding n\u00e3o apenas em bases de dados, mas tamb\u00e9m em servi\u00e7os-chave e at\u00e9 mesmo em clusters inteiros de microsservi\u00e7os.<\/p>\n\n\n\n

Nosso banco de dados principal, o Datomic, \u00e9 executado em m\u00faltiplos transactors dentro do Kubernetes, cada um lidando com um subconjunto de dados. O mesmo padr\u00e3o se aplica ao Kafka: mantemos v\u00e1rios clusters para diferentes shards, distribuindo a carga de mensagens.<\/p>\n\n\n\n

Essa abordagem atende a dois objetivos principais: primeiro, evita que problemas localizados se espalhem, pois cada shard \u00e9 relativamente independente; segundo, permite prever capacidade de forma mais precisa em unidades menores. Ao analisar o uso em um shard, conseguimos projetar com mais clareza o comportamento dos outros.<\/p>\n\n\n\n

Gest\u00e3o de capacidade e limites da AWS<\/h2>\n\n\n\n

Apesar da no\u00e7\u00e3o popular de que \u201ca nuvem \u00e9 infinita\u201d, todo provedor de nuvem imp\u00f5e limites ou cotas \u2014 que v\u00e3o desde balanceadores de carga e inst\u00e2ncias EC2 at\u00e9 capacidade total de armazenamento. Na escala do Nubank, essas cotas podem se tornar gargalos se n\u00e3o forem monitoradas com cuidado.<\/p>\n\n\n\n

Gerenciar capacidade \u00e9 uma responsabilidade compartilhada em nossas equipes de engenharia. Qualquer pessoa que crie um novo microsservi\u00e7o deve considerar quantos n\u00facleos de CPU, quanto de mem\u00f3ria e quais tipos de recursos AWS ser\u00e3o necess\u00e1rios.<\/p>\n\n\n\n

Embora a equipe de Infraestrutura forne\u00e7a boas pr\u00e1ticas e monitoramento automatizado, as equipes de cada dom\u00ednio participam ativamente da an\u00e1lise de custos e capacidade. Isso evita picos inesperados no consumo de recursos e garante que cada servi\u00e7o seja dimensionado corretamente para sua carga de trabalho.<\/p>\n\n\n\n

Detec\u00e7\u00e3o precoce de problemas: o AWS Limit Smoke Detector<\/h2>\n\n\n\n

Uma das solu\u00e7\u00f5es internas mais relevantes que desenvolvemos \u00e9 o AWS Limit Smoke Detector. Na pr\u00e1tica, trata-se de um pipeline de ETL que coleta dados de uso, cotas e custos de todas as contas AWS do Nubank e agrega essas informa\u00e7\u00f5es no BigQuery. Ao comparar continuamente o uso real com as cotas atribu\u00eddas, a ferramenta identifica poss\u00edveis problemas muito antes de atingirmos um limite cr\u00edtico.<\/p>\n\n\n\n

Esse pipeline se baseia em m\u00faltiplas fontes da AWS, incluindo Trusted Advisor, Service Quotas e CloudWatch, al\u00e9m de chamadas diretas de API quando necess\u00e1rio. Ele gera uma vis\u00e3o hist\u00f3rica do uso, permitindo que fa\u00e7amos previs\u00f5es de quando poderemos chegar a determinado limite.<\/p>\n\n\n\n

Quando o uso em uma conta cresce rapidamente, o Smoke Detector emite alertas via dashboards e mensagens autom\u00e1ticas, nos impulsionando a agir \u2014 seja solicitando aumento de cotas ou otimizando o consumo de recursos do servi\u00e7o em quest\u00e3o.<\/p>\n\n\n\n

Essa postura proativa garante que chegar a um limite da AWS nunca resulte em um grande incidente de produto. Tamb\u00e9m fornece ao nosso time de Gest\u00e3o de Custos dados valiosos sobre onde o or\u00e7amento pode precisar de ajustes. Em vez de receber uma fatura surpresa ou encarar uma escassez de \u00faltima hora, lidamos com poss\u00edveis excessos com bastante anteced\u00eancia.<\/p>\n\n\n\n

Multi-tenant vs. Single-tenant: uma abordagem equilibrada<\/h2>\n\n\n\n

Durante o meetup, discutimos como a arquitetura do Nubank mistura os modelos multi-tenant e single-tenant. Plataformas multi-tenant permitem que diversas equipes internas compartilhem a mesma infraestrutura \u2014 por exemplo, m\u00faltiplos microsservi\u00e7os podem reutilizar o mesmo cluster de Kubernetes ou os mesmos pools de brokers Kafka. Esse compartilhamento pode levar a uma utiliza\u00e7\u00e3o de recursos mais eficiente e, muitas vezes, reduz a sobrecarga operacional.<\/p>\n\n\n\n

Em determinados cen\u00e1rios, por\u00e9m, optamos por um modelo single-tenant. Algumas cargas de trabalho cr\u00edticas para o neg\u00f3cio, especialmente aquelas que exigem performance ou seguran\u00e7a extremamente espec\u00edficas, podem precisar de seu pr\u00f3prio cluster ou ambiente dedicado.<\/p>\n\n\n\n

Embora o single-tenant possa ser mais custoso, ele oferece controle e isolamento r\u00edgidos, adequados para sistemas com requisitos sens\u00edveis de dados ou tr\u00e1fego muito alto. Equilibrar esses dois modelos \u2014 e definir estrategicamente quais servi\u00e7os ficam em cada um \u2014 \u00e9 um processo cont\u00ednuo que mant\u00e9m nossa plataforma flex\u00edvel e com custos sob controle.<\/p>\n\n\n\n

Perspectivas futuras<\/h2>\n\n\n\n

A forma como o Nubank gerencia limites na nuvem ressalta a import\u00e2ncia do planejamento proativo de capacidade, do isolamento baseado em sharding e das estrat\u00e9gias de m\u00faltiplas contas em qualquer infraestrutura de grande porte. Conforme a demanda continua crescendo, garantir desempenho est\u00e1vel enquanto se controlam custos deixa de ser apenas um desafio t\u00e9cnico para se tornar uma vantagem competitiva.<\/p>\n\n\n\n

Combinando orquestra\u00e7\u00e3o via Kubernetes, monitoramento de cotas da AWS e um modelo de responsabilidade compartilhada entre equipes, o Nubank oferece, dia ap\u00f3s dia, uma experi\u00eancia resiliente e fluida a milh\u00f5es de clientes.<\/p>\n\n\n\n

Seja voc\u00ea uma startup fintech em ascens\u00e3o ou uma empresa j\u00e1 consolidada, os princ\u00edpios e aprendizados pr\u00e1ticos do Nubank Engineering Meetup #10 podem ajudar a guiar opera\u00e7\u00f5es de nuvem mais robustas, escal\u00e1veis e conscientes de custos. Fique ligado nos pr\u00f3ximos meetups, onde vamos explorar ainda mais as tecnologias e pr\u00e1ticas que impulsionam a inova\u00e7\u00e3o no Nubank e al\u00e9m.<\/p>\n\n\n\n

\n