a arquitetura dos Servidores certa para uma grande aplicação no Facebook?

Question

Somos um grupo de 3 alunos, criamos um aplicativo do Facebook com mais de 753.320 usuários ativos no momento, aplicativo hospedado no servidor LAMP 1 e 1:

- AMD Opteron 1352 4 x 2,1 GHz
- 4 GB RAM.
- 2 x 750 Go (RAID 1 Hardware).
- Connection : 100 Mbps.

Esta aplicação funciona muito bem, sem qualquer problema.

Estamos preparando um novo aplicativo e esperamos milhões de usuários ativos depois de alguns meses.

Informações sobre o aplicativo:

• Criado com PHP / MySQL.
• Cada usuário pode executar no mínimo 25 consultas por uso.
• Sirva muitos arquivos estáticos (imagens, arquivos flash, css, js).
• Este aplicativo contém 8 seções, por exemplo, jogos, presentes etc ...

Queremos saber a arquitetura certa para esse servidor de aplicativos.

• Quantos servidores precisamos para hospedá-lo?

• Se hospedarmos arquivos php neste servidor:

  • Processador Intel® Core ™ i7-920 4x2.66 GHz
  • 12 GB de RAM

Servidor remoto MySQL e arquivos estáticos em cada servidor com a mesma configuração.

O aplicativo pode lidar com milhões de solicitações diariamente?

• Qual é a sua sugestão para este tipo de aplicações? Alguém pode me dizer detalhes da arquitetura sugerida?

Obrigado antecipadamente.

    

Answer 1

Em relação ao MySQL,

1. mysqltuner é obrigatório para qualquer caixa de produtos.
2. Log de consulta lenta vai te levar a um longo caminho para um aplicativo com melhor desempenho.
3. Se você ativar o registro Geral (BRIEFLY) pode ser uma boa coisa, então execute EXPLAIN em todas as suas consultas para certificar-se de que possui uma indexação adequada (sem cobertura, boa cardinalidade, etc.)
4. Você está mantendo a sessão no banco de dados? Não faça isso se você puder evitá-lo, mas se não, considere uma tabela MEMORY.
5. Durante o assunto dos tipos de tabela, considere o uso real de cada tabela. Tabelas transacionais com altas necessidades de leitura / gravação podem ser melhores no mecanismo de armazenamento InnoDB. Tabelas que são predominantemente write ou read podem ser melhor servidas como MyISAM. Você está registrando no banco de dados também? Considere o mecanismo ARCHIVE para essas tabelas.

Answer 2

Todas as respostas que você receber serão palpites loucos. Você realmente precisa fazer o teste de carga adequado do seu aplicativo, com dados realistas e padrões de uso durante todo o processo de hardware e software. Use os números do seu teste de carga para criar um plano de escalabilidade e estimativas de custo Nada escala de maneira perfeitamente linear, especialmente na camada de banco de dados, então há algumas adivinhações mesmo quando você tem números difíceis, e você pode atingir uma "parede" em um componente em particular (como o banco de dados). Comece com JMeter , que pode capturar sessões HTTP para gerar carga. As ferramentas comerciais são muito mais capazes, mas também são muito caras.

    

Answer 3

Sem saber exatamente o que você está fazendo, é impossível dar conselhos de ferro. No entanto, vou dizer isto:

Gaste algum tempo planejando escalar agora. Considere a virtualização, cujos benefícios são múltiplos.

Por não ter muito dinheiro, você pode alugar um pequeno grupo de VPSs do Slicehost, Linode, Rackspace Cloud, etc. Seis meses a partir de agora, quando você for bem-sucedido, poderá alugar / comprar seu próprio hardware, e executar sua própria virtualização, ou ficar com seu fornecedor, ou mover para servidores "reais", ou qualquer outra coisa. Mas se você acha que precisará de mais de um servidor, codifique seu aplicativo em uma configuração de cluster. Pelo custo da sua caixa dedicada, você pode executar 10 servidores "de brinquedo".

Ao aproveitar provedores de virtualização baratos agora, você pode garantir que sua arquitetura possa se expandir para fora.

Se você observar suas necessidades e decidir que um dia precisará executar bancos de dados mysql segmentados, poderá modelá-lo agora com VPSs de baixo custo.

Se você acha que vai querer algum número de balanceadores de carga na frente de um monte de caixas PHP, você pode fazer isso agora.

O mesmo vale para configurar alguns servidores / balanceadores para servir conteúdo estático (ou você pode usar a rota s3 / cloudfront).

Mas se você realmente está esperando muita carga e muito tráfego, é aconselhável quebrar as coisas agora, em vez de comprar a maior caixa dedicada possível e rezar para poder escalar mais tarde.

    

Answer 4

Eu diria que, com o tamanho de uma base de usuários, a parte mais importante da arquitetura é o armazenamento em cache e a capacidade de escalar facilmente sob demanda. Basta olhar para o Facebook e pensar sobre isso por um segundo, em 2009 eles tiveram um crescimento diário de dados de 12 TB! sim diariamente.