Um Spark Streaming pode sobreviver ao Chaos Monkey?

por Bharat Venkat, Prasanna Padmanabhan, Antony Arokiasamy, Raju Uppalapati

Traduzido por Carla Matheus Carneiro

Artigo original

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.

Figura 1: Diferentes Componentes do Spark

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.