Dimensionamento de hardware de site

Question

Então, eu estava ouvindo o último podcast do Stackoverflow (episódio 19) e Jeff e Joel conversaram um pouco sobre como dimensionar o hardware do servidor à medida que um site cresce.Pelo que Joel estava dizendo, os primeiros passos são bastante padronizados:

1. Um servidor executando o servidor web e o banco de dados (a configuração atual do Stackoverflow)
2. Um servidor web e um servidor de banco de dados
3. Dois servidores web com balanceamento de carga e um servidor de banco de dados

Eles não conversaram muito sobre o que vem a seguir.Você adiciona mais servidores web?Outro servidor de banco de dados?Replicar este cluster de três máquinas em um datacenter diferente para redundância?Para onde vai uma startup da web a partir daqui no departamento de hardware?

Answer 1

Uma configuração razoável que suporte uma aplicação web "média" pode evoluir da seguinte forma:

1. Servidor único de aplicativo/banco de dados combinado
2. Banco de dados separado em uma máquina diferente
3. Segundo servidor de aplicativos com round-robin DNS (balanceamento de carga do pobre) ou, por exemplo. Perlbal
4. Segundo, servidor de banco de dados replicado (para cargas de leitura, requer algumas alterações na lógica do aplicativo para que as leituras de banco de dados elegíveis vão para um escravo)

Neste ponto, avaliar a situação atual ajudaria a determinar um melhor caminho de expansão.Por exemplo, se a carga de leitura for alta e o conteúdo não mudar com muita frequência, talvez seja melhor enfatizar o cache e introduzir caches front-end dedicados, por exemplo. Lula para evitar leituras desnecessárias do banco de dados, embora você precise considerar como manter coerência de cache, normalmente no aplicativo.

Por outro lado, se o conteúdo mudar com razoável frequência, você provavelmente preferirá uma solução mais ampla;introduzir mais alguns servidores de aplicativos e escravos de banco de dados para ajudar a mitigar os efeitos e usar cache de objetos, como memcached para evitar atingir o banco de dados em busca de conteúdo menos volátil.

Para a maioria dos sites, isso provavelmente é suficiente, mas se você se tornar um fenômeno global, provavelmente desejará começar a considerar ter hardware em data centers regionais e usar truques como balanceamento de carga geográfica para direcionar os visitantes ao "cluster" mais próximo. ".Nesse ponto, você provavelmente estará em condições de contratar engenheiros que possam realmente ajustar as coisas.

Provavelmente, o conselho de dimensionamento mais valioso que posso imaginar seria evitar se preocupar com isso muito cedo;concentre-se no desenvolvimento de um serviço que as pessoas queiram usar e em tornar o aplicativo razoavelmente robusto.Algumas otimizações iniciais fáceis são garantir que o design do seu banco de dados seja bastante sólido e que os índices estejam configurados para que você não faça nada dolorosamente maluco;Além disso, certifique-se de que o aplicativo emita cabeçalhos de controle de cache que direcionam os navegadores sobre como armazenar os dados em cache.Fazer esse tipo de trabalho no início do design pode gerar benefícios posteriormente, especialmente quando você não precisar retrabalhar tudo para lidar com problemas de coerência do cache.

O segundo conselho mais valioso que quero dar é que você não deve presumir que o que funciona para outro site funcionará para você;verifique seus logs, execute algumas análises em seu tráfego e crie um perfil de seu aplicativo - veja onde estão seus gargalos e resolva-os.

Answer 2

muitos peixes Arquitetura

alguns vídeos interessantes:

Escalabilidade do Youtube

Entrevista com Dan Farino, arquiteto de sistemas do Myspace

Answer 3

Joel mencionou a adição de um segundo datacenter, com a mesma configuração, e a atribuição aleatória de usuários a cada um.As alterações nos dados são registradas e enviadas de um local para outro, para que ambos os locais contenham todos os dados.

Answer 4

A palestra Scalable Web Architectures Common Patterns & Approaches de Cal Henderson (Yahoo) na Web 2.0 Expo foi bastante interessante.Achei que havia um vídeo, mas não consegui encontrá-lo.Mas aqui estão os slides:

http://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches

Answer 5

Um próximo passo seria um cluster de servidores web (um web farm) e um sistema clusterizado de servidores de banco de dados (replicação ou Oracle RAC etc.etc.)

Answer 6

Se você estiver interessado em armazenar em cache e usar .Net, dê uma olhada no bloco de cache do aplicativo na biblioteca corporativa (é claro, use isso junto com os outros pontos acima).