Siti web
Ridimensionamento e auto-ridimensionamento di un'app Node.js
Auto-scaling grows and shrinks the number of instances running your Node.js app as CPU load changes, so busy periods get more capacity and quiet periods cost less. This guide covers the KPanel tab…
Scaling e Auto-Scaling di un'App Node.js
Auto-scaling aumenta e diminuisce il numero di istanze che eseguono la tua app Node.js al variare del carico CPU, in modo che i periodi di picco ottengono più capacità e i periodi tranquilli costano meno. Questa guida copre la scheda KPanel, ogni impostazione, cosa viene fatturato e come rendere un'app sicura per il scaling.
Dove si trova il Scaling in KPanel
- Accedi a KPanel.
- Fai clic su Websites nella barra laterale sinistra, quindi fai clic sul sito.
- Nella striscia di schede del sito, apri Advanced, quindi Scaling.
L'indirizzo diretto è /websites/<site-id>/autoscale. L'indirizzo /websites/<site-id>/scaling più vecchio funziona ancora e ti rimanda allo stesso posto.
La scheda appare solo sui siti Node.js. Non sarà 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 aveva due schede qui, Scaling e Autoscale, su un unico insieme di impostazioni. Erano due visualizzazioni della stessa configurazione, che era solo un modo per confondersi, quindi ora sono una singola scheda Scaling: stato live, le impostazioni, gli eventi di scaling recenti e il pannello di utilizzo e costo per il periodo di fatturazione attuale, tutto in un unico posto.
Come funziona
La tua app viene eseguita come cluster di processi. Auto-scaling monitora la media CPU tra le istanze in esecuzione e aggiunge o rimuove istanze in base alle soglie che imposti.
La modalità cluster è obbligatoria. Se la tua app non è già in esecuzione in modalità cluster, l'abilitazione di auto-scaling la commuta automaticamente, il che comporta un breve riavvio. La pagina ti comunica quando ciò accade.
Lettura dello stato live
La scheda di stato mostra tre cose:
- Instances: quante sono in esecuzione in questo momento.
- Avg CPU: la media CPU tra quelle istanze.
- Cluster: se l'app è in modalità cluster. Se dice no, l'abilitazione di auto-scaling la commuta.
Se l'app non è in esecuzione affatto, la scheda lo indica invece di mostrare zeri.
La scheda mostra anche Last scale, l'ora dell'evento di scaling più recente, oppure never.
Le impostazioni
| Impostazione | Intervallo | Cosa fa |
|---|---|---|
| Min instances | 1 a 16 | Il minimo. Non scala mai al di sotto di questo |
| Max instances | 1 a 16 | Il massimo. Non scala mai al di sopra di questo |
| Scale up at CPU % | 5 a 99 | Una media CPU superiore a questa aggiunge un'istanza |
| Scale down at CPU % | 1 a 95 | Una media CPU inferiore a questa rimuove una |
| Cooldown (sec) | 30 a 3600 | Attesa minima tra le azioni di scaling |
L'interruttore principale è l'interruttore nell'intestazione della scheda delle impostazioni. Quando l'auto-scaling è disattivato, le impostazioni sono grigie e la tua app rimane sul numero di istanze attuale.
Valori di partenza sensati:
- Min instances 1 o 2. Due se non puoi tollerare che il riavvio di una singola istanza metta offline l'app.
- Max instances a quello che sei disposto a pagare al picco, non al massimo.
- Scale up intorno al 70 percento. Abbastanza alto che non stai pagando per spazio che non usi mai, abbastanza basso che c'è tempo per aggiungere capacità prima che le richieste inizino a mettersi in coda.
- Scale down intorno al 30 percento. Lascia un ampio divario tra le due soglie.
- Cooldown di alcuni minuti. Questa è l'impostazione più sottovalutata.
L'impostazione delle due soglie CPU troppo vicine causa flapping: il cluster scala verso l'alto, scende immediatamente al di sotto della soglia di scale-down perché il carico è ora distribuito più ampiamente, scala verso il basso, sale di nuovo e si ripete. Mantieni un ampio divario e usa un cooldown generoso. Il flapping costa denaro e destabilizza l'app.
Eventi di scaling
La scheda elenca gli eventi di scaling recenti, i più nuovi per primi, ognuno mostrando la direzione, il numero di istanze prima e dopo, la lettura della CPU che lo ha attivato e l'ora.
Questo è il registro da consultare quando l'app si è comportata in modo anomalo. Un'esplosione di eventi su e giù in pochi minuti significa che le tue soglie sono troppo vicine o il tuo cooldown troppo breve. Un singolo scale-up che non è mai tornato indietro significa che il carico è rimasto alto, il che è una questione di capacità piuttosto che di configurazione. Nessun evento affatto quando ne avresti aspettati alcuni significa che la CPU non ha mai superato una soglia o che l'auto-scaling è disattivato.
Cosa costa l'Auto-Scaling
Le istanze al di sopra dell'allocazione di base del tuo piano sono misurate e fatturate al secondo. La scheda mostra, per il periodo attuale:
- Instance-time used, in ore e minuti, con i secondi di istanza grezzi sottostanti.
- Spent so far in questo periodo.
- Projected month-end, estrapolato dall'utilizzo fino ad ora.
- Tracking, quante finestre di utilizzo sono state fatturate su quelle registrate.
- Period progress, giorni trascorsi su giorni del mese.
La tariffa al secondo è mostrata in cima allo stesso pannello, quindi la cifra su cui sei fatturato è sempre visibile accanto all'utilizzo a cui si applica.
La proiezione è il numero da guardare. Si estrapola da quello che hai usato fino ad ora, quindi una settimana insolitamente occupata all'inizio del mese lo sovrastaterà. Controllalo dopo alcuni giorni, poi di nuovo a metà mese, prima di trarre conclusioni. Se è superiore a quello che desideri, abbassa il numero massimo di istanze piuttosto che alzare la soglia di scale-up: il massimo è un limite rigido, una soglia è solo un suggerimento.
Lo scaling verso il basso fino al minimo interrompe la misurazione. Se disattivi completamente l'auto-scaling, l'app rimane sul numero di istanze che ha attualmente, quindi abbassalo prima al minimo se il costo è il motivo per cui stai disattivando.
Rendere un'app sicura per il scaling
La pagina contiene un avviso, ed è la cosa più importante su di essa: la tua app Node.js deve essere cluster-safe per scalare in modo pulito tra le istanze.
In pratica significa:
Nessuno stato di sessione in memoria. Se la sessione di un utente connesso risiede nella memoria di un'istanza, non è connesso ogni volta che una richiesta atterra su un'istanza diversa. Sposta le sessioni in un archivio condiviso.
Nessuna cache in memoria su cui fai affidamento per la correttezza. Ogni istanza ne ha una propria. Una cache che deve essere coerente deve essere condivisa.
Nessuna scrittura su file system locale che prevedi di leggere di nuovo. Gli upload scritti su disco locale da un'istanza sono invisibili agli altri. Scrivi su archiviazione condivisa.
Nessun lavoro pianificato non protetto. Se un timer viene eseguito dentro l'app, ogni istanza lo esegue, quindi un lavoro notturno con quattro istanze viene eseguito quattro volte. Sposta il lavoro pianificato a un cron job o proteggilo con un lock. Vedi Cron Jobs.
Nessuna assunzione che il numero di istanze sia stabile. Qualsiasi cosa che partiziona il lavoro per indice di istanza si rompe nel momento in cui il numero cambia.
Se uno di questi si applica alla tua app, correggilo prima di abilitare l'auto-scaling. Un'app che non è cluster-safe fallisce in modi intermittenti e difficili da riprodurre, perché dipendono da quale istanza ha servito quale richiesta.
Risoluzione dei problemi
L'interruttore non si abilita. L'abilitazione richiede l'autorizzazione di scrittura del sito. Con un ruolo di sola lettura i controlli sono disabilitati.
L'app si è riavviata quando ho abilitato l'auto-scaling. Previsto. Il passaggio alla modalità cluster richiede un riavvio e avviene una sola volta.
Gli utenti vengono disconnessi a caso. Sintomo classico non cluster-safe. Le sessioni sono in memoria e le richieste stanno atterrando su istanze diverse.
Le istanze hanno scalato verso l'alto e non sono mai tornate indietro. O il carico è rimasto al di sopra della soglia di scale-down, o qualcosa mantiene la CPU alta indipendentemente dal traffico. Controlla l'elenco degli eventi e guarda cosa sta effettivamente facendo l'app.
Un lavoro pianificato è stato eseguito più volte. Ogni istanza lo ha eseguito. Spostalo a un cron job o aggiungi un lock.
Nulla scala. Conferma che l'interruttore è acceso, l'app è in esecuzione e la modalità cluster è abilitata. Quindi controlla se la CPU ha effettivamente superato la tua soglia di scale-up nell'elenco degli eventi.
Il costo è superiore al previsto. Cerca flapping nell'elenco degli eventi, quindi abbassa il numero massimo di istanze.
Pagine correlate
- Site Performance and APM per vedere se la CPU è effettivamente il collo di bottiglia.
- Site Uptime Monitoring per confermare che il scaling sta effettivamente migliorando la disponibilità.
- Cron Jobs per il lavoro pianificato che deve essere eseguito esattamente una volta.
- Resizing a Cloud Server se hai bisogno di una macchina più grande piuttosto che più istanze.