Nick Price Tradução
Atualmente, estou trabalhando em um grande projeto de log que foi implementado originalmente usando o AWS Elasticsearch. Tendo trabalhado com clusters de backbone em larga escala do Elasticsearch por vários anos, estou completamente impressionado com a qualidade da implementação da AWS e não consigo entender por que eles não a corrigiram ou, pelo menos, melhoraram.
Sumário
O Elasticsearch armazena dados em vários índices que você cria explicitamente ou que podem ser criados automaticamente após o envio dos dados. As entradas em cada índice são divididas em um certo número de shards, que são equilibrados entre os nós do cluster (o mais uniformemente possível se o número de shards não for dividido igualmente pelo número de nós). Existem dois tipos principais de shards no ElasticSearch: shards básicos e shards de réplica. Os shards de réplica fornecem tolerância a falhas no caso de uma falha do nó, e os usuários podem especificar o número de shards de réplica separadamente para cada índice.
O trabalho de Elasticsearch padrão
Pesquisa elástica - é elástica. Às vezes, pode ser bastante complicado, mas, em geral, você pode adicionar nós ao cluster ou excluí-los. E se, no caso de excluir um nó, houver um número adequado de réplicas, o Elasticsearch distribuirá shards e equilibrará a carga nos nós do cluster. Isso geralmente funciona.
O cumprimento de consultas caras às vezes pode levar à queda de nós e similares, mas um grande número de configurações ajuda a manter o trabalho. Com um número suficiente de shards de réplica, se o nó cair, isso não afeta o trabalho como um todo.
O Standard Elasticsearch também possui vários complementos disponíveis, incluindo o X-Pack, recursos de auditoria, ACLs granulares, monitoramento e alertas. A maior parte do X-Pack recentemente se tornou gratuita, provavelmente em resposta à nova política de licenças do Splunk.
Trabalho do Amazon Elasticsearch
Como de costume, a Amazon pegou o código-fonte aberto para parte do Elasticsearch, criou um hard fork e começou a vendê-lo como seu próprio serviço, introduzindo gradualmente suas próprias versões de funções que há muitos anos estão disponíveis de uma maneira ou de outra na versão principal do Elasticsearch.
O produto da Amazon carece de muitas coisas, como: RBAC e auditoria, o que é especialmente problemático para nós, porque aceitamos logs de equipes diferentes e gostaríamos de separá-los. No momento, qualquer usuário que tenha acesso ao Elasticsearch tem todos os direitos de acesso e pode excluir acidentalmente os dados de outra pessoa, alterar a maneira como eles são replicados nos nós e parar completamente de receber dados adicionando o modelo de indexação errado.
Isso é frustrante, mas esse não é o maior problema com o serviço. O rebalanceamento de shards - o conceito central do Elasticsearch - não funciona na implementação da AWS, o que nega quase tudo de bom no Elasticsearch.
Normalmente, quando dados são adicionados aos nós, um pode preencher mais do que os outros. Isso é esperado, pois não há garantias de que os registros carregados tenham o mesmo tamanho ou que o número de shards seja sempre distribuído igualmente em todos os nós do cluster. Isso não é crítico, porque o Elasticsearch pode reequilibrar shards entre nós e, se um nó estiver realmente cheio, outros nós terão prazer em começar a receber dados em vez de preenchê-los.
Isso não é suportado na Amazon. Alguns nós podem preencher (muito) mais rapidamente que outros.
Além disso,
na Amazon, se um nó no cluster do Elasticsearch não tiver espaço livre suficiente, o cluster inteiro para de receber dados , para completamente. A solução da Amazon é permitir que os usuários passem pelo pesadelo de alterar periodicamente o número de shards em seus modelos de indexação e, em seguida, reindexar os dados criados anteriormente em novos índices, excluindo índices anteriores e, se necessário, indexando os dados novamente na estrutura anterior. Isso é completamente redundante e requer, além dos grandes custos computacionais, que uma cópia não processada dos dados baixados seja salva com o registro analisado, porque será necessária uma cópia não processada para a reindexação. E, é claro, isso duplica a quantidade de memória necessária para o trabalho "normal" na AWS.
“Opa! Não reindexei o cluster inteiro com frequência suficiente e o nó estava cheio! O que fazer? "
Você tem duas opções. Primeiro, exclua os dados necessários para recuperar o cluster e comece a reindexar com a esperança de que nada desmorone. Você tem um backup do que deseja excluir?
A segunda opção é adicionar mais nós ao cluster ou redimensionar os existentes para um tamanho de instância maior.
Mas espere, como adiciono nós ou faço alterações se os shards não podem ser reequilibrados?
A solução da Amazon é uma implantação azul esverdeada. Eles geram um cluster totalmente novo, copiam todo o conteúdo do cluster anterior para um novo e, em seguida, alternam e destroem o cluster antigo.
Essas tarefas de redimensionamento podem levar dias, para grupos grandes, como você pode imaginar, duplicar vários trilhões de registros pode levar algum tempo. Isso também cria uma carga maluca no cluster existente (provavelmente já está excedendo a capacidade) e pode realmente causar a falha do cluster. Realizei várias operações semelhantes em mais de 30 clusters na AWS e apenas uma vez observei uma conclusão bem-sucedida no modo automático.
Portanto, você tentou redimensionar seu cluster e a tarefa não foi concluída. O que agora
Interações da Amazon
Sua tarefa de redimensionar o cluster foi cortada (para o serviço que você provavelmente optou por não lidar com esse artigo), então você abre o ticket para o suporte técnico da AWS com a maior prioridade. Obviamente, eles reclamarão da quantidade ou tamanho do seu fragmento e adicionarão um link para as "melhores práticas" que você já leu 500 vezes. E então você espera que seja corrigido. E espera. E espera. A última vez que tentei redimensionar o cluster e ele foi bloqueado, o que levou a sérios problemas de funcionamento, levou SETE DIAS para devolver tudo on-line. Eles restauraram o próprio cluster em alguns dias, mas quando tudo parou, é óbvio que os nós nos quais o Kibana está executando perderam contato com o cluster principal. O Suporte da AWS passou mais quatro dias tentando consertar algo enquanto se perguntava se o Kibana estava funcionando. Eles nem sabiam se tinham resolvido o problema e eu tive que verificar se eles haviam restaurado a comunicação entre seus próprios sistemas. Desde então, parei de fazer outra coisa senão excluir dados, se o nó estiver cheio.
Os custos de nossa organização na AWS são enormes. Isso nos dá a oportunidade de nos reunir periodicamente com seus especialistas em vários campos, discutir estratégias de implementação e lidar com uma variedade de questões técnicas. Marcamos uma consulta com um representante da Elasticsearch, durante o qual passei a maior parte da reunião explicando os conceitos básicos da Elasticsearch e descrevendo ... as peculiaridades ... do seu produto. O especialista ficou completamente chocado ao saber que tudo entra em colapso quando o nó está cheio. Se o especialista enviado não souber o básico de seu produto, não surpreende que a equipe de suporte precise de sete dias para retomar o cluster de produção.
Pensamentos finalmente
No projeto de registro em que mergulhei, há uma parcela de erros de arquitetura e decisões fracas de design nas quais estamos trabalhando. E, é claro, esperava que o AWS Elasticsearch fosse diferente do produto original. No entanto, no AWS Elasticsearch, tantas funções fundamentais estão desabilitadas ou ausentes que exacerbam quase todos os problemas que encontramos.
Para facilitar o uso e pequenos clusters, o AWS Elasticsearch funciona muito bem, mas para clusters de tamanho de petabyte, foi um pesadelo sem fim.
Estou muito curioso para saber por que a implementação do Elasticsearch da Amazon não pode equilibrar fragmentos; essa é uma funcionalidade fundamental do Elasticsearch. Mesmo com limitações em comparação com a principal Elasticsearch, certamente seria um produto aceitável para grandes grupos se funcionasse corretamente. Não consigo entender por que a Amazon está oferecendo algo tão quebrado e por que eles não corrigem a situação há mais de dois anos.
Como outros sugeriram, e parece razoável, esse comportamento é um sinal da implementação da AWS, projetada como um cluster multilocatário gigante, tentando fornecer isolamento para parecer um cluster autônomo para usuários finais. Mesmo com opções como dados criptografados em repouso e transferência de dados criptografados, isso parece plausível. Ou talvez suas ferramentas e configurações sejam simplesmente um legado de uma arquitetura muito anterior.
E, como meu amigo observou, é muito engraçado que eles ainda o chamam de "Flexível" quando você não pode adicionar ou remover nós de seus clusters sem criar um novo e transferir todos os seus dados.
Nota de rodapé: quando escrevi este texto, encontrei um post há dois anos com muitas afirmações semelhantes:
read.acloud.guru/things-you-should-know-before-using-awss-elasticsearch-service-7cd70c9afb4f