Desenvolva-o no EC2. Se / quando você quiser movê-lo internamente, configure seu próprio cluster Eucalyptus e mova-o para lá, o que será fácil, já que O eucalipto é um clone de infraestrutura EC2 de código aberto.
Recebi a tarefa de descobrir como fazer uma implantação em grande escala para um aplicativo da Web baseado em flash de alta disponibilidade, tráfego intenso e dinâmico. Existe uma boa possibilidade de que este aplicativo possa crescer para 2 milhões de usuários ou possivelmente muito mais.
É claro que quando chegar a hora de fazer isso, provavelmente trarei um especialista para me ajudar. Por enquanto, isso é tudo teórico, e eu só queria ter uma boa idéia sobre como fazer isso.
Aqui está meu pensamento atual:
Meu trabalho é principalmente descobrir o hardware e como implantá-lo e mantê-lo.
Quanto a manter essa fera, estou olhando para o Slack, Rightscale, Landscape, VMware.
Eu também estou pensando em apenas implementá-lo no Amazon EC2, mas eu prefiro que eu mesmo faça o rack, pois parece que seria muito mais barato a longo prazo. Eu posso começar com este rack e adicionar instâncias EC2, se mais for necessário.
O que você acha, isso é exagero? Insuficiente? Eu já entendi, e há algo que eu esteja perdendo?
Obrigado a quem lê e responde!
Desenvolva-o no EC2. Se / quando você quiser movê-lo internamente, configure seu próprio cluster Eucalyptus e mova-o para lá, o que será fácil, já que O eucalipto é um clone de infraestrutura EC2 de código aberto.
Pelo que li em Alta escalabilidade, sua melhor estratégia é simplesmente trabalhar nos gargalos atuais e começar a planejar os próximos gargalos. A menos que você esteja usando exatamente o mesmo software e hardware que alguém já usou, e a menos que os padrões de uso sejam idênticos à medida que você escala, não é possível planejar todo o seu crescimento agora. Você precisa planejar a fase atual e a próxima, não a marca de 2 milhões de usuários.
Acho que você superestimou seriamente suas exigências. Como ponto de referência, um primário / primário de 2 ipvs na frente de um par de xeons quadcore duplos rodando nginx + tornado processa adblocks de iframe de 286 milhões a 2400 bytes + registro completo de adstream para os 7 elementos dentro do iframe. A utilização de cada um é de < 40% (permitindo que um único nó falhe sem 'sobrecarga')
O segundo problema que você diz é dinâmico "baseado em flash", o que significa que a maioria de sua largura de banda servirá para o aplicativo flash inicial - um candidato a um CDN ou cache.
É provável que seu aplicativo flash dinâmico tenha pequenas mensagens enviadas de um lado para o outro usando gevent ou alguma tecnologia semelhante. Essas mensagens provavelmente são pequenas. Sua inteligência de aplicativos provavelmente terá que analisar, registrar e responder a eles, mas, 2 milhões de usuários por dia, 80 interações cada, são 160 milhões de interações. Nos horários de pico, você provavelmente teria que lidar com 3600tps. Se você precisar de 300 servidores para lidar com isso, precisará reescrever seu código.
Virtualizar seus servidores da Web como mencionado acima é provavelmente um desperdício de desempenho. Mesmo a virtualização de peso mais leve não será executada tão rapidamente quanto o ferro nu.
No entanto, sem conhecer sua arquitetura ou projeto de sistema, qualquer opinião dada é um trabalho de adivinhação, dados os requisitos vagamente definidos.
Por que você colocaria seus servidores da Web em um ambiente VM? Isso só faz com que a sobrecarga que você não precisa, todos eles devem servir dados do mesmo armazenamento e ter configuração idêntica.
Eu posso responder pelo tamanho dos servidores haproxy. Use um kernel recente do Linux (> = 2.6.27) para se beneficiar do recurso de emenda TCP que economizará muito CPU em alta largura de banda. Use a frequência mais alta que você pode encontrar para a CPU. Não há necessidade de muitos núcleos, melhor encontrar um dual-core de 3,6 GHz do que um de 8 GHz de 2 GHz. Para a RAM, conte 1 GB por 20k de conexões simultâneas. Use dois VIPs para os LBs (ativos / ativos) gerenciados pelo daemon keepalived e anuncie-os no seu DNS. Dessa forma, seus dois LBs funcionarão ao mesmo tempo e, se um deles falhar, o outro assumirá seu IP. Um site muito grande que eu conheço roda mais de 300k conexões simultâneas em apenas dois LBs devidamente sintonizados com bastante margem de lucro.
Não subestime as placas de rede. A menor latência de algumas placas de rede, como as Myri10GE NICs da Myricom, em comparação com outras soluções (1 ou 10 GbE), pode trazer uma economia considerável no custo de processamento de pacotes e no número de conexões simultâneas nos servidores.
Em relação aos servidores apache, o haproxy pode concentrar as conexões de entrada em menos saída, reduzindo assim o número de servidores e protegendo-os dos surtos de tráfego. No entanto, isso é útil para conexões curtas. Não confie nisso para solicitações de pesquisa longa, bate-papo ou uploads / downloads de arquivos grandes.
Dê uma olhada no systemimager
No que diz respeito à leitura deste tópico, eu recomendo Scalable Internet Architectures de Theo Schlossnagle. Abrange implantações de HA e escalabilidade horizontal em detalhes bastante exaustivos.
Além disso, Web sites de alto desempenho e Arquiteturas de aplicativos em nuvem podem valer a pena dar uma olhada, mas o último pode estar um pouco desatualizado.