Quanto costerebbe il cloud hosting per un'applicazione di social media simile a Snapchat con 5 milioni di utenti?

È una domanda difficile a cui rispondere. Ma farò alcune ipotesi e cercherò di calcolarla per voi.

Come definiamo 5 milioni di utenti? Lo definisco come 5 milioni in totale. Ciò significa che non tutti saranno attivi. Ho un account Snapchat ma non lo uso da mesi. Quindi supponiamo 1 milione di utenti attivi ogni mese. Infine supponiamo che questi 1 milione di utenti inviino una media di 5 foto ogni 24 ore.

Il numero di utenti in realtà non è così importante. Ma il numero di richieste sì. Quindi facciamo un po' di conti:

1 milione di utenti X 5 foto al giorno X 30 giorni = 150 milioni di richieste al mese.

Quindi sono 5 milioni di richieste al giorno, sia per inviare che per ricevere una foto. E dato che siamo globali, supponiamo che la gente lo usi più o meno allo stesso modo tutto il giorno e la notte.

Altra matematica: 5 milioni di richieste / 24 ore / 60 minuti / 60 secondi = 57,8 richieste al secondo. In realtà non è male. Quindi abbiamo bisogno di una configurazione in cui possiamo gestire almeno 60 richieste al secondo.

Abbiamo bisogno di alcuni server di applicazioni, un database, un po' di archiviazione di file. Cerchiamo di essere prudenti e diciamo che abbiamo bisogno di 1 server di applicazioni più piccolo per 10 richieste al secondo. Quindi abbiamo bisogno di 6 server di applicazioni. Abbiamo bisogno di un bilanciatore di carico davanti ai server di applicazioni. Per il software, userei node.js, perché è buono per un sacco di richieste API più piccole.

Per il database abbiamo bisogno di un sistema che può ricevere molti dati, velocemente, e può memorizzare i meta dati che circondano le nostre immagini, come mittente e destinatario. Probabilmente andrei con couchdb, che è rinomato proprio per questo. A causa della natura distribuita di couchdb, abbiamo anche bisogno di un bilanciatore di carico davanti. Probabilmente dovremmo avere un numero approssimativo di 10 server. Sono circa 100GB di spazio per i metadati, che dovrebbero durarci un po'.

Ora per l'archiviazione delle foto, useremo un object storage. Diciamo che ogni foto ha una media di 50Kb. Quindi se il rapporto scrittura/lettura è di circa 1:20, allora ci sono 250.000 foto memorizzate al giorno, che a 50Kb equivalgono a circa 12GB di nuove foto al giorno o 360GB al mese. Qui si potrebbe considerare di non salvare le foto per più di 30 giorni, per rendere il calcolo più facile.

L'ultimo punto dell'equazione è il traffico. Quanto traffico useremo per le immagini avanti e indietro? 5.000.000 di immagini inviate o ricevute ogni giorno equivalgono a circa 238GB al giorno o poco meno di 7TB al mese di traffico.

Ok. È il momento. Facciamo i conti.

Farò i calcoli basandomi su DigitalOcean: Cloud computing progettato per gli sviluppatori, perché conosco i loro servizi. Hanno anche appena lanciato un Object Store per le nostre immagini. Iscrivendosi con quel link si ottengono 10 dollari per iniziare, ma ho paura che non andranno troppo lontano però... Tutti i prezzi sono mensili

• Managed front load balancer = $20
• 6 application server a $10 al mese (1gb ram) = $60
• Database load balancer usando HA Proxy = $10
• Database server 10 x $20 server = $200
• Stoccaggio foto ($5 primi 250GB e 110GB x $0.02/GB) = $7.2 (si davvero!)
• Il traffico è stato calcolato per essere di 7TB al mese ma i 6 server applicativi includono 2TB ciascuno, quindi siamo coperti fino a 14TB e il traffico interno è gratuito, quindi prezzo = $0

Quindi diciamo 20+60+10+200+7.2+0 = $297.2 al mese.

-----

Modifica: dopo aver chiarito con DigitalOcean per i dettagli, il loro nuovo oggetto memorizza il traffico in uscita non è gratuito come il resto del traffico interno. Quindi questo aggiunge 144 dollari al mese all'importo di cui sopra.

-----

Può essere vero? Beh sì e no. È un po' semplificato. Potremmo aver bisogno di più application server, per tenere conto delle sessioni leggermente più lunghe a causa della dimensione della risposta (l'immagine), potrebbe alterare il calcolo se cambiamo il modello per ottenere 10 immagini alla volta, invece di una sola.

Una cosa su cui non ci siamo soffermati è come l'utente viene informato delle nuove immagini. Qui si presume che succeda e basta, come per esempio usando i messaggi push dove apple e google forniscono l'infrastruttura. Ma se vogliamo fare aggiornamenti dal vivo, con un socket, abbiamo bisogno di server anche per questo.

Questa è la configurazione di produzione. Ma abbiamo anche bisogno di una configurazione di test e di una configurazione per gli sviluppatori. Anche se non è così grande, aumenta il conto. Non dimenticare i backup!

Potresti voler aggiungere altri componenti come una cache o un CDN per le immagini. Potresti voler aggiungere una coda per ricevere le immagini che devono essere ridimensionate se l'applicazione non lo fa per te, ecc.

Potresti voler distribuire l'applicazione in centri dati in tutto il mondo, il che naturalmente si aggiunge al conto, ma è anche più complesso da calcolare per ora.

Per completezza, ho fatto lo stesso calcolo per Amazon Web Services che è venuto a 1147,57 dollari al mese. Sì, davvero. Corrisponde all'incirca alla stessa dimensione di un server standard. Questo non include i costi EBS per i server con supporto EBS, anche se DigitalOcean ha un minimo di 20GB di dischi ciascuno.
Calcolo precompilato qui: Amazon Web Services Simple Monthly Calculator.

Spero che questo piccolo pezzo di lettura leggera vi abbia dato qualche idea su come calcolare il costo della vostra soluzione specifica.