Dimensionamento de domínios do Amazon ES

Não existe nenhum método de dimensionamento infalível de domínios do Amazon ES, mas ao começar com a compreensão de suas necessidades de armazenamento, do serviço e do próprio Elasticsearch você pode fazer uma estimativa inicial embasada de suas necessidades de hardware. Essa estimativa pode servir como um ponto de partida útil para a maioria dos aspectos mais importantes do dimensionamento de domínios: testá-los com cargas de trabalho e monitorar seu desempenho.

Cálculo de requisitos de armazenamento

A maioria das cargas de trabalho do Elasticsearch pode ser classificada em uma das duas categorias amplas:

• índice de longa duração: você escreve o código que processa os dados em um ou mais índices do Elasticsearch e, em seguida, atualiza esses índices periodicamente à medida que os dados de origem são alterados. Alguns exemplos comuns são pesquisa de sites, documentos e comércio eletrônico.

• índices contínuos: os dados fluem de modo contínuo em um conjunto de índices temporários, com um período de indexação e janela de retenção, como um conjunto de índices diários que são retidos por duas semanas. Alguns exemplos comuns são análises de log, processamento de séries temporais e análise de cliques.

Para cargas de trabalho de índice de longa duração, você pode examinar os dados de origem no disco e determinar facilmente a quantidade de espaço de armazenamento que eles consomem. Se os dados vierem de várias fontes, basta adicionar essas fontes.

Para índices contínuos, você pode multiplicar o volume de dados gerados durante um período representativo pelo período de retenção. Por exemplo, se você gerar 200 dados MiB de log por hora, são 4.7 GiB por dia, que é 66 GiB dados em um determinado momento, se você tiver um período de retenção de duas semanas.

O tamanho de seus dados de origem, no entanto, é apenas um aspecto dos seus requisitos de armazenamento. Também é necessário considerar o seguinte:

1. Número de réplicas: cada réplica é uma cópia completa de um índice e precisa da mesma quantidade de espaço em disco. Por padrão, cada índice do Elasticsearch tem uma réplica. Recomendamos pelo menos uma para evitar a perda de dados. As réplicas também melhoram o desempenho da pesquisa, portanto, é aconselhável ter mais réplica se tiver uma carga de trabalho com uso intensivo de leitura.

2. ElasticsearchSobrecarga de indexação do : o tamanho de um índice no disco varia, mas normalmente é 10% maior do que os dados de origem. Após a indexação dos seus dados, você pode usar a API _cat/indices?v e o valor pri.store.size para calcular a sobrecarga exata. _cat/allocation?v O também fornece um resumo útil.

3. Espaço reservado para o sistema operacional: por padrão, o Linux reserva 5% do sistema de arquivos para o usuário root para processos críticos, recuperação do sistema e para se proteger contra problemas ocasionados pela fragmentação do disco.

4. Amazon ES Sobrecarga do : o Amazon ES reserva 20% do espaço de armazenamento de cada instância (até 20 GiB) para segmentar fusões, logs e outras operações internas.

   Devido a esse GiB máximo de 20, a quantidade total de espaço reservado pode variar muito, dependendo do número de instâncias em seu domínio. Por exemplo, um domínio pode ter três m4.xlarge.elasticsearch instâncias , cada uma com 500 GiB de espaço de armazenamento, para um total de 1,46 TiB. Nesse caso, o total de espaço reservado é apenas 60 GiB. Outro domínio pode ter 10 m3.medium.elasticsearch instâncias, cada uma com 100 GiB de espaço de armazenamento, para um total de 0,98 TiB. Aqui, o total de espaço reservado é 200 GiB, embora o primeiro domínio seja 50% maior.

   Na fórmula a seguir, aplicamos uma estimativa de "pior caso" da sobrecarga que inclui espaço livre adicional para ajudar a minimizar o impacto de falhas de nó e interrupções da zona de disponibilidade.

Em resumo, se em determinado momento você tiver 66 GiB de dados e quiser uma réplica, seu requisito de armazenamento mínimo será mais próximo de 66 * 2 * 1,1 / 0,95 / 0,8 = 191. GiB Você pode generalizar esse cálculo da seguinte forma:

Dados de origem * (1+Número de réplicas) * (1+Sobrecarga de indexação)/(1 - Espaço reservado pelo Linux)/(1 – Sobrecarga do Amazon ES) = Requisito de armazenamento mínimo

