Práticas recomendadas para configurar seu domínio do Amazon Elasticsearch Service

Por Jon Handler, Arquiteto Principal de Soluções na Amazon Web Services

O Amazon Elasticsearch Service (Amazon ES) é um serviço totalmente gerenciado que facilita a implantação, a segurança, o dimensionamento e o monitoramento do seu cluster Elasticsearch na Nuvem AWS. O Elasticsearch é uma solução de banco de dados distribuído que pode ser difícil de planejar e executar. Esta publicação discute algumas práticas recomendadas para a implantação de domínios do Amazon ES.

A prática mais importante é iterar. Se você seguir essas práticas recomendadas, poderá planejar uma implantação de linha de base do Amazon ES. O Elasticsearch comporta-se de maneira diferente para cada carga de trabalho — sua latência e seu throughput são amplamente determinados pela combinação de solicitações, pelas solicitações propriamente ditas e pelos dados ou consultas que você executa. Não há nenhuma regra determinística que possa prever 100% como a sua carga de trabalho se comportará. Planeje tempo para ajustar e refinar sua implantação, monitorar o comportamento do seu domínio e ajustar-se de acordo.

Implantando o Amazon ES

Não importa se você está implantando no Console de gerenciamento da AWS, no AWS CloudFormation ou por meio de APIs do Amazon ES, você tem várias opções para configurar os recursos de hardware, alta disponibilidade e segurança do seu domínio. Esta postagem aborda as práticas recomendadas para escolher seus nós de dados e sua configuração de nós principais dedicados.

Ao configurar seu domínio do Amazon ES, você escolhe o tipo de instância e a contagem de dados e nós principais dedicados. O Elasticsearch é um banco de dados distribuído que é executado em um cluster de instâncias ou nós. Esses tipos de nós têm funções diferentes e exigem dimensionamentos diferentes. Nós de dados armazenam os dados em seus índices e processam solicitações de indexação e consulta. Nós principais dedicados não processam essas solicitações. Eles mantêm o estado do cluster e fazem a orquestração. Esta postagem concentra-se em tipos de instâncias. Para obter mais informações sobre o dimensionamento de instâncias para nós de dados, consulte Get started with Amazon Elasticsearch Service: T-shirt-size your domain. Para obter mais informações sobre o dimensionamento de instâncias para nós principais dedicados, consulte Get Started with Amazon Elasticsearch Service: Use Dedicated Master Instances to Improve Cluster Stability.

O Amazon ES oferece suporte a cinco classes de instâncias: M, R, I, C e T. Como prática recomendada, use o tipo de instância de última geração de cada classe de instância. Na ocasião deste artigo, os tipos são M5, R5, I3, C5 e T2.

Escolhendo seu tipo de instância para nós de dados

Ao escolher um tipo de instância para seus nós de dados, tenha em mente que esses nós comportam todos os dados em seus índices (armazenamento) e fazem todo o processamento para as suas solicitações (CPU). Como prática recomendada, para cargas de trabalho de produção pesada, escolha o tipo de instância R5 ou I3. Se a sua ênfase for principalmente no desempenho, o R5 geralmente oferece o melhor desempenho para cargas de trabalho de análises de log e, muitas vezes, para cargas de trabalho de pesquisa. As instâncias I3 são concorrentes fortes e podem se adequar melhor à sua carga de trabalho. Portanto, você deve testar ambas. Se a sua ênfase estiver no custo, as instâncias I3 terão melhor economia em grande escala, especialmente se você optar por comprar instâncias reservadas.

Para uma instância de nível de entrada ou uma carga de trabalho menor, escolha os tipos M5. Os tipos C5 são uma instância especializada, relevante para casos de uso de consultas pesadas, que exigem mais trabalho da CPU do que disco ou rede. Use as instâncias T2 para cargas de trabalho de desenvolvimento ou controle de qualidade, mas não para produção. Para obter mais informações sobre quantas instâncias escolher e fazer uma análise mais aprofundada da área de cobertura de dados, consulte Get started with Amazon Elasticsearch Service: T-shirt-size your domain.

