Quando iniziare a pensare alla scalabilità? [chiuso]

Sto avendo un problema divertente ma anche terribile. Sto per lanciare una nuova app (iPhone). È un gioco multiplayer a turni in esecuzione sul mio backend personalizzato. Ma ho paura di lanciare.

Per qualche ragione, penso che potrebbe diventare qualcosa di grande e che la sua popolarità ucciderà il mio povero server solitario + database MySQL.

Da un lato sto pensando che se sta crescendo, è meglio essere preparati e avere già un'infrastruttura scalabile.

D'altra parte, ho solo voglia di farlo uscire nel mondo e vedere cosa succede.

Leggo spesso cose come "l'ottimizzazione prematura è la radice di tutti i mali" o persone che dicono che dovresti semplicemente costruire il tuo gioco assassino ora, con gli strumenti a portata di mano, e preoccuparmi di altre cose come la scalabilità in seguito.

Mi piacerebbe sentire alcune opinioni su questo da esperti o persone con esperienza in questo. Grazie!

In realtà è una scelta abbastanza facile.

Al momento, hai zero utenti e la scalabilità non è un problema.

Idealmente, vuoi raggiungere il punto in cui hai milioni di utenti e la scalabilità diventa un problema.

In questo momento, non hai un problema di scalabilità; hai un problema relativo al numero di utenti. Se lavori sul problema della scalabilità, non risolverai il problema del numero di utenti, il che significa che avrai risolto un problema che non hai ancora e non avrai risolto il problema che hai. Il risultato più probabile è che il tuo prodotto non ce la farà e tutto il tuo lavoro sarà per niente.

Se lavori sul problema del numero di utenti, risolverai un problema che hai in questo momento e quindi puoi concentrarti sul problema successivo, che potrebbe essere la scalabilità.

La cosa bella dei problemi di scalabilità è che, per definizione, averli di solito significa che gli affari sono dannatamente buoni, e questo a sua volta significa che puoi permetterti di spendere soldi per ottimizzare la scalabilità. Non passi da zero utenti a dieci milioni durante la notte e se tieni d'occhio le prestazioni del sistema, avrai un sacco di tempo per ottimizzare quando sarà il momento.

Naturalmente aiuta a tenere a mente la scalabilità mentre si scrive il codice di cui hai bisogno in questo momento, ma non ha molto senso spendere dozzine o addirittura centinaia di ore-uomo su una funzionalità di cui non sai se Ne avremo mai bisogno, e lo scenario più probabile è che non lo farai. In questo momento, la tua preoccupazione principale è spedire. Cosa succede dopo? bene, puoi preoccupartene più tardi.

Non c'è motivo di ottimizzare fino a quando non si conosce l'ottimizzazione necessaria. Come fai a sapere che è necessaria l'ottimizzazione? Tu misuri.

Supponendo che il tuo server abbia una sorta di interfaccia basata sul web, puoi simulare molti utenti usando strumenti come Apache JMeter . Scopri come utilizzare lo strumento, quindi inizia lo stress test del back-end. Dovresti essere in grado di imparare abbastanza per sapere quali sono i limiti del tuo sistema. È quindi possibile combinare tali informazioni con il numero di utenti che hai e il numero medio che sono in esecuzione contemporaneamente, per decidere quando ridimensionare.

TL; DR Dovresti pensare alla scalabilità prima di scrivere la prima riga di codice.

Cominciando dall'inizio. Scalabilità! = Ottimizzazione

Dovresti pensare alla scalabilità prima di scrivere la prima riga di codice. Questo non significa che hai creato un'infrastruttura enorme nel caso in cui il tuo gioco potesse essere un successo. Pensare alla scalabilità significa:

• Assicurarsi che il codice sia scritto in modo che si ridimensioni. Ho visto molti progetti in cui non si pensava che fosse necessario ridimensionarli. I risultati sono una base di codice che non si ridimensionerà a prescindere dall'hardware che ci si lancia o è proibizionalmente costoso da ridimensionare.
• Scopri la tua strategia di ridimensionamento. Avere un piano su come supportare tutti gli utenti. Hai un db MySQL, hai intenzione di condividerlo o cluster, o qualcos'altro. Strategie come lo sharding richiedono alcune riflessioni perché impongono requisiti sull'architettura. Clustering, meno. Stai supportando le sessioni e come reagiranno le sessioni con più server front-end. Avrai bisogno di sessioni appiccicose, nel tuo bilanciamento del carico.
• Capire la strategia di attuazione. Utilizzerai AWS per il ridimensionamento. Puoi sfruttare qualsiasi prodotto o servizio che ti offra un ridimensionamento dinamico immediato? Ciò comporta anche la comprensione dei costi.

MA sembra che tu abbia già una base di codice. La domanda ora è quando iniziare il ridimensionamento. Questo dipende completamente dal tuo codice.

Se il tuo codice si presta al ridimensionamento, allora hai fatto la parte difficile. Puoi ottenere un account AWS, girare i server in base alle esigenze e via.

Se il tuo codice non si ridimensiona o presenta colli di bottiglia, allora devi lavorare. Devi identificare quali sono i tuoi colli di bottiglia e risolverli. Il "quando" è davvero difficile da sapere. Alcuni altopiani dei servizi, alcuni aumentano costantemente e altri esplodono. Decidere quando lanciare risorse su qualcosa come il ridimensionamento di solito è una funzione del business ed è la valutazione dei rischi.

Nella tua posizione , potrei rilasciarlo come "beta" e gestire le aspettative degli utenti. In questo modo posso ottenere il prodotto e vedere come si svolge.

Quindi, ci sono due volte che dovresti pensare alla scalabilità.

Innanzitutto, dovrebbe essere meditato attentamente prima di scrivere una singola riga di codice. Questo per assicurarti di non scrivere te stesso in un buco di scalabilità e per assicurarti che il tuo codice sia strumentato per darti le misure necessarie per la seconda volta.

La seconda volta che si considera la scalabilità è abbastanza in anticipo che le cose diventano inaccettabilmente lente. Ciò significa che devi sapere cosa significa "troppo lento" e come reagisce sotto carico. Se si dispone di un servizio il cui driver (probabilmente qps) aumenta di N% al mese, si hanno tempi piuttosto diversi dal "95% delle risorse della macchina consumate" se l'utilizzo delle risorse è al quadrato o carico lineare.

Con un gioco a turni, dovresti avere un discreto margine di sicurezza (probabilmente non hai un solo mondo di gioco, e se lo fai, probabilmente c'è una geometria interna, il che significa che non hai "tutti interagiscono con tutti ciascuno girare "problemi).

Senza conoscere i dettagli, impiegherei uno o due giorni a pensare a dove hai problemi di ridimensionamento e quali possibili strategie hai per risolverli. Ma questo è importante, Pensaci. Non farlo, basta pensare (e documentare). A meno che tu non abbia problemi di scalabilità che iniziano a manifestarsi a poche centinaia di utenti, dovresti quindi avere il tempo di controllare il carico e far girare più risorse di back-end.

Dalla tua descrizione sembra che ci siano due possibili esiti:

• Il gioco è un fallimento e quindi non ti interessa.
• Il gioco ha successo e quindi il tuo backend non sarà in grado di gestire il carico e il risultato sarebbe un fallimento.

Hmmm.

Ecco alcune domande da porsi:

• Quanti utenti può gestire il tuo back-end attuale con prestazioni accettabili?
• Hai una sorta di piano per limitare l'impatto per gli utenti attuali se stai vedendo una sorta di rapida crescita (ad esempio, estrarre temporaneamente il gioco dall'App Store)
• In quanto tempo puoi creare un backend migliore se hai successo?
• Quali sono le implicazioni commerciali dell'attesa. Puoi nutrirti? Quali sono i rischi?
• Quali sono le implicazioni commerciali del rilascio ora date le risposte alla domanda sopra.

La risposta alla tua domanda dovrebbe diventare evidente una volta considerate queste. Nessun esperto può dirti cosa fare senza ulteriori informazioni poiché ogni sistema è diverso e ogni azienda è diversa.

Il tuo server verrà utilizzato in modo interattivo dagli utenti. Ciò significa che la latenza sta influenzando l'esperienza utente in modo molto profondo. Una cattiva latenza comporta sempre una cattiva esperienza utente.

Almeno fare alcuni test di carico ad hoc come descritto da Bryan.

Un approccio più serio

Esegui alcune sessioni di simulazione e scopri quale latenza fa la tua esperienza utente (utilizzando una simulazione del ritardo di rete o semplicemente sleep () all'interno dell'applicazione). Scopri a quale latenza sta diventando evidente, fastidioso e inutilizzabile.

Poi arriva il primo passo nella direzione dell'ottimizzazione. Decidi uno SLA per il tuo server: ad es. Nel peggiore dei casi il 10% delle chiamate con fastidiosa latenza e l'1% delle chiamate con latenza inutilizzabile. Con questi limiti è possibile utilizzare il test di carico per scoprire quanti utenti possono supportare il server.

Il puro test della velocità effettiva senza misurare la latenza (o almeno usando manualmente il server durante il test di carico) non è così utile perché non indica se i numeri della velocità effettiva misurata comportano un'esperienza utente sopportabile.

Una presentazione molto bella sulla misurazione della latenza di Gil Tene: http://www.infoq.com/presentations/latency-pitfalls

Nella fase dei requisiti aziendali, che viene quindi utilizzata per stabilire una comprensione comune delle prestazioni per tutti gli elementi a valle come architettura, operazioni, sviluppo, controllo qualità e monitoraggio in prod. Se non si stabilisce una comprensione comune per ciò che è richiesto in anticipo, ciascuna parte dell'organizzazione farà ipotesi sulle prestazioni (o non ci penserà affatto) quando si impegnano in compiti specifici durante il ciclo di vita del applicazione. Questo è vero se sei impegnato in cascata, cascata corta, agile o qualunque sia la metodologia di sviluppo del momento è calda nell'elenco delle parole chiave riprendi.

Le prestazioni e la scalabilità sono difficili. La funzionalità è semplice. Lo scarso codice di ridimensionamento crescerà per riempire qualsiasi pool di risorse che gli fornisci, quindi spostare la bolla dei costi acquistando hardware più grande ti porta solo molto prima che tu debba riparare il codice inefficiente o acquistare sempre più hardware. Lasciare questo per durare in via prioritaria è anche molto costoso. Esistono decisioni sull'architettura e sul design che vengono prese all'inizio del ciclo di vita dell'applicazione che potrebbero dover essere completamente invertite per soddisfare un requisito di arrivo in ritardo relativo alle prestazioni - Pensa a un produttore di auto sportive ad alte prestazioni che deve passare dall'alluminio al fibra di carbonio alla fine del ciclo di progettazione per raggiungere un rapporto peso / potenza correlato alle prestazioni e al modo in cui ciò influisce su attrezzature, addestramento, costruzione dell'auto, ecc ...

Chiedi agli architetti, agli sviluppatori e agli addetti all'attività nella tua organizzazione quali sono i requisiti di prestazione per l'applicazione. Se questi non vengono acquisiti dall'azienda, non sorprenderti se ricevi risposte diverse (o nessuna risposta) da persone diverse anche all'interno dello stesso gruppo. Quei "presupposti" tornano sempre a colpire l'organizzazione nella distribuzione.