Quando iniziare a pensare alla scalabilità? [chiuso]

In realtà è una scelta abbastanza semplice.

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.

Al momento, non hai un problema di scalabilità; hai un problema con il numero di utenti. Se lavori sul problema della scalabilità, non risolvi 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à inutile.

Se lavori sul problema del numero degli utenti, risolvi un problema che hai adesso, e allora puoi concentrarti sul prossimo problema, che potrebbe essere la scalabilità.

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

Ovviamente aiuta a tenere a mente la scalabilità mentre scrive il codice di cui hai bisogno in questo momento, ma non ha molto senso spendere dozzine o anche centinaia di ore di lavoro su una funzione di cui non hai sapere se ne avrai mai bisogno, e lo scenario più probabile è che non lo farai. In questo momento, la tua principale preoccupazione è spedire. Cosa succede dopo; beh, puoi preoccupartene più tardi.

Non c'è motivo di ottimizzare finché non si è a conoscenza dell'ottimizzazione. Come sai che è necessaria l'ottimizzazione? Misura.

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 a stressare il tuo back-end. Dovresti essere in grado di imparare abbastanza da sapere quali sono i limiti del tuo sistema. Puoi quindi combinare tali informazioni con il numero di utenti che hai e il numero medio in esecuzione in una sola volta, per decidere quando scalare.

TL; DR dovresti pensare alla scalabilità prima che venga scritta la prima riga di codice.

Per prima cosa. Scalabilità! = Ottimizzazione

Dovresti pensare alla scalabilità prima che venga scritta la prima riga di codice. Questo non significa che tu costruisca un'infrastruttura massiccia nella remota possibilità che il tuo gioco possa essere un successo. Pensare alla scalabilità significa:

• Assicurati che il codice sia scritto in modo da ridimensionarlo. Ho visto molti progetti in cui non è stato preso in considerazione il bisogno di ridimensionare. I risultati sono una base di codice che non si ridimensionerà a prescindere dall'hardware che si butta su di esso, o è eccessivamente costoso da scalare.
• Scopri la strategia di ridimensionamento. Avere un piano su come supportare tutti gli utenti. Hai un db MySQL, stai per dividerlo o un cluster, o qualcos'altro. Strategie come il sharding richiedono un po 'di accortezza perché pone requisiti sull'architettura. Clustering, meno così. Stai sostenendo le sessioni e in che modo le sessioni reagiranno con più server front-end. Avrai bisogno di sessioni appiccicose, nel tuo sistema di bilanciamento del carico.
• Scopri la strategia di implementazione. Utilizzerai AWS per il ridimensionamento. Puoi sfruttare tutti i prodotti o servizi che ti offrono scalabilità dinamica fuori dagli schemi? Ciò implica 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 a ridimensionare allora hai fatto la parte difficile. Puoi ottenere un account AWS, avviare i server in base alle esigenze e allontanarti.

Se il tuo codice non è scalabile o presenta colli di bottiglia , allora hai del lavoro da fare. Devi identificare quali sono i tuoi colli di bottiglia e correggerli. Il "quando" è davvero difficile da sapere. Alcuni servizi si stabilizzano, alcuni aumentano costantemente e alcuni esplodono. Decidere quando lanciare risorse su qualcosa come il ridimensionamento è di solito una funzione del business e la valutazione dei rischi.

Nella tua posizione , potrei rilasciarmi come una "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à.

In primo luogo, si dovrebbe riflettere con attenzione 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 che ti servono per la seconda volta.

La seconda volta che si prende in considerazione la scalabilità è sufficiente per far sì che le cose diventino inaccettabilmente lente. Ciò significa che devi sapere cosa significa "troppo lento" e come reagisce la tua cosa sotto carico. Se hai un servizio il cui driver (probabilmente qps) aumenta del N% al mese, hai tempi piuttosto diversi da "il 95% delle risorse della macchina consumate" se l'utilizzo delle risorse è carico-quadrato o lineare nel carico.

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

Senza conoscere le specifiche, ci vorrebbe uno o due giorni per pensare a dove si hanno i problemi di ridimensionamento e quali strategie possibili si hanno per risolverli. Ma questo è importante, Pensa. Non farlo, pensa (e documenta). A meno che tu non abbia problemi di scalabilità che iniziano a manifestarsi a poche centinaia di utenti, dovresti avere il tempo di controllare il caricamento e generare più risorse di back-end.

Dalla tua descrizione sembra che ci siano due possibili risultati:

• Il gioco è un fallimento e quindi non ti interessa.
• Il gioco ha successo e il tuo back-end 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 attuale back-end con prestazioni accettabili?
• Hai una sorta di piano per limitare l'impatto agli utenti attuali se stai vedendo una sorta di rapida crescita (ad esempio, puoi ritirare temporaneamente il gioco dall'app store)
• Quanto velocemente riesci a trovare 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 che li consideri. 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 dell'utente in modo molto profondo. Una cattiva latenza comporta sempre un'esperienza utente negativa.

Effettua almeno alcuni test di carico ad hoc come descritto da Bryan.

Un approccio più serio

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

Quindi arriva il primo passo verso l'ottimizzazione. Decidi uno SLA per il tuo server: ad es. nel peggiore dei casi il 10% chiama con fastidiosa latenza e l'1% chiama con latenza inutilizzabile. Con questi limiti puoi utilizzare il test del carico per scoprire quanti utenti il tuo server può supportare.

I test di throughput puro senza misurare la latenza (o almeno manualmente utilizzando il server durante il test di caricamento) non sono così utili perché non ti dicono se i numeri di throughput misurati risultano in un'esperienza utente accettabile.

Una presentazione molto bella sulla misurazione della latenza di Gil Tene: link

Alla fase dei requisiti aziendali, che viene poi utilizzata per stabilire una comprensione comune delle prestazioni per tutti gli elementi a valle quali architettura, operazioni, sviluppo, controllo della qualità e monitoraggio in prod. Se non stabilisci una comprensione comune di ciò che è necessario in anticipo, allora avrai ciascuna delle parti dell'organizzazione che fa ipotesi sulle prestazioni (o non le penserà affatto) quando si impegnano in particolari compiti lungo il ciclo di vita del applicazione. Questo è vero se sei impegnato in cascata, cascata corta, agile o qualsiasi altra cosa la metodologia di sviluppo del momento è calda nell'elenco delle parole chiave di ripresa.

Le prestazioni e la scalabilità sono difficili. La funzionalità è semplice. Il codice di ridimensionamento scadente aumenterà fino a riempire qualsiasi pool di risorse fornito, quindi spostare la bolla dei costi acquistando un hardware più grande ti porta solo lontano prima di dover correggere il codice inefficiente o acquistare sempre più hardware. Lasciare che ciò duri in priorità è anche molto costoso. Ci sono decisioni di architettura e design che vengono fatte nelle prime fasi del ciclo di vita dell'applicazione che potrebbe dover essere completamente invertita al fine di raggiungere un requisito in ritardo relativo alle prestazioni. Pensare a un produttore di auto sportive ad alte prestazioni che deve passare dall'alluminio a fibra di carbonio in ritardo nel ciclo di progettazione per colpire un rapporto potenza / peso correlato alle prestazioni e come questo influisce sull'attrezzatura, sull'allenamento, sulla costruzione dell'auto, ecc ...

Chiedi agli architetti, agli sviluppatori e ai responsabili della tua organizzazione quali sono i requisiti di prestazione per l'applicazione. Se questi non vengono catturati dall'azienda, non sorprenderti se ricevi risposte diverse (o nessuna risposta) da individui diversi anche all'interno dello stesso gruppo. Quelle "ipotesi" tornano sempre a schiaffeggiare l'organizzazione nella distribuzione.