Modelli comuni di scalabilità automatica
In questa unità vengono esaminati modelli di scalabilità automatica.
La scalabilità automatica non è una soluzione immediata. L'aggiunta di risorse a un sistema o l'esecuzione di più istanze di un processo non garantisce prestazioni migliorate per il 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. Ad esempio, se il database back-end è il collo di bottiglia, l'aggiunta di altri server Web non risulta 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. Il sito pubblico potrebbe riscontrare picchi improvvisi di traffico, mentre il sito di amministrazione ha un carico più piccolo e prevedibile.
Offload delle attività a elevato utilizzo di risorse: Le attività che richiedono molte risorse di CPU o I/O devono essere spostate nei processi in background, quando possibile. L'offload delle attività riduce al minimo il carico sul front-end che gestisce le richieste utente.
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 delle istanze: Tenere presente che con la scalabilità elastica l'applicazione ha periodi di riduzione delle istanze, in cui le istanze vengono rimosse. L'applicazione deve gestire correttamente le istanze rimosse. Ecco alcuni modi per gestire la riduzione delle istanze:
- Occorre essere in ascolto degli eventi di arresto quando sono disponibili ed eseguire l'arresto correttamente.
- Supportare la gestione degli errori temporanei e riprovare.
- Valutare la possibilità di suddividere il lavoro per le attività a esecuzione prolungata.
- 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à che invia una notifica tramite posta elettronica, SMS (Short Message Service) o webhook ogni volta che si verifica un errore di scalabilità automatica.
- 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
Alla sera o nel fine settimana si potrebbe avere una domanda di applicazione inferiore. 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à. L'esecuzione di questa azione di riduzione delle istanze azione riduce i costi di esecuzione del set di scalabilità poiché si esegue solo il numero di istanze necessarie per soddisfare la domanda 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.