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

O Elasticsearch é um poderoso mecanismo de busca e análise distribuído que se destaca no manuseio de grandes volumes de dados. No entanto, alcançar desempenho e estabilidade ideais depende significativamente de como você estrutura a distribuição dos seus dados—especificamente, o dimensionamento de shards. 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 inadequado de shards pode levar a sérios gargalos de desempenho, aumento da sobrecarga operacional ou, inversamente, subutilização de recursos.

Este guia de dimensionamento de shards do Elasticsearch oferece uma maneira prática de escolher um número inicial de shards e validá-lo com métricas reais de carga de trabalho. O objetivo não é um número perfeito; é uma disposição de shards que permaneça recuperável, pesquisável e acessível à medida que seus dados crescem.

Entendendo os Shards do Elasticsearch

Antes de mergulhar 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. Réplicas

Shards Primários: Estes contêm os dados reais. Eles são responsáveis pelas operações de indexação e busca. Quando você define o número de shards primários para um índice, 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 busca, permitindo que as consultas sejam atendidas tanto por cópias primárias quanto por réplicas.

O Impacto do Número de Shards

O número 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 rastrear 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 shards individuais sejam pequenos.

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

Não existe um "número mágico" único 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.

Faixa alvo comum: Muitos clusters de produção visam shards primários na faixa de 10GB a 50GB.
Cuidado com shards grandes: Shards maiores podem funcionar para algumas cargas de trabalho somente de anexação ou de baixa consulta, mas aumentam o tempo de recuperação e tornam a realocação mais cara. Teste antes de confiar em shards próximos ou acima de 100GB.

Por que o limite? Se um nó falhar, o Elasticsearch deve realocar (relocar ou replicar novamente) os shards armazenados naquele 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 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.

Não há um número seguro universal de documentos por shard. Um shard com milhões de pequenos documentos de log pode se comportar bem, enquanto um shard com menos documentos grandes e altamente analisados pode ser caro. Acompanhe tanto o tamanho do armazenamento do shard quanto o comportamento da carga de trabalho, em vez de confiar apenas na contagem de documentos.

3. Sobrecarga do Cluster e Número de Shards

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

Orientações mais antigas frequentemente usavam regras de shard por GB de heap. Trate-as como sinais de alerta aproximados, não como limites rígidos. O Elasticsearch moderno tem uma sobrecarga de heap por shard menor do que as versões mais antigas, mas muitos shards ainda aumentam o trabalho do estado do cluster, os manipuladores de arquivos, a sobrecarga de segmentos e a complexidade da recuperaçã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.

Etapa 1: Estimar o Tamanho Total do Índice

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

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

Etapa 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.

Etapa 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 mais próximo.

$$\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.

Etapa 4: Determinar o Número de Réplicas

Decida o número de réplicas com base em suas necessidades de resiliência e volume de busca.

Resiliência: Defina number_of_replicas para pelo menos 1 (para alta disponibilidade).
Desempenho de Busca: Se o tráfego de busca 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).

Etapa 5: Distribuir Entre os Nós

Certifique-se de que seu cluster tenha nós, heap, disco e capacidade de E/S suficientes para hospedar esses shards de forma eficaz. Com réplicas, o Elasticsearch deve ser capaz de colocar cada réplica em um nó diferente do seu primário.

Gerenciando o Ciclo de Vida do Índice e o Redimensionamento

O Elasticsearch não permite que você altere index.number_of_shards diretamente em um índice existente. Você pode usar fluxos de trabalho de divisão, redução ou reindexação, mas cada um tem requisitos e custos operacionais.

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

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

Em vez de criar um índice enorme e difícil de gerenciar, você cria um alias de rollover apontando para um modelo.

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

Esta abordagem permite manter shards de tamanho consistente e com desempenho ideal 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 empregar a API de Reindexação para corrigir a distribuição dos shards:

Crie um novo índice com a configuração de shards corrigida (ideal).
Use a API de Reindexação para copiar todos os dados do índice antigo e mal dimensionado 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 que consome muitos 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 shards primários entre 10GB e 50GB (máx. 100GB).
Contagem de Documentos	Observe a contagem de documentos como um sinal secundário, mas valide com métricas de consulta e indexação.
Sobrecarga do Cluster	Mantenha o número de shards baixo o suficiente para que a pressão do heap, as atualizações do estado do cluster e a recuperação permaneçam saudáveis.
Gerenciamento de Índices	Use o Gerenciamento do Ciclo de Vida do Índice (ILM) e o Rollover para dados de séries temporais, garantindo um dimensionamento ideal contínuo.
Redimensionamento	Não tente alterar o número de shards primários em índices ativos; use a API de Reindexação para migrar dados para um novo índice com o tamanho correto.

Comece com um tamanho alvo de shard, calcule os shards primários a partir do volume de dados esperado e, em seguida, valide com testes de carga e métricas de produção. Para dados de séries temporais, o rollover do ILM é geralmente a maneira mais limpa de manter os tamanhos dos shards previsíveis sem intervenção manual constante.