Estratégia de Dimensionamento de Shards no Elasticsearch: Encontrando o Equilíbrio Ideal

O Elasticsearch, um poderoso mecanismo de busca e análise distribuído, deve grande parte de sua escalabilidade e desempenho à sua arquitetura subjacente, particularmente ao conceito de shards. Shards são essencialmente índices Lucene independentes que armazenam um subconjunto dos seus dados. Entender e otimizar seu tamanho não é apenas uma boa prática; é um fator crítico que impacta diretamente o desempenho, a estabilidade e a eficiência de custos do seu cluster.

A estratégia de dimensionamento de shards do Elasticsearch é um problema de planejamento de capacidade, não uma fórmula única. Você quer shards grandes o suficiente para evitar sobrecarga de metadados, pequenos o suficiente para se recuperar rapidamente e numerosos o suficiente para distribuir o trabalho de indexação e busca entre seus nós de dados.

Entendendo os Shards do Elasticsearch

Antes de mergulhar no dimensionamento, vamos recapitular brevemente o que são shards e como eles funcionam dentro de um cluster Elasticsearch.

O que é um Shard?

No Elasticsearch, um índice é um agrupamento lógico de dados. Para distribuir esses dados e permitir o processamento paralelo, um índice é dividido em um ou mais shards. Cada shard é um índice Lucene autocontido. Quando você cria um índice, define o número de shards primários que ele terá.

Para alta disponibilidade e escalabilidade de leitura, o Elasticsearch também permite especificar shards de réplica. Um shard de réplica é uma cópia exata de um shard primário. Se o nó de um shard primário falhar, uma réplica pode ser promovida para ocupar seu lugar, garantindo a disponibilidade dos dados e evitando perda de dados. As réplicas também atendem a solicitações de busca, distribuindo a carga de leitura.

Como os Shards Funcionam

Quando você indexa um documento, o Elasticsearch determina a qual shard primário ele pertence com base em um algoritmo de roteamento (por padrão, baseado no ID do documento). Este documento é então armazenado naquele shard primário específico e em seus shards de réplica correspondentes. Quando você pesquisa, a solicitação é enviada para todos os shards relevantes, que processam sua parte dos dados em paralelo. Os resultados são então agregados e retornados ao cliente. Esse processamento paralelo é o que dá ao Elasticsearch sua imensa velocidade e escalabilidade.

Por que o Dimensionamento de Shards é Importante

O dimensionamento ideal de shards é um elemento fundamental para um cluster Elasticsearch saudável. Um dimensionamento incorreto pode levar a uma infinidade de problemas, desde desempenho lento de consultas até desperdício custoso de recursos e cenários de recuperação instáveis.

Desempenho

Velocidade de Consulta: Um shard bem dimensionado pode processar consultas de forma eficiente. Shards muito pequenos significam mais sobrecarga de coordenação; shards muito grandes significam tempos de busca individuais mais longos.
Taxa de Transferência de Indexação: Da mesma forma, o desempenho da indexação pode ser impactado. Se os shards forem muito pequenos, a sobrecarga de gerenciar muitos shards pode desacelerar as gravações. Se os shards forem muito grandes, o desempenho individual do shard pode se tornar um gargalo.

Utilização de Recursos

Cada shard consome recursos no nó onde reside, incluindo CPU, memória (heap JVM) e I/O de disco. O dimensionamento adequado garante que seus nós sejam utilizados de forma eficiente, sem serem sobrecarregados ou subutilizados.

Escalabilidade

Shards são as unidades de distribuição no Elasticsearch. Para escalar horizontalmente, você adiciona mais nós, e o Elasticsearch reequilibra os shards entre eles. Se os shards forem muito grandes, o reequilíbrio leva mais tempo e requer mais largura de banda de rede. Se você tiver poucos shards, pode atingir um teto de escalabilidade cedo, pois não pode distribuir a carga de trabalho além do número de shards primários.

Recuperação e Estabilidade

Falhas de Nó: Quando um nó falha, o Elasticsearch deve realocar seus shards primários (promovendo réplicas) e recriar as réplicas perdidas. O tempo que isso leva é diretamente proporcional ao tamanho e número de shards envolvidos.
Recuperação do Cluster: Shards grandes levam mais tempo para recuperar e replicar, aumentando a janela de vulnerabilidade durante falhas de nó ou reinicializações do cluster.

