Existem muitos métodos para dimensionar aplicativos da Web e a infraestrutura de suporte. Cal Henderson escreveu um bom livro sobre o assunto chamado "Construindo Web Sites Escaláveis". Foi baseado em suas experiências com o Flickr. A menos que você cresça lentamente, encontrará os mesmos tipos de problemas de crescimento que muitos outros já viram. O escalonamento é, como muitos outros assuntos, uma jornada e não um destino.
Os primeiros passos são para tornar tudo repetível, mensurável e gerenciável. Por repetitivo quero dizer usar ferramentas como FAI ou kickstart para instalar o sistema operacional e algo como fantoche ou cfengine para configurar as máquinas, uma vez que um sistema operacional básico é instalado. Por mensurável, quero dizer usar algo como cactos, críquete ou gânglios para monitorar o desempenho do seu cluster agora. Meça não apenas coisas como a média de carga, mas quanto tempo leva para processar uma página ou atender a uma solicitação. Nenhum deles parece crítico quando se inicia, mas deve avisá-lo antes que o sistema caia na carga e possa simplificar a adição de 10 ou cem máquinas de uma só vez. Baseie seus planos de crescimento em dados e não adivinha.
Gerenciável significa colocar as ferramentas no lugar para permitir que você gere e teste automaticamente a maior parte da configuração possível. Comece com o que você tem e cresça. Se você está armazenando informações da máquina em um banco de dados, ótimo. Se você não tiver uma planilha, pode exportar. Coloque sua configuração em algum tipo de controle de origem, se você não tiver já. A criação automática de configurações a partir do seu banco de dados permite que você cresça com menos estresse. Testá-los antes de serem ativados em seus servidores pode evitar que um serviço seja iniciado devido a erros de digitação ou outros erros.
Os métodos horizontais assumem que você pode repetir as coisas apropriadamente. Pense na sua aplicação. Quais áreas fazem sentido dividir? Quais áreas podem ser manipuladas por muitas máquinas em paralelo? A latência afeta seu aplicativo. Qual a probabilidade de você encontrar limites de conexão ou outros gargalos? Você está pedindo que seus servidores da Web também lidem com entrega de correio, banco de dados ou outras tarefas?
Eu trabalhei em ambientes com centenas de servidores web. As coisas devem ser divididas de maneira diferente para diferentes tipos de carga. Se você tiver grandes conjuntos de arquivos de dados que raramente mudam, particioná-los longe de "coisas" que mudam ativamente pode dar mais espaço para servir dados estáticos e dinâmicos. Diferentes ferramentas funcionam melhor para cargas diferentes. O Apache e o Lighttpd funcionam bem para algumas coisas, o Nginx funciona melhor para os outros.
Veja os proxies e caches. Tanto entre seus usuários quanto o aplicativo e entre partes do aplicativo. Eu li que você já está usando memcache, isso ajuda. Colocar um proxy reverso como perlbal ou pound entre seu balanceador de carga e os servidores da web pode fazer sentido dependendo do tráfego do seu aplicativo.
Em algum momento você pode descobrir que o MySQL master < - > (N * escravo) replicação não está mantendo-se e que você precisa particionar os bancos de dados. Particionar seus bancos de dados pode envolver a configuração de outra camada de gerenciamento de dados. Muitas pessoas usam outro banco de dados com memcache para esse gerenciamento. Em um lugar eu trabalhei nós usamos mestre < - > pares replicados mestre para a maioria dos dados e outro par com 10 escravos lidos para ponteiros para os dados.
Esta é apenas uma descrição básica de alguns dos problemas que enfrentei ao trabalhar em sites com centenas de máquinas. Não há fim de coisas que crescem de algumas máquinas para algumas centenas. Tenho certeza que o mesmo vale para o crescimento em milhares.