Guia de Dimensionamento de Shards do Elasticsearch: Equilibrando Desempenho e Escalabilidade

O Elasticsearch é um poderoso motor distribuído de pesquisa e análise que se destaca no processamento de volumes massivos de dados. No entanto, alcançar o desempenho e a estabilidade ideais dependem significativamente de como você estrutura a distribuição dos seus dados — especificamente, o dimensionamento dos shards. Os shards são os blocos de construção fundamentais dos índices do Elasticsearch; eles determinam como os dados são particionados, replicados e distribuídos entre os nós do cluster.

Um dimensionamento incorreto dos shards pode levar a sérios gargalos de desempenho, aumento da sobrecarga operacional ou, inversamente, a recursos subutilizados.

Este guia fornece uma estrutura prática para determinar o tamanho ideal do shard no seu cluster Elasticsearch. Exploraremos as trocas críticas entre o desempenho da consulta, a taxa de transferência de indexação, a resiliência do cluster e o consumo de recursos para ajudá-lo a encontrar o equilíbrio perfeito para sua carga de trabalho específica.

Entendendo os Shards do Elasticsearch

Antes de mergulharmos no dimensionamento, é essencial entender o que é um shard e como ele funciona dentro da arquitetura do cluster. Um índice no Elasticsearch é composto por um ou mais shards primários. Cada shard primário é um índice independente baseado em Lucene que pode hospedar dados.

Shards Primários vs. Shards de Réplica

Shards Primários: Eles contêm os dados reais. São responsáveis pelas operações de indexação e pesquisa. Ao definir o número de shards primários para um índice, você decide como os dados serão distribuídos horizontalmente pelo cluster.
Shards de Réplica: São cópias dos shards primários. Eles fornecem redundância (tolerância a falhas) e aumentam a taxa de transferência de pesquisa, permitindo que as consultas sejam atendidas tanto pelas cópias primárias quanto pelas de réplica.

O Impacto da Contagem de Shards

A contagem total de shards (Primários + Réplicas) impacta diretamente a sobrecarga do cluster. Cada shard requer memória (espaço de heap) e recursos de CPU para monitorar seu status e metadados. Muitos shards pequenos sobrecarregam o nó mestre e aumentam a sobrecarga de gerenciamento do cluster, levando à degradação do desempenho, mesmo que os shards individuais sejam pequenos.

Restrições Chave e Recomendações de Dimensionamento

Não existe um único "número mágico" para o tamanho do shard. O tamanho ideal depende muito do volume de dados, da taxa de indexação e dos padrões de consulta. No entanto, a documentação do Elasticsearch e as melhores práticas da comunidade oferecem várias diretrizes cruciais.

1. Limite de Tamanho: O Tamanho Ideal do Shard

O fator mais crítico é o tamanho dos dados contidos em um único shard.

Tamanho Máximo Recomendado: O consenso geral e a melhor prática sugerem manter os shards primários individuais entre 10GB e 50GB.
Máximo Absoluto: Embora tecnicamente possível, exceder 100GB por shard é fortemente desencorajado, pois sobrecarrega as operações de recuperação, o desempenho da indexação e a estabilidade do cluster.

Por que o limite? Se um nó falhar, o Elasticsearch deve realocar (realocar ou re-replicar) os shards armazenados nesse nó. Shards grandes aumentam significativamente o tempo necessário para a recuperação, aumentando a janela de resiliência reduzida. Além disso, o Lucene tem um melhor desempenho ao gerenciar segmentos de tamanho médio.

2. Limite de Contagem de Documentos

Embora o tamanho seja primordial, a contagem de documentos também é relevante, especialmente para documentos muito pequenos.

Faixa de Documentos Recomendada: Busque shards contendo entre 100.000 e 5 milhões de documentos.

Se seus documentos forem extremamente pequenos (por exemplo, algumas centenas de bytes), você poderá atingir o limite de tamanho (50GB) antes de atingir a recomendação de contagem de documentos. Por outro lado, se os documentos forem muito grandes (por exemplo, blobs JSON de vários megabytes), você poderá atingir o limite de contagem de documentos rapidamente, permanecendo abaixo do limite de tamanho.

3. Sobrecarga do Cluster e Contagem de Shards

Limite o número total de shards por nó para gerenciar o consumo de recursos de forma eficaz.

Shard por GB de Heap: Uma diretriz comum sugere manter o número total de shards (primários + réplicas) de modo que o cluster use aproximadamente 20 shards por 1GB de espaço de heap alocado aos nós de dados.

Cálculo de Exemplo: Se seus nós de dados tiverem 30GB de heap alocados:

$$30 \text{ GB} \times 20 \text{ shards/GB} = 600 \text{ shards no total}$$

Se você precisar de 100 shards primários para um índice, certifique-se de que o cluster tenha nós suficientes para manter a sobrecarga total gerenciável de acordo com essa proporção.

Metodologia Prática de Dimensionamento de Shards

