Algumas coisas que você deve saber antes de usar o Elasticsearch Service da Amazon em AWS

A pesquisa elástica é uma infra-estrutura poderosa mas frágil com uma série de coisas que podem fazer com que o serviço AWS se torne instável

Eu escrevo isso seguindo um dia particularmente frustrante de giro do polegar e aguardando mensagens escassas da equipe de suporte da AWS. Nosso cluster Elasticsearch estava desligado durante a maior parte de um dia, e nos envolvemos com o suporte AWS o tempo todo.

No meu trabalho anterior trabalhando para a Loggly, minha equipe e eu mantivemos uma enorme e multi-cluster Elasticsearch de implantação. Aprendi muitas lições e tenho muitos truques nas minhas mangas para lidar com os temperamentos da Elasticsearch. Eu me sinto equipado para lidar com a maioria dos problemas de Elasticsearch, tendo acesso a APIs, métricas e log de Elasticsearch administrativos.

A Elasticsearch da AWS não oferece acesso a nada disso . Nem mesmo APIs que são somente leitura, como a API / _cluster / pending_tasks , o que teria sido realmente útil, já que o número de tarefas em nossa fila de tarefas pendentes estava em constante escalada na região 60K +.

Esta mensagem maldita me atormentou desde que a ELSssecherche hospedada pela AWS foi imposta em mim há alguns meses atrás:

 { 
 "Mensagem": "Seu pedido: '/ _cluster / pending_tasks' não está permitido." 
 }

Obrigado, AWS. Obrigado….

Sem acesso a logs, sem acesso às APIs de administrador, sem métricas de nível de nó (tudo o que você obtém é métricas agregadas de nível de cluster) ou mesmo os registros de consultas, é basicamente impossível solucionar o seu próprio cluster Elasticsearch. Isso deixa você com uma opção sempre que qualquer coisa começa a dar errado: entre em contato com a equipe de suporte da AWS.

9 vezes em 10, a AWS simplesmente se queixa de que você tem muitos fragmentos.

É amargamente engraçado que eles o aceitem por isso porque, por padrão, qualquer índice que você crie conterá 5 fragmentos e 1 réplica. Qualquer veterano da ES diz para si mesmo: heck, vou apenas atualizar as configurações do cluster e diminuir o padrão para 1 shard! Não.

 { 
 "Mensagem": "Seu pedido: '/ _cluster / settings' não está permitido para verbo: GET" 
 }

Bem, foda-se (embora você possa contornar isso usando modelos de índice ).

Eventualmente, o suporte da AWS sugeriu que atualizássemos o tamanho da instância de nossos nós mestres, uma vez que não conseguiram acompanhar a crescente fila de tarefas pendentes. Mas, eles nos aconselharam a ser cautelosos porque fazer qualquer alteração dobrará o tamanho do cluster e copiará todos os fragmentos.

Está certo. Aumentar o tamanho da instância de apenas os nós mestres realmente causará o middleware da AWS para duplicar o tamanho de todo o cluster e realocar todos os fragmentos no cluster para novos nós. Depois disso, os nós antigos são retirados do cluster. Por que isso é necessário é totalmente além de mim.

Adicionar uma entrada à lista de endereços IP que tenham acesso ao cluster fará com que o cluster dobre em tamanho e migre todo o fragmento fedorento.

Na verdade, mesmo adicionar um único nó de dados ao cluster faz com que ele seja duplicado e todos os dados se moverão.

Não acredite em mim? Aqui está o gráfico atual de nossa contagem de nós enquanto lidamos com o problema de ontem:

A contagem do nó aumentou 10x por um período de tempo

De volta a Loggly, nunca teríamos considerado fazer isso. O deslocamento de cada fragmento em qualquer agrupamento de tamanho respeitável tudo-em-uma vez oblitera os nós mestres e faria com que tanto a indexação quanto a busca pareçam. Qual é exatamente o que acontece sempre que fazemos qualquer alteração no nosso cluster Elasticsearch no AWS.

É provavelmente por isso que a AWS está sempre reclamando sobre o número de fragmentos que temos … Como, eu sei que o Elasticsearch tem uma maneira fácil e simples de adicionar um único nó a um cluster. Não há razão para essa loucura dada a maneira como o Elasticsearch funciona.

Muitas vezes me pergunto o quanto a complexidade gratuita se esconde no middleware Elasticsearch da AWS. Minha teoria é que seus clusters ES são multi-inquilino. Por que razão o ponto final das tarefas pendentes seria bloqueado? Por que mais eles não lhe dariam acesso aos registros do ES? Por que mais eles deveriam administrar tantas API administrativa útil atrás do Cerberus “não permitido”?

Devo admitir, porém, é muito bom poder adicionar e remover nós de um cluster com o clique de um botão. Você pode alterar os tamanhos de instância de seus nós de um menu suspenso; você obtém um painel de métricas semi-útil de métricas; Quando os nós caem, eles são automaticamente trazidos de volta; você obtém instantâneos automáticos; A autenticação funciona perfeitamente no ecossistema da AWS (mas torna seu cluster ES obnóxamente difícil de se integrar com bibliotecas e ferramentas não-AWS, que eu poderia gastar toda a publicação de blog do nother) e, quando as coisas derem errado, tudo o que você precisa fazer é gire seus polegares e espere em folga porque você não tem o poder de fazer qualquer outra coisa.

A pesquisa elástica é uma infra-estrutura poderosa mas frágil. Seus problemas são matizados. Há toneladas de coisas que podem fazer com que ele se torne instável, a maioria das quais está relacionada aos padrões de consulta, os documentos indexados, o número de campos dinâmicos criados, os desequilíbrios nos tamanhos de fragmentos, a proporção de documentos para o espaço de pilha, etc. Diagnosticar esses problemas é um pouco de arte e um precisa de muitas métricas, arquivos de log e APIs administrativas para detalhar e encontrar a causa raiz de um problema.

A Elasticsearch da AWS não fornece acesso a nenhuma dessas coisas, não deixando nenhuma outra opção senão entrar em contato com a equipe de suporte da AWS. Mas a equipe de suporte da AWS não tem tempo, habilidades ou contexto para diagnosticar problemas não triviais, então eles apenas vão te repreender pelo número de fragmentos que você tem e dizer-lhe para jogar mais hardware no problema. Apesar de hospedar o Elasticsearch no AWS, você pode ter o problema de precisar de um engenheiro de devol de sua equipe, isso não significa que seu cluster seja mais estável.

Portanto, se o seu conjunto de dados for pequeno, se você puder tolerar infinitas horas de tempo de inatividade, se o seu orçamento for muito apertado, se a sua infra-estrutura estiver muito bloqueada no ecossistema da AWS para comprar algo melhor do que o Elasticsearch hospedado da AWS: AWS Elasticsearch é para você. Mas considere-se avisado …

Atualização – 19/06/2017 : Desde a publicação, os engenheiros da equipe AWS Elasticsearch nos contactaram pessoalmente para entender melhor nossos casos de uso. Eles estão planejando melhorar a experiência para “usuários avançados”, e reuniram muitos comentários de nós. Agradeço sinceramente a vontade da AWS de enfrentar essas questões de frente e estou impressionado com a rapidez com que eles abordaram isso. Então, chapéus para eles!

Obrigado por ler! Se você gosta do que lê, segure o botão aplauso abaixo para que outros possam achar isso. Você pode me seguir no Twitter .

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *