Opções de infraestrutura para a disponibilização de cargas de trabalho de publicidade (parte 1)

Neste artigo, descrevemos os componentes que são compartilhados em diferentes plataformas de tecnologia de anúncios, incluindo servidores de anúncios e proponentes. Aqui também oferecemos opções para implementar esses componentes.

Geralmente, servidores de anúncios e proponentes são plataformas complementares que usam a mesma tecnologia. Para evitar a duplicação de conteúdo, fornecemos neste artigo e na parte 2 o contexto necessário para a série:

Para ler a visão geral e conhecer a terminologia usada na série inteira, consulte o artigo Como criar plataformas de publicidade (visão geral).

Considerações sobre plataforma

Ao lidar com o aspecto relativo a compras ou vendas das plataformas, leve os seguintes fatores em consideração:

  • Plataforma de computação: as plataformas de publicidade programática são compostas de diversos serviços, cada um com uma ou mais funções. Decida primeiro se é possível colocar uma ou todas as funções em contêineres, ou se é necessário executar o serviço diretamente em instâncias de máquina virtual (VM, na sigla em inglês).
  • Locais geográficos: implantar a infraestrutura próximo ao local onde seus clientes e provedores estão reduz a latência de rede.
  • Reprodutibilidade: ao replicar um sistema em diferentes regiões do mundo, implantar consistentemente a mesma infraestrutura proporciona mais consistência para a plataforma como um todo.
  • Balanceamento de carga: uma única máquina não pode processar cargas de tecnologia de anúncios. Distribua as solicitações internas e externas por vários servidores.
  • Escalonamento automático: as cargas de solicitação de anúncio flutuam ao longo do dia. Habilite o escalonamento automático do sistema para reduzir os custos e aumentar a disponibilidade.
  • Comunicação de rede: um sistema distribuído gera dúvidas sobre a comunicação. Por exemplo, imagine que alguém faz lances nos Estados Unidos, mas o banco de dados de gerenciamento de campanhas está na Europa. Mesmo se a comunicação consistir em sincronização off-line, provavelmente você não quer que ela aconteça via Internet pública.

Plataforma de computação

O Google Cloud oferece várias opções para executar cargas de trabalho computacionais. Tenha em mente as seguintes opções:

  • App Engine para executar a interface do usuário (IU) da Web, sem grande parte das despesas operacionais.
  • Compute Engine para instalar e gerenciar alguns bancos de dados relacionais ou códigos personalizados não compatíveis com o App Engine.
  • Google Kubernetes Engine (GKE) para configurar front-ends sem estado ou executar aplicativos em contêineres.

Essas opções são recomendações e geralmente são intercambiáveis. Em última análise, os requisitos que você precisa cumprir, seja com relação ao custo, às despesas operacionais ou ao desempenho, são o fator decisivo.

O Compute Engine e o GKE são compatíveis com VMs preemptivas, que são frequentemente usadas em cargas de trabalho de tecnologias de anúncios para economizar nos custos. VMs preemptivas podem ser interrompidas forçadamente com apenas um aviso de um minuto. Portanto, talvez o ideal seja fazer o seguinte:

  • Se você usa o Compute Engine, é possível ter dois grupos de instâncias gerenciadas diferentes (um com VMs preemptivas e outro com VMs padrão) residindo por trás do mesmo balanceador de carga. No entanto, é necessário que um grupo seja de VMs padrão para que o front-end seja sempre capaz de processar as solicitações recebidas. O diagrama a seguir mostra essa abordagem.

    dois grupos de instâncias gerenciadas diferentes no mesmo balanceador de carga

  • Se você usa o GKE, é possível mitigar o custo com a disponibilidade. Para isso, crie pools de nós preemptivos e não preemptivos no cluster do GKE.

Locais geográficos

Os anunciantes talvez queiram alcançar clientes em todas as regiões do mundo. Adicionar alguns milésimos de segundo extras a um dos front-ends de IU da plataforma não prejudicará a experiência dos anunciantes quando, por exemplo, eles visualizarem os dados de desempenho. No entanto, tenha cuidado caso a distância de rede adicional inclua alguns milésimos de segundo à resposta com o lance. Esses poucos milésimos de segundo podem ser a diferença entre o lance do anunciante ser aceito e o anúncio ser veiculado para o cliente ou não.

O Google Cloud está presente em várias regiões, incluindo us-east, us-west, europe-west, asia-southeast e asia-east. Cada região inclui diversas zonas para oferecer alta disponibilidade e em escala.

Se a latência for crítica, distribua alguns serviços entre as zonas de regiões diferentes. É possível personalizar a configuração de acordo com suas necessidades. Por exemplo, é possível ter alguns servidores de front-end em us-east4 e us-west1, mas armazenar os dados em um banco de dados em us-central. Em alguns casos, é possível replicar alguns dos dados no banco de dados localmente nos servidores de front-end. Outra opção é usar uma instância multirregional do Cloud Spanner.

Reprodutibilidade

A reprodutibilidade torna a manutenção e a implantação mais simples. Além disso, a execução da plataforma em todas as localizações geográficas relevantes é essencial para que os lances sejam retornados antes do prazo crítico. Para garantir a reprodutibilidade, é necessário que todas as regiões realizem um trabalho semelhante. A principal diferença é a carga de trabalho e quantas máquinas e zonas precisam ser escalonadas para atender à demanda regional.

Com o Compute Engine, os modelos de instâncias são a base para configurar grupos de instâncias gerenciadas regionais semelhantes. Esses grupos podem estar localizados em regiões diferentes para que fiquem mais próximos às plataformas de venda (SSP, na sigla em inglês). Além disso, eles podem estar ocupar várias zonas para proporcionar alta disponibilidade. O diagrama a seguir mostra como é esse processo.

Use o modelo de instância para configurar grupos de instâncias gerenciadas regionais

Os contêineres oferecem um nível mais alto de abstração do que a virtualização de máquina. O Kubernetes facilita a reprodutibilidade de aplicativos nativamente por meio de arquivos de configuração YAML, que podem ser usados para definir pods, serviços e implantações com consistência nos diferentes clusters.

Balanceamento de carga

Há dois cenários principais que exigem o balanceamento de carga:

Ao usar o Kubernetes em algumas partes da infraestrutura, recomendamos que você utilize o GKE. Talvez seja necessário realizar implementações extras para alguns recursos do Kubernetes se o provedor não for nativamente compatível com eles. Com o GKE, o Kubernetes pode usar recursos nativos do Google Cloud:

O GKE também é compatível com o balanceamento de carga nativo de contêiner para minimizar o tempo de rede e possíveis saltos extras. De maneira geral, o balanceador de carga impede que uma solicitação seja encaminhada para uma instância que não hospeda um pod do serviço solicitado.

Dimensionamento

Como a plataforma precisa ser capaz de analisar e calcular bilhões de solicitações de anúncios por dia, o balanceamento de carga é imprescindível. Além disso, utilizar uma única máquina é inadequado para essa tarefa. No entanto, o número de solicitações tende a mudar ao longo do dia. Isso significa que a infraestrutura precisa ser capaz de dimensionar conforme a demanda.

Ao usar o Compute Engine, é possível criar grupos de instâncias gerenciadas com escalonamento automático com base em modelos de instâncias. Depois, dimensione esses grupos por métricas diferentes, como carga de HTTP, CPU e métricas personalizadas do Cloud Monitoring (por exemplo, latência do aplicativo). Esses grupos também podem ser dimensionados de acordo com uma combinação dessas métricas.

As decisões de dimensionamento automático são baseadas na média da métrica nos últimos dez minutos, e são tomadas a cada minuto usando uma janela deslizante. Cada grupo de instâncias pode ter o próprio conjunto de regras de dimensionamento.

Se você decidir usar o Autoescalador de cluster do Kubernetes, é possível implementá-lo nativamente com o GKE Cluster Autoscaler. O GKE Cluster Autoscaler se comporta de maneira diferente do Compute Engine Autoscaler. Ele inicia nós novos quando não é mais possível programar pods novos nos nós atuais devido à falta de CPU ou memória nos nós subjacentes. A redução de escala funciona automaticamente quando a CPU ou a memória é liberada novamente.

Comunicação da rede

As nuvens privadas virtuais (VPC, na sigla em inglês) podem abranger várias regiões. Em outras palavras, se você tiver réplicas de leitura do banco de dados em us-east e um banco de dados mestre em asia-southeast na mesma VPC, eles poderão se comunicar com segurança usando nomes de host ou IPs privados sem sair da rede do Google.