Fatores que Influenciam o Dimensionamento de Shards

Determinar o tamanho certo do shard não é uma solução única para todos. Depende de vários fatores interdependentes específicos do seu caso de uso e infraestrutura.

Volume de Dados e Crescimento: O tamanho atual dos seus dados e a taxa de crescimento projetada são fundamentais. Um índice estático de 100 GB terá requisitos diferentes de um índice rolante que cresce 1 TB diariamente.
Tamanho do Documento e Complexidade do Esquema: Índices com muitos campos ou documentos muito grandes podem se beneficiar de shards menores, pois o processamento de cada documento requer mais recursos.
Padrões de Consulta:
- Pesado em Busca: Se o seu cluster é usado principalmente para busca, você pode priorizar um número maior de shards menores para maximizar a paralelização e minimizar os tempos de busca individuais.
- Pesado em Análise (agregações): Grandes agregações podem ter melhor desempenho com shards maiores, pois a sobrecarga de combinar resultados de muitos shards minúsculos pode se tornar significativa.
Taxa de Indexação: Altas taxas de indexação podem se beneficiar de mais shards para distribuir a carga de gravação, mas muitos podem introduzir sobrecarga.
Especificações do Nó: A CPU, RAM (tamanho do heap JVM) e tipo de disco (SSD vs. HDD) dos seus nós de dados são cruciais. Nós mais potentes podem lidar com mais shards ou shards maiores.
Topologia do Cluster: O número total de nós de dados disponíveis para distribuir os shards impacta diretamente o número viável de shards.

As Compensações: Muitos Shards vs. Poucos Shards

Encontrar o equilíbrio ideal significa entender as consequências de ambos os extremos.

Consequências de Muitos Shards

Embora mais shards pareçam oferecer mais paralelismo, há um ponto de retornos decrescentes:

Maior Sobrecarga: Cada shard consome CPU e memória (heap JVM) para seus metadados, arquivos abertos, mesclagens de segmentos, etc. Muitos shards em um nó levam a um maior consumo geral de recursos para gerenciar os próprios shards, deixando menos para o processamento real de dados.
- Dica: Regras antigas de shard por heap eram úteis como avisos aproximados, mas versões modernas do Elasticsearch reduziram a sobrecarga de heap por shard. Ainda assim, um cluster com milhares de shards minúsculos desperdiça memória e dificulta o trabalho do estado do cluster.
Recuperação Mais Lenta: Durante falhas de nó ou reequilíbrio, gerenciar e mover muitos shards pequenos leva mais tempo e I/O de rede do que um número menor de shards maiores.
Aumento da Contenção de Recursos: Quando muitos shards estão realizando operações ativamente (por exemplo, mesclando segmentos, respondendo a consultas) no mesmo nó, eles competem por CPU, memória e I/O de disco, levando a um desempenho geral mais lento.
"Inchaço de Shards": Um cluster com muitos shards pequenos e quase vazios é ineficiente. Consome recursos para gerenciamento sem benefícios proporcionais de dados.

Consequências de Poucos Shards

Por outro lado, ter poucos shards também apresenta desafios significativos:

Paralelização Limitada: Se um índice tem apenas alguns shards grandes, as consultas de busca não podem aproveitar todo o poder de processamento do seu cluster, pois a carga de trabalho não pode ser distribuída por muitos nós/núcleos.
Pontos Quentes: Um shard grande em um único nó pode se tornar um "ponto quente" se receber uma quantidade desproporcional de solicitações de leitura ou gravação, levando à saturação de recursos naquele nó específico.
Dificuldade em Escalar Horizontalmente: Se o seu índice tem, por exemplo, apenas 5 shards primários, você só pode distribuir efetivamente esse índice por um máximo de 5 nós de dados. Adicionar mais nós não ajudará no desempenho desse índice específico se todos os shards já estiverem em nós diferentes.
Reequilíbrio Mais Lento: Mover um único shard muito grande pela rede durante o reequilíbrio é uma operação demorada e intensiva em I/O, potencialmente impactando a estabilidade do cluster.
Tempos de Recuperação Mais Longos: Um único shard grande que precisa ser recuperado ou copiado pode estender significativamente o tempo de recuperação do cluster após uma falha.

Recomendações Gerais e Melhores Práticas

Embora nenhuma regra única sirva para todos, algumas diretrizes amplamente aceitas fornecem um bom ponto de partida.

Tamanho Alvo do Shard

A recomendação mais citada para um tamanho de shard individual (após indexação e possíveis mesclagens) está entre 10 GB e 50 GB. Algumas fontes estendem isso até 100 GB para cenários específicos (por exemplo, dados de série temporal com gravações principalmente anexadas e consultas menos complexas). Essa faixa geralmente fornece um bom equilíbrio entre gerenciabilidade, velocidade de recuperação e utilização eficiente de recursos.

Por que essa faixa?:
- Recuperação: Shards nessa faixa podem se recuperar relativamente rápido após uma falha de nó.
- Desempenho: Eles são grandes o suficiente para minimizar a sobrecarga, mas pequenos o suficiente para permitir processamento eficiente e mesclagens rápidas.
- Escalabilidade: Permite distribuição flexível entre nós.

Shards por Nó

Evite ter um número excessivo de shards em um único nó. O Elasticsearch impõe limites de shards do cluster em versões modernas, e seu limite prático depende do heap, mapeamentos, volume de consultas e velocidade do disco. Use a contagem de shards como uma métrica de aviso e, em seguida, confirme com a pressão da JVM, latência de atualização do estado do cluster e latência de busca/indexação.

Arquitetura Hot-Warm-Cold e Dimensionamento de Shards

Em uma arquitetura Hot-Warm-Cold (HWC), o dimensionamento de shards pode variar:

Camada Hot: Nós de dados que recebem gravações ativas e são frequentemente consultados. Aqui, você pode optar por shards ligeiramente mais numerosos ou menores para maximizar a taxa de transferência de indexação e o paralelismo de consultas.
Camada Warm/Cold: Nós que armazenam dados mais antigos e menos acessados com frequência. Esses shards são tipicamente maiores, pois a indexação parou e as mesclagens estão completas. Shards maiores (até 100 GB+) podem ser aceitáveis aqui para reduzir a contagem total de shards e a sobrecarga associada, especialmente em armazenamento otimizado para custo.

Réplicas

Sempre use réplicas! Um mínimo de uma réplica por shard primário (total de 2 cópias dos seus dados) é crucial para alta disponibilidade. As réplicas também aumentam a capacidade de leitura ao distribuir solicitações de busca. O número ideal de réplicas depende dos seus requisitos de disponibilidade e carga de consultas.

Estratégia Prática para Determinar o Tamanho do Shard

Aqui está uma abordagem passo a passo para derivar uma estratégia inicial de dimensionamento de shards, seguida por um processo de refinamento iterativo.

Passo 1: Estimar o Volume Total de Dados e o Crescimento

Projete quantos dados seu índice (ou índices diários/mensais rolantes) armazenará ao longo de seu ciclo de vida. Considere o tamanho médio do documento.

Exemplo: Você espera ingerir 100 GB de dados por dia e retê-los por 30 dias. Seus dados ativos totais serão de aproximadamente 3 TB (100 GB/dia * 30 dias).

Passo 2: Determinar o Tamanho Alvo do Shard

Comece com a recomendação geral de 30 GB-50 GB por shard primário. Ajuste com base no seu caso de uso:

Shards menores (por exemplo, 10-20 GB): Se você tem uma taxa de transferência de consultas muito alta, agregações complexas em documentos grandes ou dados que mudam com muita frequência.
Shards maiores (por exemplo, 50-100 GB): Se você tem principalmente dados de série temporal, índices somente anexados ou consultas menos frequentes e mais simples.
Exemplo (continuando do Passo 1): Vamos mirar em um tamanho médio de shard primário de 50 GB.

Passo 3: Calcular a Contagem Inicial de Shards Primários

Divida o volume total estimado de dados pelo tamanho alvo do shard.

Número de Shards Primários = (Volume Total de Dados) / (Tamanho Alvo do Shard)

Exemplo: 3000 GB / 50 GB = 60 shards primários.

Passo 4: Considerar os Recursos do Nó e o Tamanho do Heap

Determine quantos shards primários e de réplica seu cluster pode hospedar confortavelmente, respeitando a regra de shards por GB de heap.

