Fragmentando (sic!) a camada da web para evitar um gargalo no balanceador de carga?

Question

Como grandes sites que não podem ser completamente apátridas alcançam escalabilidade extrema na camada da web?

Existem sites como eBay e Amazon, que não podem ser totalmente apátridas, pois possuem carrinho de compras ou algo parecido.Não é viável codificar todos os itens do carrinho de compras na URL, nem é possível codificar todos os itens em um cookie e enviá-los em todas as conexões.Portanto, a Amazon simplesmente armazena o ID da sessão no cookie que está sendo enviado.Portanto, entendo que a escalabilidade da camada da web do eBay e da Amazon deve ser muito mais difícil do que a escalabilidade do mecanismo de pesquisa do Google, onde tudo pode ser codificado de forma tranquila no URL.

Por outro lado, tanto o eBay quanto a Amazon cresceram de forma absolutamente massiva.Há rumores de que existem cerca de 15.000 servidores de aplicativos J2EE no eBay.

Como esses sites lidam com ambos:extrema escalabilidade e estado?Como o site tem estado, não é viável fazer um simples balanceamento de DNS.Portanto, seria de se supor que essas empresas tenham um balanceador de carga baseado em hardware como BigIP, Netscaler ou algo parecido, que é o único dispositivo por trás do endereço IP único desse site.Este balanceador de carga descriptografaria o SSL (se codificado), inspecionaria o cookie e decidiria, dependendo do ID de sessão desse cookie, qual servidor de aplicativos mantém a sessão desse cliente.

Mas isso simplesmente não pode funcionar, já que nenhum balanceador de carga poderia lidar com a carga de milhares de servidores de aplicativos?Eu imagino que mesmo esses balanceadores de carga de hardware não chegam a esse nível.

Além disso, o balanceamento de carga está sendo feito de forma transparente para o usuário, ou seja,os usuários não são encaminhados para endereços diferentes, mas todos permanecem coletivamente em www.amazon.com o tempo todo.

Então minha pergunta é:Existe algum truque especial com o qual se pode conseguir algo como fragmentação transparente da camada da web (não da camada do banco de dados, como é feito comumente)?Enquanto o cookie não for inspecionado, não há como saber qual servidor de aplicativos está mantendo esta sessão.

Editar: Percebi que só há necessidade de transparência, se houver necessidade de o site ser indexado e marcado como favorito.Por exemplo.se o site for um mero aplicativo da web, algo como um sistema de reserva de passagens de avião ou trem, não deverá haver problema em apenas redirecionar os usuários para clusters específicos de servidores da web por trás de URLs diferentes, por exemplo.a17.ticketreservation.com.Neste caso específico, seria viável usar apenas vários clusters de servidores de aplicação, cada um atrás de seu próprio balanceador de carga.Curiosamente, não encontrei nenhum site que utilize esse tipo de conceito.Editar: achei esse conceito discutido no highscalability.com, onde a discussão se refere a um artigo de Lei Zhu chamado "Balanceamento de carga do lado do cliente para aplicativos Web 2.0".Lei Zhu usa scripts cruzados para fazer esse balanceamento de carga do lado do cliente de forma transparente.

Mesmo que existam desvantagens, como bookmarking, xss, etc, penso que isto parece uma ideia extremamente boa para certas situações especiais, nomeadamente aplicações web quase sem conteúdo, que não necessitam de ser indexadas ou marcadas (por exemplo,sistemas de reserva de bilhetes ou algo parecido).Então não há necessidade de fazer o balanceamento de carga de forma transparente.

Poderia haver um simples redirecionamento do site principal para o servidor, por ex.um redirecionamento de www.ticketreservation.com para a17.ticketreservation.com.A partir daí o usuário permanece no servidor a17.a17 não é um servidor, mas um cluster em si, pelo qual a redundância pode ser alcançada.

O próprio servidor de redirecionamento inicial pode ser um cluster atrás de um balanceador de carga.Dessa forma, uma escalabilidade realmente alta poderia ser alcançada, já que o balanceador de carga primário por trás de www só é atingido uma vez no início de cada sessão.

É claro que o redirecionamento para URLs diferentes parece extremamente desagradável, mas com meros aplicativos da Web (que não precisam ser indexados, vinculados ou marcados como favoritos), isso deve ser apenas um problema óptico para o usuário?

O cluster de redirecionamento poderia pesquisar a carga dos clusters de aplicativos e adaptar os redirecionamentos de acordo, alcançando assim o equilíbrio e não a mera distribuição de carga.

Answer 1

Fácil.Os servidores web, que não têm estado, têm balanceamento de carga.Os servidores de aplicativos (camada intermediária), que armazenam os dados da sessão, não o são.Os servidores da web podem usar o cookie de identificação de sessão para determinar qual servidor de aplicativo entrar em contato.

Memcached e Velocity da Microsoft são produtos que atendem exatamente a essa necessidade.

Editar:Como um servidor web sabe qual servidor de aplicativo contatar?Isso está incorporado no hash do ID da sessão e pode ser feito genericamente como você quiser.Poderia ser tão simples quanto o seu ID de sessão ser server:guid. Memcached baseia-se no hash, no entanto.

O importante é que o cliente seja capaz de descobrir qual servidor de aplicativo contatar sem estado.A maneira mais fácil de fazer isso é incorporá-lo à chave, embora um registro (talvez em seu próprio nível) também funcione e possa fornecer alguma tolerância a falhas.

