Modelli comuni di scalabilità automatica
In questa unità vengono esaminati modelli di scalabilità automatica.
La scalabilità automatica non è una soluzione immediata. La semplice aggiunta di risorse a un sistema o l'esecuzione di più istanze di un processo non garantisce il miglioramento delle prestazioni del sistema. Quando si progetta una strategia di scalabilità automatica, tenere presente quanto segue:
Consigli
Identificare i colli di bottiglia: l'aumento della capacità non è una soluzione magica per ogni problema di prestazioni. Se, ad esempio, il database back-end rappresenta un collo di bottiglia, l'aggiunta di altri server Web non sarà utile. Identificare e risolvere prima di tutto i colli di bottiglia nel sistema prima di generare più istanze. Le parti con stato del sistema sono le cause più probabili dei colli di bottiglia.
Scomporre i carichi di lavoro in base ai requisiti di scalabilità: le applicazioni sono spesso costituite da più carichi di lavoro con requisiti diversi per la scalabilità. Un'applicazione potrebbe ad esempio avere un sito pubblico e un sito di amministrazione separato. Nel sito pubblico potrebbero verificarsi picchi improvvisi di traffico, mentre il carico del sito di amministrazione è minore e più prevedibile.
Eseguire l'offload delle attività che richiedono molte risorse: le attività che richiedono molte risorse della CPU o di I/O devono essere spostate nei processi in background, quando possibile, per ridurre al minimo il carico sul front-end che gestisce le richieste degli utenti.
Usare le funzionalità di scalabilità automatica predefinite: se l'applicazione ha un carico di lavoro prevedibile e regolare, è possibile aumentare la capacità in base a una pianificazione. Ad esempio, aumentare il numero di istanze durante l'orario di ufficio. In caso contrario, se il carico di lavoro non è prevedibile, usare le metriche delle prestazioni, ad esempio relative a lunghezza della coda di richieste o CPU, per attivare la scalabilità automatica.
Prendere in considerazione la scalabilità automatica aggressiva per i carichi di lavoro critici: è consigliabile avere sempre una capacità superiore alle richieste per i carichi di lavoro critici. In condizioni di carico elevato, è preferibile aggiungere rapidamente nuove istanze per gestire il traffico aggiuntivo e quindi ridurle gradualmente.
Progettare per la riduzione della capacità: tenere presente che con la scalabilità elastica l'applicazione avrà periodi di riduzione delle risorse, in cui le istanze vengono rimosse. L'applicazione deve gestire correttamente le istanze rimosse. Ecco alcuni modi per gestire la riduzione delle istanze:
- Restare in ascolto degli eventi di arresto (quando disponibili) ed eseguire la chiusura normale.
- I client/consumer di un servizio devono supportare la gestione degli errori temporanei e i nuovi tentativi.
- Per le attività a esecuzione prolungata, valutare la possibilità di suddividere il lavoro.
- Inserire gli elementi di lavoro in una coda, in modo che un'altra istanza possa gestire il lavoro se un'istanza viene rimossa durante l'elaborazione.
Notifications
- Tutti gli errori di scalabilità automatica vengono registrati nel log attività. È quindi possibile configurare un avviso del log attività in modo da ricevere una notifica tramite posta elettronica, SMS o webhook ogni volta che si verifica un errore.
- Analogamente, tutte le azioni di scalabilità riuscite vengono pubblicate nel log attività. È quindi possibile configurare un avviso del log attività in modo da ricevere una notifica tramite posta elettronica, SMS o webhook ogni volta che l'azione riesce. È anche possibile configurare le notifiche tramite posta elettronica o webhook nella scheda Notifiche dell'impostazione della scalabilità automatica per ricevere un avviso per le azioni riuscite.
Modelli comuni per la scalabilità delle risorse in Azure
Dimensionamento in base alla richiesta
È possibile aumentare automaticamente il numero di istanze del servizio all'inizio della giornata lavorativa quando si verifica un incremento delle richieste dei clienti. Al termine della giornata lavorativa ridurre automaticamente il numero di istanze dell'applicazione per ridurre al minimo i costi delle risorse nelle ore notturne quando l'uso delle applicazioni è inferiore.
Scalabilità diversa per giorni feriali e fine settimana
Nelle ore serali o nel fine settimana è possibile che la richiesta delle applicazioni si riduca. Se il carico rimane coerente nel tempo, è possibile configurare regole di scalabilità automatica per diminuire il numero di istanze del servizio nel set di scalabilità. Questa azione riduce i costi di esecuzione del set di scalabilità poiché si esegue solo il numero di istanze necessarie per soddisfare la richiesta corrente.
Dimensionare diverso durante le festività
In caso di utilizzo intensivo di un servizio in specifici periodi del ciclo fiscale o mensile, è possibile ridimensionare automaticamente il numero di istanze del servizio per soddisfare queste richieste aggiuntive. Quando si verifica un evento di marketing, una promozione o in periodo di saldi, è possibile ridimensionare automaticamente il numero di istanze del servizio rispetto all'esigenza prevista del cliente.
Dimensionamento in base a una metrica personalizzata
Infine, è consigliabile definire attentamente le regole di scalabilità automatica. Un attacco Denial of Service (DoS), ad esempio, in genere determina un massiccio aumento del traffico in ingresso. Tentare di gestire un picco delle richieste causato da un attacco DoS sarebbe inutile e costoso. Queste richieste non sono autentiche e dovrebbero essere eliminate anziché elaborate. Una soluzione migliore consiste nell'implementare il rilevamento e il filtro delle richieste che si verificano durante un attacco di questo tipo prima che raggiungano il servizio.
Dopo avere configurato le regole di scalabilità automatica, monitorare le prestazioni dell'applicazione nel tempo. Usare i risultati del monitoraggio per regolare il criterio con cui il sistema implementa la scalabilità, se necessario.