Arquitetura: como otimizar o processamento de eventos e registros de análise em larga escala

Neste artigo, descrevemos uma arquitetura para otimização do processamento de análises em larga escala no Google Cloud Platform (GCP). Para os fins deste artigo, "larga escala" significa mais de 100 mil eventos por segundo, ou um tamanho de payload de evento agregado total de mais de 100 MB por segundo.

Você pode usar os serviços flexíveis e escalonáveis do GCP para coletar grandes quantidades de eventos de registro e análise recebidos e, em seguida, processá-los para inserção em um armazenamento de dados, como o BigQuery.

Qualquer arquitetura para processamento de quantidades significativas de dados de análise leva em conta quais dados precisam ser acessados quase em tempo real e quais podem ser processados após um pequeno atraso, a fim de separá-los corretamente. Uma abordagem segmentada traz estes benefícios:

  • Integridade dos registros. Você pode ver registros completos. Nenhum registro se perde devido a limites de cota de streaming ou amostragem.
  • Redução de custos. Inserções de streaming de eventos e registros são faturadas a uma taxa maior do que as inserções do Cloud Storage que usam jobs em lote.
  • Recursos de consulta reservados. Mover registros de prioridade inferior para carregamento em lote impede que eles causem impactos nos recursos de consulta reservados.

O diagrama de arquitetura a seguir mostra um sistema desse tipo e introduz os conceitos de hot paths e cold paths para processamento:

caminhos de processamento gerais

Visão geral da arquitetura

Nesta arquitetura, os dados surgem a partir de duas possíveis origens:

Após a ingestão de uma dessas origens, com base nos requisitos de latência da mensagem, os dados são colocados em hot path ou cold path. O hot path usa entradas de streaming, que podem lidar com um fluxo de dados contínuo, enquanto o cold path é um processo de lote, que carrega os dados em uma programação determinada por você.

Eventos de geração de registros

Você pode usar o Stackdriver Logging para processar eventos de geração de registros criados por instalações padrão dos sistemas operacionais. Por padrão, o Stackdriver Logging está disponível em diversos ambientes do Compute Engine, incluindo imagens padrão. Ele pode também ser instalado em vários sistemas operacionais por meio do Stackdriver Logging Agent. O agente de geração de registros é o coletor de registros padrão do App Engine e do Kubernetes Engine.

Hot path

geração de registros em hot path

No hot path, registros essenciais necessários para monitoramento e análise dos serviços são escolhidos por meio da seleção de um filtro no coletor do Stackdriver Logging e transmitidos por streaming a várias tabelas do BigQuery. Use tabelas separadas para níveis ERROR e WARN e, em seguida, divida por serviços, se forem esperados volumes muito altos. Esta prática recomendada mantém o número de inserções por segundo por tabela abaixo do limite de 100 mil e mantém o bom desempenho das consultas para esses dados.

Cold path

geração de registros em cold path

Para o cold path, os registros que não precisam de análise quase em tempo real são selecionados por meio de um coletor do Stackdriver Logging direcionado para um intervalo do Cloud Storage. Os registros são organizados em lotes e gravados em arquivos de registro nos lotes do Cloud Storage de hora em hora. Esses registros podem, então, ser carregados em lote para o BigQuery usando o processo de importação de arquivos padrão do Cloud Storage, que pode ser iniciado usando o Console do Google Cloud Platform, a interface de linha de comando (CLI) ou um simples script. O carregamento em lotes não causa impactos no processamento de streaming de hot path nem no desempenho de consultas. Na maioria dos casos, provavelmente é melhor mesclar os registros de cold path nas mesmas tabelas usadas pelos registros de hot path para simplificar a solução de problemas e a geração de relatórios.

Eventos de análise

Os eventos de análise podem ser gerados pelos serviços do aplicativo no GCP ou enviados a partir de clientes remotos. O processamento desses eventos de análise por meio do Cloud Pub/Sub e, em seguida, por meio do Cloud Dataflow proporciona um sistema de alta capacidade com baixa latência. Ainda que seja possível enviar os eventos de análise de hot path e cold path para dois tópicos distintos do Cloud Pub/Sub, você precisa enviar todos os eventos para um tópico e processá-los por meio de jobs hot path e cold path do Cloud Dataflow distintos. Dessa maneira, é possível alterar o caminho que um evento de análise segue por meio de atualizações dos jobs do Cloud Dataflow, o que é mais fácil do que implantar um novo aplicativo ou uma versão de cliente.

Hot path

eventos de hot path

Alguns eventos precisam de análises imediatas. Por exemplo, um evento pode indicar comportamento indesejado do cliente ou agentes com baixo desempenho. Selecione esses eventos a partir do Cloud Pub/Sub por meio de um job de dimensionamento automático do Cloud Dataflow e envie-os diretamente ao BigQuery. Esses dados podem ser particionados pelo job do Dataflow para garantir que o limite de 100 mil linhas por segundo por tabela não seja atingido. Dessa forma, as consultas apresentam bom desempenho.

Cold path

eventos de cold path

Os eventos que precisam ser rastreados e analisados de hora em hora ou diariamente, mas nunca imediatamente, podem ser empurrados pelo Cloud Dataflow para objetos no Cloud Storage. Os carregamentos podem ser feitos do Cloud Storage para o BigQuery por meio do Console do Cloud Platform, da CLI ou de um simples script. Você pode mesclá-los com as mesmas tabelas que as usadas para eventos de hot path. Como no registro em cold path, os eventos de análise carregados em lote não causam impactos nos recursos de consulta reservados e mantêm o carregamento do caminho de processamento de streaming em um nível razoável.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…