Editar2:Voltando alguns eBay entrevistas, posso ter entendido um pouco errado os detalhes de sua implementação.Eles não fazem cache e não fazem estado na camada intermediária.O que eles fazem é ter uma camada intermediária com balanceamento de carga (servidores de aplicativos) particionada por função.Assim, eles teriam um conjunto de servidores para, por exemplo, visualizar itens.E depois outro pool para venda de itens.

Esses servidores de aplicativos têm um DAL "inteligente" que roteia para bancos de dados fragmentados (particionados por função e dados, portanto, Usuários AL no Banco de Dados1, Usuários MZ no Banco de Dados2, Itens 1-10000 nos Itens1, etc.).

Eles não têm estado na camada intermediária porque são particionados por função.Portanto, uma experiência normal do usuário envolveria mais de um pool de servidores de aplicativos.Digamos que você visualize um item (ViewAppServerPool) e, em seguida, faça um lance em um item (BidAppServerPool).Todos esses servidores de aplicativos teriam que permanecer sincronizados, o que exigiria um cache distribuído para gerenciar tudo.Porém, sua escala é tão grande que nenhum cache distribuído poderia gerenciá-lo com eficácia, nem um único servidor de banco de dados.Isso significa que eles precisam fragmentar a camada de dados e qualquer implementação de cache teria que ser dividida nos mesmos limites.

Isso é semelhante ao que postei acima, apenas desci uma camada.Em vez de fazer com que o servidor web determine qual servidor de aplicativos contatar, o servidor de aplicativos determina qual banco de dados contatar.Só que, no caso do Ebay, ele poderia atingir mais de 20 servidores de banco de dados devido à sua estratégia de partição.Mas, novamente, a camada sem estado tem algum tipo de regra(s) que usa para entrar em contato com a camada com estado.As regras do Ebay, no entanto, são um pouco mais complicadas do que a regra simplista "Usuário1 está no Servidor10" que expliquei acima.

Answer 2

O artigo a seguir pode ser útil, que apresenta o design e a implementação de um sistema de armazenamento de valores-chave altamente disponível que alguns dos principais serviços da Amazon usam para fornecer uma experiência “sempre ativa”:

Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swami Sivasubramanian, Peter Vosshall e Werner Vogels, “Dínamo:Armazenamento de valores-chave altamente disponível da Amazon”, nos Anais do 21º Simpósio ACM sobre Princípios de Sistemas Operacionais, Stevenson, WA, outubro de 2007.

Answer 3

Você provavelmente teria que fazer parte da equipe de engenharia de um desses lugares para ter certeza, mas há pessoas que fizeram suposições fundamentadas em palestras e outras informações que surgiram de ambos os lugares:

Arquitetura Ebay e Arquitetura Amazônica

Apenas um único balanceador de carga por si só no mundo de hoje é equivalente ao round robin de DNS dos anos anteriores.Hoje você tem coisas como qualquer transmissão que permitem que você faça todos os tipos de truques.Você pode ter certeza de que empresas como ebay e amazon usam balanceadores de carga e usam muitos deles.

Você pode querer resumir um pouco mais quando pensar em como isso pode funcionar, porque grande parte do tráfego não tem estado.Em uma única solicitação de página, há potencialmente muitos objetos que não precisam saber sobre o estado.Tire esses objetos de cena servindo-os a partir de um sistema sem estado (é aqui que entra o anycast) e o número de solicitações diminuirá drasticamente.

Se isso não levar você ao ponto em que um único balanceador de carga possa lidar com a carga, o próximo passo é dividir as transações usando roteamento IP e/ou geo-DNS.Sites tão grandes como eBay e Amazon estarão em vários datacenters diferentes, com um grande número de conexões de Internet em cada um.Você pega tudo que vem do internet pop quest-west e envia para os servidores "quest" do datacenter da costa oeste, qualquer coisa de att-west é enviada para os servidores "att" do datacenter da costa oeste, qualquer coisa de quest-east e vai para os servidores de "missão" do datacenter da costa leste, etc.Cada um desses sistemas pode ser uma ilha, um único balanceador de carga que pode lidar com a carga. Alguns dos balanceadores de carga existentes podem lidar com centenas de milhares de transações por segundo, mesmo criptografadas por SSL.Por outro lado, você replica em massa para cada datacenter constantemente, mas pode estar fora de sincronia.

Answer 4

Não sei como eles fazem isso, mas aqui vão algumas sugestões:

• Para evitar sobrecarregar o próprio host do balanceador de carga, use DNS round-robin OU
• Redirecione diferentes clientes para diferentes endereços de cluster com base na carga, configurações, geolocalização, etc.

Para distribuir a carga da camada intermediária,

• Incorpore o ID do servidor de sessão de camada intermediária no cookie de ID da sessão - como outros sugeriram.Dessa forma, a caixa de front-end que você atingiu é irrelevante, elas podem ser adicionadas/removidas sem qualquer impacto.
• Se for suficientemente importante, tenha um mecanismo para redirecionar clientes para um servidor alternativo de camada intermediária durante uma sessão, para que um possa ser desativado para manutenção, etc.
• Os clientes começam a usar um servidor de camada intermediária recém-comissionado ao iniciar uma nova sessão

Para distribuir a carga do banco de dados de back-end

• Fragmentação "convencional" de dados "em tempo real" por conta ou por usuário
• Replique de forma assíncrona dados que mudam lentamente ou relativamente estáticos;os usuários podem vê-lo desatualizado (mas não muito na maioria das vezes).Servidores de camada intermediária e da web se conectam a um banco de dados local em seu próprio local