Caches compartilhados com clusters de cache do NGINX Plus, parte 1

Owen GarrettDiretor Sênior de Gestão de Produtos

Nota do editor – Esta é a primeira parte de uma série sobre cache de alta capacidade e alta disponibilidade:

• Caches compartilhados com clusters de cache do NGINX Plus, Parte 1 (este artigo)
• Caches compartilhados com clusters de cache do NGINX Plus, parte 2

Esta publicação foi atualizada para fazer referência à API do NGINX Plus, que substitui e torna obsoleto o módulo separado de status estendido discutido originalmente aqui.

Como criar um cluster de cache de alta capacidade e alta disponibilidade usando o NGINX ou o NGINX Plus? Esta é a primeira parte de uma série de duas partes que apresenta abordagens alternativas para atingir esse objetivo. Você pode acessar a segunda parte pelo link acima. (Salvo indicação em contrário, as abordagens se aplicam igualmente ao NGINX Open Source e ao NGINX Plus, mas, para simplificar, mencionaremos apenas o NGINX Plus.)

Uma visão geral do cache do NGINX Plus

O NGINX Plus pode operar como um servidor de cache de proxy, posicionado entre o servidor de origem e os clientes remotos. O NGINX Plus gerencia o tráfego para o servidor de origem e armazena em cache recursos comuns que não sofrem alterações. Isso permite que o NGINX Plus responda diretamente aos clientes quando esses recursos são solicitados, reduzindo assim a carga no servidor de origem. O cache de proxy do NGINX Plus é mais comumente implantado em um data center próximo ao servidor de origem, mas também pode ser implantado de forma semelhante a uma CDN em PoPs distribuídos globalmente.

O cache de conteúdo é um assunto surpreendentemente complexo. Vale a pena se familiarizar com algumas técnicas básicas de cache antes de continuar a leitura deste artigo:

• A mecânica do cache do NGINX Plus – Configuração básica e a função dos processos de carregamento e gerenciamento do cache
• Ajuste fino dos tempos de cache – Implementação de práticas como o microcaching para controlar como o conteúdo é armazenado em cache e como ele é atualizado quando expira

Por que o NGINX Plus não usa um disco compartilhado para armazenamento em cache?

Cada servidor NGINX Plus atua como um servidor independente de cache da Web. Não há meios técnicos de compartilhar um cache baseado em disco entre vários servidores NGINX Plus; essa é uma decisão de projeto deliberada.

Armazenar um cache em um sistema de arquivos compartilhado de alta latência e potencialmente não confiável não é uma boa escolha de projeto. O NGINX Plus é sensível à latência do disco e, embora o recurso de pools de threads transfira as operações de read() e write() da thread principal, quando o sistema de arquivos está lento e a E/S do cache é alta, o NGINX Plus pode ficar sobrecarregado com um grande volume de threads. Manter um cache compartilhado e consistente entre instâncias do NGINX Plus também exigiria bloqueios em todo o cluster para sincronizar operações de cache simultâneas, como preenchimentos, leituras e exclusões. Por fim, os sistemas de arquivos compartilhados introduzem uma fonte de falta de confiabilidade e desempenho imprevisível no cache, para o qual a confiabilidade e a consistência do desempenho são fundamentais.

Por que compartilhar um cache entre vários servidores NGINX Plus?

Embora compartilhar um sistema de arquivos não seja uma boa abordagem para armazenamento em cache, ainda há bons motivos para armazenar conteúdo em cache em vários servidores NGINX Plus, cada um com uma técnica correspondente:

• Se o seu principal objetivo é criar um cache de altíssima capacidade, fragmente (particione) o cache entre vários servidores. Abordaremos essa técnica neste artigo.
• Se o seu principal objetivo for alcançar alta disponibilidade e, ao mesmo tempo, minimizar a carga nos servidores de origem, use um cache compartilhado de alta disponibilidade. Para saber mais sobre essa técnica, consulte o artigo complementar (em breve).

Particionando seu cache

O particionamento de um cache é o processo de distribuir as entradas de cache entre vários servidores de cache da Web. O particionamento de cache do NGINX Plus usa um algoritmo de hash consistente para selecionar um único servidor de cache para cada entrada de cache. As figuras mostram o que acontece com um cache particionado entre três servidores (figura à esquerda) quando um dos servidores fica indisponível (figura central) ou quando outro servidor é adicionado (figura à direita).

A capacidade total do cache é a soma da capacidade de cache de cada servidor. Você minimiza as solicitações ao servidor de origem porque apenas um servidor tenta armazenar cada recurso em cache (não há várias cópias independentes do mesmo recurso).

Esse padrão é tolerante a falhas no sentido de que, se você tiver N servidores de cache e um deles falhar, perderá apenas 1/N do cache. Essa “parte perdida” é distribuída uniformemente pelo hash consistente entre os N –1 servidores restantes. Métodos de hash mais simples, por outro lado, redistribuem todo o cache entre os servidores restantes, fazendo com que você perca quase todo o cache durante a redistribuição.

Ao realizar o balanceamento de carga com hash consistente, use a chave de cache (ou um subconjunto dos campos usados para construir a chave) como a chave do hash consistente:

upstream cache_servers {    hash $scheme$proxy_host$request_uri consistent;

    server red.cache.example.com;
    server green.cache.example.com;
    server blue.cache.example.com;
}

Você pode distribuir o tráfego de entrada entre os servidores da camada de balanceamento de carga (LB) usando a solução de alta disponibilidade ativo-passivo do NGINX Plus, DNS round-robin ou uma solução de alta disponibilidade como o keepalived.

Otimizando sua configuração de cache fragmentado

Você pode escolher uma das duas otimizações para a configuração de particionamento do cache.

Combinando as camadas de balanceamento de carga e cache

Você pode combinar as camadas de balanceamento de carga e cache. Nessa configuração, dois servidores virtuais são executados em cada instância do NGINX Plus. O servidor virtual de balanceamento de carga (“LB VS” na figura) aceita solicitações de clientes externos e usa um hash consistente para distribuí-las entre todas as instâncias do NGINX Plus no cluster, que estão conectadas por uma rede interna. O servidor virtual de cache (“Cache VS”) em cada instância do NGINX Plus escuta em seu endereço IP interno as solicitações que lhe cabem, encaminhando-as ao servidor de origem e armazenando as respostas em cache. Isso permite que todas as instâncias do NGINX Plus atuem como servidores de cache, maximizando a capacidade do cache.

Configurando um cache “quente” de primeiro nível

Como alternativa, você pode configurar um cache de primeiro nível na camada de balanceamento de carga (LB) do frontend para conteúdo acessado com muita frequência, usando o cache compartilhado de grande capacidade como cache de segundo nível. Isso pode melhorar o desempenho e reduzir o impacto no servidor de origem caso uma camada de cache de segundo nível falhe, pois o conteúdo só precisa ser atualizado à medida que o conteúdo do cache de primeiro nível expira gradualmente.

Se o cluster de cache estiver processando um volume muito grande de conteúdo acessado com frequência, talvez você perceba que a taxa de rotatividade no cache de primeiro nível, que é menor, é muito alta. Em outras palavras, a demanda pelo espaço limitado no cache é tão alta que o conteúdo é removido do cache (para liberar espaço para conteúdo solicitado mais recentemente) antes mesmo que possa ser usado para atender a uma única solicitação subsequente.

Um indicador dessa situação é uma baixa proporção entre o conteúdo fornecido e o conteúdo gravado, duas métricas incluídas nas estatísticas estendidas relatadas pelo módulo de API do NGINX Plus. Elas aparecem nos campos Fornecido e Gravado da guia Caches do painel integrado de monitoramento de atividades em tempo real. (Observe que o módulo de API do NGINX Plus e o painel de monitoramento de atividades em tempo real não estão disponíveis no NGINX Open Source.)

Esta captura de tela mostra uma situação em que o NGINX Plus está gravando mais conteúdo no cache do que fornecendo a partir dele:

Nesse caso, você pode ajustar seu cache para armazenar apenas o conteúdo solicitado com mais frequência. A diretiva proxy_cache_min_uses pode ajudar a identificar esse conteúdo.

Resumo

Distribuir um cache em vários servidores de cache web NGINX ou NGINX Plus é uma maneira eficaz de criar um cache escalável e de altíssima capacidade. O hash consistente oferece um bom nível de alta disponibilidade, garantindo que, se um cache falhar, apenas a parte do conteúdo armazenado nele seja invalidada.

A segunda parte desta publicação descreve um padrão alternativo de cache compartilhado que replica o cache em um par de servidores de cache NGINX ou NGINX Plus. A capacidade total é limitada à capacidade de um único servidor, mas a configuração é totalmente tolerante a falhas, e nenhum conteúdo armazenado em cache é perdido se um servidor de cache ficar indisponível.

Experimente o particionamento de cache em seus próprios servidores – comece hoje mesmo sua avaliação gratuita de 30 dias ou entre em contato conosco para discutir seus casos de uso.

Sobre o autor

Owen GarrettDiretor Sênior de Gestão de Produtos

Mais publicações de Owen Garrett