Armadilhas mais comuns de escalabilidade de sites

Estamos projetando um site / aplicativo da Web em que esperamos obter altas contagens de usuários e, em geral, muito uso. Mais especificamente, pretendemos usar o PHP como a linguagem de programação / script e o MySQL para as necessidades de banco de dados relacional como um começo. Ainda não decidimos se devemos ou não usar um banco de dados NoSQL.

Relacionado a isso, queremos projetar com escalabilidade em mente. Quais são as armadilhas de escalabilidade mais comuns para sites? Quais são as principais áreas que precisamos levar em consideração, para que o sistema possa ser facilmente escalável?

Eu acrescentaria a isso uma coisa muito comum - otimizar no lugar errado. Eu já vi vários artigos que discutem diferenças de nanossegundos nas construções de sintaxe PHP, mas muito menos que discutem como projetar adequadamente a infraestrutura de cache para um aplicativo. Então, como já foi observado, teste. Mas não apenas teste - analise e descubra exatamente o queé lento - é ligado à CPU? E / S ligado? Memória ligada? São as consultas ao banco de dados que o prejudicam, é a leitura dos arquivos, os cálculos? Você pode eliminar ou refazê-lo para que funcione mais rápido? Etc. Não comece com "vamos usar o NoSQL porque é mais rápido". Comece com "queremos fazer isso e aquilo, quais seriam os gargalos? Como os eliminamos? Como se comportaria se obtivéssemos 100 usuários?" Sem saber mais sobre a carga de trabalho e o aplicativo, é difícil dizer algo concreto, mas eu começaria pensando no que você pode armazenar em cache e em como reduzir o sistema de arquivos / banco de dados / etc. acessos e principalmente modificações (uma vez que esses também invalidariam os caches).

A armadilha mais comum da escalabilidade não é fazer testes de carga desde o início. Se você configurar testes que simulam algo comparável à sua carga esperada no início do desenvolvimento, poderá detectar e corrigir quaisquer impedimentos tecnológicos ou arquitetônicos à escalabilidade antes que eles se tornem muito caros de corrigir.

Alguns bons exemplos de dimensionamento com PHP: Tumblr , Flickr , Netlog

O conselho comum dado sobre escalabilidade:

• Mantenha simples!
  Não faça engenharia excessiva nem adquira soluções sofisticadas específicas de fornecedores.
• Arquitetura de nada compartilhado
  Mantenha seu estado no banco de dados e fora dos servidores de aplicativos (evite até mesmo os dados da sessão no servidor). Dessa forma, você pode adicionar facilmente servidores de aplicativos adicionais, conforme necessário.
• Foco no cache do front-end (arquivo estático)
  Use um proxy reverso e, posteriormente, em uma CDN. Tudo o que não precisa ser veiculado no servidor de aplicativos é menos carregado nesse servidor.
• Avalie o sistema real
  Crie um monitoramento para saber onde estão seus gargalos. Assegure-se de prever a carga futura com base nas curvas de crescimento.
• Preste atenção ao seu design de banco de dados
  Ajuste suas consultas, use o memcached para evitar consultas e compartilhe seus dados entre instâncias quando você ficar sem espaço para respirar em uma instância de banco de dados (monitore para saber isso com antecedência).

Algumas armadilhas:

• NoSQL vs SQL é um arenque vermelho.
  Todos os grandes estão executando seu núcleo nos bancos de dados SQL. Use NoSQL se tiver certeza de que faz sentido, mas não use-o assumindo que resolverá seus problemas de dimensionamento. Não vai.
• Tenha cuidado com os ORMs.
  Eles são muito pesados ​​no servidor de aplicativos (contradiz a arquitetura de nada compartilhado) e exigem que você entenda não apenas como ajustar as consultas SQL, mas como ajustar o ORM sobre as consultas SQL (em outras palavras, eles apenas simplifique as coisas se o desempenho não for importante). Dê preferência a consultas projetadas à mão e use liberalmente o memcached.
• Sistemas pesados ​​de modelagem / roteamento no servidor. Mantenha a pilha do servidor deliberadamente leve.
• Não se preocupe com o desempenho do código linha por linha.
  Você sempre pode entrar e corrigir pontos ativos mais tarde (use xdebug ou ferramentas de criação de perfil semelhantes). Ter uma arquitetura escalável é muito mais importante que o desempenho do código; portanto, invista sua capacidade intelectual de acordo.

A única maneira real de saber se você tem problemas de escalabilidade é testá-lo; portanto, teste cedo, teste com frequência, como diz Michael Borgwardt .

Fora isso, uma razão comum pela qual os sistemas não são dimensionados é por causa da contenção de recursos. E isso geralmente aparece no banco de dados - tentando ler e escrever ao mesmo tempo. Portanto, convém pensar em usar uma abordagem CQRS que desconecte o lado de leitura (consulta) do lado de gravação (comando).

Esteja pronto para estilhaçar tudo. Se você puder particioná-lo em vários hosts, estará muito mais perto de criar algo que possa ser dimensionado.

Projete também para o caso de um milhão de usuários e reduza a escala. Não projete para 1.000 usuários e aumente a escala.

Honestamente, PHP e MySQL não seriam minha escolha. Tentar fazer dados fragmentados no MySQL é uma dor de cabeça.