Estes são alguns dos desafios de escala de serviço do Avance Network com os quais lidamos no nosso dia a dia.

Nesta série de blog, compartilharemos como fazemos isso e os desafios que enfrentamos. Neste artigo (parte 1), vamos nos concentrar na arquitetura. A Parte 2 cobre as lições que aprendemos ao longo dos anos.

Olá, visualizações de página!

O objetivo do Avance Network é fornecer as melhores tecnologias em uma comunidade. Nossa plataforma atende a mais de 360 ​​bilhões de acessos e processa mais de dois bilhões de visualizações de página por dia. A exibição de página é um registro que descreve recomendações, atividades do usuário (como um clique) e muito mais na visita de um usuário a uma página da web. Atualmente, o registro de exibição de página tem cerca de 1.000 campos.

Dois bilhões de visualizações de página geram uma grande quantidade de dados. Esses dados são processados ​​e analisados ​​usando clusters do Apache Spark , que têm cerca de 25K (no local) núcleos. O processamento local funciona muito bem para análises periódicas, como faturamento. No entanto, nossos analistas e equipes de desenvolvimento realizam consultas interativas complexas em dados de longo prazo. Essas consultas ad-hoc criam um pico de demanda por recursos que não temos. É aqui que entra a nossa de nuvem personalizado de BigQuery.

O BigQuery é um serviço de banco de dados altamente escalonável e de alto desempenho. Ele permite que você execute consultas em grandes quantidades de dados (PBs) em um curto espaço de tempo. Por exemplo, o BigQuery nos permite executar consultas em um mês ou mais de visualizações de página em questão de minutos. Além disso, permite-nos armazenar seis meses de visualizações de página, mais de 13 PB. Obviamente, isso não é gratuito. O modelo de preços do BigQuery é por armazenamento de dados e por consulta (os bytes verificados).

Nossa nuvem responsável por criar e enviar exibições de página para o BigQuery, mais de 2 bilhões de exibições de página por dia. Ele cria as visualizações de página em nosso próprio data center e, em seguida, faz o upload para a nuvem, cerca de 150 TB / dia.

Em alto nível, o serviço pode ser dividido em três partes:

Caminho de dados - lida com o processamento de dados e a retransmissão de dados

Caminho de controle - agenda as operações do caminho de dados

Caminho de monitoramento - expõe o status do serviço e alerta quando as coisas vão mal

O Caminho de Dados

O caminho de dados do servidor lida com o processamento de dados e a retransmissão de dados. Este processo é composto por três etapas:

Criar as visualizações de página e enviá-las ao Cloud Storage

Carregar as visualizações de página do Cloud Storage para uma tabela de teste no BigQuery

Copiando a mesa de palco para uma mesa de produção

A primeira etapa, construir e enviar as visualizações de página, é uma etapa de processamento de dados pesada e complexa. Esta etapa deve ser paralelizada e executada em centenas de núcleos. Adaptarmos um de nosso servidores para esse uso

Cada tarefa do é responsável pelo processamento de cerca de 1/3000 dos dados. Cada tarefa lê os eventos relevantes do armazenamento de dados Apache Cassandra, cria suas visualizações de página na memória e os carrega para o nosso Cloud Storage como um arquivo JSON (delimitado por nova linha). O formato de arquivo JSON delimitado por nova linha oferece suporte a estruturas de dados aninhadas, um requisito fundamental para representar uma exibição de página. Cada visualização de página é uma linha nesse arquivo. Por último, o esquema do BigQuery de visualizações de página é gerado automaticamente com base nas classes Java.

Na segunda etapa, carregamos os arquivos JSON em uma tabela de teste no BigQuery. A tabela de estágio nos permite validar os dados carregados antes de usá-los na produção. Esta é uma etapa simples do projeto. Tudo o que ele faz é enviar alguns jobs de carregamento para o BigQuery. O BigQuery faz todo o trabalho pesado de dados.

A última etapa é anexar a tabela de estágio à tabela de produção. O trabalho de cópia do BigQuery é usado para anexar os dados. Anexar os dados é uma operação atômica, garantindo que os dados da tabela de produção sejam sempre consistentes.

As funcionalidades acima são implementadas por um microsserviço Java denominado mecanismo. É responsável por construir as visualizações de página, enviá-las e controlar os jobs do BigQuery. O mecanismo apresenta uma API REST para acionar e monitorar suas funções.