No diagrama a seguir, todas as instâncias estão na mesma VPC e podem se comunicar diretamente sem a necessidade de uma rede privada virtual (VPN, na sigla em inglês), mesmo se estiverem em regiões diferentes.

Todas as instâncias estão na mesma VPC e em regiões diferentes

No momento da criação dos clusters do GKE, eles são atribuídos a uma VPC. Esses clusters podem usar muitos dos recursos atuais da rede.

O Google também oferece dois tipos de infraestrutura de rede:

  • Premium: usa a rede particular global do Google. Priorize essa opção para as cargas de trabalho críticas, como a replicação de banco de dados entre regiões.
  • Padrão: priorize essa opção caso o preço seja uma preocupação e usar a Internet pública não for um problema.

Ao usar produtos gerenciados, como Cloud Bigtable, Cloud Storage ou BigQuery, o Google Cloud fornece acesso particular a esses produtos por meio da VPC.

Front-end de usuário

O front-end de usuário é importante, mas requer o mínimo de trabalho técnico porque ele processa cargas de trabalho muito menores. O front-end de usuário permite aos usuários da plataforma administrar recursos de publicidade, como campanhas, criativos, faturamento ou lances. O front-end também possibilita interagir com ferramentas de relatório para, por exemplo, monitorar campanhas ou o desempenho de anúncios.

Esses dois recursos requer disponibilização via Web para exibir uma IU ao usuário da plataforma e repositórios para armazenar os dados transacionais ou analíticos.

Disponibilização via Web

Seu front-end de publicidade precisa:

  • oferecer alta disponibilidade;
  • processar centenas de solicitações por segundo;
  • estar disponível globalmente com latência aceitável para oferecer uma boa experiência ao usuário;
  • fornecer uma IU.

A interface geralmente deve incluir funcionalidades como um painel e páginas para configurar anunciantes, campanhas e componentes relacionados. O design da IU em si é um assunto distinto que não faz parte do escopo deste artigo.

Para minimizar o trabalho técnico, recomendamos usar o App Engine como uma plataforma de front-end. Isso minimizará o tempo gasto no gerenciamento da infraestrutura do seu site. Se você precisar de um ambiente de execução personalizado, pense em usar o Custom Runtimes. Como alternativa, use o GKE ou o Compute Engine se sua pilha de aplicativos preferencial tiver outros requisitos.

Armazenamentos de dados

Há dois tipos de armazenamento de dados nos front-ends de usuário:

  • Armazenamentos de dados de administração que exigem bancos de dados de processamento de transações on-line (OLTP, na sigla em inglês). As opções estão detalhadas na seção sobre armazenamento de gerenciamento de metadados.
  • Armazenamentos de dados de relatório que exigem bancos de dados de processamento analítico online (OLAP, na sigla em inglês). As opções estão detalhadas na seção sobre armazenamento de painel/relatórios.

Como processar solicitações

Front-ends

As solicitações são enviadas para o processamento em um endpoint HTTP(S) fornecido por sua plataforma. Os principais componentes são:

  • um balanceador de carga capaz de processar milhares de consultas por segundo (QPS, na sigla em inglês);
  • um conjunto de instâncias que podem ser escalonadas rapidamente com base em vários indicadores principais de desempenho (IPDs);
  • uma possível API que limita e/ou autentica no endpoint.

Tanto o Compute Engine quanto o GKE são boas opções como plataformas de computação:

  • O Compute Engine usa o Cloud Load Balancing e os grupos de instâncias gerenciadas mencionados na seção sobre escalonamento.
  • O GKE usa o Cloud Load Balancing e a Entrada (ou o Istio Ingress Gateway), o Autoescalador de pods horizontal e o Autoescalador de cluster.

Como o escalonamento de pods é mais rápido que o de nós, o GKE talvez realize o escalonamento automático por serviço mais rapidamente. O GKE também é compatível com balanceamento de carga nativo de contêiner para otimizar o encaminhamento de solicitações diretamente para uma instância que hospeda um pod do serviço em questão.

É possível gerenciar a limitação e a autenticação usando tecnologias como a Apigee ou a Infraestrutura de serviços.

Análise