Escolhendo o tipo de instância para nós principais dedicados

Ao escolher um tipo de instância para os nós principais dedicados, lembre-se de que esses nós são principalmente vinculados à CPU, com alguma demanda de RAM e rede também. As instâncias C5 funcionam melhor como nós principais dedicados até cerca de 75 clusters de nós de dados. Acima dessa contagem de nós, você deve escolher R5.

Escolhendo zonas de disponibilidade

O Amazon ES facilita o aumento da disponibilidade do cluster usando o recurso de Reconhecimento de zona. Você pode optar por implantar seus dados e nós principais em uma, duas ou três Zonas de disponibilidade. Como prática recomendada, escolha três Zonas de disponibilidade para suas implantações de produção.

Quando você escolhe mais de uma Zona de disponibilidade, o Amazon ES implanta nós de dados igualmente nas zonas e garante que as réplicas entrem em zonas diferentes. Além disso, quando você escolhe mais de uma Zona de disponibilidade, o Amazon ES sempre implanta nós principais dedicados em três zonas (se a região oferecer suporte a três zonas). A implantação em mais de uma Zona de disponibilidade proporciona ao seu domínio mais estabilidade e aumenta a sua disponibilidade.

Definição de Índices e Shards do Elasticsearch

Ao usar o Amazon ES, você envia dados para índices no seu cluster. Um índice é como uma tabela em um banco de dados relacional. Cada documento de pesquisa é como uma linha, e cada campo JSON é como uma coluna.

O Amazon ES particiona seus dados em shard, com um hash aleatório por padrão. Você deve configurar a contagem de shard e usar as práticas recomendadas nesta seção.

Padrões de índice

Para casos de uso de análise de log, você deseja controlar o ciclo de vida dos dados no seu cluster. Isso pode ser feito com um padrão de índice contínuo. Todos os dias, você cria um novo índice e depois arquiva e exclui o índice mais antigo do cluster. Você define um período de retenção que controla quantos dias (índices) de dados devem ser mantidos no domínio com base nas suas necessidades de análise. Para obter mais informações, consulte Gerenciamento de estados de índice.

Definindo suas contagens de shard

Existem dois tipos de shard: primário e de réplica. A contagem de shard primários define quantas partições de dados o Elasticsearch cria. A contagem de réplicas especifica quantas cópias adicionais dos shard primários são criadas. Você define a contagem de shard primários ao criar o índice e não pode alterá-la (há maneiras, mas não é recomendável usar a API _shrink ou _split para clusters sob carga em grande escala). Você também define a contagem de réplicas na criação do índice, mas pode alterar a contagem de réplicas em tempo real, e o Elasticsearch ajusta adequadamente criando ou removendo réplicas.

Você poderá definir as contagens de shard primários e de réplica se criar o índice manualmente, com um comando POST. Uma maneira melhor de análises de log é definir um modelo de índice. Veja o seguinte código:

PUT _template/<template_name>
{
    "index_patterns": ["logs-*"],
    "settings": {
        "number_of_shards": 10,
        "number_of_replicas": 1
    },
    "mappings": {
        …
    }
}

Quando você define um modelo como este, cada índice que corresponde a index_pattern tem as configurações e o mapeamento (se você especificar um) aplicados a esse índice. Isso oferece uma maneira conveniente de gerenciar sua estratégia de shard para índices contínuos. Se você alterar seu modelo, obterá sua nova contagem de shard no próximo ciclo de indexação.

Você deve definir number_of_shards com base no tamanho dos dados de origem, usando a seguinte diretriz: contagem de shard primários = (dados de origem diários em bytes * 1,25)/50 GB.

