Nginx + Elasticsearch: Segmentando Leitura e Escrita
O Nginx pode tornar ainda melhor a arquitetura e o crescimento do seu cluster de Elasticsearch, permitindo o controle do fluxo HTTP tratando as requisições e respostas, incluindo autenticação via SSO/SAML, LDAP, entre outros meios de autenticação e autorização, balanceamento de carga (load balancer) para distribuição de requisições entre os coordinators/data/hot nodes, entre outros recursos interessantíssimos. Hoje, vamos falar sobre um ponto que me ajudou muito na projeção e compreensão das minhas reais necessidades em um cluster de Elasticsearch de alta performance: a segmentação da leitura e da escrita.
Porque separar a leitura e a escrita?
Existem diversos motivos para justificar tanto a segmentação da leitura e da escrita, como para utilizar um proxy reverso na frente da sua aplicação ou serviço. Dentre esses motivos, temos como principal o fato de manter o domínio de quais aplicações fazem cada tipo de operação, garantindo previsibilidade em toda manutenção no cluster e nas aplicações, que necessitam ser desenvolvidas ou ajustadas com esse mindset.
Normalmente, as aplicações que utilizam o Elasticsearch são segmentadas na camada de persistência (seja uma aplicação, ETL, etc) e as aplicações de leitura (dashboards, analytics, lojas de e-commerce, sites, etc).
Com o nginx na “frente”, conseguimos permitir a configuração do seu firewall liberando ou bloqueando quem precisa ou não acessar determinado recurso (leitura ou escrita) e também facilitamos alterações no cluster, com as regiões de escrita e leitura. Por exemplo, se tenho necessidade de manter a escrita próxima do meu ETL ou Banco de dados primário, e a leitura próxima da aplicação ou do cliente fazendo roteamentos realmente inteligentes. Obviamente essa configuração vai depender totalmente da arquitetura do seu cluster e do seu negócio.
Exemplo de arquitetura e configuração
Nesse exemplo, o nginx está sendo executado em cada nó coordinator. Para permitir a segmentação da leitura e escrita, essa solução atende todos requisitos necessários. Se você utiliza o Kibana é importante ressaltar a necessidade de um DNS para read-write, requerido para o funcionamento do Kibana. Para isso adicionaremos uma configuração a mais e um DNS (seguindo o exemplo, https://elasticsearch-readwrite.xxx.com) permitindo o seu uso.
No exemplo de configuração do nginx que será disponibilizado, essa configuração estará presente.
No exemplo acima, temos um cluster do nginx na frente do cluster de elasticsearch. A diferença para o formato anterior, além de ser necessário administrar o cluster do nginx é a possibilidade para extender o seu comportamento, permitindo que a leitura e a escrita sejam feitas em “regiões” diferentes de forma mais prática e escalável do que a solução anterior.
Com duas regiões separadas, com objetivo de aproximar os serviços e reduzir a latência, utilizar apenas um cluster do nginx pode ser um “tiro no pé”, pois do que adianta a leitura na região de São Paulo e a escrita na Califórnia, se voce possui apenas um cluster do nginx em apenas uma das regiões? O seu pacote tcp irá percorrer um caminho a mais. Ao invés de reduzir, você estará somente aumentando o seu tempo de resposta.
Para ter esse ganho significativo, você precisa ter um cluster do nginx também em cada região. Não pense que ganhar 100ms, 200ms em uma requisição é algo fácil e de baixo custo, quando mais otimizado mais estratégias como essa você precisa “planejar” e “executar”. Veja o resultado na figura abaixo.
E você deve estar se perguntando: “Mas pra fazer isso eu posso por um load balancer para meus clients de cada região e tá tudo certo!” — Errado!
De certa forma funcionaria, mas você perderia a segmentação da leitura e da escrita, como proposto no artigo.
Configuração no Nginx
Multiregião no Cluster de Elasticsearch
Para configurar o seu cluster de elasticsearch para funcionar com multiplas regiões, alocar shards de forma “equilibrada” entre as regiões entre outras configurações associadas, dá uma olhadinha em Shard Allocation Awareness.
O objetivo desse artigo é tirar nosso pensamento de arquitetura unicamente do serviço e compreender que serviços auxiliares podem nos ajudar para atingir otimizações para a administração, tempo de resposta, entre outros. Aqui foi possível entender um pouco de como o nginx pode ser uma ferramenta poderosa aliado com o elasticsearch. Espero que seja útil e contribua para sua otimização também. Até a próxima! 👋
