Simplificação da autorização
Imagine que você esteja entrando em um pub. Uma pessoa olha o seu documento de identidade na porta e, toda vez que pede uma bebida, você precisa mostrar a identidade novamente. Era assim que a autorização costumava executar verificações antes da versão 7.16: cada nó (porta) exigia uma verificação de autorização, e cada shard (pedido de bebida) também exigia uma verificação de autorização. Mas e se uma única verificação de identidade na porta pudesse cobrir os dois? Vamos aplicar essa mesma ideia à autorização no Elasticsearch!
O Elasticsearch permite que os usuários configurem o controle de acesso por função/atributo para conceder permissão refinada por campo, por documento ou por índice. Antes, o authorize
estava presente em muitas fases de uma consulta de busca para garantir que solicitações não autorizadas não tivessem acesso a dados injustificados. No entanto, a vigilância da funcionalidade de autorização tem um custo, e parte da lógica não é redimensionada horizontalmente à medida que o tamanho do cluster aumenta. Por exemplo, obter funcionalidades de campo para todos os campos em todos os índices de um cluster grande pode levar muitos segundos ou até minutos, gastando quase todo o tempo de execução em trabalho relacionado à autorização.
A versão 7.16 aborda esses problemas de dois lados:
- As melhorias algorítmicas tornam a autorização de solicitações individuais mais rápida, tanto ao autorizar uma solicitação REST quanto ao autorizar durante a comunicação da camada de transporte (ou seja, toda a rede interna de nó a nó) entre nós dentro de um cluster Elasticsearch.
- A autorização de solicitações internas é herdada de verificações anteriores ou se torna significativamente mais barata em muitos casos. Antes da versão 7.16, o Elasticsearch executava a mesma lógica de autorização pela qual a solicitação externa inicial passava ao autorizar as solicitações de transporte internas no cluster. Isso era feito para evitar a introdução de uma superfície de ataque na comunicação interna de nó a nó, que permitiria que um invasor criasse solicitações internas para contornar a lógica de autorização. Isso ficou muito mais barato agora ignorando a expansão de curingas em subsolicitações, ignorando a autorização para solicitações locais de nó (dentro do mesmo nó) e reduzindo o número geral de solicitações necessárias para ações como a busca.
Redução das solicitações de shard na fase pre-filter
Uma nova estratégia de busca foi implementada na versão 7.16 nas fases de pre-filter
para reduzir o número de solicitações para uma vez por nó correspondente. Antes da versão 7.16, a primeira fase de uma busca que tentasse filtrar todos os shards de uma consulta que não contivesse dados relevantes exigiria uma solicitação por shard do nó coordenador para um nó de dados. Ao consultar milhares de shards de uma vez, isso envolveu enviar milhares de solicitações por solicitação de busca do nó coordenador, lidar com milhares de respostas no nó coordenador, além de lidar com todas essas solicitações nos nós de dados e responder a elas. O redimensionamento do cluster para mais nós de dados melhoraria o desempenho ao lidar com tantas solicitações nos nós de dados, mas não ajudaria no desempenho dessa operação no nó coordenador.
A partir da versão 7.16, a estratégia de execução da fase pre-filter
foi ajustada para enviar apenas uma única solicitação por nó na fase, cobrindo todos os shards do nó. Isso pode ser visto na Figura 1 abaixo. Um cluster com milhares de shards em três nós de dados veria o número de solicitações de rede na fase de busca inicial passar de milhares para até três solicitações, independentemente do número de shards buscados. Como as solicitações por shard enviadas antes da versão 7.16 continham basicamente os mesmos dados em todos os shards, ou seja, a consulta de busca, o envio de apenas uma solicitação por nó significa que essas informações não são mais duplicadas em várias solicitações, reduzindo drasticamente o número de bytes que precisam ser enviados pela rede.