Dimensionamento de domínios do Amazon OpenSearch Service - Amazon OpenSearch Service

Dimensionamento de domínios do Amazon OpenSearch Service

Não há um método perfeito para dimensionar domínios do Amazon OpenSearch Service. Porém, ao começar com a compreensão de suas necessidades de armazenamento, do serviço e do próprio OpenSearch, você pode fazer uma estimativa inicial embasada em 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 workloads e monitorar sua performance.

Cálculo de requisitos de armazenamento

A maioria das workloads do Elasticsearch podem ser classificadas em uma das duas categorias amplas:

  • Índice de longa duração: você escreve um código que processa dados em um ou mais índices do OpenSearch 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 para um conjunto de índices temporários, com um período de indexação e uma janela de retenção (como um conjunto de índices diários que é retido por duas semanas). Alguns exemplos comuns são análises de log, processamento de séries temporais e análise de cliques.

Para workloads 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 MiB de dados de log por hora, são 4,7 GiB por dia, que é 66 GiB de 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:

  • 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 OpenSearch tem uma réplica. Recomendamos pelo menos uma para evitar a perda de dados. As réplicas também melhoram a performance da pesquisa, portanto, é aconselhável ter mais réplicas se você tiver uma workload com uso intensivo de leitura. Use PUT /my-index/_settings para atualizar a configuração number_of_replicas para o seu índice.

  • Sobrecarga de indexação do OpenSearch: o tamanho de um índice no disco varia. O tamanho total dos dados de origem mais o índice geralmente é de 110% da origem, com o índice de até 10% dos dados de origem. Após indexar os dados, é possível usar a API _cat/indices?v e o valor pri.store.size para calcular a sobrecarga exata. _cat/allocation?v também fornece um resumo útil.

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

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

    Por causa desse máximo de 20 GiB, 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 instâncias m6g.xlarge.search, 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 instâncias m3.medium.search, 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 sobre a “pior das hipóteses” para sobrecarga. Essa estimativa inclui espaço livre adicional para ajudar a minimizar o impacto das falhas nos nós e das 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 maneira:

Dados da origem * (1 + número de réplicas) * (1 + sobrecarga de indexação) / (1 - espaço reservado pelo Linux) / (1 – sobrecarga do OpenSearch Service) = requisito de armazenamento mínimo

Ou você pode usar esta versão simplificada:

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

Espaço de armazenamento insuficiente é uma das causas mais comuns da instabilidade do cluster. Portanto, é necessário verificar os números ao escolher tipos de instância, as contagens de instâncias e os volumes de armazenamento.

Existem outras considerações de armazenamento:

Como escolher o número de fragmentos

Depois de entender os requisitos de armazenamento, você poderá investigar a sua estratégia de indexação. Por padrão, cada índice no OpenSearch Service é dividido em cinco fragmentos primários e uma réplica (total de 10 fragmentos). Esse comportamento difere do OpenSearch de código aberto, cujo padrão é um fragmento primário e um fragmento de réplica. Como você não pode alterar facilmente o número de fragmentos principais para um índice existente, decida sobre a contagem de fragmentos antes de indexar seu primeiro documento.

O objetivo geral de escolher um número de fragmentos é distribuir um índice de forma uniforme por todos os nós de dados no cluster. No entanto, esses fragmentos não devem ser muito grandes nem muito numerosos. Uma orientação geral é buscar manter o tamanho do fragmento entre 10 e 30 GiB, para workloads em que a latência de pesquisa é um dos principais objetivos de performance, e entre 30 e 50 GiB, para workloads em que há gravação intensa, como análise de log.

Fragmentos grandes podem dificultar a recuperação de falhas do OpenSearch. No entanto, como cada fragmento usa alguma quantidade de CPU e memória, ter muitos fragmentos pequenos pode causar problemas de performance e erros de memória. Em outras palavras, os fragmentos devem ser pequenos o suficiente para que a instância do OpenSearch Service 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 fragmentos em torno de 30 GiB cada um. Seu número de fragmentos, portanto, deve ser aproximadamente 66 * 1,1/30 = 3. Você pode generalizar esse cálculo da seguinte maneira:

(Dados da origem + espaço para crescer) * (1 + sobrecarga de indexação) / tamanho desejado do fragmento = número aproximado de fragmentos principais

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

Um problema muito menos comum envolve limitar o número de fragmentos por nó. Se você dimensionar seus fragmentos adequadamente, normalmente ficará sem espaço em disco muito antes de atingir esse limite. Por exemplo, uma instância m6g.large.search tem um tamanho máximo de disco de 512 GiB. Se você ficar abaixo de 80% do uso do disco e dimensionar seus fragmentos em 20 GiB, ela poderá acomodar aproximadamente 20 fragmentos. O Elasticsearch 7.x e posteriores, além de todas as versões do OpenSearch, têm um limite de 1.000 fragmentos por nó. Para ajustar o máximo de fragmentos por nó, ajuste a configuração cluster.max_shards_per_node. Para ver um exemplo, consulte Cluster settings (Configurações de cluster).

Se dimensionar os fragmentos adequadamente, você quase sempre se manterá abaixo desse limite, mas também é possível considerar o número de fragmentos para cada GiB de heap Java. Em um determinado nó, não tenha mais de 25 fragmentos por GiB de heap de Java. Por exemplo, uma instância m5.large.search tem um heap de 4 GiB, de modo que cada nó não deva ter mais de 100 fragmentos. Nessa contagem de fragmentos, cada fragmento 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 fragmentos de que precisa, você pode começar a tomar decisões quanto ao hardware. Os requisitos de hardware variam drasticamente por workload, 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 workloads leves. Por exemplo, uma instância m6g.large.search tem um tamanho máximo de volume do EBS de 512 GiB, 2 núcleos de vCPUs e 8 GiB de memória. Se o seu cluster tiver muitos fragmentos, 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 o cluster estiver em uma dessas categorias, tente começar com uma configuração mais próxima de dois 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 Preços do Amazon OpenSearch Service.

No entanto, até mesmo esses recursos podem ser insuficientes. Alguns usuários do OpenSearch relatam que eles precisam desses recursos muitas vezes para atender aos seus requisitos. Para localizar o hardware certo para sua workload, é necessário fazer uma estimativa inicial embasada, testar workloads representativas, ajustar e testar novamente.

Etapa 1: Fazer uma estimativa inicial

Para começar, recomendamos utilizar um mínimo de três nós para evitar possíveis problemas no OpenSearch, como estado de dupla personalidade (quando um lapso na comunicação leva a um cluster com dois nós principais). Se você tiver três nós principais dedicados, ainda recomendamos um mínimo de dois nós de dados para replicação.

Etapa 2: Calcular os requisitos de armazenamento por nó

Se você tiver um requisito de 184 GiB de armazenamento e o número mínimo recomendado for de três nós, use a equação 184/3 = 61 GiB para determinar a quantidade de armazenamento necessária para cada nó. Nesse exemplo, é possível selecionar três instâncias m6g.large.search, em que cada uma usa um volume de armazenamento do EBS de 90 GiB, para que você tenha uma rede de segurança e espaço para crescimento ao longo do tempo. Essa configuração fornece 6 núcleos de vCPU e 24 GiB de memória, portanto, é adequada para workloads mais leves.

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

Se o cluster incluir centenas de terabytes de dados, consulte Reduzir a escala horizontalmente de petabytes no Amazon OpenSearch Service.

Etapa 3: Executar o teste de representatividade

Após configurar o cluster, você poderá adicionar seus índices utilizando o número de fragmentos que calculou anteriormente, executar alguns testes de cliente representativos usando um conjunto de dados realista e monitorar as métricas do CloudWatch para ver como o cluster lida com a workload.

Etapa 4: Sucesso ou iteração

Se a performance 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 alarmes do CloudWatch para detectar problemas de utilização de recursos.

Se a performance não for aceitável, os testes falharem ou CPUUtilization ou JVMMemoryPressure estiverem altas, poderá 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 OpenSearch faz o rebalanceamento automaticamente da distribuição de fragmentos em todo o cluster.

Como é mais fácil medir a capacidade em excesso de um cluster sobrecarregado do que o déficit de 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 os clusters com estados complexos se beneficiam de nós principais dedicados, que melhoram a performance e a confiabilidade do cluster.