Que estratégias de cache posso implementar entre meu balanceador de carga da web e meu farm da web?

Question

Eu tenho um web farm de máquinas IIS7. funciona bem. Estamos prestes a liberar uma API para o mundo real. É bem simples, mas sabemos que será muito difícil desde o primeiro dia (temos pelo menos um cliente inscrito).

Então, estamos pensando em adicionar uma camada de armazenamento em cache entre nossos servidores da Web e as interwebs. Em primeiro lugar, não faço ideia se esta é uma boa solução, por isso estou aberto a ideias. Em segundo lugar, o que colocamos na frente da fazenda? Uma caixa dedicada do Windows ou Linux? Nosso balanceador de carga da web é um F5 BIG IP.

Estou aberto a sugestões:)

Alguma idéia, pessoal?

    

Answer 1

Não sei se entendi a pergunta. O cache de proxy reverso é uma prática comum e há muitas ferramentas para isso. Varnish e Squid são popular no mundo do código aberto para fazer isso. Normalmente, você colocaria algumas caixas de RPC atrás de seu balanceador de carga e, em seguida, iria diretamente das caixas de RPC para os servidores da Web ou voltaria pelo balanceador de carga para os servidores da Web.

Dito isso, se você estiver falando sobre uma API, normalmente a maior parte do conteúdo que você veicaria seria dinâmica, o que tornaria o armazenamento em cache inútil.

    

Answer 2

Estou atrasado para a festa aqui; mas eu tenho algo para contribuir ...

Cal Henderson fala (brevemente) sobre os problemas que você está enfrentando em seu livro Building Scalable Websites . Você deve ler o capítulo sobre APIs de serviço da web.

Como o cavalete aponta corretamente, o cache de proxy reverso normalmente não oferece muito benefício para uma API.

Duas coisas que beneficiarão você são:

1. Um cache de valor-chave distribuído para os dados com os quais você está trabalhando. Ou seja você pode armazenar em cache seus hot dados em seu formato de objeto nativo de plataformas, ou como matrizes serializadas simples ou qualquer outra coisa que seja rápida para sua plataforma. Isso limita o número de acessos ao seu banco de dados, onde você terá seus piores problemas de dimensionamento. Seus servidores de API ainda precisarão recuperar quaisquer conjuntos de dados não armazenados em cache e serializar a resposta, mas pelo menos a parte de serialização será vinculada apenas à CPU e poderá ser dimensionada com facilidade.
2. Algum tipo de sistema de limitação de taxa, ou seja, a capacidade de limitar ou negar clientes que estão fazendo muitas solicitações. Normalmente, as chamadas de API envolvem processamento bastante pesado em seus servidores (conforme eles leem ou manipulam dados brutos), portanto, proteger-se contra clientes mal escritos faz sentido.

Além do acima, o Cal Henderson sugere a criação de bibliotecas cliente de software livre em idiomas populares e a colocação de práticas recomendadas nessas (ou seja, armazenamento em cache no lado do cliente, limitação de taxa). Desta forma, os desenvolvedores de terceiros terão uma plataforma de código fácil e compatível para reutilizar e desenvolver. A idéia parece ótimo IMHO, mas também um pouco caro.

    

Answer 3

Uma camada de cache ajudaria com o conteúdo estático, mas não vejo como isso ajudará muito com as APIs dinâmicas. No entanto, isso ainda pode ser útil.

Por exemplo, você poderia usar um CDN para ajudar a armazenar em cache e distribuir itens estáticos para reduzir a carga de trabalho do seu servidor, para que ele gaste mais tempo com o material dinâmico.

Para o seu material dinâmico, você pode usar algo como o que é mencionado aqui se você está usando um CDN para coisas dinâmicas.

    

Answer 4

CDNs como o Akamai podem ser úteis até mesmo para conteúdo dinâmico, como APIs e SSL. Eles fazem isso mantendo sessões TCP abertas entre seus nós de borda e seus servidores. Isso reduz o número de conexões abertas em seus servidores e economiza uma tonelada de tempo e pacotes para estabelecer novas sessões TCP.

Um balanceador de carga como o HAProxy também pode ajudar, agilizando e otimizando as sessões TCP. Pode até executar pacotes de 1500 MTU no lado 'Mundo' e quadros Jumbo no lado de back-end para reduzir os tempos de processamento em seus servidores reais. Tem vários truques para descarregar a manipulação de conexões dos servidores reais para o LB. Ter threads e soquetes TCP em seus servidores de API amarrados apenas para alguns clientes TCP lentos é um desperdício de recursos.