Ou você pode usar esta versão simplificada:

Dados de origem * (1 + Número de réplicas) * 1,45 = Requisito de armazenamento mínimo

Espaço de armazenamento insuficiente é uma das causas mais comuns de instabilidade do cluster; portanto, você deve verificar todos os números ao escolher tipos de instância, contagens de instâncias e volumes de armazenamento.

Existem outras considerações de armazenamento:

• Se o requisito mínimo de armazenamento ultrapassar 1 PB, consulte Escala de petabytes para Amazon Elasticsearch Service.

• Se você tiver índices contínuos e quiser usar uma arquitetura de atividade muito alta, consulte UltraWarm para Amazon Elasticsearch Service.

Como escolher o número de estilhaços

Depois de entender os requisitos de armazenamento, você poderá investigar a sua estratégia de indexação. Cada índice do Elasticsearch é dividido em algum número de estilhaços. Como não é possível alterar facilmente o número de estilhaços principais para um índice existente, você deve decidir sobre a contagem de estilhaços antes de indexar seu primeiro documento.

O objetivo geral da escolha de um número de estilhaços é distribuir um índice uniformemente por todos os nós de dados no cluster. No entanto, esses estilhaços não devem ser muito grandes nem muito numerosos. Uma boa regra geral é tentar manter o tamanho do estilhaço entre 10 –50 GiB. Estilhaços grandes podem dificultar Elasticsearch a recuperação de falhas do , mas como cada estilhaço usa alguma quantidade de CPU e memória, ter muitos estilhaços pequenos pode causar problemas de desempenho e erros de memória. Em outras palavras, os estilhaços devem ser pequenos o suficiente para que a instância do Amazon ES subjacente possa lidar com eles, mas não tão pequenos de modo que sobrecarreguem o hardware desnecessariamente.

Por exemplo, suponha que você tenha 66 GiB de dados. Você não espera que esse número aumente ao longo do tempo e deseja manter seus estilhaços em torno de 30 GiB cada. Seu número de estilhaços, portanto, deve ser aproximadamente 66 * 1,1/30 = 3. Você pode generalizar esse cálculo da seguinte maneira:

(Dados de origem+Espaço para crescer) * (1+Sobrecarga de Indireto)/Tamanho desejado do estilhaço = Número aproximado de estilhaços principais

Essa equação ajuda a compensar o crescimento ao longo do tempo. Se você espera que os mesmos 67 GiB de dados quadruplique nos próximos anos, o número aproximado de estilhaços é (66 + 198) * 1,1 / 30 = 10. No entanto, lembre-se GiB de que você ainda não tem esses 198 dados extras. Verifique se essa preparação para o futuro não cria desnecessariamente estilhaços muito pequenos que consomem enormes quantidades de CPU e memória. Nesse caso, 66 * 1,1/10 estilhaços = 7,26 GiB por estilhaço, o que consumirá recursos extras e está abaixo do intervalo de tamanho recomendado. Você pode considerar a abordagem intermediária de seis estilhaços, o que deixa você com 12 GiB estilhaços hoje e 48 GiB estilhaços no futuro. Em seguida, novamente, você pode preferir começar com três estilhaços e reindexar seus dados quando os estilhaços excederem 50 GiB.

Um problema muito menos comum envolve limitar o número de estilhaços por nó. Se você dimensionar seus estilhaços adequadamente, normalmente ficará sem espaço em disco muito antes de atingir esse limite. Por exemplo, uma m5.large.elasticsearch instância tem um tamanho máximo de disco de 512 GiB. Se você permanecer abaixo de 80% de uso do disco e dimensionar seus estilhaços em 20 GiB, ele poderá acomodar aproximadamente 20 estilhaços. Elasticsearch O 7.x e posterior têm um limite de 1.000 estilhaços por nó, ajustável usando a cluster.max_shards_per_node configuração .

O dimensionamento de estilhaços adequadamente quase sempre o mantém abaixo desse limite, mas você também pode considerar o número de estilhaços para cada heap GiB do Java. Em um determinado nó, não tenha mais de 20 estilhaços por heap GiB Java. Por exemplo, uma m5.large.elasticsearch instância tem um 4 GiB heap, portanto, cada nó não deve ter mais de 80 estilhaços. Nessa contagem de estilhaços, cada estilhaço tem aproximadamente 5 GiB de tamanho, o que está bem abaixo da nossa recomendação.