Para casos de uso de pesquisa, nos quais você não está usando índices contínuos, use 30 GB como divisor, almejando shard de 30 GB. No entanto, estas são apenas diretrizes. Sempre teste com seus próprios dados, indexação e consultas para encontrar o tamanho ideal de shard.

Você deve tentar alinhar suas contagens de shard e instâncias para que seus shard se distribuam igualmente entre os nós. Isso pode ser feito ajustando contagens de shard ou contagens de nós de dados para que eles sejam divisíveis uniformemente. Por exemplo, as configurações padrão para o Elasticsearch versões 6 e abaixo são 5 shard primários e 1 de réplica (um total de 10 shard). Você pode obter distribuição uniforme escolhendo 2, 5 ou 10 nós de dados. Embora seja importante distribuir sua carga de trabalho uniformemente em seus nós de dados, nem sempre é possível implantar todos os índices igualmente. Use o tamanho do shard como guia principal para a contagem de shard e faça pequenos ajustes (< 20%), geralmente favorecendo mais instâncias ou shard menores, com base em uma distribuição uniforme.

Determinando o tamanho do armazenamento

Até agora, você mapeou uma contagem de shard, com base no armazenamento necessário. Agora, você precisa certificar-se de que tem recursos suficientes de armazenamento e CPU para processar suas solicitações. Primeiro, descubra sua necessidade geral de armazenamento: armazenamento necessário = (dados de origem diários em bytes * 1,25) * (número_de_réplicas + 1) * número de dias de retenção.

Você multiplica o tamanho do índice não replicado pelo número de réplicas e dias de retenção para determinar o armazenamento total necessário. Cada réplica adiciona uma necessidade de armazenamento adicional igual ao tamanho do armazenamento primário. Você adiciona isso novamente para cada dia que você deseja reter dados no cluster. Para casos de uso de pesquisa, defina o número de dias de retenção como 1.

A necessidade total de armazenamento gera um mínimo no tipo de instância e na instância com base no armazenamento máximo que essa instância fornece. Se você estiver usando instâncias com suporte pelo EBS, como M5 ou R5, poderá implantar volumes do EBS até o limite compatível. Para obter mais informações, consulte Limites do Amazon Elasticsearch Service.

Para instâncias com armazenamento temporário, o armazenamento é limitado pelo tipo de instância (por exemplo, i3.8xlarge.elasticsearch tem 7,8 TB de armazenamento conectado). Se você escolher o EBS, deverá usar o tipo de volume de propósito geral GP2. Embora o serviço ofereça suporte ao tipo de volume io1 e IOPS provisionadas, você geralmente não precisa deles. Use IOPS provisionadas somente em circunstâncias especiais, quando as métricas oferecerem suporte.

Use o armazenamento total necessário e divida pelo armazenamento máximo por instância do seu tipo de instância escolhido para obter a contagem mínima de instâncias.

Depois de ter um tipo de instância e uma contagem, verifique se você tem vCPUs suficientes para processar suas solicitações. Multiplique a contagem de instâncias pelas vCPUs que a instância fornece. Isso fornece uma contagem total de vCPUs no cluster. Como ponto de escala inicial, verifique se a contagem de vCPUs é 1,5 vezes a contagem de shard ativos. Um shard ativo é qualquer shard para um índice que esteja recebendo gravações substanciais. Use a contagem de shard primários para determinar shard ativos para índices que estejam recebendo gravações substanciais. Para análises de log, somente o índice atual está ativo. Para casos de uso de pesquisa, que são pesados em termos de leitura, use a contagem de shard primários.

Embora 1,5 seja recomendado, isso é altamente dependente da carga de trabalho. Certifique-se de testar e monitorar a utilização da CPU e a escala adequadamente.

