A escalabilidade se estende além da camada de hardware e também na camada de aplicativos. A capacidade de um ambiente crescer para bigbigots depende em grande parte da capacidade do software em cada camada de lidar com falhas e manter um estado coerente em todo o ambiente. Se o banco de dados que comanda todo o seu ambiente não puder ser fragmentado, você terá introduzido um limitador de escalabilidade usando esse banco de dados. Esse tipo de coisa.
A Amazon tem alguns white papers sobre desenvolvimento para a nuvem, e vários deles são geralmente aplicáveis a qualquer infraestrutura escalável.
Existem alguns princípios de alto nível que você precisa ter em mente ao dimensionar:
- Deve sobreviver à falha de qualquer componente único e fazê-lo sem intervenção humana.
- Deve responder dinamicamente a cargas elevadas, sem intervenção humana.
Não use apenas um balanceador de carga, use um trio de balanceadores de carga que apresentam como um único LB, de modo que, se algum deles falhar, os outros possam pegar a carga.
Os servidores da Web / de aplicativos devem ter o estado do usuário disponível em todos os nós, portanto, se um usuário for enviado para outro servidor da Web / aplicativo, sua sessão será preservada. Melhor caso, todo estado pode ser servido de todos os servidores.
Deve haver roteadores redundantes em sua rede, para que você possa desativar um deles sem interromper todo o tráfego. O HSRP é um protocolo para permitir isso.
O plano do seu banco de dados deve incluir o quanto você dimensionará o único servidor de banco de dados antes de começar a fragmentar e iniciar o desenvolvimento com o sharding em mente quando chegar perto desse ponto.
As camadas de cache (memcached) podem ser necessárias em seu ambiente por motivos de desempenho.
Quando você ficar grande o suficiente, precisará planejar como hospedará seu ambiente a partir de vários locais separados (como Oeste dos EUA e Leste dos EUA ou Oeste dos EUA e Europa) via Anycast ou GeoIP. Mover dados entre locais separados será um desafio, e você precisa começar a desenvolver essa suposição assim que chegar perto de precisar de locais separados.
O Ruby em si tem alguns problemas de dimensionamento, concentrando-se em sua capacidade (ou não) de aproveitar vários processadores em servidores. As capacidades estão lá, mas novas, não tão bem compreendidas na comunidade de desenvolvimento (ou assim eu entendo). Quando o Ruby amadurecer, alguns desses problemas desaparecerão.