Progettare per aumentare il numero di istanze
Progettare l'applicazione in modo che consenta la scalabilità orizzontale
Un importante vantaggio del cloud è la scalabilità elastica, ovvero la possibilità di usare la capacità necessaria, aumentandola quando aumenta il carico e riducendola quando la capacità aggiuntiva non è necessaria. Progettare l'applicazione in modo che consenta la scalabilità orizzontale, aggiungendo o rimuovendo istanze e facendo corrispondere offerta e domanda.
La scalabilità viene misurata in base al rapporto tra aumento della velocità effettiva e aumento delle risorse. Idealmente, in un sistema ben progettato, entrambi i numeri sono proporzionali: un'allocazione duplice delle risorse raddoppierà la velocità effettiva. La scalabilità è in genere limitata dall'introduzione di colli di bottiglia o punti di sincronizzazione all'interno del sistema.
Consigli
Evitare la persistenza delle istanze. Si parla di persistenza, o affinità di sessione, quando le richieste dello stesso client vengono sempre instradate allo stesso server. La persistenza limita la capacità dell'applicazione di aumentare il numero di istanze. Ad esempio, il traffico proveniente da un utente con volumi elevati non verrà distribuito tra le istanze. Tra le cause della persistenza ci sono lo stato sessione in memoria e l'uso di chiavi specifiche del computer per la crittografia. Assicurarsi che qualsiasi istanza possa gestire qualsiasi richiesta.
Identificare i colli di bottiglia. La scalabilità orizzontale 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 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 spesso sono costituite da più carichi di lavoro, con requisiti di scalabilità diversi. 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.
Progettare componenti autonomi e disaccoppiati che comunicano tramite protocolli di comunicazione asincroni. Idealmente, i componenti devono avere uno stato indipendente e gli eventi per comunicare qualsiasi modifica o attività ai componenti esterni. Ciò consente di ridimensionare in modo indipendente solo il componente di overload. Implementare meccanismi di controllo del flusso per gestire il traffico e degradarsi normalmente. I consumatori devono controllare il proprio tasso di consumo. I produttori devono controllare il proprio tasso di trasmissione, inclusa l'interruzione. Le code di messaggi sono buone opzioni per assorbire un carico di lavoro aggiuntivo e consentire ai consumatori di svuotare il lavoro in tempo libero.
Evitare comunicazioni, coordinamento e attesa inutili.
Offload attività naturalmente asincrone. Le attività come l'invio di messaggi di posta elettronica, le azioni in cui l'utente non ha bisogno di una risposta immediata e l'integrazione con altri sistemi sono tutti elementi validi per usare modelli di messaggistica asincroni.
Ripartire il carico delle attività a elevato utilizzo di 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.
Scalabilità automatica basata sulle metriche di utilizzo in tempo reale e uso delle funzionalità di scalabilità automatica predefinite. Molti servizi di calcolo di Azure offrono il supporto predefinito per la scalabilità automatica. Se l'applicazione ha un carico di lavoro prevedibile e regolare, è possibile aumentare il numero di istanze 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. Osservare le applicazioni e le relative comunicazioni per identificare i colli di bottiglia e derivare decisioni più accurate. Per le procedure consigliate relative alla scalabilità automatica, vedere Scalabilità automatica.
Prendere in considerazione la scalabilità automatica aggressiva per i carichi di lavoro critici. Per i carichi di lavoro critici, è necessario anticipare le richieste. 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 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, prendere in considerazione la possibilità di suddividere il lavoro, usando checkpoint o il modello Pipe e filtri.
- 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.
Prendere in considerazione il ridimensionamento per la ridondanza. La scalabilità orizzontale può migliorare l'affidabilità dell'applicazione. Si consideri, ad esempio, la scalabilità orizzontale tra più zone di disponibilità, ad esempio usando i servizi con ridondanza della zona. Questo approccio può migliorare la velocità effettiva dell'applicazione e fornire resilienza in caso di interruzione di un'area.
Modellare e ottimizzare la scalabilità del sistema. È possibile usare il modello del sistema usando un approccio come la legge di Amdahl. Quantificare la scalabilità in base a parametri quali contesa e coerenza. La contesa si riferisce al ritardo dovuto all'attesa o alla coda delle risorse condivise. La coerenza si riferisce al ritardo per cui i dati diventano coerenti. Ad esempio, la presenza di una contesa elevata indica l'elaborazione sequenziale che potrebbe essere parallelizzata, pur avendo una coerenza elevata suggerisce dipendenze eccessive tra i processi, richiedendo di ridurre al minimo le interazioni. Durante la progettazione del carico di lavoro, è possibile calcolare la capacità effettiva massima del sistema per evitare di fornire più offerta rispetto alla domanda che porta a sprechi.