L'auto-scaling aumenta e riduce il numero di istanze che eseguono la tua app Node.js al variare del carico CPU, cosa che garantisce più capacità nei periodi intensi e costi minori nei periodi tranquilli. Questa guida descrive la scheda di KPanel, ogni impostazione, cosa viene fatturato e come rendere un'app sicura da scalare.
Dove si trova lo Scaling in KPanel
- Accedi a KPanel.
- Clicca su Siti web nella barra laterale sinistra, poi clicca sul sito.
- Nel menu a sinistra del sito, apri Prestazioni, poi Scaling.
L'indirizzo diretto è /websites/<site-id>/autoscale. Il vecchio indirizzo /websites/<site-id>/scaling funziona ancora e ti reindirizza allo stesso punto.
La scheda compare solo sui siti Node.js. Non comparirà nel menu per un sito WordPress, WooCommerce, statico, PHP, Python o Ruby, perché il meccanismo scala un cluster di processi Node.js.
Una scheda, una configurazione
KPanel un tempo presentava qui due schede, Scaling e Autoscaling, sovrapposte a un unico insieme di impostazioni. Erano due viste della stessa configurazione, il che serviva solo a creare confusione, quindi ora sono un'unica scheda Scaling: stato in tempo reale, impostazioni, eventi di scaling recenti e il pannello di utilizzo e costi per il periodo di fatturazione corrente, tutto in un unico posto.
Come funziona
La tua app viene eseguita come cluster di processi. L'auto-scaling monitora la CPU media sulle istanze in esecuzione e aggiunge o rimuove istanze in base alle soglie impostate.
La modalità cluster è obbligatoria. Se la tua app non è già in esecuzione in modalità cluster, l'attivazione dell'auto-scaling la converte automaticamente, il che comporta un breve riavvio. La pagina ti avvisa quando ciò avviene.
Leggere lo stato in tempo reale
La scheda di stato mostra tre informazioni:
- Instances: quante sono in esecuzione in questo momento.
- CPU media: la CPU media su quelle istanze.
- Cluster: se l'app è in modalità cluster. Se indica no, l'attivazione dell'auto-scaling la passerà a questa modalità.
Se l'app non è affatto in esecuzione, la scheda lo segnala invece di mostrare valori a zero.
La scheda mostra anche Ultimo scaling, l'orario dell'evento di scaling più recente, oppure mai.
Le impostazioni
| Impostazione | Intervallo | Cosa fa |
|---|---|---|
| Istanze minime | da 1 a 16 | Il minimo. Non scala mai al di sotto di questo valore |
| Istanze massime | da 1 a 16 | Il massimo. Non scala mai al di sopra di questo valore |
| Aumenta scala a CPU % | da 5 a 99 | Una CPU media superiore a questo valore aggiunge un'istanza |
| Riduci scala a CPU % | da 1 a 95 | Una CPU media inferiore a questo valore ne rimuove una |
| Cooldown (sec) | da 30 a 3600 | Attesa minima tra due azioni di scaling |
L'interruttore principale è il selettore nell'intestazione del pannello delle impostazioni. Quando l'auto-scaling è disattivato, le impostazioni appaiono in grigio e la tua app rimane al numero di istanze attuale.
Valori di partenza ragionevoli:
- Istanze minime 1 o 2. Due se non puoi tollerare che il riavvio di una singola istanza metta l'app fuori servizio.
- Istanze massime impostate in base a quanto sei disposto a spendere nei picchi, non al limite massimo consentito.
- Aumenta scala intorno al 70 percento. Abbastanza alto da non pagare per margine che non usi mai, abbastanza basso da lasciare tempo per aggiungere capacità prima che le richieste comincino ad accodarsi.
- Riduci scala intorno al 30 percento. Lascia un ampio margine tra le due soglie.
- Cooldown di alcuni minuti. È l'impostazione più sottovalutata.
Impostare le due soglie CPU troppo vicine tra loro causa oscillazioni (flapping): il cluster scala verso l'alto, scende subito sotto la soglia di riduzione perché il carico ora è distribuito su più istanze, scala verso il basso, risale di nuovo, e il ciclo si ripete. Mantieni un ampio margine e usa un cooldown generoso. Il flapping costa denaro e destabilizza l'app.
Eventi di scaling
La scheda elenca gli eventi di scaling recenti, dal più recente, mostrando per ciascuno la direzione, il numero di istanze prima e dopo, il valore di CPU che lo ha innescato e l'orario.
Questo è il registro da consultare quando l'app si è comportata male. Una serie di eventi su e giù in pochi minuti indica che le soglie sono troppo vicine o il cooldown troppo breve. Un singolo scaling verso l'alto che non è mai tornato indietro significa che il carico è rimasto alto, il che è una questione di capacità più che di configurazione. Nessun evento quando te ne aspettavi qualcuno significa che la CPU non ha mai superato una soglia, oppure che l'auto-scaling è disattivato.
Quanto costa l'auto-scaling
Le istanze oltre l'assegnazione base del tuo piano vengono misurate e fatturate al secondo. La scheda mostra, per il periodo corrente:
- Istanza-tempo utilizzata, in ore e minuti, con i secondi-istanza grezzi sottostanti.
- Speso finora in questo periodo.
- Proiezione fine mese, estrapolata dall'utilizzo registrato finora.
- Tracking, quante finestre di utilizzo sono state fatturate sul totale registrato.
- Progresso del periodo, giorni trascorsi sui giorni del mese.
La tariffa al secondo è mostrata in cima allo stesso pannello, così l'importo su cui vieni fatturato è sempre visibile accanto all'utilizzo a cui si applica.
La proiezione è il valore da tenere d'occhio. Viene estrapolata da quanto hai usato finora, quindi una settimana insolitamente intensa a inizio mese la farà apparire sovrastimata. Controllala dopo qualche giorno, e di nuovo a metà mese, prima di trarre conclusioni. Se è più alta di quanto vorresti, riduci il numero massimo di istanze piuttosto che alzare la soglia di aumento scala: il tetto massimo è un limite rigido, una soglia è solo un'indicazione.
Scalare fino al minimo interrompe la misurazione a consumo. Se disattivi del tutto l'auto-scaling, l'app resta al numero di istanze che aveva in quel momento, quindi riportala prima al minimo se la ragione per cui la stai disattivando è il costo.
Rendere un'app sicura da scalare
La pagina riporta un avviso, ed è la cosa più importante che contiene: la tua app Node.js deve essere sicura per i cluster per scalare correttamente su più istanze.
In pratica questo significa:
Nessuno stato di sessione in memoria. Se la sessione di un utente autenticato vive nella memoria di un'istanza, l'utente viene disconnesso ogni volta che una richiesta arriva su un'istanza diversa. Sposta le sessioni in un archivio condiviso.
Nessuna cache in memoria su cui fai affidamento per la correttezza. Ogni istanza ha la propria. Una cache che deve essere coerente va condivisa.
Nessuna scrittura su filesystem locale che ti aspetti di poter rileggere. I caricamenti scritti su disco locale da un'istanza sono invisibili alle altre. Scrivi su uno storage condiviso.
Nessun'attività pianificata non protetta. Se un timer gira all'interno dell'app, ogni istanza lo esegue, quindi un'operazione notturna con quattro istanze viene eseguita quattro volte. Sposta le attività pianificate su un cron job, oppure proteggile con un lock. Vedi Cron Jobs.
Nessuna assunzione che il numero di istanze sia stabile. Qualunque cosa suddivida il lavoro in base all'indice dell'istanza si rompe nel momento in cui il numero cambia.
Se una di queste condizioni si applica alla tua app, correggila prima di attivare l'auto-scaling. Un'app non sicura per i cluster fallisce in modi intermittenti e difficili da riprodurre, perché dipendono da quale istanza ha servito quale richiesta.
Risoluzione dei problemi
L'interruttore non si attiva. L'attivazione richiede il permesso di scrittura sul sito. Con un ruolo di sola lettura i controlli sono disabilitati.
L'app si è riavviata quando ho attivato l'auto-scaling. È normale. Il passaggio alla modalità cluster richiede un riavvio, e avviene una sola volta.
Gli utenti vengono disconnessi a caso. Sintomo classico di mancata sicurezza per i cluster. Le sessioni sono in memoria e le richieste finiscono su istanze diverse.
Le istanze sono aumentate e non sono mai diminuite. O il carico è rimasto sopra la soglia di riduzione, oppure qualcosa mantiene la CPU alta indipendentemente dal traffico. Controlla l'elenco degli eventi e osserva cosa sta effettivamente facendo l'app.
Un'attività pianificata è stata eseguita più volte. Ogni istanza l'ha eseguita. Spostala su un cron job o aggiungi un lock.
Niente scala. Verifica che l'interruttore sia attivo, che l'app sia in esecuzione e che la modalità cluster sia abilitata. Poi controlla se la CPU ha effettivamente superato la soglia di aumento scala nell'elenco degli eventi.
Il costo è più alto del previsto. Guarda l'elenco degli eventi per individuare oscillazioni (flapping), poi riduci il numero massimo di istanze.
Pagine correlate
- Prestazioni del sito e APM per capire se la CPU è davvero il collo di bottiglia.
- Monitoraggio dell'uptime del sito per confermare che lo scaling stia effettivamente migliorando la disponibilità.
- Cron Jobs per attività pianificate che devono essere eseguite esattamente una volta.
- Ridimensionamento di un server cloud se hai bisogno di una macchina più grande anziché di più istanze.