Use as seguintes etapas para calcular o número apropriado de shards primários para um novo índice com base no tamanho total esperado dos dados.

Passo 1: Estimar o Tamanho Total do Índice

Determine a quantidade total de dados que você espera que este índice armazene durante sua vida operacional (por exemplo, 6 meses ou 1 ano).

Exemplo: Antecipamos armazenar 2 TB de dados para nosso índice logs-2024.

Passo 2: Definir o Tamanho Alvo do Shard

Selecione um tamanho alvo seguro, com base nas diretrizes (por exemplo, 40GB).

Exemplo: Tamanho alvo do shard = 40 GB.

Passo 3: Calcular os Shards Primários Necessários

Divida o tamanho total estimado pelo tamanho alvo do shard. Sempre arredonde para o número inteiro seguinte.

$$\text{Shards Primários} = \text{Teto} \left( \frac{\text{Tamanho Total do Índice}}{\text{Tamanho Alvo do Shard}} \right)$$

Exemplo de Cálculo (2 TB = 2048 GB):
$$\text{Shards Primários} = \text{Teto} \left( \frac{2048 \text{ GB}}{40 \text{ GB}} \right) = \text{Teto}(51.2) = 52$$

Neste cenário, você deve criar o índice com 52 shards primários.

Passo 4: Determinar a Contagem de Réplicas

Decida a contagem de réplicas com base em suas necessidades de resiliência e volume de pesquisa.

Resiliência: Defina number_of_replicas como pelo menos 1 (para alta disponibilidade).
Desempenho de Pesquisa: Se o tráfego de pesquisa for intenso, use 2 ou mais réplicas.
Exemplo: Escolhemos 1 réplica para tolerância a falhas padrão.

Configurações Finais do Índice: 52 shards primários e 1 réplica (total de 104 shards).

Passo 5: Distribuir Entre os Nós

Certifique-se de que seu cluster tenha nós suficientes (e espaço de heap suficiente) para hospedar esses shards de forma eficaz, mantendo a regra de 20 shards/GB de heap.

Gerenciamento do Ciclo de Vida e Redimensionamento do Índice

O Elasticsearch não oferece suporte ao redimensionamento do número de shards primários em um índice existente e não vazio. Esta é uma limitação crítica a ser lembrada durante o projeto inicial.

O Papel do Gerenciamento do Ciclo de Vida do Índice (ILM)

Para dados de séries temporais (logs, métricas), a melhor prática é alavancar o Gerenciamento do Ciclo de Vida do Índice (ILM) e o recurso Rollover.

Em vez de criar um índice maciço e de difícil gerenciamento, você cria um alias de rollover que aponta para um modelo.

Fase Hot (Ativa): Os dados são gravados no índice ativo atual. O ILM monitora este índice com base no tamanho ou idade (por exemplo, fazer rollover quando atinge 40GB).
Rollover: Quando o limite é atingido, o Elasticsearch cria automaticamente um novo índice com base no modelo (com o número calculado de shards primários) e alterna o alias para apontar para o novo índice. O índice antigo passa para uma fase diferente (Warm/Cold).

Essa abordagem permite que você mantenha shards de tamanho consistente e com desempenho otimizado ao longo do ciclo de vida dos seus dados.

Quando o Re-sharding é Necessário (Avançado)

Se um índice existente crescer muito além da recomendação de 50GB devido a padrões de dados imprevistos, você deve usar a API Reindex para corrigir a distribuição dos shards:

Crie um novo índice com a configuração de shard corrigida (ótima).
Use a API Reindex para copiar todos os dados do índice antigo, com dimensionamento incorreto, para o novo.
Atualize os aliases para apontar para o novo índice.
Exclua o índice antigo.

Aviso sobre Reindexação: A reindexação é uma operação intensiva em recursos. Deve ser agendada durante períodos de baixo tráfego e requer recursos de cluster suficientes para lidar com a carga simultânea de indexação e cópia.

Resumo das Melhores Práticas

Área	Melhor Prática / Diretriz
Tamanho Individual do Shard	Mantenha os shards primários entre 10GB e 50GB (máx. 100GB).
Contagem de Documentos	Busque de 100k a 5M de documentos por shard (secundário ao tamanho).
Sobrecarga do Cluster	Limite o total de shards (primários + réplicas) a aproximadamente 20 shards por 1GB de heap nos nós de dados.
Gerenciamento de Índices	Use Gerenciamento do Ciclo de Vida do Índice (ILM) e Rollover para dados de séries temporais para garantir um dimensionamento ótimo contínuo.
Redimensionamento	Não tente alterar a contagem de shards primários em índices ativos; use a API Reindex para migrar dados para um novo índice com dimensionamento correto.

Ao aderir a essas diretrizes de dimensionamento e utilizar o ILM para gerenciamento contínuo, você pode garantir que seu cluster Elasticsearch permaneça performático, escalável e resiliente contra falhas operacionais.