Case de Sucesso – Como a Passei Direto captura e analisa dados de milhões de eventos diários com a AWS

Sergio Zaccarelli, Arquiteto de Soluções, AWS Setor Público

Gabriel Bella Martini, Arquiteto de Soluções, AWS Setor Público

Renato Bibiano, Data Engineer Manager, Passei Direto

Paulo Neves, Software Engineer, Passei Direto

Fundado em 2012, o Passei Direto é a maior rede de estudos do Brasil e tem o propósito de facilitar o acesso ao conhecimento para empoderar as pessoas e transformar o futuro. Hoje, a rede conta com mais de 24 milhões de usuários e mais de 12 milhões de materiais em todos os níveis de ensino.

Overview

As arquiteturas de soluções na nuvem cada vez mais estão possibilitando a geração de um grande volume de dados em tempo real, de diversos tipos de eventos e dos mais variados formatos. Esses dados podem ser trabalhados como fonte para muitos casos de uso orientados à análise de informações, começando desde a monitoração de eventos para identificação rápida de anomalias para manutenção da eficiência operacional dos sistemas, como realização de análises na busca de insights onde se encontre novas oportunidades para a evolução do negócio, passando pela aplicação de análise preditiva para execução de motores de recomendação e adaptação de conteúdo.

Os usuários do Passei Direto hoje geram mais de 20 milhões de eventos diariamente. Com o crescimento e a evolução da plataforma, novos tipos de eventos são capturados frequentemente e num volume que cresce constantemente. Por isso, a empresa buscou formas de armazenar e consumir tais eventos de forma eficiente, possibilitando aplicação em inúmeros casos de uso que trazem insights para o negócio e melhorias para a plataforma, beneficiando diretamente os usuários finais.

O Desafio

No desenvolvimento de arquiteturas escaláveis orientadas a microsserviços, o número de eventos gerados pode crescer exponencialmente. Quando se trata de ambientes web acessados por milhares de usuários diariamente, o volume pode ser alto e ainda diverso.

Nesse contexto, era importante a concepção de uma solução que possibilitasse a captura de eventos de forma massiva e elástica, assim como o consumo desses eventos, de forma eficiente e orientada a casos de uso diversos das diferentes unidades de negócio.  . Desta forma, o ambiente poderia consumir uma grande variedade e volume de dados, e a arquitetura com os serviços AWS foi criada visando suportar este cenário elástico, de maneira confiável e segura. Nas próximas sessões o blog post irá abordar os componentes que formam essa arquitetura, bem como apresentar como essa captura possibilitou a alavancagem de um importante caso de uso.

A Solução

A arquitetura que compõe o caso de uso irá ser demonstrada em duas partes: primeiramente irá ser apresentado os detalhes sobre o Tracking Framework, responsável pela ingestão, processamento e armazenamento dos eventos de nossa plataforma core. Em seguida irá ser abordado como esses dados capturados no passo anterior foram utilizados para análise da qualidade dos mecanismos de busca no SEO Experiment Framework.

Arquitetura do Tracking Framework

A arquitetura do PD Tracking Framework é ilustrada na figura abaixo:

Os eventos são capturados a partir do uso na nossa plataforma (via página web ou aplicativo mobile), sendo enviados para a nossa API de tracking, rodando no Amazon ECS. Esta API então vai enviar estes eventos para o Amazon Kinesis Data Streams.

O Amazon Kinesis vai manter um buffer de 128mb ou 15 minutos, o que for alcançado primeiro, então enviará os dados para o Amazon Kinesis Data Firehose, que usa uma função do AWS Lambda para tratar os dados e salvá-los num bucket do Amazon S3, em formato json (dados “crus”, ou seja ainda sem modificação).

Para tratamento desses dados, foi criada uma DAG (Directed Acyclic Graphs, uma tarefa) no Apache Airflow, que provisiona um cluster no Amazon EMR, executando um job pyspark para extrair os dados em json, transformá-los em parquet e carregá-los no Data Lake (outro bucket no S3) já separados por evento. O parquet é um formato de armazenamento de dados colunar que traz benefícios como melhor performance para consultas analíticas e compressão no armazenamento, por isso seu uso é bastante popular em arquiteturas de dados para fim de análise.