Geralmente, as solicitações de anúncios são formatadas em JSON ou protobuf com informações como endereço IP, user agent ou categoria do site. É essencial extrair esses dados, que também podem conter detalhes sobre o usuário (único), para recuperar segmentos utilizados na seleção e filtragem de anúncios.

Filtragem estática

Algumas solicitações, normalmente recebidas no lado do comprador, podem ser descartadas com a aplicação de regras estáticas. Com essa filtragem antecipada, é possível reduzir a quantidade de dados e o processamento complexo posteriormente necessários.

As regras podem ser listas de bloqueios de editores ou exclusões de tipos de conteúdo. Durante a inicialização, os trabalhadores podem extrair e carregar essas regras a partir de um arquivo hospedado no Cloud Storage.

Seleção de anúncios

É possível realizar a seleção de anúncios em vários serviços ou plataformas, incluindo: o servidor de anúncios do editor, o servidor de anúncios do anunciante ou a plataforma de demanda (DSP, na sigla em inglês). Há diferentes níveis de complexidade ao selecionar um anúncio:

  • Algumas seleções podem ser tão simples quanto selecionar um anúncio de uma categoria específica do site ou página do editor. Nesse caso, os preços não diferem por anúncio.
  • Seleções mais avançadas incorporam atributos e segmentos de usuário e possivelmente envolvem sistemas de recomendação de anúncios com base em machine learning (ML).
  • Os sistemas de lances em tempo real (RTB, na sigla em inglês) geralmente tomam as decisões mais complexas. Os anúncios são selecionados com base em atributos, como segmentos de usuário (único) e preços de lances anteriores. A seleção também inclui um cálculo de lance para otimizar o preço por solicitação.

Escolher o anúncio relevante é a função principal do seu sistema. Há muitos fatores que devem ser levados em consideração, incluindo algoritmos avançados baseados em regras ou seleção de ML. Porém, neste artigo, focamos no processo geral e nas interações com armazenamentos de dados diferentes.

O processo de seleção de anúncios consiste nas seguintes etapas:

  1. Recuperar os segmentos associados ao usuário desejado de um armazenamento de perfis de usuário (único).
  2. Selecionar as campanhas ou os anúncios que combinam bem com os segmentos do usuário. Essa seleção requer a leitura de metadados do armazenamento de gerenciamento de metadados. É por isso que esse armazenamento exige a implementação de um dos padrões de armazenamento de leitura pesada.
  3. Filtrar as campanhas ou os anúncios selecionados de acordo com as métricas, por exemplo, o orçamento restante, armazenado em um dos armazenamentos de contexto.
  4. Selecionar o anúncio.

Os proponentes têm mais etapas relacionadas a lances e leilões, e requisitos de latência mais difíceis. Para mais detalhes sobre os requisitos de proponentes durante a seleção de anúncios, consulte Opções de infraestrutura para proponentes em tempo real (parte 4).

Padrões de armazenamento de leitura pesada

A maioria das decisões tomadas ao selecionar um anúncio exige dados inteligentes que:

  • são lidos em milésimos de segundo, às vezes abaixo disso;
  • são gravados o mais rápido possível, especialmente no caso de contadores dependentes do tempo;
  • são gravados muitas vezes como parte de um processo off-line que usa tarefas de machine learning ou de análise em segundo plano.

A escolha do armazenamento de dados depende da ordem de prioridade dos requisitos abaixo:

  • Minimização das latências de leitura ou gravação: se a latência for um fator crítico, você precisará de um armazenamento próximo aos seus servidores e que processe leituras ou gravações rápidas em escala.
  • Minimização do trabalho operacional: se sua equipe de engenharia é pequena, talvez você precise de um banco de dados totalmente gerenciado.
  • Escalonamento: para suportar milhões de usuários segmentados ou bilhões de eventos por dia, o armazenamento de dados precisa dimensionar horizontalmente.
  • Adaptação ao estilo de consulta: algumas consultas usam uma chave específica, enquanto outras precisam recuperar registros que atendem a um conjunto diferente de condições. Em alguns casos, os dados da consulta podem ser codificados na chave. Em outros, as consultas precisam de recursos do tipo SQL.
  • Maximização da atualização de dados: alguns contadores, como orçamento, precisam ser atualizados o mais rápido possível. Outros dados, como segmento de público-alvo ou contadores (por exemplo, limites diários), podem ser atualizados posteriormente.
  • Minimização dos custos: nem sempre é econômico ou prático processar bilhões de leituras e gravações todos os dias com consistência forte globalmente em um único banco de dados para minimizar o DevOps.