O Caminho de Controle

O caminho de controle agenda as operações do caminho de dados. A cada hora, o nosso projeto carrega uma hora de dados de visualizações de página para o BigQuery, executando as três etapas do caminho de dados descritas acima. Para fazer isso, é melhor ter um bom plano de controle!

Escolhemos o Apache Airflow para o plano de controle. Airflow é uma plataforma de código aberto usada para agendar e monitorar fluxos de trabalho. Cada fluxo de trabalho é descrito por um DAG (Direct Acyclic Graph). O Airflow programa os DAGs para serem executados periodicamente com base em sua configuração cron. Os nós dos DAGs representam operadores. Cada operador é uma única tarefa necessária para concluir o fluxo de trabalho. O Airflow gerencia as execuções de seus operadores: ordenando-os, executando-os, tentando novamente e monitorando-os.

O fluxo de trabalho do caminho de dados é descrito por um DAG, que é composto de duas classes de operadores:

Operadores de caminho de dados: execute trabalhos de mecanismo. O operador envia um trabalho de mecanismo e consulta seu status até que seja concluído usando a API REST do mecanismo.

Operadores de validação: protegem o processo de dados inválidos. O operador consulta as tabelas de status e produção para validar os dados carregados: contagem de linhas, contagem de bytes e tamanho médio do registro. Quando uma anomalia grave é detectada, o operador falha e interrompe a execução do DAG.

O Caminho de Monitoramento

Os usuários do esperam visualizações de página completas e oportunas no BigQuery. Na maioria das vezes, o processo funciona bem. Mas, de vez em quando, as coisas podem dar errado: problemas de rede podem falhar no upload, bancos de dados podem não estar disponíveis, podemos ter problemas temporários e outros problemas inesperados podem ocorrer. Portanto, um bom monitoramento é uma parte fundamental para a disponibilidade e o desempenho do serviço.

O monitoramento é composto de duas partes: 

Alertas: embora tenhamos mecanismos de nova tentativa, alguns problemas podem exigir intervenção humana. Uma variedade de verificações detectam esses casos e pedem ajuda humana usando o Pagerduty .

Visibilidade: a visibilidade nos expõe a uma variedade de métricas sobre o estado atual e histórico do serviço. Em caso de anomalia, comparar os dados atuais e históricos é essencial para solucionar o problema. Além disso, os dados históricos expõem as tendências de desempenho do serviço. Isso nos permite otimizar ainda mais o serviço (por exemplo, adicionar recursos devido ao crescimento de dados).

A cada dois minutos, consultamos os bancos de dados de estado do Airflow em busca de anomalias, como uma execução de DAG com falha ou um operador que está executando por muito tempo. 

Existem dois tipos de anomalias:

Alertas: acionados quando algo dá errado e é necessária a intervenção humana. Um alerta cria um incidente do Pagerduty e envia uma notificação do Slack. Por exemplo, uma execução de DAG falhou ou a contagem de linhas da tabela está significativamente baixa / alta.

Avisos: os avisos têm limites mais baixos do que os alertas. Eles nos avisam quando o serviço está chegando perto do limite e pode ocorrer um alerta. Um aviso envia apenas uma notificação do Slack. Por exemplo, o DAG está demorando muito e prestes a atingir o tempo limite ou a contagem de linhas da tabela está fora do intervalo esperado.

Para cada operação, mantemos métricas e status nas tabelas de estado do MySQL. Essas métricas são mantidas por um longo período de tempo.

Grafana é uma ótima ferramenta para expor dados de séries temporais como gráficos. Criamos vários gráficos mostrando: 

Duração de DAGs e operadores, contagem de novas tentativas e estado

Métricas de tabelas de produção do BigQuery, como linha, byte e tamanho médio do registro

Desempenho de DAGs, operadores e trabalhos de motor. Por exemplo, taxa de upload de bytes

150 TB / dia é complicado

Construir e operar um serviço com upload de mais de 150 TB / dia é uma tarefa complexa. Nessa escala, a arquitetura certa é importante. Decompor o serviço em alguns caminhos, conforme demonstrado acima, é a chave para o sucesso do serviço. 

Na parte 2 , compartilharemos as lições que aprendemos ao operar o nosso projeto personalizado ao longo dos anos, como reduzir custos, aumentar a confiabilidade...

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.