Test di carico e di tenuta prolungata prima del lancio di una piattaforma da casinò

Una data di lancio è un piano di traffico, non un fatto di traffico. Un titolo nuovo, un jackpot accumulato, una partita a eliminazione o una campagna cambiano quanti giocatori arrivano e con quale velocità; e se la piattaforma assorba quel cambiamento è un’affermazione che qualcuno deve verificare invece di dare per scontata.

Un test di carico risponde con onestà a una domanda ristretta: questo sistema, in questa configurazione, riesce a servire questa miscela di lavoro a questo ritmo senza violare i propri obiettivi? Quasi tutto il resto che si dice sui test di carico — che una piattaforma «scala», che «reggerà il giorno del lancio» — è una previsione su un traffico che nessuno ha ancora misurato.

Il lancio è esso stesso il picco

La checklist di coordinamento del lancio di Google è un buon punto di partenza perché è stata scritta per essere eseguita prima di una data, non dopo un incidente. Chiede al team di lancio «stime di traffico HTTP e larghezza di banda, il “picco” del lancio e la miscela di traffico», un «test di carico, test end-to-end, capacità per data center alla latenza massima», l’«impatto sugli altri servizi a cui teniamo di più» e la «degradazione graduale e come evitare di sovraccaricare per errore servizi di terze parti».

Quella lista è generica per i servizi web e precede gran parte degli strumenti attuali del settore. La sua forma continua a valere per una piattaforma di gioco, perché un lancio è un gradino e non una rampa. Nel momento in cui un titolo va online i giocatori arrivano insieme, e ogni arrivo non è una singola richiesta. Avvio di sessione, lettura della lobby, controllo del saldo, puntata, esito, la sequenza di movimenti nel portafoglio e la lettura dello storico sono lavori distinti che arrivano moltiplicati dalla stessa folla.

Scrivete il modello di carico prima dello script

Un test comparativo su un singolo endpoint misura un endpoint. Non dice nulla della piattaforma. Il primo artefatto utile di un programma di capacità è quindi un inventario del lavoro che la piattaforma fa davvero, con il costo e gli effetti collaterali di ogni voce:

Lavoro	Che cosa deve modellare il test	Che cosa scrive
Avvio di sessione e autenticazione	Raffiche di accesso al momento dell’annuncio, comprese le ripetizioni che una risposta lenta provoca	Record di sessione ed eventi di autenticazione
Letture di lobby, catalogo e dettaglio gioco	Quasi solo letture, economiche singolarmente, dominanti per volume	Nulla
Ciclo del round	Accettazione della puntata, generazione dell’esito e i movimenti di portafoglio che chiudono il round	Movimenti di libro mastro e storico dei round
Contributo e accumulo del jackpot	Un contatore condiviso che ogni round contribuente tocca	Stato di accumulo e i record che lo giustificano
Valutazione e assegnazione dei bonus	Regole con molte letture e scritture occasionali che creano passività	Record di bonus e passività in essere
Pagamenti	Avvio del deposito, callback del fornitore e prelievi, ciascuno con la propria latenza esterna	Record di pagamento e di portafoglio
Query di back office e reportistica	Lunghe, costose e spesso eseguite da persone in orario di lavoro	Nulla, ma consumano le stesse risorse
Flussi di eventi e analytics	Continui, asincroni e facili da dimenticare nel dimensionamento	Offset del flusso e reportistica derivata

Due scelte di quel modello decidono che cosa il test può concludere. La prima è la miscela: un’esecuzione fatta soprattutto di letture di lobby passa comodamente senza dire nulla del percorso del round. La seconda è se il carico sia modellato come una popolazione fissa di utenti o come un tasso di arrivo fisso. La distinzione merita la lettura della documentazione di k6 sui modelli aperti e chiusi, perché i due si comportano diversamente nell’istante in cui il sistema rallenta: uno applica contropressione aspettando, l’altro continua ad arrivare.

Un conteggio di richieste non è un modello di capacità

È tentante esprimere la capacità come richieste al secondo e confrontare quel numero con una stima di lancio. Il capitolo SRE sulla gestione del sovraccarico spiega perché quel confronto inganna: «Richieste diverse possono avere fabbisogni di risorse enormemente diversi», e modellare la capacità come «query al secondo» o come caratteristiche statiche della richiesta «spesso produce una metrica scadente», perché i rapporti tra le richieste cambiano man mano che il prodotto cambia. La raccomandazione del capitolo è misurare la capacità in risorse disponibili — la CPU per prima, nella maggior parte dei casi — e definire limiti per singolo cliente, così che l’eccesso di uno non lasci gli altri senza risorse.

Per una piattaforma di gioco la versione pratica è che un round chiuso che tocca il libro mastro più volte non è intercambiabile con una lettura di lobby. Se il modello di carico non porta con sé un costo per unità di lavoro, il valore di picco che ne deriva è un numero senza unità di misura.

Provate in un ambiente che possa sbagliare allo stesso modo

Un test di carico eseguito contro un ambiente sottodimensionato produce un numero sicuro del sistema sbagliato. La parità conta dove si decide se una query è veloce: volume del dataset e dimensione degli indici, statistiche delle tabelle, configurazione e stato dei flag di funzionalità in prova, calore della cache e raggiungibilità dei partner di integrazione con una latenza realistica. Un dataset ripristinato e con la forma della produzione trova la query lenta che un campione di qualche migliaio di righe non troverà mai. La guida ai requisiti degli ambienti non di produzione copre che cos’altro quell’ambiente debba separare prima di poter essere usato per questo.

Sei tipi di test, sei modi diversi di fallire

La pagina Grafana sui tipi di test di carico organizza il lavoro in test di fumo, a carico medio, di stress, di tenuta prolungata, di picco e di punto di rottura, e porta due idee valide per qualsiasi programma di capacità: «nessun tipo di test elimina da solo tutti i rischi», e le categorie sono relative — «un test di stress per un’applicazione è un test a carico medio per un’altra».

Tipo	La domanda a cui risponde in una piattaforma	Che cosa conservare
Fumo	Lo script percorre ancora il percorso reale dopo l’ultima release?	La versione dello script e un risultato di riferimento
Carico medio	La piattaforma mantiene i propri obiettivi nella miscela attesa?	Latenza e tasso di errore al ritmo modellato
Stress	Che cosa accade oltre il picco atteso e che cosa degrada per primo?	Il punto della prima degradazione e la sua forma
Tenuta prolungata	La piattaforma tiene per ore e non per minuti?	L’andamento delle risorse durante la prova, non solo la fine
Picco	Un arrivo improvviso e breve sopravvive senza cascata?	Il tempo di recupero e se qualcosa è rimasto bloccato
Punto di rottura	Dov’è il limite e il guasto è ordinato?	La risorsa limitante e il comportamento di rifiuto

La finestra di tenuta è dove emerge l’accumulo

Un test di un’ora a carico medio esercita i percorsi; un test di tenuta prolungata esercita l’aritmetica della piattaforma che mantiene stato. I guasti che trova sono lenti: un pool di connessioni che perde un descrittore per ciclo, una tabella delle sessioni che cresce senza una routine di conservazione, una cache che non espelle mai, una coda svuotata di giorno e mai di notte, un accumulo che deriva perché una routine di riconciliazione non è stata eseguita, e un volume di log che riempie un disco oltre una soglia che nessuno ha modellato. La descrizione stessa di Grafana per un test di tenuta è «l’affidabilità e le prestazioni del sistema su periodi estesi», con una durata misurata in ore e non in minuti.

Due regole pratiche rendono un test di tenuta meritevole del tempo che occupa in calendario: eseguirlo abbastanza a lungo da attraversare almeno una finestra programmata di manutenzione o di elaborazione batch, e osservare le risorse nel tempo invece di leggere il riepilogo finale.

Il carico sintetico scrive record finanziari reali

Un test di carico contro una piattaforma di gioco non rinvia una pagina statica. Ogni round simulato crea movimenti di libro mastro, ogni bonus simulato crea passività e ogni deposito simulato crea un record di pagamento. Quei record finiscono nelle stesse tabelle da cui il business produce i propri report e, se il test non viene identificato, in seguito saranno indistinguibili dall’attività reale.

Decidete prima dell’esecuzione come viene marcato il traffico sintetico, quali conti o tenant usa, se è escluso dalla riconciliazione e quando viene rimosso; e conservate il record di quella decisione insieme all’esecuzione. La guida ai requisiti di riconciliazione del portafoglio descrive i controlli che quelle esclusioni devono rispettare, e la guida alla registrazione di sicurezza e alle prove di audit descrive dove appartiene il record di un test deliberato.

Il vostro picco è anche il picco dei vostri fornitori

Una piattaforma sotto carico spinge quel carico verso l’esterno. I fornitori di pagamento limitano la frequenza, i fornitori di identità applicano soglie proprie e gli endpoint di portafoglio dei fornitori di giochi hanno limiti loro. La riga della checklist sull’evitare di sovraccaricare per errore servizi di terze parti avverte esattamente di questo: il vostro picco diventa il loro, e la loro degradazione torna indietro come timeout.

Confermate con ogni partner i limiti pubblicati, modellate nell’ambiente la loro latenza realistica e i loro errori, e provate come si comporta la piattaforma quando sono lenti invece che assenti. Una politica di retry aggressiva, innocua a volume normale, è il modo in cui una dipendenza lenta diventa una coda che satura tutto ciò che sta dietro.

Fissate la condizione di superamento prima di premere avvio

La checklist chiede «capacità per data center alla latenza massima», e la qualificazione è il punto: un valore di capacità senza un limite di latenza descrive un sistema che ha servito richieste, non uno che le ha servite in modo utile.

Scrivete prima le soglie — il percentile che conta, il tasso di errore accettabile, la miscela che la prova deve usare e il tetto di risorse — e lasciate che l’esecuzione produca un superamento o un fallimento rispetto a esse. Una conclusione scelta dopo aver letto i risultati è un’opinione con un grafico allegato. Quando l’obiettivo è un obiettivo di livello di servizio per i giocatori, vale la stessa disciplina di ogni altro caso: il numero è ciò rispetto a cui si fallisce.

Rifiutate il carico di proposito e dimostrate di saperlo fare

Sotto sovraccarico il comportamento desiderabile non è accettare tutto e crollare. È continuare a servire il traffico che si riesce a elaborare e rifiutare il resto con chiarezza. L’RFC 6585 definisce la forma di quel rifiuto: il codice di stato 429 «indica che l’utente ha inviato troppe richieste in un dato intervallo di tempo (“limitazione di frequenza”)», la risposta «DOVREBBE includere dettagli che spiegano la condizione e PUÒ includere un’intestazione Retry-After», e una risposta 429 «NON DEVE essere memorizzata da una cache». Il capitolo SRE sulla gestione del sovraccarico dice lo stesso dal lato di chi serve: un task dimensionato per un certo ritmo dovrebbe «continuare a servire traffico a quel ritmo senza un impatto significativo sulla latenza, indipendentemente da quanto traffico in eccesso gli venga gettato addosso», non deve cadere, e questo dovrebbe valere «da qualche parte oltre due o persino dieci volte ciò che il task è dimensionato a elaborare».

Il test di stress ha quindi un secondo risultato oltre al limite: la prova che il rifiuto è ordinato. Superate la capacità di proposito e verificate se chi chiama riceve una risposta chiara e ripetibile, oppure se riceve timeout mentre le code si riempiono.

Conservate un record che sopravviva alla release

Un’esecuzione di capacità che non lascia alcun artefatto è indistinguibile da una saltata. Il record che vale la pena conservare è breve: lo script e la versione del modello di carico, il dataset e come è stato prodotto, la topologia e le dimensioni delle istanze, la configurazione e lo stato dei flag di funzionalità, il profilo di carico, i risultati grezzi, le soglie, ogni eccezione con un responsabile, chi ha letto il risultato e che cosa è stato deciso, e la data.

Altre due condizioni appartengono a quel record e non alla memoria di qualcuno. La prima: un test contro capacità condivisa o di produzione richiede una finestra dichiarata, un responsabile nominato e una condizione di arresto definita; un test di carico che inizia a incidere sui giocatori reali ha smesso di essere un test ed è diventato l’incidente che doveva prevenire. La seconda: se ci si aspetta che l’esecuzione produca un picco, la guida al piano di risposta agli incidenti è il documento che dovrebbe già indicare chi osserva e chi può fermarla.

Fermatevi a ciò che il test dimostra

Un’esecuzione superata dimostra che questa build, in questo ambiente, ha servito quel modello di carico in quella data a quel ritmo. Non dimostra che la piattaforma sia corretta, che una popolazione reale si comporti come il modello, che un fornitore rispetti i propri limiti, né che il risultato sopravviva alla release successiva. La capacità è una tendenza, non una medaglia: un cambiamento nel percorso del round, nel volume dei dati o nella topologia invalida l’ultimo risultato, e il numero utile è quello che ha accanto una data e una build.

È anche per questo che un test di carico appartiene a un calendario e non soltanto a una checklist di lancio. La guida all’osservabilità dell’RGS copre il lato in tempo di esecuzione della stessa domanda — che cosa la piattaforma registra di sé mentre serve — e le due cose insieme sono ciò che trasforma una data di lancio da speranza in evento osservato. Il lavoro di sviluppo di piattaforme è dove si colloca il lato di capacità di quel processo di rilascio.

Domande che si pongono gli operatori

Quanto deve durare un test di tenuta prolungata?

Abbastanza da attraversare almeno una finestra programmata di elaborazione batch o manutenzione, cioè in pratica ore e non minuti. La durata non è tenuta fine a se stessa: serve a lasciare che perdite, crescita e derive si accumulino fino a una dimensione visibile.

Un test di carico può essere eseguito contro la produzione?

Sì, ma è un esercizio diverso con regole diverse: finestra dichiarata, responsabile nominato, condizione di arresto definita e una decisione sui record sintetici che crea. Un test di carico che degrada il servizio in produzione è un incidente. Quando l’obiettivo è misurare la piattaforma e non il cambiamento, provare su un ambiente con la forma della produzione è la decisione meno costosa.

Un test di carico superato dimostra che la piattaforma sopravvivrà al giorno del lancio?

No. Dimostra che un carico modellato è stato servito da una build specifica in un ambiente specifico in una data specifica. Una popolazione reale di giocatori decide la propria miscela, le terze parti impongono i propri limiti e la release successiva può cambiare il costo del lavoro.