Há opções diferentes para atender aos requisitos de leitura pesada. Essas opções incluem réplicas de leitura, sistemas de armazenamento em cache, bancos de dados NoSQL na memória e bancos de dados NoSQL gerenciados de colunas largas.

Réplicas de leitura RDBMS

Ao usar o Cloud SQL (ou um RDBMS equivalente instalado e gerenciado no Compute Engine), é possível descarregar as leituras da instância mestre. Muitos bancos de dados são nativamente compatíveis com esse recurso. Os trabalhadores podem consultar informações necessárias por meio de:

  • réplicas de leitura que correspondem ao número de trabalhadores;
  • um proxy de pooling.

O diagrama a seguir mostra como é esse processo.

Banco de dados em que as leituras são descarregadas da instância mestre

As réplicas de leitura foram projetadas para atender ao tráfego de leitura pesada. No entanto, a escalabilidade não é linear e o desempenho pode sofrer com o número maior de réplicas. Se você precisar de leituras ou gravações que possam ser escalonadas, tenham consistência global e exijam trabalho operacional mínimo, pense em usar o Cloud Spanner.

Camada de armazenamento em cache local

É possível usar uma camada de armazenamento em cache, como o Redis no Compute Engine, com réplicas locais opcionais nos trabalhadores. Essa camada pode minimizar muito a latência de leituras e da rede. O diagrama a seguir mostra como é essa camada.

Utilize uma camada de armazenamento em cache para minimizar a latência

Se você usar o Kubernetes nesse caso, observe o DaemonSet e a afinidade para verificar se:

  • a quantidade de dados replicados está limitada;
  • os dados permanecem próximos de um pod de disponibilização.

NoSQL de chave-valor na memória

Implante um banco de dados na memória, como o Aerospike ou o Redis, para fornecer leituras rápidas em escala. Essa solução é útil para dados e contadores regionais. Se você estiver preocupado com o tamanho das estruturas de dados armazenadas, uma opção é usar bancos de dados na memória que fazem gravações em discos SSD. O diagrama a seguir mostra como é essa solução.

Um banco de dados na memória que pode gravar em discos SSD

NoSQL de colunas largas gerenciado

Os armazenamento de dados de colunas largas são armazenamentos de chave-valor que podem fornecer leituras e gravações rápidas em escala. É possível instalar um banco de dados de código aberto comum, como o Cassandra ou o HBase.

Se você usar um armazenamento desse tipo, recomendamos o Cloud Bigtable para minimizar o trabalho operacional. Esses armazenamentos permitem escalonar as operações de entrada/saída (IOPs, na sigla em inglês) linearmente com o número de nós. Desde que o design de chave seja apropriado, os seletores de anúncios poderão fazer leituras e o pipeline de dados poderá fazer gravações na velocidade de milésimos de segundo de um único dígito até o primeiro byte em petabytes de dados. O diagrama a seguir mostra como é esse processo.

Armazenamentos de dados de colunas largas

Armazenamento de objetos estáticos

No caso de dados estáticos que podem ser salvos nos formatos protobuf, AVRO e JSON, os trabalhadores podem carregar o conteúdo a partir do Cloud Storage durante a inicialização e mantê-lo na RAM. O diagrama a seguir mostra como é esse processo.

Carregar dados do Cloud Storage

Não existe uma única solução ideal para todos os casos. Escolha aquelas que melhor se adequam às suas prioridades e ofereçam os resultados mais equilibrados quanto a latência, custo, operações, desempenho de leitura/gravação e tamanho dos dados.

Solução Latência Custo Trabalho operacional Desempenho de leitura/gravação Tamanho dos dados
Réplicas de leitura RDBMS Milésimos de segundo Baseado em serviço ou computação Alto Limitado Limitado
Cloud Spanner Milésimos de segundo Baseado em serviço Baixo Escala linear com o número de nós Petabytes
Armazenamentos na memória Menos de um milésimo de segundo Baseado em computação Alto Escala com o número de nós Escala com o número de nós
Cloud Bigtable Milésimos de segundo de um dígito Baseado em serviço Baixo Escala linear com o número de nós Petabytes

Armazenamentos de dados de publicidade

