Di tanto in tanto, sui social media ci capita di leggere commenti di sviluppatori che si chiedono perché mai qualcuno dovrebbe utilizzare una soluzione per le sale d'attesa. Per loro, installare CrowdHandler equivarrebbe a un'ammissione di sconfitta piuttosto che a un'aggiunta intelligente al proprio arsenale di strumenti.
Dopotutto, perché mai dovresti aver bisogno di una soluzione per la sala d’attesa quando puoi semplicemente utilizzare un cloud magico e scalabile all’infinito?
Ecco un esempio:
“Una strategia di bilanciamento del carico adeguata con possibilità di espansione illimitata contro una sala d’attesa fastidiosa per i clienti… hmm, scelta difficile”
Espansione illimitata? Non esiste
Per qualche motivo, molti sviluppatori sembrano dare per scontato che le loro soluzioni cloud – come i gruppi EC2 con autoscaling, AWS Lambda o gli equivalenti di Azure e Google – siano in grado di scalare all’infinito.
Forse credono di essere fatti di magia.
La verità è che le soluzioni cloud possono scalare solo entro determinati parametri e, indipendentemente dal numero di server che si riesca magicamente ad aggiungere, alla fine si raggiungeranno comunque dei limiti.
I tuoi parametri includeranno quelli che avrai dovuto impostare e pagare di tasca tua – in altre parole, i parametri entro i quali quel servizio cloud ti consente di operare in base alla tua fascia di prezzo. Ma probabilmente ci sarà anche un limite massimo determinato dalla tecnologia del tuo database. (Dopotutto, nessun livello di archiviazione ACID può scalare all’infinito, perché, per sua stessa natura, nessuna transazione ACID può essere infinita.)
Quindi, quando vedo un commento come quello sopra, capisco che quella persona non ha in realtà molta esperienza con il ridimensionamento in condizioni reali.
Perché, una volta che avrai lavorato con un'applicazione che cerca di adattarsi a livelli enormi di traffico in un lasso di tempo molto breve, raggiungerai quei limiti e capirai che non esiste una cosa come l'"espansione illimitata".
Il ridimensionamento automatico funziona... finché non smette di funzionare
Certo, hai un'applicazione scalabile davvero ottima, in grado di adattarsi automaticamente nel corso della giornata o magari nel corso di un mese. Puoi regolarla per far fronte a livelli di traffico variabili senza alcun problema, anche durante i periodi di maggiore affluenza. La tua architettura di scalabilità automatica rileverà che c'è un po' più di traffico e aggiungerà automaticamente dei server per gestirlo... poi, quando la situazione si calmerà, li rimuoverà dal sistema. Funziona bene.
Tutto questo va benissimo, nel 99% dei casi. Ma i modelli di traffico che richiederebbero un’architettura di auto-scaling infinitamente scalabile non sono affatto così. Stiamo parlando dello scenario in cui la vostra applicazione si ritrova improvvisamente dieci volte più trafficata, cento volte più trafficata – forse persino mille volte più trafficata… in meno di un minuto.
All'improvviso mille volte più impegnato
La messa in vendita dei biglietti è l’esempio più evidente di questo tipo di picco improvviso di traffico che osserviamo qui a CrowdHandler. Quando vengono messi in vendita i biglietti per il tour dell’ultima megastar, ad esempio, il sito di un venditore può passare da zero a un milione esattamente alle 10 del mattino.
Ma non si tratta solo delle vendite dei biglietti delle megastar. Un picco improvviso di traffico può capitare a chiunque. Qualsiasi tipo di vendita caratterizzata da una dinamica di calo; un’improvvisa scarsità di una linea popolare; una menzione del tuo prodotto da parte di un influencer sui social media (prevedibile o meno!). Tutti questi fattori possono determinare un’impennata di traffico.
Ciò che tende ad accadere in questi casi è che, sì, l'auto-scaler rileva l'aumento del traffico – magari nota che i tempi di caricamento delle pagine si stanno allungando, oppure che l'utilizzo della CPU sui server è più elevato – e reagisce mettendo in funzione altri server.
Tuttavia, questo processo non è immediato. I container devono avviarsi e le cache devono raggiungere la temperatura di esercizio.
In realtà è piuttosto ironico: quando entrano in funzione i meccanismi di autoscalabilità, di solito si osserva un netto calo delle prestazioni. Questa fase di stallo, che dura fino a cinque minuti, termina quando i sistemi tornano a stabilizzarsi.
Se è stata configurata una "sala d'attesa", è a questo punto che entra in funzione. Quando le prestazioni rallentano al punto che gli utenti finali rischierebbero altrimenti di trovarsi di fronte a un'applicazione bloccata, la "sala d'attesa" serve a trattenere gli utenti per quei pochi minuti necessari affinché il sistema torni a funzionare a pieno regime.
Tempo di attività di Triple 9
A proposito: cosa prevede il vostro SLA in merito al tempo di attività complessivo? Perché, su un mese, quei cinque minuti necessari per ripristinare la scalabilità passeranno quasi inosservati, nonostante possano causare danni ingenti. Fate voi i conti: 5/43920 significa che si registra comunque un tempo di attività del 99,99%! Ma quei cinque minuti sono probabilmente i più critici dell’intero mese in termini di esperienza utente e reputazione.
Allora, cosa si può fare per prevenire i problemi?
Ridurre il sovraccarico di traffico - 1: Quando è prevedibile
Spesso si sa in anticipo quando ci sarà un picco di traffico. Ad esempio, potresti lanciare le tue offerte di prodotti di fascia alta il venerdì mattina. Oppure state pianificando una vendita per il Black Friday. Il nostro consiglio è quindi: non aspettate che il traffico attivi l’autoscaling! Programmate in anticipo l’aumento di capacità del vostro "magic cloud". (È proprio quello che fanno i nostri amici di Made Media: sanno che molti dei loro clienti lanceranno delle offerte, sanno che questo avviene in genere il venerdì mattina, quindi la loro infrastruttura è programmata per aumentare di capacità ogni venerdì mattina.)
E… l’avete indovinato: installate CrowdHandler. Perché anche se conoscete alla perfezione i parametri del vostro scalamento e siete estremamente sicuri di comprendere il livello di traffico che riceverete, c’è comunque un margine di errore enorme. Una “sala d’attesa”, invece, resisterà praticamente a tutto (e ricordate: non entrerà in azione se non è necessario).
Possiamo anche affermare con certezza che le sorprese capitano. Spesso un cliente ci chiede perché la sala d’attesa si sia attivata e ci dice che la sua dashboard di CrowdHandler segnala un traffico “errato” o “che non c’è”. Ma il traffico c’è: è solo inaspettato. In seguito, scoprono di aver ricevuto una menzione da un influencer, che ha portato un numero elevato di visitatori sul loro sito in un momento in cui non se lo aspettavano. Nel mondo della vendita dei biglietti, stiamo vedendo sempre più artisti anticipare i tempi e condividere un link come parte dell’annuncio di un tour senza consultare il programma di pubbliche relazioni preparato con cura.
Ridurre il sovraccarico di traffico - 2: Quando è imprevedibile
Se non sai quando si verificheranno i picchi di traffico (o se stai collaborando con influencer imprevedibili!), allora dovresti assolutamente installare CrowdHandler come soluzione universale, lasciandolo sempre in esecuzione.
Ancora meglio, usalo con Autotune attivato. In questo caso:
- Aumento del traffico
- La coda viene attivata e la funzione Autotune di CrowdHandler gestisce la frequenza
- Il cloud con scalabilità automatica reagisce all'aumento del carico e avvia il processo di scalabilità, il che rallenta le prestazioni
- La funzione Autotune di CrowdHandler rileva il rallentamento, mantiene alcuni utenti in coda e garantisce loro un’esperienza utente positiva grazie a messaggi adeguati
- I livelli di prestazione tornano alla normalità e Autotune aumenta la velocità per svuotare rapidamente la coda
Un'ultima considerazione sull'esperienza utente
Ecco una cosa curiosa. Anche se la vostra “magica” infrastruttura cloud con auto-scaling funzionasse alla perfezione e il vostro prodotto andasse esaurito in meno di un secondo, i vostri utenti vivrebbero un’esperienza tutt’altro che ottimale (e potrebbero esprimere il loro malcontento). Questo perché, quando qualcosa accade molto rapidamente – ad esempio se sembra non esserci alcun intervallo di tempo tra il momento in cui la transazione diventa disponibile e quello in cui il prodotto va esaurito – l’utente finale può percepirlo come molto ingiusto. Abbiamo avuto clienti che ci hanno riferito che il processo CrowdHandler e la relativa comunicazione aiutano a mantenere gli utenti dalla nostra parte, dando loro il tempo di riprendere fiato e tenendoli informati.
Quindi, quando entra in gioco la pagina di attesa, abbi fiducia nel processo. Non farti prendere dal panico (ma usa i campi dei messaggi con giudizio). I tuoi utenti si sentiranno molto più a loro agio ad aspettare in coda per qualche secondo o minuto piuttosto che trovarsi di fronte a un sito bloccato o a una pagina che dice immediatamente "tutto esaurito".