Elasticsearch sobrecarregado?

Fazer scaling nem sempre é a solução

Qual é o motivo de um cluster de Elasticsearch ficar sobrecarregado? Você já pensou sobre isso?

Há diversos motivos fáceis de serem percebidos como:

• Alta quantidade de eventos sendo indexados;
• Eventos com características diferentes do padrão;
• Alta quantidade de CPU nos nodes do Elasticsearch;
• Consultas pesadas demais sendo executadas no Cluster;
• Falta de configuração dos templates.

Além destes motivos mais óbvios, há dois pontos que fazem com que um cluster de Elasticsearch seja menos saudável e menos estável.

Ponto 1: Falta de planejamento de índices

Planejar os índices de um cluster de Elasticsearch nem sempre é óbvio, como não foi para o nosso time. A necessidade de existir um planejamento surgiu após novos índices que passavam de 100GBs por dia aparecerem, pois a falta de planejamento da distribuição deles no cluster aumentava a demanda de retrabalho.

No nosso caso, os índices eram criados por dia, pelos seguintes motivos:

• Facilidade no momento de fazer e recuperar os snapshots (backups);
• Maior facilidade em movimentar shards menores pelo cluster.

Mas mesmo assim , sempre haviam problemas no cluster, como veremos a seguir:

Índices grandes com muita escrita

Esse problema pode afetar diretamente qualquer cluster, onde o responsável não dê a devida atenção ao armazenamento e no tamanho dos índices gerados.

No Elasticsearch, os índices são separados em shards de tamanhos quase equivalentes. Então, em um índice de 100MBs dividido em 3 partes, o Elasticsearch pode separar em 3 shards de 33MBs.

Tudo vai funcionar muito bem se esse índice manter o tamanho descrito acima durante todo o tempo. Mas quando esse índice muda de tamanho e vai para 100GBs, a situação é outra.

Nesse caso, o cluster fica sobrecarregado e o Elasticsearch não consegue armazenar os dados na velocidade que o Logstash envia os dados, causando problemas na fila dos eventos.

A primeira coisa que geralmente as pessoas fazem é o scaling do cluster, mas isso não adianta. A figura abaixo mostra o que acontece quando simplesmente adicionamos 3 novos hosts no cluster:

Podemos observar que a CPU dos hosts não mudou, pois a pressão de escrita continua somente nos 3 primeiros hosts. Para resolver este primeiro cenário, temos que responder a 2 perguntas:

Qual o tamanho máximo de índice e dos shards que meu cluster pode ter?

Sabendo o tamanho máximo do índice e dos shards, podemos definir quantos shards o nosso índice poderá ser dividido. Nesse exemplo, vamos dividir em seis partes, ficando 16,66 GBs por shard.

Podemos ver que o problema diminuiu e o cluster ficou mais balanceado entre os hosts. Nessa situação, fica muito claro quantos shards cada host pode ter, pois temos somente um índice dividido em seis hosts.

O que acontece quando temos mais de 100 índices no cluster de diferentes tamanhos?

Podemos imaginar um cenário onde todos os índices terão o mesmo tamanho e estarão espalhados igualmente no cluster:

Mas a realidade será esta aqui:

Sem planejamento dos índices no cluster, teremos:

• Shards de índices grandes juntos em um mesmo host;
• Shards de um mesmo índice em um mesmo host;
• Concentração de índices pequenos juntos;
• Desbalanceamento de CPU (poucos hosts com CPU alta e muitos com CPU baixa)

Há 3 pontos de atenção para minimizar este problema:

1 — Monitorar o tamanho dos índices

Podemos monitorar o tamanho dos índices na URL do cluster /_cat/indices.

Nessa URL , é possível ver o tamanho total do índice, seus shards e quantidade de réplicas.

2 — Monitorar a localização dos shards no cluster

Podemos avaliar onde os shards estão pelo endpoint /cat/shards.

Neste endpoint será indicado onde está cada shard do cluster, o que dará a oportunidade de fazer a movimentação entre os nodes, através do endpoint /cluster/reroute.

3 — Configurar o template corretamente

Configurar o Template do índice do ElasticSearch é parte essencial para evitar problemas futuros.

Devemos então:

• Ter um template por conjunto de índices ou por índice;
• Especificar a quantidade de shards;
• Especificar a quantidade de réplicas;
• Configurar para que um shard não fique em um mesmo host (para índices grandes).

Ponto 2: O horário problemático

O “horário problemático” acontece principalmente quando a maioria dos índices são recriados em um mesmo horário.

No nosso caso, todos os índices eram criados em um mesmo horário (às 21 e 22 horas no antigo horário de verão).

É exatamente este o problema, a criação de todos os índices em um mesmo horário quando há grande pressão de escrita de dados.

Isso acontece porque quando um índice é gerado no Elasticsearch, em um primeiro momento, o cluster deve criar toda a estrutura do índice (todos os shards e todas as réplicas).

Na fase 1, o Elasticsearch deve produzir os shards primários. Nesse momento o índice ficará com o status RED, impossibilitando a escrita no índice até a criação completa de todos os shards primários.

Na fase 2, o Elasticsearch irá criar as réplicas, copiando as primárias para outros hosts, com o objetivo de deixar os dados do índice mais seguros, deixando-os com o status YELLOW até terminar a cópia das réplicas.

Sendo assim, caso não seja planejado como será feita a criação dos índices diários, todos os índices que estão sofrendo escrita são criados no mesmo momento, fazendo com que o cluster do ElasticSearch fique com status RED, parando totalmente a escrita de dados.

Um efeito colateral deste problema é a saúde da equipe, pois todos os dias tínhamos alguém tratando este problema, acompanhando e fazendo scaling do cluster de Logstash.

Mas afinal de contas… Como resolver este problema?

É extremamente simples!

Para minimizar esse efeito do horário problemático, basta simplesmente criar o futuro índice em um horário que ele não esteja recebendo escrita.

Para deixar mais claro o problema, quando o Logstash está configurado para criar um índice por dia ou por hora, de tempos em tempos eles são criados automaticamente, deixando o novo índice criado com status em RED.

Como sabemos exatamente o padrão de nomes dos índices, podemos criar o índice do dia seguinte ou da hora seguinte, criando um processo que faça isso.

Desta forma, quando o Logstash começar a escrever no índice, ele já estará criado, resolvendo o problema.

Concluindo, resolvendo estes 2 pontos, você consegue minimizar problemas que podem afetar o seu cluster sem causa aparente, conseguindo mais qualidade de vida para sua equipe e um cluster mais saudável e sem problemas de retenção.

Se você busca uma oportunidade de desenvolvimento, trabalhando com inovação em um negócio de alto impacto, acesse o portal B2W Carreiras! Nele, você consegue acessar todas as vagas disponíveis. Venha fazer parte do nosso time!