Heap por Nó: Digamos que você tenha nós de dados com 30 GB de heap JVM cada.
Máximo de Shards por Nó (Aprox.): Usando a regra de 10-20 shards por GB de heap, um nó com heap de 30 GB poderia hospedar 30 * 10 = 300 a 30 * 20 = 600 shards.
Total de Réplicas: Se você usar 1 réplica (altamente recomendado), terá 60 shards primários + 60 shards de réplica = 120 shards no total.
Número de Nós de Dados: Certifique-se de que esses shards possam ser distribuídos sem colocar uma réplica no mesmo nó que seu primário. Para resiliência em produção, use nós e zonas de dados suficientes para que uma falha de nó ou zona não deixe você com réplicas não atribuídas.

Cenário de Exemplo

Vamos supor um cluster de dados de 3 nós, cada um com 30 GB de heap:

Nosso total calculado atual de shards: 120 shards (60 primários + 60 réplicas)
Média de shards por nó: 120 shards totais / 3 nós = 40 shards por nó.
A contagem é razoável apenas se a pressão do heap, I/O de disco, latência de indexação e latência de busca permanecerem saudáveis sob carga.

Passo 5: Testar e Monitorar

Este é o passo mais crítico. Seus cálculos teóricos são apenas um ponto de partida.

Teste de Carga: Simule seus padrões esperados de indexação e consulta. Observe as métricas de desempenho.
Ferramentas de Monitoramento: Use o monitoramento integrado do Kibana, as APIs _cat do Elasticsearch ou ferramentas de monitoramento externas (por exemplo, Prometheus, Grafana) para ficar de olho em:
- _cat/shards: Verifique os tamanhos e a distribuição dos shards.
- _cluster/stats: Estatísticas em nível de cluster, especialmente para uso de heap JVM.
- CPU, Memória e I/O de Disco em nós individuais.
- Latências de indexação e busca.
- Atividade de mesclagem de segmentos.
```
# Obter informações de alocação e tamanho de shards
GET _cat/shards?v=true&h=index,shard,prirep,state,docs,store,node

# Obter estatísticas do cluster para uso de heap e contagem de shards
GET _cluster/stats
```

Passo 6: Ajuste Iterativo

Com base no seu monitoramento, esteja preparado para ajustar sua contagem de shards. Isso pode envolver:

API Shrink: Se você tem muitos shards primários para um índice que não está mais sendo escrito, pode usar a API _shrink para reduzir o número de shards primários. O índice deve ser somente leitura, e a colocação dos shards deve satisfazer os requisitos de redução.
API Split: Se os shards de um índice estão crescendo muito e o desempenho está sofrendo, a API _split pode aumentar o número de shards primários. O índice deve ser somente leitura e deve ter sido criado com uma contagem de shards de roteamento compatível.
API Reindex: Para alterações mais complexas, como modificar o mapeamento ou alterar o número de shards para um índice ativo e com gravação ativa, você pode precisar reindexar seus dados em um novo índice com uma configuração de shard diferente.

Armadilhas Comuns e Como Evitá-las

Criação Cega de Muitos Shards: Criar 1 shard por GB de dados em clusters pequenos, levando a sobrecarga excessiva. Evite: Comece com alvos razoáveis e aumente os shards à medida que os dados crescem.
Criação de Poucos Shards em um Índice: Ter apenas 1-3 shards para um índice muito grande, limitando a paralelização e a escalabilidade. Evite: Calcule com base no volume de dados e na capacidade do nó.
Ignorar Projeções de Crescimento: Dimensionar para os dados atuais sem considerar a ingestão futura. Evite: Sempre considere o crescimento esperado dos dados durante o ciclo de vida dos seus dados.
Não Monitorar: Configurar e esquecer. Os tamanhos dos shards, os recursos do nó e o desempenho das consultas mudam com o tempo. Evite: Implemente monitoramento robusto e alertas para métricas-chave.
Seguir Regras Práticas Cegamente: A regra de 10 GB-50 GB é uma diretriz, não uma lei estrita. Sua carga de trabalho específica pode ditar variações. Evite: Sempre valide as recomendações gerais com seus dados reais e padrões de uso.

Conclusão Prática

Escolha uma contagem inicial de shards a partir do volume de dados esperado e um tamanho alvo de shard, depois prove com testes de carga. Observe o tempo de recuperação, a pressão do heap, o I/O de disco e a latência após o rollover ou crescimento. Se os números se desviarem, use rollover, shrink, split ou reindexação antes que o layout do shard se torne um incidente.