Dimensionamento de domínios do Amazon OpenSearch Service

Não existe um método perfeito para dimensionar os domínios do Amazon OpenSearch Service. No entanto, começando com uma compreensão de suas necessidades de armazenamento, do serviço e de OpenSearch si mesmo, você pode fazer uma estimativa inicial fundamentada sobre 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 OpenSearch cargas de trabalho se enquadra em uma das duas grandes categorias:

• Índice de longa duração: você escreve um código que processa dados em um ou mais OpenSearch índices 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 OpenSearch índice 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.

• OpenSearch sobrecarga de indexação: o tamanho em disco de um índice 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.

• OpenSearch Sobrecarga de OpenSearch serviço: o serviço reserva 20% do espaço de armazenamento de cada instância (até 20 GiB) para mesclagens de segmentos, registros 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 de origem * (1 + número de réplicas) * (1 + sobrecarga de indexação)/(1 - espaço reservado do Linux)/(1 - sobrecarga do OpenSearch serviço) = requisito mínimo de armazenamento

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:

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

• Se você tiver índices contínuos e quiser usar uma arquitetura quente-morna, consulte UltraWarm armazenamento para Amazon OpenSearch Service.

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, no OpenSearch Serviço, cada índice é dividido em cinco fragmentos principais e uma réplica (total de 10 fragmentos). Esse comportamento difere do código aberto OpenSearch, cujo padrão é um fragmento primário e uma 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 OpenSearch a recuperação de falhas, mas como cada fragmento usa uma certa quantidade de CPU e memória, ter muitos fragmentos pequenos pode causar problemas de desempenho e erros de falta de memória. Em outras palavras, os fragmentos devem ser pequenos o suficiente para que a instância de OpenSearch serviço subjacente possa lidar com eles, mas não tão pequenos que sobrecarreguem desnecessariamente o hardware.

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 middle-of-the-road abordagem mais ampla de seis fragmentos, o que deixa você com 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. Elasticsearch 7. x e versões posteriores, e todas as versões de 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 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 os preços do Amazon OpenSearch Service.

No entanto, até mesmo esses recursos podem ser insuficientes. Alguns OpenSearch usuários relatam que muitas vezes precisam desses recursos para atender às suas necessidades. 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 um mínimo de três nós para evitar possíveis OpenSearch problemas, como um estado cerebral dividido (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 Escala de petabytes no Amazon Service OpenSearch .

Etapa 3: Executar o teste de representatividade

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

Etapa 4: Sucesso ou iteração

Se o desempenho satisfizer suas necessidades, os testes forem bem-sucedidos e CloudWatch as métricas estiverem normais, o cluster estará pronto para uso. Lembre-se de definir CloudWatch alarmes para detectar o uso insalubre 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. Conforme você adiciona instâncias, reequilibra OpenSearch automaticamente a distribuição dos 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.