Quanto custaria o alojamento em nuvem para um aplicativo de mídia social Snapchat com 5 milhões de usuários?

É uma pergunta difícil de responder. Mas eu vou fazer algumas suposições e tentar calcular para você.

Como definimos 5 milhões de usuários? Vou defini-lo como 5 milhões no total. Isso significa que nem todos estarão ativos. Eu tenho uma conta snapchat, mas não a uso há meses. Então vamos assumir que 1 milhão de usuários ativos a cada mês. Finalmente vamos assumir que esses 1 milhão de usuários enviam uma média de 5 fotos por 24 horas.

O número de usuários na verdade não importa tanto. Mas o número de pedidos importa. Então vamos fazer algumas contas:

1 milhão de usuários X 5 fotos diárias X 30 dias = 150 milhões de pedidos por mês.

Então são 5 milhões de pedidos por dia, seja enviando ou recebendo uma foto. E como somos globais, vamos assumir que as pessoas a usam mais ou menos igualmente todo o dia e toda a noite.

Mais matemática: 5 milhões de pedidos / 24 horas / 60 minutos / 60 segundos = 57.8 pedidos por segundo. Isso na verdade não é muito mau. Então precisamos de uma configuração onde possamos tratar pelo menos 60 pedidos por segundo.

Precisamos de alguns servidores de aplicações, uma base de dados, algum armazenamento de ficheiros. Vamos ser conservadores e dizer que precisamos de 1 servidor de aplicação menor por 10 requisições/segundo. Então precisamos de 6 servidores de aplicação. Precisamos de um balanceador de carga em frente aos servidores de aplicação. Para software, eu usaria o node.js, porque ele é bom para muitos pedidos API menores.

Para banco de dados precisamos de um sistema que possa receber muitos dados, rápido, e possa armazenar os meta dados em torno de nossas imagens, como o remetente e o receptor. Eu provavelmente iria com couchdb, que é conhecido exatamente por isso. Devido à natureza distribuída do couchdb, também precisamos de um equilibrador de carga na frente. Provavelmente deveríamos ter um número aproximado de 10 servidores. É cerca de 100GB de espaço para metadados, que deve durar um pouco.

Agora para armazenamento de fotos, vamos usar um armazenamento de objetos. Digamos que cada imagem tem uma média de 50Kb. Então se a relação escrita para leitura é de cerca de 1:20, então são 250.000 fotos armazenadas por dia, o que a 50Kb equivale a cerca de 12GB de novas fotos por dia ou 360GB por mês. Aqui você pode considerar não salvar fotos por mais de 30 dias, para facilitar o grande cálculo.

O último ponto da equação é o tráfego. Quanto tráfego usaremos para as fotos para frente e para trás? 5.000.000 fotos enviadas ou recebidas diariamente somam cerca de 238GB por dia ou pouco menos de 7TB por mês de tráfego.

Ok. Está na hora. Vamos lá a fazer os números.

Faço os cálculos com base no DigitalOcean: Computação em nuvem concebida para desenvolvedores, porque eu conheço os seus serviços. Eles também acabaram de lançar uma loja de objetos para as nossas fotos. Inscrevendo-se com esse link você ganha $10 para começar, mas temo que eles não vão muito longe... Todos os preços são mensais

>ul>li>balanceador de carga frontal gerenciado = $206 servidores de aplicação a $10 por mês (1gb ram) = $60>li>balanceador de carga de banco de dados usando HA Proxy = $10Servidores de banco de dados 10 x $20 servidores = $200>li>Armazenamento de fotos ($5 primeiros 250GB e 110GB x $0.02/GB) = $7.2 (sim realmente!)Traffic foi calculado para ser 7TB por mês mas os 6 servidores de aplicação incluem 2TB cada um, então estamos cobertos até 14TB e o tráfego interno é grátis, então o preço = $0

Então dizemos 20+60+10+200+7.2+0 = $297,2 por mês.

-----

Editar: depois de esclarecer com DigitalOcean para detalhes, seu novo objeto armazena o tráfego de saída não é livre como o resto do tráfego interno. Então isso adiciona $144 por mês ao valor acima.

-----

P>Pode isso ser verdade? Bem, sim e não. É um pouco simplificado. Podemos precisar de mais servidores de aplicação, para contabilizar as sessões um pouco mais longas por causa do tamanho da resposta (a imagem), pode distorcer o cálculo se alterarmos o padrão para obter 10 imagens de cada vez, em vez da única.

Uma coisa em que não nos demos conta é como o utilizador é notificado de novas imagens. Aqui assume-se que isso apenas acontece, como por exemplo usando mensagens push onde apple e google fornecem a infra-estrutura. Mas se quisermos fazer atualizações ao vivo, com um socket, precisamos de servidores para isso também.

Esta é a configuração de produção. Mas também precisamos de uma configuração de teste e uma configuração para desenvolvedores. Apesar de não ser tão grande, ele adiciona à conta. Não se esqueça dos backups!

Você pode querer adicionar outros componentes como um cache ou um CDN para imagens. Você pode querer adicionar uma fila para receber imagens que precisam ser redimensionadas se o aplicativo não fizer isso para você, etc.

Você pode querer distribuir o aplicativo em centros de dados em todo o mundo que, é claro, adiciona à conta, mas também é mais complexo de calcular por enquanto.

Por uma questão de integridade, eu fiz o mesmo cálculo para Amazon Web Services que chegou a $1147,57 por mês. Sim, realmente. Mapeando aproximadamente para o mesmo tamanho de servidor padrão. Isso não inclui os custos de EBS para servidores com suporte a EBS, mesmo que a DigitalOcean tenha no mínimo 20GB de discos cada.
Cálculo pré-preenchido aqui: Amazon Web Services Simple Monthly Calculator.

Então espero que esta pequena leitura leve lhe tenha dado algumas idéias de como calcular o custo de sua solução específica.