Nesta seção, falamos sobre as opções de armazenamento de dados que atendem a um dos três cenários diferentes:

  • Armazenamentos de veiculação de anúncios são usados por serviços relacionados à seleção de anúncios. A disponibilização de cargas de trabalho requer baixa latência e capacidade de processar bilhões de leituras por dia. O tamanho dos dados depende do tipo.
  • Armazenamentos analíticos são usados off-line por meio de consultas ad hoc ou pipelines de dados em lote. Eles suportam centenas de terabytes de dados armazenados diariamente.
  • Armazenamentos de painel/relatórios podem ser usados para painéis pré-desenvolvidos, séries temporais ou relatórios personalizados. Essas opções diferenciam o front-end, permitindo que os usuários da plataforma recebam insights rapidamente e visualizem o desempenho dos negócios.

Os armazenamentos de veiculação de anúncios podem ser mais detalhados, conforme abaixo:

Armazenamento de gerenciamento de metadados

O armazenamento de gerenciamento de metadados contém os dados de referência a que são aplicadas as regras ao fazer a seleção de anúncios. Alguns recursos armazenados são específicos de uma plataforma. No entanto, outros são compartilhados:

  • No caso de servidor de anúncios no lado do vendedor, os editores gerenciam os dados sobre campanhas, criativos, anunciantes, espaços de anúncios e preços. Alguns front-ends também concedem acesso aos compradores.
  • No caso de servidor de anúncios no lado do comprador, os compradores gerenciam os dados sobre campanhas, criativos, anunciantes e preços. Os anunciantes geralmente podem atualizar os dados por meio de uma IU.
  • No caso de DSP, os compradores gerenciam os dados sobre campanhas, criativos, anunciantes e preços de lances. Os anunciantes geralmente podem atualizar os dados por meio de uma IU.

O armazenamento de metadados contém dados semiestáticos relacionais ou hierárquicos:

  • As gravações são resultado das edições do usuário da plataforma usando o front-end e ocorrem com pouca frequência.
  • Os dados são lidos bilhões de vezes por dia pelos servidores de seleção de anúncios.

Com relação ao front-end do usuário, o banco de dados de metadados da campanha precisa gerenciar relacionamentos e hierarquias entre recursos e armazenar desde megabytes a poucos gigabytes de dados. Também é necessário que o banco de dados realize leituras e gravações no intervalo de centenas de QPS. Para cumprir com esses requisitos, o Google Cloud oferece várias opções de banco de dados, gerenciados e não gerenciados:

  • Cloud SQL: um serviço de banco de dados totalmente gerenciado que executa MySQL ou PostgreSQL.
  • Datastore: um serviço de banco de dados NoSQL gerenciado e distribuído, além de altamente escalonável. É compatível com transações ACID, inclui linguagem de consulta semelhante a SQL e tem níveis de consistência posterior e forte.
  • Spanner: um banco de dados relacional com escalonamento horizontal que realiza leituras eficientes e consistentes, transações globais e replicação entre regiões. Pode processar leituras e gravações pesadas.
  • Personalizado: também é possível instalar e gerenciar muitos dos bancos de dados de código aberto ou proprietários, como MySQL, PostgreSQL, MongoDB ou Couchbase, no Compute Engine ou no GKE.

Os requisitos restringem as opções. No entanto, o Cloud SQL pode ser usado em geral por ser compatível com dados relacionais. O Cloud SQL também é gerenciado e oferece opções de réplica de leitura.

Conforme mencionado anteriormente, o armazenamento de metadados é usado tanto pelos usuários da plataforma, para fins de administração ou geração de relatórios, quanto pelos servidores que selecionam anúncios. Essas leituras acontecem bilhões de vezes ao dia. Há duas maneiras principais de abordar esses requisitos de leitura pesada:

  • usando um banco de dados capaz de processar gravações consistentes de maneira global e bilhões de leituras por dia, como o Spanner.
  • desassociando as leituras das gravações. É possível adotar essa abordagem porque os metadados não são alterados com frequência. Para saber mais sobre essa abordagem, leia a seção sobre exportações (parte 2).

Armazenamento de perfis de usuário (único)

