Sua plataforma de anúncios não aguenta picos de tráfego? O que corrigir primeiro e quem pode ajudar

Se a sua plataforma de anúncios falha em picos de tráfego, os engenheiros que podem ajudar são os que a medem durante um pico real e depois a corrigem em uma ordem definida. Eles interrompem o trabalho que vai terminar depois do deadline, limitam as retentativas e o tráfego que a plataforma aceita, e tiram os contadores de orçamento e de frequência do caminho da requisição. Depois, adicionam capacidade antes dos picos que dá para prever. O código é reescrito por último, e só onde as medições apontam.

Como “não aguentar picos de tráfego” se manifesta em uma plataforma de anúncios?

Um pico de tráfego aparece com sintomas diferentes em cada parte de uma plataforma de anúncios:

• Bidder. Mais respostas chegam depois do deadline da exchange, a taxa de lances cai enquanto o volume de requisições sobe, e a exchange pode começar a enviar menos requisições
• Supply-side platform (SSP) ou exchange. Os leilões fecham antes de alguns bidders responderem, e menos lances disputam cada impressão. No header bidding, os lances que não chegam dentro do timeout do leilão da página ficam fora da chamada ao ad server
• Ad server. As chamadas de anúncio ficam mais lentas e alguns espaços de anúncio aparecem vazios
• Pipeline de eventos. As contagens de impressões e de cliques chegam atrasadas ou divergem entre os sistemas
• Orçamentos e limites de frequência. As campanhas gastam além do orçamento ou mostram o mesmo anúncio vezes demais, porque os contadores são atualizados depois das decisões que deveriam tê-los consultado

Timeouts e espaços vazios aparecem durante o pico. Problemas de eventos e de orçamento podem ficar escondidos até que os eventos atrasados cheguem aos relatórios e à cobrança.

Por que uma plataforma de anúncios quebra no pico se funciona bem com a carga média?

No OpenRTB, o protocolo do IAB Tech Lab para real-time bidding, a exchange pode informar o deadline na própria requisição: o “tempo máximo em milissegundos que a exchange permite para receber os lances, incluindo a latência da Internet, para evitar timeout”. A documentação do Authorized Buyers do Google diz que o deadline normalmente vai de 80 a 1000 ms. O Google exige que 85 por cento das respostas cheguem dentro dele, conforme vistas a partir do trading location, e restringe os bidders que não conseguem cumprir isso de forma consistente. Um bidder que fica mais lento em um pico perde os leilões em que chega atrasado e depois pode receber menos tráfego.

Perto do limite de capacidade, um serviço começa a enfileirar requisições. O livro Site Reliability Engineering (SRE), do Google, observa que “requisições enfileiradas consomem memória e aumentam a latência” e que os servidores gastam recursos com requisições que vão perder o deadline de qualquer jeito. A menos que o código verifique o deadline, uma requisição que esperou demais ainda é processada por inteiro, e a resposta é descartada.

Quando uma chamada a um banco de dados, a um cache ou a um parceiro estoura o timeout, quem chamou tenta de novo, e as retentativas chegam justamente quando o sistema tem menos condição de absorvê-las. O livro de SRE mostra a aritmética de uma tempestade de retentativas: “100 QPS de retentativas no primeiro segundo levam a 200 QPS, depois a 300 QPS, e assim por diante.”

Uma exchange ou um SSP envia cada requisição a muitos bidders, e o leilão ou espera a resposta mais lenta, ou fecha sem ela. Jeffrey Dean e Luiz André Barroso, do Google, quantificaram isso na Communications of the ACM, em 2013. No exemplo deles, cada servidor normalmente responde em 10 ms, mas leva um segundo em uma a cada cem requisições. Uma requisição que precisa reunir as respostas de 100 servidores assim, em paralelo, leva então mais de um segundo em 63 por cento das vezes. Um leilão não espera tanto. Pela mesma conta, se cada um de 100 bidders se atrasa em uma a cada cem requisições, cerca de 63 por cento dos leilões fecham com pelo menos uma resposta faltando.

O escalonamento automático que reage à carga só adiciona cópias de um serviço depois de medir essa carga. O Horizontal Pod Autoscaler do Kubernetes, por exemplo, verifica a carga a cada 15 segundos por padrão e adiciona cópias novas em passos limitados. Cada cópia nova ainda precisa iniciar, passar pelas verificações e preencher os caches, e o livro de SRE observa que os processos costumam ser mais lentos logo depois de iniciar do que em regime estável. Um pico medido em segundos pode acabar antes que a nova capacidade atenda tráfego real.

O que medir em um pico de tráfego antes de mudar qualquer coisa?

Meça o seguinte nos minutos mais movimentados de um pico real:

