Otimizando o pipeline de dados do Threat Stack com Apache Spark e Amazon EMR

O Threat Stack coleta dezenas de bilhões de eventos por dia, o que ajuda os clientes a entender seu ambiente, identificar atividades indesejadas e melhorar sua postura de segurança. Esses dados são provenientes de diferentes sistemas operacionais, contêineres, APIs de provedores de nuvem e outras fontes. Quanto mais eficientemente processarmos todos esses dados, mais valor poderemos entregar aos clientes.

Neste post, forneço algum contexto sobre o estado antes e depois do pipeline de dados do Threat Stack, o que nos permitiu aumentar a estabilidade da nossa plataforma e melhorar nossa eficiência operacional.

Operando a plataforma de dados

O Threat Stack tem sistemas de back-end escaláveis e robustos que manipulam dados em alto rendimento para permitir a detecção de ameaças à segurança quase em tempo real. Para dar suporte a esse fluxo detalhado de dados de segurança, a plataforma Threat Stack é dividida em muitos microsserviços especializados. Essa arquitetura permite o fácil dimensionamento horizontal de nossa infraestrutura de pipeline de dados à medida que nossa base de clientes cresce e simplifica a solução de problemas ao segmentar diferentes responsabilidades de processamento de dados em serviços dedicados.

A equipe de engenharia do Threat Stack normalmente se antecipa às ineficiências da plataforma ou aos possíveis problemas de escalabilidade antes que eles se tornem um problema para o cliente. Além disso, se um membro da equipe de engenharia for chamado no meio da noite, identificamos o problema, propomos um plano de escala e implementamos uma correção. Interrupções do sistema têm um custo humano e de oportunidade significativo, desviando equipes de novos projetos que geram valor adicional ao cliente. Na Threat Stack, levamos a sério a saúde do sistema e sua correlação com o impacto humano e fazemos o melhor para manter nossa equipe de engenharia saudável e produtiva.

Uma das nossas mais novas áreas de investimento tem sido a Threat Stack Data Platform, que permite que clientes e usuários internos aproveitem a telemetria de segurança de novas maneiras interessantes, como relatórios, análises e aprendizado de máquina.

A plataforma de dados consiste em uma camada de armazenamento e uma série de serviços que ingerem, processam e consomem os dados armazenados para alimentar diversas análises e habilitar nosso recurso de portabilidade de dados . Com o Threat Stack Data Portability, os clientes podem exportar telemetria de segurança avançada da nossa plataforma e carregá-la em seus próprios sistemas, como Splunk para SIEM, Amazon Redshift para armazenamento de dados ou Amazon S3 Glacier para arquivamento profundo. Alguns desses dados também permitem que os analistas de segurança em nosso Programa Cloud SecOps℠, que trabalham em nosso SOC 24 horas por dia, 7 dias por semana, monitorem os ambientes dos clientes e identifiquem padrões de atividades suspeitas.

Para os propósitos desta postagem, vamos nos concentrar no aspecto de portabilidade de dados da plataforma de dados. A portabilidade de dados é operada por uma série de serviços que recuperam e processam dados da plataforma de dados para particioná-los por organização e tempo. No bucket S3 de destino, os dados são organizados por data e um identificador de organização.

Com a crescente utilização da Plataforma de Dados e dos recursos que ela oferece, precisávamos redesenhar partes do nosso back-end para oferecer suporte à Portabilidade de Dados do Threat Stack. Agora que você sabe um pouco sobre como trabalhamos e o recurso que oferecemos suporte, vamos dar uma olhada no estado da plataforma antes e depois.

Pilha de ameaças antes do Spark