A DAG também dispara um crawler no AWS Glue, que vai ler estes arquivos e disponibilizá-los para consumo através do registro de seus metadados no AWS Glue Data Catalog, possibilitando sua leitura tanto pelo Amazon Quicksight para desenvolvimento de análises visuais e dashboards, quanto para usuários de negócios através do AWS Athena, onde podem ser consumidos via SQL.

Caso de uso – consumo de eventos para execução de Experimentos de SEO

Problema

SEO (Search Engine Optimization) é um conjunto de processos e práticas que visam melhorar a quantidade e a qualidade do tráfego que um site recebe de motores de busca na Internet. Os motores de busca vasculham a Internet, através de crawlers, em busca de conteúdo para seus índices e utilizam essa informação para apresentar o resultado que melhor atende às buscas das pessoas que utilizam seus serviços.

Apesar de existirem algumas boas práticas recomendadas pelos motores de busca e levantadas pela comunidade, os motores de busca não revelam exatamente como funcionam seus algoritmos.

Quando uma empresa faz modificações nas páginas de seu website, os motores de busca vão identificar essas alterações e podem alterar como enxergam a relevância dessas páginas em relação a outras páginas na Internet que competem pelo mesmo tráfego orgânico. Pela dependência de uma plataforma externa (o motor de busca), e por não ser possível saber se essas modificações vão ser positivas ou negativas, existe sempre um risco para o negócio. Além disso, também é difícil mensurar o impacto gerado por uma modificação.

Solução

É possível criar um ambiente de experimentação controlado (SEO Experiment Framework) em que apenas um grupo de páginas aleatório recebe as modificações. Os motores de busca vão identificar essas modificações, vão atualizar essas páginas nos rankings de busca e possivelmente isso irá alterar o tráfego orgânico nesse grupo de páginas. Um outro grupo aleatório de páginas (grupo controle) é separado, sem receber modificações, para servir de base de comparação. É o mesmo mecanismo utilizado em testes A/B tradicionais, em que são criados grupos de usuários, mas no contexto no contexto de SEO são testados grupos de páginas.

Nesse contexto, o Tracking Framework é peça chave para medir o tráfego orgânico ao longo do tempo nos grupos do experimento, para verificar se o grupo com as alterações apresenta um resultado melhor, pior ou neutro em relação ao grupo controle.

Arquitetura

A arquitetura do SEO Experiment Framework é ilustrada na figura abaixo:

Quando um usuário visita uma página do Passei Direto, antes de renderizar a página, a URL é enviada para a SEO Experiment Selector API, uma aplicação executada no ECS usando a engine do AWS Fargate, mecanismo de computação sem servidor para containers. Essa API é responsável por verificar se a página em questão pertence a algum grupo de experimento de SEO ativo. O resultado dessa operação é utilizado pela aplicação do front-end para renderizar a versão da página correspondente ao experimento. Isso é válido tanto para usuários humanos visitando nosso site, quanto para os crawlers das engines de busca.

Quando a página carrega, um evento de PageView é enviado para a tracking-api, iniciando todo o fluxo de processamento do PD Tracking Framework, descrito acima. Esse evento inclui algumas informações, como o referer que possibilita identificar o site que antecedeu à visita ao Passei Direto.

O SEO Experiment Metrics Job é um script python que usa o pyspark para processar os eventos de PageView e coletar métricas relacionadas aos experimentos de SEO. Essa aplicação roda em um cluster Amazon EMR com instâncias Amazon EC2, sendo agendado diariamente para processar os dados do dia anterior. A orquestração desse processo ocorre via Airflow.