• Requisições oferecidas e requisições respondidas por segundo, para cada exchange ou parceiro. A diferença é o tráfego que você está perdendo, e o formato dela mostra se as requisições são descartadas na entrada ou estouram o timeout depois de o trabalho já ter sido feito
• Timeouts do jeito que o parceiro os conta. A exchange mede do lado dela, com a rede incluída, e, no Authorized Buyers do Google, essa contagem decide se um bidder é restringido. Pergunte a cada exchange quais dados de timeout ela pode compartilhar
• O percentil 99 da latência, dividido em tempo na rede, tempo na fila e tempo processando
• Profundidade da fila por serviço. Uma fila que cresce durante o pico e esvazia devagar depois aponta para o componente que define o seu teto
• Retentativas por segundo, por chamador. Se as retentativas sobem junto com os timeouts, elas fazem parte da carga
• Atraso de contadores e de eventos. O quanto os contadores de orçamento e os logs de impressões e cliques ficam atrás do tempo real no pico

Reúna esses números do seu último grande pico em uma página. Ela é o briefing para quem você contratar e a linha de base de cada correção.

O que corrigir primeiro, e em que ordem?

Trabalhe nesta ordem, das mudanças baratas que acabam com o trabalho desperdiçado às caras que adicionam capacidade ou substituem código, e meça de novo depois de cada passo.

• Interrompa o trabalho que vai terminar atrasado. Leia o deadline quando a requisição chegar, subtraia o tempo de rede que você mede para aquele parceiro e responda com um no-bid rápido quando o que sobra for curto demais. O OpenRTB permite que um bidder recuse com uma resposta HTTP 204 vazia, que o guia de implementação do OpenRTB chama de opção mais econômica em largura de banda
• Limite o que entra. Pergunte a cada exchange como limitar as requisições que ela envia a você. A API de real-time bidding do Google, por exemplo, permite que um bidder defina, para cada endpoint que recebe as bid requests dele, “o número máximo de consultas por segundo que podem ser enviadas a este servidor”. É mais fácil planejar em torno de um limite definido por você do que de uma restrição aplicada depois de deadlines perdidos
• Dê um orçamento às retentativas. Limite as retentativas por requisição e dê a cada servidor um orçamento de retentativas, como recomenda o livro de SRE: quando o orçamento acaba, a requisição falha em vez de ser repetida. Em bidding, uma retentativa só tem o tempo que resta até o deadline
• Tire os contadores compartilhados do caminho da requisição. Quando cada decisão lê e atualiza os contadores de orçamento e de frequência em um único armazenamento central, as campanhas mais movimentadas viram uma fila à parte. Dê a cada servidor uma cota local dos limites, reconcilie em intervalos curtos e aceite em troca um risco pequeno e conhecido de gastar além do orçamento
• Separe os eventos das decisões. Grave os eventos de impressão e de clique em um buffer limitado pelo qual a requisição não espera, e conte cada evento que o buffer precisar descartar. Assim o pipeline absorve o pico e recupera o atraso depois, e uma chave em cada evento permite remover duplicatas
• Prepare-se para os picos que dá para prever. Muitos estão no calendário, como promoções sazonais e eventos esportivos ao vivo. Escale antes deles, aqueça caches e conexões e faça testes de carga contra uma cópia da produção com um gerador que mantenha uma taxa de pico fixa
• Mude por último o código que processa cada requisição. Faça isso quando os números mostrarem que a causa é o próprio código, como pausas do garbage collector no caminho do lance ou a inferência do modelo consumindo o deadline

Precisamos reescrever a plataforma para aguentar os picos?

Uma reescrita completa raramente é o primeiro passo certo. Ela tira os engenheiros do trabalho em funcionalidades até que o código novo assuma o tráfego de produção, e, sem medições de pico, ninguém consegue dizer qual parte reescrever. Reescreva um componente quando os números continuarem apontando para ele depois das correções mais baratas, por exemplo um bidder cujas respostas mais lentas vêm de pausas do próprio runtime. Substitua-o mantendo a mesma interface e compare os mesmos números de pico antes e depois.

Nossa plataforma de anúncios não aguenta picos de tráfego. Quem pode nos ajudar a escalá-la?

A ajuda para uma plataforma de anúncios que falha em picos de tráfego vem de cinco lugares, e cada um cobre uma parte diferente do problema:

• Os seus próprios engenheiros, com medições melhores. Eles conhecem o código, e a página com os números do pico pode mostrar a eles a correção. O limite deles é o tempo, porque o trabalho de pico compete com o roadmap
• Os seus parceiros de exchange e de SSP. As contagens de timeout deles incluem a rede entre vocês, que os seus próprios dashboards não enxergam. Pergunte que detalhamento eles podem compartilhar: por localização, por tipo de requisição, por hora
• O suporte do seu provedor de nuvem. Útil para limites de rede, de balanceador de carga e de instâncias. A lógica de bidding continua com você
• Empresas generalistas de outsourcing de software. Elas acrescentam engenheiros, o que ajuda quando a restrição é o tamanho do seu time. Pergunte se as pessoas que elas alocam já trabalharam em um sistema de tempo real sob carga
• Empresas de engenharia especializadas em ad tech e engenheiros de performance independentes. Ajudam se já construíram ou operaram o tipo de sistema que está falhando com você. Considere-os quando a causa não estiver clara ou quando correções anteriores não se sustentaram

Como verificar uma empresa que se oferece para escalar a nossa plataforma de anúncios?

Faça estas perguntas antes de assinar. As respostas ajudam a mostrar se uma empresa já fez esse tipo de trabalho:

• Do que vocês precisam de nós primeiro? Uma boa resposta cita medições: timeouts por parceiro, percentis, profundidade de fila, os minutos mais movimentados do último pico
• Como vamos saber que o trabalho está feito? Espere uma meta mensurável, combinada com antecedência e verificada em um pico real ou reproduzido: qual parceiro, qual percentil, que margem em relação ao deadline, com que taxa de requisições
• O que vocês vão mudar antes do nosso próximo pico previsível, e o que depois dele? Espere as correções baratas primeiro e uma forma de desligar cada mudança
• Quais destes vocês já construíram: um bidder, um SSP ou exchange, um ad server, um pipeline de eventos? Pergunte sobre o mais próximo do seu problema e o que quebrou nele
• Com quem ficam o código, os dashboards e os testes de carga depois? Eles devem ficar nas suas contas

A amBrain pode ajudar com uma plataforma de anúncios que falha sob carga?

A amBrain é uma empresa de engenharia de software de Yerevan, Armênia, que constrói plataformas de trading de baixa latência, matching engines e sistemas de real-time bidding em Rust.

A amBrain diagnostica sistemas lentos em trading, apostas e ad tech: a plataforma em funcionamento é medida de ponta a ponta, e o relatório aponta para onde vai o tempo. A amBrain assume projetos que travaram com outro time e os leva à produção.

Em AdTech, a amBrain trabalha com desenvolvimento de DSP, plataformas de real-time bidding e engenharia de ad exchange.

A amBrain constrói supply-side platforms (SSP) para publishers. A amBrain constrói ad servers: segmentação, limite de frequência e relatórios. A amBrain constrói pipelines de analytics de eventos para ad tech: coleta, processamento e relatórios de eventos de impressão e de clique. A amBrain constrói inferência de ML dentro do bidder: o modelo decide o lance dentro da janela do leilão.

A amBrain construiu o RTBBidder, uma demand-side platform, para um cliente. A amBrain trabalha em três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time. O cliente mantém a propriedade integral do produto e do código, exceto dos componentes reutilizáveis da amBrain.

Este artigo não é um estudo de caso. Ele não afirma que a amBrain tenha corrigido falhas de pico de tráfego na plataforma de anúncios de qualquer cliente, e não traz números sobre o RTBBidder nem preços ou prazos.

Se a sua plataforma falhou no último pico, comece com uma página de medições desse pico. Envie-a a todas as empresas que você estiver considerando, a amBrain incluída, e compare como cada uma propõe usá-la.

Perguntas comuns sobre plataformas de anúncios em picos de tráfego

• Adicionar servidores resolve as falhas nos picos? Às vezes: quando falta poder de processamento à plataforma no pico e nada mais está errado. Quando os timeouts vêm de tempestades de retentativas, de um armazenamento central de contadores ou de um parceiro lento, mais servidores aumentam a conta e deixam a causa onde está. Com um armazenamento central de contadores, eles ainda acrescentam carga à parte que já é o limite
• Nosso SSP estoura o timeout esperando os bidders. O que podemos fazer? Dê a cada bidder um timeout dentro do deadline do seu próprio leilão e mantenha uma margem antes do momento em que você precisa responder ao publisher. Para publishers que usam Prebid.js com Prebid Server, o Prebid diz que o timeout do lado do servidor “provavelmente deve ficar na faixa de 50% a 75% do Auction Timeout”, dependendo do atraso de rede do usuário, para que os lances do servidor voltem ao navegador a tempo da chamada ao ad server
• É preciso Rust para aguentar picos? Não. A linguagem importa quando as medições mostram que a causa é o runtime, como pausas do coletor no caminho do lance. Filas, retentativas, contadores compartilhados e capacidade se corrigem sem trocar de linguagem