Esse tipo de armazenamento contém usuários (únicos) e as informações associadas a eles que fornecem insights importantes para selecionar uma campanha ou um anúncio mediante solicitação. As informações podem incluir atributos do usuário (único), seus próprios segmentos ou segmentos importados de terceiros. Em RTB, os segmentos importados geralmente incluem recomendações de preços de lance.

Esse tipo de armazenamento de dados precisa armazenar centenas de gigabytes e, possivelmente, até terabytes de dados. Além disso, o armazenamento de dados precisa recuperar registros únicos com uma velocidade de, no máximo, menos de 10 milésimos de segundo. A quantidade de dados armazenados depende do nível de detalhamento das suas informações de usuário (único). No mínimo, o armazenamento precisa recuperar uma lista de segmentos para o usuário desejado.

O armazenamento é atualizado com frequência, com base na interação do usuário (único) com anúncios, sites visitados ou ações realizadas. Quanto mais informações, melhor a segmentação. Pense também em usar plataformas de gerenciamento de dados (DMP, na sigla em inglês) de terceiros para enriquecer os dados próprios.

O Cloud Bigtable e o Datastore são bancos de dados comuns para dados de usuários (únicos). Esses dois bancos de dados são adequados para leituras e gravações aleatórias de registros únicos. Use o Cloud Bigtable somente se você tiver, pelo menos, várias centenas de gigabytes de dados.

Outros bancos de dados comuns, como o MongoDB, o Couchbase, o Cassandra ou o Aerospike, também podem ser instalados no Compute Engine ou no GKE. Esses bancos de dados geralmente exigem mais trabalho de gerenciamento, mas alguns oferecem mais flexibilidade, possivelmente menor latência e, em alguns casos, replicação entre regiões.

Para mais detalhes, veja a seção sobre correspondência de usuário (parte 4).

Armazenamentos de contexto

Geralmente, o armazenamento de contexto é usado para armazenar contadores, por exemplo, limites de frequência e orçamento restante. A frequência com que os dados são atualizados no armazenamento de contexto varia. Por exemplo, um limite diário pode ser propagado diariamente, enquanto o orçamento restante da campanha requer recálculo e propagação o mais rápido possível.

Dependendo do padrão de armazenamento escolhido, dos contadores atualizados e dos recursos do banco de dados selecionado, é possível gravar diretamente no banco de dados. Como alternativa, pode ser uma opção melhor desacoplar a implementação usando um padrão de publicação-assinatura com um sistema de mensagens, como Pub/Sub, para atualizar o armazenamento após o cálculo.

Algumas boas opções de armazenamento de contexto são:

  • Cloud Bigtable
  • o padrão NoSQL de chave-valor na memória regional
  • o padrão de armazenamento em cache regional

Ao usar dimensionamento horizontal, esses armazenamentos conseguem processar gravações e leituras em escala. Nos artigos Opções de infraestrutura para servidores de anúncios (parte 3) e Opções de infraestrutura para proponentes em tempo real (parte 4), discutimos algumas dessas opções com mais detalhes.

Exemplo de como gerenciar um contador de orçamento em um ambiente distribuído

Configure os orçamentos na ferramenta de gerenciamento de campanhas. As campanhas não devem exceder o limite de gastos porque, na maioria das vezes, os anunciantes não pagam por impressões extras. No entanto, agregar contadores, como orçamento restante, pode ser uma tarefa difícil nos ambientes distribuídos, principalmente quando o sistema recebe milhares de solicitações de anúncios por segundo. As campanhas poderão exceder os gastos em poucos segundos, se o orçamento global restante não for consolidado rapidamente.

Por padrão, um trabalhador gasta frações do orçamento sem tomar conhecimento do quanto os trabalhadores irmãos gastaram. Essa falta de comunicação pode levar a uma situação em que o trabalhador gasta um valor que já não está mais disponível.