Esse job filtra todos os PageViews orgânicos, isto é, visitas às páginas do Passei Direto cujo referer são sites motores de busca na Internet. Na sequência, para cada URL o job verifica a qual experimento de SEO a página pertencia, através de consultas à SEO Experiment Selector API. No final o job computa o total de visitas agrupando por experimento de SEO e armazena o resultado em  um banco de dados de métricas.

O último elemento da arquitetura é a ferramenta de data visualization utilizada para acompanhar e analisar o resultado dos experimentos. Criamos dashboards no Amazon Quicksight, trazendo as métricas computadas para cada experimento e disponibilizando para os usuários que consomem e analisam os insights.

Resultados

Com esse framework, o Passei Direto consegue efetuar experimentos no website de forma a ter uma melhor previsibilidade se as modificações propostas podem ter algum impacto no tráfego orgânico recebido. Isso diminui o risco ao negócio possibilitando reverter experimentos com resultado negativo, deixando passar apenas os experimentos com resultado positivo ou neutro. Os experimentos também trazem aprendizados que permitem iterar em melhorias no produto com mais assertividade.

Além disso, é possível mensurar o impacto em termos percentuais de tráfego em cada experimento que apresenta um resultado positivo ou negativo.

A seguir é apresentado o gráfico de um experimento de exemplo. A linha vermelha representa a diferença de tráfego orgânico entre o grupo de teste e o grupo controle do experimento. O teste foi iniciado no dia marcado pela linha vertical. Mesmo antes do início, os grupos apresentam uma diferença de tráfego, o que é normal pois existem muitos fatores que influenciam no tráfego orgânico, porém é possível identificar um padrão.

Após cerca de duas semanas, a diferença de tráfego entre os grupos começou a aumentar (com o grupo de teste prevalecendo), o que indica que os motores de busca começaram a recompensar positivamente as modificações introduzidas por esse experimento. Nesse experimento em específico o Passei Direto obteve um resultado estatisticamente significativo de incremento de tráfego de 8%, podendo variar de +2% a +14% com 95% de grau de confiança.

Conclusão e próximos passos

Neste blog post foi abordado como um cliente AWS utilizou serviços em nuvem para criar uma solução de captura de eventos em tempo real que fosse escalável, resiliente e não tivesse alta demanda operacional. A utilização de serviços gerenciados AWS garantiu os requisitos necessários. Com as informações capturadas e prontas para consumo a Passei Direto conseguiu alavancar diversos casos de uso para análise dos dados de eventos.

Como próximo passo o objetivo é suportar mais casos de uso para os eventos, como algoritmos de recomendação mais complexos usando Machine Learning. Além disso, os times de produto também estão instrumentando mais a plataforma do Passei Direto, capturando novos tipos de eventos e potencializando novas aplicações.

Com a quantidade crescente de eventos diferentes capturados se torna necessário catalogar melhor esses eventos para que todas as pessoas que trabalham com os dados tenham autonomia para descobrir e explora-los mas também mantendo a governança dos dados.

Sobre os autores

Sergio Zaccarelli (Zacca) é Engenheiro de Computação com mais 20 anos de experiência, e arquiteto de soluções do time de Setor Público no Brasil com foco na área de Educação. Trabalha apoiando os clientes para serem bem sucedidos em sua jornada para a nuvem, atuando em projetos estruturantes e inovadores com empresas de todos os tipos e tamanhos. Tem grande interesse em bancos de dados e analytics.

Gabriel Bella Martini é formando em Ciência da Computação e especializado em Engenharia de Software. Atualmente trabalha na AWS atendendo clientes de Educação e possui experiência em diferentes projetos relacionados a Serverless e Inteligência Artificial.

Renato Bibiano de Sá Marques é Engenheiro de Dados na Passei Direto. Tem experiência com várias ferramentas do mundo de Big Data e tem interesse em arquitetura, escalabilidade e qualidade de dados.

Paulo Fernandes Neves é Engenheiro de Software na Passei Direto e atua como Tech Lead na tribo de Growth. Tem experiência em projetos em várias áreas do sistema e tem interesse em arquitetura de soluções e escalabilidade de sistemas.