Reverse Proxy Server Cloud Arquitetura (AWS + nginx)

Question

Atualmente, faço o cache de respostas usando nginx + fastcgi. Estou no processo de mover meu aplicativo para a AWS. Estou arquitetando uma abordagem de escala horizontal, mas tentando determinar onde é melhor colocar o cache nginx + fastcgi.

Encontrei algumas soluções da minha própria pesquisa, ambas com desvantagens significativas.

• Use o AWS Elastic Load Balancer para equilibrar um cluster de aplicativos da web. Cada aplicativo da Web executa sua própria pilha de nginx e de servidor da web. Drawback: o cache em cada servidor precisa ser aquecido . Pior caso 1 / n a taxa de acerto.
• Coloque nginx + fastcgi na frente do AWS ELB para que o cache fique centralizado para hits máximos. Inconveniente: ponto único de falha - se o nginx morrer, o tráfego não passa para o ELB. Adicionada instância nginx.

Eu gostaria de receber sugestões de arquiteturas comuns que superem as desvantagens descritas acima.

    

Answer 1

Eu configurei esta pilha muitas vezes na AWS. Opção # 1 sempre funcionou bem para mim e é o que eu normalmente escolho porque é o mais simples. Estou curioso para saber com quanto tráfego você está lidando, onde os acertos do cache inicial são menores do que os ideais? Estou exibindo alguns milhões de exibições de página por mês em um par de instâncias de m1.small e elas mal são arranhadas.

Outros pensamentos:

• O Nginx pode usar o memcached como um armazenamento em cache. Conecte-o em um cluster ElasticCache. Isso fornecerá um datastore muito rápido e centralizado para várias instâncias para se conectar ao conteúdo do cache. (nunca fiz isso, mas parece factível. Por favor, poste os resultados se você tentar.)

• O problema SPoF mencionado na Opção 2 pode ser atenuado pela configuração de um grupo de escalonamento automático que contenha uma única instância. Se ele morrer, ele deve voltar a ficar on-line em questão de alguns minutos. Você precisará mexer com um script de inicialização que automaticamente agarra o Elastic IP.

• Tenha em mente que colocar qualquer coisa na frente de um ELB exigirá que você use o VPC. Em geral, essa é uma boa prática, mas pode ter uma curva de aprendizado acentuada.

As

• Ações de alarme do CloudWatch foram anunciadas hoje. Você poderia fazer algumas coisas legais com isso para ajudar a minimizar o problema do SPoF.

Answer 2

Parece que você está pensando sobre a mesma arquitetura que estou planejando implementar.

Pensei nos cenários e na mesma abordagem e, depois, resolvi essa solução.

Eu estarei usando a segunda opção, configurando a solução de cache na frente do Load Balancer. Eu estou indo para lidar com o ponto único de falha com adição de mais um nó com o modo de espera e usando algo como HAProxy para continuar verificando a integridade da máquina. Se a primeira máquina de cache foi desativada, o HAProxy automaticamente moverá o IP e moverá o tráfego para a outra máquina em espera do cache e, portanto, o ponto único de falha será manipulado.

Além disso, no meu cenário, vou usar algo como o Varnish, em vez do Nginx + php, que eu também sugiro, caso seu aplicativo não seja dependente do Nginx. O verniz terá seu próprio Balanceador de Carga integrado, portanto, você também ignorará o balanceador de carga da AWS.

Espero que isso ajude você a construir uma infraestrutura robusta e escalável.