Um Spark Streaming pode sobreviver ao Chaos Monkey?
Traduzido por Carla Matheus Carneiro
A Netflix é uma organização orientada a dados que prioriza a
qualidade dos dados coletados e processados. Em nosso post anterior, nós destacamos
os casos de processamento de fluxo em tempo real no contexto das recomendações
online e do monitoramento de dados. Ao escolhermos o Spark Streaming como nosso
processador de fluxo, nós nos propusemos a avaliar e compartilhar o histórico
de resiliência do Spark Streaming no ambiente da nuvem AWS. Uma abordagem baseada no Chaos Monkey, que finalizou
aleatoriamente instâncias ou processos, foi empregada para simular falhas.
O Spark na Amazon Web Services (AWS) é importante já
que a Netflix transmite seu serviço principalmente fora da nuvem AWS. Sistemas
de processamento de fluxo precisam operar em 24/7, além de serem tolerantes a
falhas. Instâncias na AWS são efêmeras, o que torna imprescindível garantir a
resiliência do Spark.
Componentes
do Spark
O Apache Spark é um sistema de computação em
cluster rápido e genérico. O Spark pode ser implantado no Mesos, no próprio
gerenciador de cluster do Yarn ou Spark, que aloca os recursos do nó de
trabalho para uma aplicação. O Spark Driver se conecta ao gerenciador de
cluster e é responsável pela conversão de uma aplicação em um grafo acíclico
direto (DAG) de tarefas individuais que são executadas dentro de um processo
nos nós de trabalho.
Criando
o Chaos
Os dispositivos de transmissão Netflix enviam periodicamente
eventos que capturam as atividades dos membros, o que tem um papel
significativo na personalização. Esses eventos vão para nossas aplicações no
servidor e são encaminhados para o Kafka. Nossa aplicação de transmissão Spark
utiliza esses eventos do Kafka e calcula métricas. A arquitetura de implantação
está demonstrada abaixo:
Figura 2: Arquitetura de Implantação
Nosso objetivo é assegurar que não haja interrupção no cálculo de
métricas quando os diferentes componentes Spark falham. Para simular tais
falhas, nós aplicamos uma abordagem "whack-a-mole" (processo
repetitivo de eliminação) e eliminamos os vários componentes Spark.
Nós executamos nossa aplicação de transmissão spark no Spark
Standalone. O exercício de resiliência foi executado com o Spark v1.2.0, Kafka
v0.8.0 e Zookeeper v3.4.5.
A
Resiliência do Spark Streaming
Resiliência do
Driver: O Spark Standalone suporta dois
modos de iniciar o aplicativo de driver. No modo cliente, o aplicativo de
driver é iniciado no mesmo processo como aquele em que o cliente envia a
aplicação. Quando esse processo morre, o aplicativo é abortado. No
modo cluster, o aplicativo é iniciado a partir de um processo de trabalho no
cluster. Além disso, o modo standalone cluster suporta uma opção de
supervisão que permite reiniciar o aplicativo automaticamente em códigos de saída
diferente de zero.
Resiliência do
Master: A agenda Spark utiliza o
Master para tomar decisões agendadas. Para evitar qualquer ponto de
falha, é melhor configurar um multi master standalone cluster. O
Spark utiliza o Zookeeper para definir um líder. Um dos nós master se torna um
nó ATIVO e todos os nós de trabalho ficam registrados nele. Quando esse nó
master morre, um dos nós master STANDBY se torna o nó ATIVO e todos os nós de
trabalho ficam automaticamente registrados nele. Se houver qualquer aplicação
sendo executada no cluster durante a falha do master, elas ainda continuarão
funcionando sem nenhuma falha.
Resiliência do
Processo de Trabalho: O processo de trabalho inicia e
monitora o Executor e o Driver como processos primários. Quando o processo de
trabalho morre, todos os seus processos primários também morrem. O
processo de trabalho reinicia automaticamente, que por sua vez reinicia o
processo do Driver e/ou do Executor.
Resiliência do
Executor: Quando o processo Executor morre,
eles são automaticamente reiniciados pelo processo de trabalho e quaisquer
tarefas que estiverem suspensas são reagendadas.
Resiliência do
Receptor: O Receptor é executado como uma
longa tarefa em um Executor e tem as mesmas características de resiliência de
um executor.
O efeito sobre as métricas calculadas, em função do término de
vários componentes Spark, está demonstrado abaixo.
Figura 3: O comportamento na falha do Receptor/Driver/Master
Falha do Driver: O principal impacto está na contra-pressão acumulada devido a uma
falha do nó, o que resulta em uma queda brusca no processamento de mensagens,
seguido de um pico, antes que o grafo fique estável.
Falha do
Receptor: A queda nas métricas calculadas
ocorreu devido ao fato do receptor padrão Kafka ser um receptor não confiável. O Spark
streaming 1.2 traz um recurso experimental chamado write ahead logs que faz do kafka
um receptor confiável. Quando estiver habilitado, as aplicações terão
êxito com o receptor de transferência Kafka. No entanto, isso pode ser
abordado através do aumento do número de receptores.
Resumo
A tabela abaixo resume as características de
resiliência dos diferentes componentes Spark:
Componente
|
Tipo
|
Comportamento na Falha do Componente
|
Resiliente
|
Driver
|
Processo
|
Modo Cliente: A aplicação inteira morre
|
|
Modo Cluster
com supervisão: O Driver é reiniciado em um nó
de trabalho diferente
|
|
||
Master
|
Processo
|
Master Único: A aplicação inteira morre
|
|
Multi Master: Um master STANDBY se torna ATIVO
|
|
||
Processo de Trabalho
|
Processo
|
Todos os processos primários (executor ou driver)
também são finalizados e um novo processo de trabalho é iniciado
|
|
Executor
|
Processo
|
Um novo executor é iniciado pelo processo de trabalho
|
|
Receptor
|
Tópico(s)
|
O mesmo que o Executor, pois estão executando longas tarefas
dentro do Executor
|
|
Nó de Trabalho
|
Nó
|
Processos de Trabalho, Executor e Driver são
executados em nós de trabalho e o comportamento é o mesmo ao matá-los
individualmente
|
|
Nós encontramos alguns erros (SPARK-5967, SPARK-3495, SPARK-3496, etc.) durante este exercício, porém a equipe Spark Streaming foi
capaz de corrigí-los em tempo. A performance Spark ainda está em teste e os
resultados serão divulgados em posts no blog.
No geral, estamos satisfeitos com a resiliência do spark
standalone e animados para chegar ao próximo nível em que estamos trabalhando a
fim de construir uma Arquitetura
Lambda unificada que envolve uma
combinação de lote e transmissão em tempo real de processamento. Estamos
nos estágios iniciais desse desenvolvimento, por isso, se você tiver interesse
em contribuir, por favor entre em contato conosco.