Há algumas maneiras diferentes para lidar com esse problema. Ambas as opções a seguir implementam um administrador de orçamento global, mas elas se comportam de forma diferente.

  1. Notificação sobre o esgotamento do orçamento aos trabalhadores: o administrador de orçamento rastreia os gastos e envia notificações para cada trabalhador quando o orçamento da campanha se esgota. Devido à probabilidade de altos níveis de QPS, as notificações devem ocorrer em até um segundo para limitar rapidamente o gasto excessivo. O diagrama a seguir mostra como esse processo funciona.

    Notificação de esgotamento do orçamento

  2. Alocação periódica de frações do orçamento para cada trabalhador : o administrador divide o orçamento restante global em valores menores que são alocados para cada trabalhador individualmente. Os trabalhadores gastam o próprio orçamento local e, quando o valor é esgotado, eles podem solicitar mais. Esta opção tem algumas vantagens:

    1. Antes de gastar novamente, os trabalhadores precisam esperar que o administrador de orçamento aloque um novo valor para eles. Essa abordagem evita gastos excessivos, ainda que alguns trabalhadores permaneçam inativos por um tempo.
    2. O administrador de orçamento pode adaptar o valor alocado a ser enviado a cada trabalhador com base no comportamento de gastos individual em cada ciclo. O diagrama a seguir mostra esse processo.

      O administrador de orçamento aloca um orçamento para cada nó

Independentemente da opção escolhida, os contadores de orçamento são calculados com base no modelo de preços acordado entre o editor e o anunciante. Por exemplo, se o modelo for:

  • com base em CPM, uma impressão faturável envia um evento ao sistema, que diminui o orçamento restante de acordo com o preço definido por mil impressões.
  • com base em CPC, um clique de usuário envia um evento ao sistema, que diminui o orçamento restante de acordo com o preço definido por clique.
  • com base em CPA, um pixel de rastreamento colocado na propriedade do anunciante envia um evento ao sistema, que diminui o orçamento de acordo com o preço definido por ação.

O número de impressões geralmente é de algumas ordens de grandeza superior ao número de cliques. Por sua vez, o número de cliques geralmente é de algumas ordens de grandeza superior ao número de conversões. A ingestão desses eventos requer uma infraestrutura de processamento de eventos escalonável. Discutimos essa abordagem em mais detalhes no artigo sobre pipeline de dados.

Armazenamento analítico

O armazenamento analítico é um banco de dados usado para armazenar e processar off-line terabytes de dados ingeridos diariamente, ou seja, não durante processamentos em tempo real. Exemplo:

  • Os dados do usuário (único) são processados off-line para determinar os segmentos associados, que, por sua vez, são copiados para bancos de dados mais rápidos, como o de perfis de usuários, para veiculação. Este processo é explicado na seção sobre exportações.
  • Unir solicitações com impressões e ações do usuário (único) para agregar os contadores off-line usados em um armazenamento de contexto.

Armazenamento de painel/relatórios

O armazenamento de painel/relatórios é usado no front-end do usuário e fornece insights sobre o desempenho de campanhas ou inventários. Há tipos diferentes de relatórios. Você tem a opção de oferecer alguns ou todos, incluindo recursos de análise personalizada e painéis semiestáticos atualizados a cada poucos segundos ou em tempo real.

É possível usar o BigQuery para aproveitar os recursos de análise dessa solução. Se você utilizar as visualizações para limitar o acesso a dados e compartilhá-las com seus clientes, poderá oferecer aos usuários da sua plataforma recursos analíticos específicos por meio de sua própria IU ou as ferramentas de visualização que eles utilizam. Nem toda empresa oferece essa opção, mas é um ótimo recurso adicional que você pode oferecer aos clientes. Pense em aplicar o modelo de preços fixos para esse caso de uso.

Se você quiser oferecer aos seus clientes recursos de processamento analítico on-line (OLAP, na sigla em inglês) com latência de segundos ou milésimos de segundo, use um banco de dados em frente ao BigQuery. É possível agregar dados para a geração de relatórios e exportá-los do BigQuery para o banco de dados que você preferir. Geralmente usa-se os bancos de dados relacionais, como aqueles compatíveis com o Cloud SQL, para essa finalidade.

Utilizando o App Engine ou qualquer outro front-end que atua em nome do usuário usando uma conta de serviço, o BigQuery entende as consultas como provenientes de um único usuário. O resultado é que o BigQuery pode armazenar em cache algumas consultas e retornar resultados calculados anteriormente mais rápido.

Painéis semiestáticos também são frequentemente usados. Esses painéis usam KPIs pré-agregados gravados por um processo de pipeline de dados. Os armazenamentos provavelmente são baseados em NoSQL, como o Firestore, para realizar atualizações em tempo real com mais facilidade ou camadas de cache, como Memorystore. A atualidade dos dados normalmente depende da frequência das atualizações e da duração da janela usada para agregá-los.

Próximas etapas