No mundo do áudio programático, 101 ms significa receita zero. Isso não é um problema de desempenho. É um problema de sobrevivência.  Operamos uma plataforma de publicidade em áudio (DSP) que processa aproximadamente   Cada solicitação precisa ser recebida, avaliada e respondida em menos de   Se esse prazo for perdido, o lance é descartado. Com 101 ms, na prática, deixamos de existir. 350 milhões de solicitações por dia — cerca de 2 bilhões por semana. 100 milissegundos.  Fazemos isso com uma equipe de engenharia de três pessoas e uma fatura de nuvem que fica abaixo de US$ 10.000 por mês. A mesma equipe é responsável por tudo: infraestrutura do sistema de licitação, camada de aplicação, bancos de dados e operações.   O Ecossistema RTB  Se você não está familiarizado com tecnologia de publicidade, aqui vai uma versão resumida. A publicidade programática funciona com base em lances em tempo real (RTB).  Do lado da oferta estão   . Essas são plataformas como a AdsWizz ou a Triton que agregam inventário de anúncios em milhares de aplicativos e editores — players de podcast, aplicativos de streaming e outras plataformas de áudio. as SSPs (Supply-Side Platforms)  Do lado da demanda estão   – sistemas como o nosso que representam os anunciantes e decidem, em tempo real, se devem ou não dar um lance em uma determinada impressão. as DSPs (Demand-Side Platforms)  Quando um ouvinte abre um aplicativo de podcast e um espaço publicitário fica disponível, o aplicativo se comunica com sua SSP (Plataforma de Suporte a Serviços). A SSP, por sua vez, envia solicitações de lances para várias DSPs (Plataformas de Venda de Dados). Nosso sistema recebe essa solicitação, avalia o usuário e as campanhas ativas, calcula o preço do lance e envia uma resposta. Tudo isso precisa acontecer em menos de 100 ms, de ponta a ponta.  A latência não é apenas uma métrica aqui. Ela é o produto.  Assim que aceitamos isso, ficou óbvio que os padrões tradicionais de aplicativos web não funcionariam. Não podíamos arcar com os custos de saltos de rede entre microsserviços e, definitivamente, não podíamos arcar com a conta da nuvem que acompanha uma configuração Kubernetes extensa. Para sobreviver, tivemos que projetar considerando as limitações em primeiro lugar.  Essa restrição não era teórica. No início, quando ainda tínhamos créditos na nuvem, não nos preocupávamos muito com a eficiência. Assim que esses créditos acabaram, cada decisão arquitetônica passou a ter um custo real. Foi então que tivemos que repensar e reestruturar o sistema para reduzir a latência, reduzir custos e simplificar a operação.  A seguir, apresentamos a arquitetura que permite a uma equipe de três pessoas operar um sistema RTB global em grande escala, sem gastar dinheiro ou perder o sono.  1. A geografia como primeiro filtro: projetando para a física de redes  As principais SSPs de áudio com as quais nos integramos —   — estão hospedadas nos EUA, na Europa e no Sudeste Asiático. Nossa camada de aplicação, que contém a lógica de campanha para anunciantes na Índia, está localizada na Índia. Triton, AdsWizz, Magnite (antiga Rubicon) e MCTV  O tempo de ida e volta da rede entre essas regiões, por si só, é de cerca de   , mesmo antes da execução de qualquer lógica de aplicação. Isso já nos coloca mais que o dobro acima do orçamento permitido. 240 milissegundos  A solução foi simples, mas inegociável. Implementamos nossos clusters de lances em   : Oeste dos EUA (Oregon), Centro-Europa (Frankfurt) e Ásia-Pacífico (Singapura e Hong Kong). quatro regiões estratégicas da AWS  Isso garante que, quando um SSP envia uma solicitação de lance, nossa distância até o hardware seja insignificante — normalmente milissegundos de um dígito —, deixando a maior parte do orçamento de 100 ms para computação propriamente dita.  2. O modelo híbrido monolítico-microsserviço   Chegamos a uma arquitetura que se situa algures entre um monolito tradicional e uma configuração de microsserviços. Em vez de distribuirmos os serviços pela rede, colocamos um   e, em seguida, escalamos essas VMs horizontalmente por trás de um balanceador de carga global. pequeno cluster de serviços fortemente acoplados numa única máquina virtual  Dentro de cada máquina virtual — tratada como um único nó — ela se assemelha a um sistema distribuído em miniatura:    : Um único contêiner de entrada que atua como controlador de tráfego interno. Nginx    : 3 a 5 réplicas do serviço de licitação Node.js em execução na mesma máquina para utilizar totalmente a CPU. Licitante    : Uma instância local do Redis executada juntamente com o código. Redis  A vantagem é a localidade dos dados por padrão. O licitante não precisa atravessar a rede para buscar dados; ele lê do localhost. Isso também nos permite aumentar significativamente   . Ao usar VMs maiores (por exemplo, c6i.xlarge) e compartilhar um único conjunto de dados em memória entre vários workers, obtemos uma relação RAM/CPU muito melhor, minimizando o desperdício e maximizando a taxa de transferência. a densidade de recursos  3. A Lógica: Falhar Rapidamente  Para cumprir um prazo de 100 ms, não basta ter um código rápido. O sistema precisa decidir rapidamente quando não deve executar nenhuma tarefa.  A maioria das solicitações de lances recebidas nunca resultará em uma vitória. Permitir que essas solicitações acessem o estado, os bancos de dados ou os caminhos de escrita é a maneira mais rápida de estourar o orçamento de latência. Estruturamos o licitante como uma árvore de decisão ordenada por "probabilidade de falha", executando primeiro as verificações mais baratas.  As verificações são realizadas aproximadamente nesta ordem:    : Uma grande parte das ofertas falha aqui. Esta é uma comparação simples e os resultados são obtidos quase imediatamente. Verificação geográfica    : Se a localização geográfica for aprovada, validamos as restrições de plataforma e dispositivo. Verificações de SO e dispositivo    : Verificação se o aplicativo corresponde ao nosso inventário permitido. Segmentação de editor/aplicativo    : Somente se uma solicitação sobreviver a esses filtros é que acessamos caminhos mais complexos — dados em nível de usuário, lógica de orçamento e ritmo, ou qualquer coisa que exija coordenação. Lógica com estado  Ao falharmos rapidamente, rejeitamos 90% do tráfego em microssegundos, reservando ciclos de CPU para os lances que realmente convertem.  4. A arquitetura de dados: Redis para regras, Aerospike para perfis  Dividimos nossa arquitetura de dados em duas camadas com base nos padrões de acesso e no custo da "obsolescência".  As regras: Redis local  Cada nó armazena metadados "quentes" (campanhas ativas e limites de orçamento) em seu Redis local. Um processo cron utiliza um   , acessando nossa API central a cada 60 segundos para baixar os dados mais recentes. modelo de pull  Na nossa escala, essa defasagem de 60 segundos cria um risco:   . Se vários nós agirem simultaneamente com base nos mesmos dados orçamentários desatualizados, eles podem gastar mais do que o cliente alocou. o gasto excessivo  Lidamos com isso por meio de um   : consideramos o tamanho da frota como uma entrada para o controle do orçamento. À medida que o número de nós ativos em leilão aumenta, cada nó reduz dinamicamente a "fatia" do orçamento que lhe é permitida usar. Mesmo que um nó esteja trabalhando com dados desatualizados, seus limites locais já estão controlados com base no tamanho atual da frota. Os gastos diminuem gradualmente em vez de apresentarem picos, e o sistema converge no próximo ciclo de atualização. Mecanismo de Frenagem  Os perfis: Aerospike (A vantagem do SSD)  Consultas de perfis de dados em nível de usuário, limites de frequência e redirecionamento exigem acesso a conjuntos de dados massivos e mutáveis em menos de um milissegundo. Um SGBD relacional tradicional não consegue lidar com essa carga pelo preço que oferecemos.  Utilizamos   nessa camada porque ele é otimizado para tratar SSDs como armazenamento primário, em vez de manter todo o conjunto de trabalho na RAM. Isso nos proporciona latência previsível, mantendo os custos de hardware muito menores do que uma solução baseada exclusivamente em RAM, como o ElastiCache. o Aerospike  Para manter essa camada acessível, somos rigorosos com a higiene dos dados:  Regra dos 10 dias: Só retemos dados de usuários ativos nos últimos 10 dias.  Limite de 10 milhões: reduzimos ativamente o conjunto de dados aos poucos milhões de usuários mais ativos.  Se um usuário deixa de interagir, seus dados são removidos. Essa prática garante que os custos de armazenamento permaneçam estáveis, enquanto o licitante se concentra apenas nos usuários que importam.  5. O Segredo "Assíncrono": Desacoplando a Carga  Nossa primeira versão, tecnicamente, tentava ser assíncrona. Enviávamos a resposta do lance imediatamente e deixávamos a função Node.js continuar rodando em segundo plano para gravar o log no MongoDB.    : O tráfego não é constante; ele explode. Durante os picos, mesmo após a resposta da oferta ter desaparecido, nossos contêineres Node.js ficavam "flutuando" — mantendo conexões abertas e consumindo ciclos de CPU tentando concluir as gravações no banco de dados. Isso fazia com que nosso escalonador automático criasse mais VMs apenas para lidar com o   , o que, por sua vez, sobrecarregava nosso banco de dados com conexões. A Armadilha acúmulo de gravações    : Passamos de "Código Assíncrono" para "   ". Introduzimos   como um amortecedor entre o servidor de envio e o caminho de escrita. Agora, o servidor de envio envia uma mensagem para o Kafka e libera imediatamente seus recursos. A "escrita" é tratada por uma frota de consumidores separada, em um ritmo controlado. A solução Arquitetura Assíncrona o Kafka  6. Benchmarking: Meça, não chute  Nessa escala, adivinhar os tipos de instância é custoso. Então, em vez de confiar na teoria, fizemos testes de desempenho.  Tínhamos hipóteses — se o licitante era limitado por computação ou memória, quantos processos de trabalho faziam sentido por nó e como o tamanho da instância afetava a latência. Testamos em várias famílias e tamanhos de instâncias da AWS e variamos quantos serviços de licitação eram executados em um único nó.  Adotamos a mesma abordagem na camada de dados, testando diferentes tipos de máquinas para ver o que funcionava melhor para o MongoDB sob carga real, priorizando a latência estável em detrimento da taxa de transferência máxima.  Tudo isso foi validado com testes de carga que submeteram o sistema a uma demanda de QPS semelhante à de produção, medindo os tempos de resposta e a latência de cauda. Algumas suposições se confirmaram. Muitas outras, não.  A conclusão foi simples:   . com um orçamento de 100ms, os benchmarks superam a teoria sempre  7. FinOps: Como mantemos a fatura em US$ 10 mil  Startups não morrem quando o tráfego aumenta repentinamente. Elas morrem quando os créditos na nuvem acabam. Para nós, o controle de custos não é uma reflexão tardia — faz parte do projeto do sistema.  Algumas economias vieram da negociação. Passamos a utilizar um revendedor para o faturamento, o que nos permitiu obter um desconto fixo por volume. Em relação à largura de banda, nos comprometemos com   , o que nos permitiu negociar um desconto de mais de 60% nos preços da CDN em comparação com as tarifas sob demanda. Com nossos níveis de tráfego, esse único compromisso fez uma diferença significativa. aproximadamente 1 PB de transferência mensal  Também separamos as responsabilidades: servidores de licitação sem estado são executados em capacidade spot com grandes descontos, enquanto bancos de dados com estado usam instâncias previsíveis e de longa duração.  Na nossa escala, armazenar centenas de milhões de registros por dia é uma bomba-relógio. Os registros detalhados de lances têm um período de retenção curto — da ordem de dias, não meses. Os dados que queremos manter são agregados antecipadamente — a cada hora, em vez de por evento — e movidos para armazenamentos mais baratos e com melhor capacidade de consulta. Tudo o que for necessário apenas para fins de conformidade ou auditorias históricas é armazenado em data warehouse frio, onde os custos caem de 80% a 90% em comparação com os planos padrão.  A maior economia, porém, não vem do desconto. Vem da   . utilização  A maioria dos sistemas opera a CPU com 20-30% de utilização "por segurança". O nosso não precisa. Como a arquitetura é tolerante a falhas e projetada para liberar carga de forma controlada, podemos operar a CPU com   sem problemas. Não pagamos por ciclos ociosos. Se estamos pagando por um núcleo, é porque esse núcleo está em processo de licitação. 80% de utilização  Essa mentalidade — de tratar a eficiência como uma restrição primordial — é o que mantém a conta estável mesmo com o aumento do tráfego.  8. Operando com três pessoas: a filosofia da "taxa de matrícula"  Operar em escala global com uma equipe de três pessoas só funciona se os sistemas — e não as pessoas — carregarem o fardo. Projetamos as operações para eliminar a intervenção humana do caminho crítico e remover pontos únicos de falha sempre que possível. Também evitamos a compartimentalização de funções — cada engenheiro consegue navegar por toda a pilha de tecnologia —, de modo que o conhecimento operacional nunca seja um ponto único de falha.  A infraestrutura é descartável por padrão. Se um nó apresentar mau funcionamento, não o depuramos no local — nós o encerramos e deixamos o escalonador automático substituí-lo. A recuperação é mais rápida do que a investigação, e cada instância parte de um estado conhecido e limpo.  A observabilidade é importante, mas os dashboards sozinhos não ajudam uma equipe pequena. Nós dependemos de alertas acionáveis (via Datadog) que são disparados somente quando a intervenção humana é necessária. Se um cluster regional ficar lento ou um consumidor ficar para trás, somos notificados. Todo o resto é automatizado.  A automação, porém, não é mágica. Ainda pagamos mensalidades escolares de tempos em tempos.  Em um dos primeiros incidentes, uma tarefa em segundo plano responsável por atualizar o orçamento falhou silenciosamente. O licitante continuou operando com dados desatualizados e gastou em uma campanha que já deveria ter terminado — um cenário clássico de "licitante zumbi". Reembolsamos o cliente, corrigimos a falha e reforçamos a segurança do sistema com verificações de pulsação monitoradas pelo Datadog. A atualização do orçamento agora é explícita e o silêncio, por si só, aciona um alerta. Se o licitante não receber uma atualização válida, a campanha é encerrada sem aviso prévio.  Em uma equipe pequena, os erros são inevitáveis.  Repeti-los é opcional.  Considerações finais  Nenhuma das decisões neste sistema é exótica por si só. O que o faz funcionar é a forma como elas se combinam.  A física da rede define os limites. A localidade e a lógica de falha rápida protegem o caminho de 100 ms. Limites assíncronos absorvem picos de tráfego. A medição substitui a intuição. A disciplina de custos e a alta utilização mantêm a economia transparente. As operações são projetadas para que os humanos intervenham somente quando o sistema não conseguir se recuperar sozinho.  Esta não é uma história sobre tecnologia de anúncios ou uma pilha tecnológica específica. É um lembrete de que, em grande escala,   . Quando você trata latência, custo e número de funcionários como requisitos de primeira classe, a arquitetura que emerge tende a ser mais simples, não mais complexa. as restrições não são obstáculos — são entradas de design  O objetivo não era construir algo impressionante. Era construir algo que sobrevivesse.

This story contains new, firsthand information uncovered by the writer.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Read My Stories

Este áudio é produzido no idioma original da história!

2 bilhões de solicitações, prazos de 100 ms, US$ 10 mil por mês: projetando um sistema RTB global enxuto.

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Digital Nomads Ouçam: O que você precisa saber sobre o novo visto DTV da Tailândia

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Telegram: a ponte da Crypto Island para o continente

Digital Nomads Ouçam: O que você precisa saber sobre o novo visto DTV da Tailândia

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Telegram: a ponte da Crypto Island para o continente

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps