O verniz consegue lidar com centenas de milhares de solicitações por segundo? Se não, posso agrupá-lo?

Question

Estou planejando ter uma arquitetura semelhante a:

  nginx - nginx - nginx - nginx
    \       \       /       /
             varnish 
    /           |         \
app server - app server - app server

(Os servidores de aplicativos são todos "idênticos" no sentido de que uma solicitação pode ser roteada para qualquer um deles pelo verniz.) O verniz nesse diagrama estaria processando (potencialmente) centenas de milhares de solicitações por segundo. Pode fazer isso?

Eu preferiria executar vários servidores Varnish, por motivos de failover e desempenho, mas o problema imediato que vejo é que o armazenamento em cache não teria muito uso, porque cada solicitação atingiria um servidor Varnish diferente, até que cada um deles servidores tinham uma cópia do objeto em cache. Qual é o jeito certo de fazer isso? (Novamente, os servidores de aplicativos são idênticos ao Varnish, não importa para o qual a solicitação é roteada. Gostaria de ter vários servidores Varnish (por trás do balanceamento de carga do nginx) processando as solicitações.)

    

Answer 1

Eu recentemente lidei com a mesma pergunta. O verniz pode lidar com um grande número de solicitações por segundo, mas você deve testá-lo com sua configuração (hardware, rede, tamanho das respostas, índice de acertos) para ter uma ideia dos números de desempenho. Além do desempenho, há a questão do failover para iniciar o balanceamento.

• se urls forem sua chave de cache, você pode configurar um mecanismo no nginx que escolha uma instância de verniz específica com base na url (varnish_instance = hash (url) modulo nr_of_varnishes). Se o verniz reescreve o URL antes de enviá-lo para um back-end ou faz uma pesquisa de cache e URLs diferentes são reescritos para o mesmo URL novo, esse truque não é eficaz.

• no meu caso, não posso rotear com base na URL no balanceador de carga. Usamos lvs-dr e simplesmente não sabemos sobre o URL no balanceador.

• Eu joguei com a ideia de configurar tal mecanismo de distribuição em verniz. Pode-se configurar os outros vernizes como 'back-ends', calcular um hash e direcionar o pedido para o verniz direito. O verniz 'direito' faz a chamada de back-end e armazena-a no cache. Outros vernizes também podem armazenar os resultados, mas não precisam. Essa configuração torna sua configuração de verniz mais complicada, portanto, pense com cuidado antes de escolher esse caminho. O Direct Routing (parte do lvs-dr) torna isso ainda mais complicado.

No final, escolhi uma solução simples: distribuir solicitações em duas grandes instâncias de verniz sem nenhum material inteligente. Os resultados são calculados e armazenados em cache duas vezes, mas as configurações do verniz foram mantidas o mais simples possível.