Escolha dos tipos de instância e testes

Depois de calcular os requisitos de armazenamento e escolher o número de estilhaços de que precisa, você pode começar a tomar decisões quanto ao hardware. Os requisitos de hardware variam drasticamente por carga de trabalho, mas ainda podemos fazer algumas recomendações básicas.

Em geral, os limites de armazenamento para cada tipo de instância são mapeados para a quantidade de CPU e memória que pode ser necessária para cargas de trabalho leves. Por exemplo, uma m4.large.elasticsearch instância tem um tamanho máximo de volume do EBS de 512 GiB, 2 núcleos de vCPU e 8 GiB de memória. Se o seu cluster tiver muitos estilhaços, executar agregações desgastantes, atualizar os documentos com frequência ou processar um grande número de consultas, esses recursos poderão ser insuficientes para suas necessidades. Se você acredita que seu cluster está em uma dessas categorias, tente começar com uma configuração mais próxima de 2 núcleos de vCPU e 8 GiB de memória para cada 100 GiB de seu requisito de armazenamento.

dica

Para obter um resumo dos recursos de hardware que são alocados para cada tipo de instância, consulte Definição de preço do Amazon Elasticsearch Service.

No entanto, até mesmo esses recursos podem ser insuficientes. Alguns usuários do Elasticsearch relatam que eles precisam desses recursos muitas vezes para atender aos seus requisitos. Localizar o hardware certo para sua carga de trabalho significa fazer uma estimativa inicial embasada, testar cargas de trabalho representativas, ajustar e testar novamente:

1. Para começar, recomendamos um mínimo de três nós para evitar possíveis problemas do Elasticsearch, como cérebro dividido. Se você tiver três nós principais dedicados, ainda recomendamos um mínimo de dois nós de dados para replicação.

2. Se você tiver um requisito de GiB armazenamento 184 e o número mínimo recomendado de três nós, use a equação 184/3 = 61 GiB para encontrar a quantidade de armazenamento necessária a cada nó. Neste exemplo, você pode selecionar três m5.large.elasticsearch instâncias , cada uma usando um volume de armazenamento do GiB EBS de 90 para que você tenha uma rede de segurança e espaço para crescer ao longo do tempo. Essa configuração fornece 6 núcleos de vCPU e 24 GiB de memória, portanto, é adequada para cargas de trabalho mais leves.

   Para obter um exemplo mais substancial, considere um requisito de armazenamento 14 TiB (14.336 GiB) e uma carga de trabalho pesada. Nesse caso, você pode optar por iniciar o teste com 2 * 144 = 288 núcleos de vCPU e 8 * 144 = 1152 GiB de memória. Esses números funcionam para aproximadamente 18 instâncias do i3.4xlarge.elasticsearch Se você não precisa do armazenamento local rápido, também pode testar 18 r5.4xlarge.elasticsearch instâncias, cada uma usando um volume de armazenamento TiB do EBS.

   Se o cluster incluir centenas de terabytes de dados, consulte Escala de petabytes para Amazon Elasticsearch Service.

3. Depois de configurar o cluster, você pode adicionar seus índices usando o número de estilhaços calculados anteriormente, executar alguns testes de cliente representativos usando um conjunto de dados realista e monitorar CloudWatch métricas para ver como o cluster lida com a carga de trabalho.

4. Se o desempenho atender às suas necessidades, os testes forem bem-sucedidos e as métricas do CloudWatch estiverem normais, o cluster estará pronto para uso. Lembre-se de definir CloudWatch alarmes para detectar o uso de recursos não íntegros.

   Se o desempenho não for aceitável, os testes falharem ou CPUUtilization ou JVMMemoryPressure estiverem altas, pode ser necessário escolher um tipo de instância diferente (ou adicionar instâncias) e continuar o teste. À medida que você adiciona instâncias, o Elasticsearch faz o rebalanceamento automaticamente da distribuição de estilhaços em todo o cluster.

   Como é mais fácil medir a capacidade em excesso em um cluster sobrecarregado do que o déficit em um cluster não sobrecarregado, recomendamos começar com um cluster maior do que você imagina ser necessário. Depois, teste e reduza para um cluster eficiente que tenha os recursos adicionais a fim de garantir operações estáveis durante períodos de maior atividade.

Os clusters de produção ou clusters com estados complexos se beneficiam de nós principais dedicados, que melhoram o desempenho e a confiabilidade do cluster.