A iteração anterior de aplicativos de processamento usou o Apache Flink , que é um mecanismo de processamento distribuído dependente de RAM para computações com estado para processamento em lote e processamento de fluxo. O Flink foi escolhido porque já estava alimentando outras partes da plataforma para streaming de dados e agregação de telemetria. Para dar suporte ao novo recurso, criamos um novo cluster Flink que executava uma única tarefa, que consumiria um tópico do Apache Kafka, particionaria os eventos e os gravaria no S3. Por fim, o cluster cresceu para mais de cem gerenciadores de tarefas Flink e exigiu manutenção manual significativa. Para lhe dar uma ideia da escala do processamento que oferecemos suporte, a plataforma do Threat Stack lida com meio milhão de eventos por segundo. Todos os serviços em nosso back-end precisam suportar esse ritmo.

O cluster de ingestão em execução no Apache Flink passou por várias rodadas de ajustes nas configurações de paralelismo de estágios, salting de dados de eventos para atingir uma carga de trabalho uniformemente equilibrada e vários experimentos de tamanho de instância de infraestrutura. Infelizmente, o cluster chegou a um ponto em que ficou cada vez mais caro para nossa equipe operá-lo, o que afetou nossos engenheiros e nossa conta com o provedor de nuvem.

Com o tempo, começamos a perceber alguns antipadrões, um dos quais eram as falhas em cascata dos trabalhadores. Quando um único trabalhador ficava sem recursos, ele eventualmente ficava sem resposta, o que fazia com que o restante dos nós processassem mais mensagens do tópico do Apache Kafka. Os nós então ficaram carentes de recursos, um de cada vez. Embora tenhamos projetado redundâncias no sistema, eventos de falhas em cascata afetaram negativamente o desempenho e exigiram intervenção manual de pessoas de plantão.

Aliás, devo observar que o Apache YARN não estava sendo usado para gerenciar recursos de cluster. O Apache YARN teria resolvido a falha em cascata nos trabalhadores do cluster, mas não teria ajudado com as preocupações com custos e eficiência de serviço. O número de incidentes de estabilidade da plataforma atribuídos a esse serviço de ingestão representou até 30% do total de eventos de serviço por mês.

O outro lado do desafio era o custo associado à execução da infraestrutura para dar suporte ao serviço de ingestão de dados. Esse serviço representava cerca de 25% da nossa fatura mensal com o provedor de nuvem. Também teve um grande impacto humano, acordando indivíduos durante a noite e diminuindo sua capacidade de realizar seu trabalho regular. Devido à quantidade de manutenção e interrupções causadas pelo serviço, era hora de substituí-lo e buscar pontualidade, escalabilidade, custo-benefício e estabilidade.

Passando do Flink para o Spark

Voltamos aos requisitos, que eram a capacidade de gravar dados de eventos brutos particionados por organização em blocos de tempo em preparação para envio aos buckets S3 dos clientes. Não precisávamos das qualidades de processamento com estado do Apache Flink, só precisávamos de um pipeline ETL simples. Nossa equipe de engenharia já experimentou o Apache Spark em outras áreas da nossa arquitetura e viu resultados promissores.

Decidimos portar a lógica de negócios do Apache Flink para o Apache Spark, em execução no Amazon EMR . Essa mudança nos permitiu usar ferramentas padrão da indústria mais amplamente adotadas e com melhor suporte. Com o EMR, começamos a usar o conector Hadoop S3 fornecido pela AWS em vez da implementação gratuita com suporte da comunidade. A mudança para um serviço gerenciado, o EMR, em vez de executar nosso próprio cluster Apache Flink internamente, eliminou a maior parte da complexidade operacional envolvida na manutenção do antigo pipeline em execução. Além disso, o novo pipeline ETL não tem estado e não depende de pontos de verificação ou gravações intermediárias que faziam com que falhas não fossem detectadas no pipeline antigo. Além disso, o novo pipeline executa trabalhos discretos em intervalos curtos e predefinidos e tenta novamente lotes inteiros devido a qualquer falha parcial. Comparado à forma como trabalhávamos anteriormente com dados de streaming, o processamento ainda é rápido para nossos clientes, mas agora com a durabilidade adicional que o processamento de microlotes Spark oferece.