À medida que você trabalha com contagens de shard e instâncias, lembre-se de que o Amazon ES funciona melhor quando a contagem total de shard é a menor possível: menos de 10.000 é um bom limite flexível. Cada instância também não deve ter mais de 25 shard no total por GB de heap de JVM nessa instância. Por exemplo, R5.xlarge tem 32 GB de RAM no total. O serviço aloca metade da RAM (16 GB) para o heap (o tamanho máximo do heap para qualquer instância é 31,5 GB). Você nunca deve ter mais de 400 = 16 * 25 shard em qualquer nó nesse cluster.

Caso de uso

Suponha que você tenha uma carga de trabalho de análise de log com suporte para logs da Web do Apache (500 GB/dia) e syslogs (500 GB/dia), retidos por 7 dias. Esta postagem concentra-se no tipo de instância R5 como a melhor escolha para análises de log. Você usa uma implantação de três Zonas de disponibilidade: uma primária e duas réplicas por índice. Com uma implantação de três zonas, você precisa implantar nós em múltiplos de três, o que impulsiona a contagem de instâncias e, em certa medida, a contagem de shard.

A contagem de shard primários para cada índice é (500 * 1,25)/50 GB = 12,5 shard, que você arredonda para 15. O uso de 15 primários permite que o espaço adicional cresça em cada shard e é divisível por três (o número de zonas de disponibilidade e, portanto, o número de instâncias, é um múltiplo de 3). O armazenamento total necessário é de 1.000 * 1,25 * 3 * 7 = 26,25 TB. Você pode fornecer esse armazenamento com 18x instâncias 18x R5.xlarge.elasticsearch, 9x R5.2xlarge.elasticsearch ou 6x R5.4xlarge.elasticsearch (com base nos limites do EBS de 1,5 TB, 3 TB e 6 TB, respectivamente). Você deve escolher as instâncias 4xlarge, na diretriz geral de que a escalabilidade vertical tem geralmente maior desempenho que a escalabilidade horizontal (como há muitas exceções a essa regra geral, certifique-se de iterar adequadamente).

Tendo encontrado uma implantação mínima, agora você precisa validar a contagem de CPUs. Cada índice tem 15 shard primários e 2 réplicas, em um total de 45 shard. Os índices mais recentes recebem gravação substancial, de modo que cada um tem 45 shard ativos, resultando em um total de 90 shard ativos. Ignore os outros 6 dias de índices, pois eles são acessados com pouca frequência. Para análises de logs, é possível assumir que seu volume de leitura seja sempre baixo e caia conforme os dados envelhecem. Cada R5.4xlarge.elasticsearch tem 16 vCPUs, totalizando 96 no seu cluster. A diretriz de práticas recomendadas é de 135 = 90 * 1,5 vCPUs necessárias. Como ponto de escala inicial, você precisa aumentar para 9x R5.4xlarge.elasticsearch, com 144 vCPUs. Novamente, testes podem revelar que você está provisionado em excesso (o que é provável), e talvez seja possível reduzir para seis. Por fim, dadas as suas contagens de nó de dados e shard, provisione 3x nós principais dedicados C5.large.elasticsearch.

Conclusão

Esta postagem abordou algumas das principais práticas recomendadas para implantar seu domínio do Amazon ES. Essas diretrizes fornecem uma estimativa razoável do número e do tipo de nós de dados. Fique atento às postagens subsequentes que abordam as práticas recomendadas para implantar domínios seguros, monitorar o desempenho do seu domínio e ingerir dados no seu domínio.

Este artigo foi traduzido do Blog da AWS em Inglês.

Sobre o autor

Jon Handler é Arquiteto principal de soluções da Amazon Web Services com sede em Palo Alto, CA. Jon trabalha em estreita colaboração com as equipes do CloudSearch e do Elasticsearch, fornecendo ajuda e orientação a uma ampla gama de clientes que têm cargas de trabalho de pesquisa que desejam migrar para a Nuvem AWS. Antes de fazer parte da AWS, a carreira de Jon como desenvolvedor de software incluiu quatro anos de codificação de um mecanismo de pesquisa de comércio eletrônico em grande escala.