Scalabilità automatica

  • Articolo

La scalabilità automatica è il processo di allocazione dinamica delle risorse in base ai requisiti di prestazioni. Man mano che aumenta il volume di lavoro, un'applicazione potrebbe richiedere altre risorse per gestire i livelli di prestazioni desiderate e soddisfare i contratti di servizio. Quando la richiesta diminuisce e le risorse aggiuntive non sono più necessarie, è possibile deallocarle per ridurre al minimo i costi.

La scalabilità automatica sfrutta la flessibilità degli ambienti ospitati nel cloud, semplificando nel contempo la gestione. Riduce la necessità che un operatore monitori continuamente le prestazioni di un sistema e prenda decisioni sull'aggiunta o la rimozione di risorse.

È possibile scalare un'applicazione in due modi principali:

  • Scalabilità verticale, definita anche come aumento o riduzione delle prestazioni, indica la modifica della capacità di una risorsa. Ad esempio, è possibile spostare un'applicazione su una macchina virtuale di dimensioni più grandi. La scalabilità verticale spesso prevede che il sistema sia temporaneamente non disponibile mentre è in fase di ridistribuzione. Pertanto, è meno comune automatizzare la scalabilità verticale.

  • Scalabilità orizzontale, definita anche come aumento o riduzione delle istanze, implica l'aggiunta o la rimozione delle istanze di una risorsa. L'applicazione può ancora essere eseguita senza interruzioni durante il provisioning delle nuove risorse. Quando il processo di provisioning viene completato, la soluzione viene distribuita su queste risorse aggiuntive. Se la domanda cala, le risorse aggiuntive possono essere totalmente arrestate e deallocate.

Numerosi sistemi basati sul cloud, tra cui Microsoft Azure, supportano l'automazione della scalabilità orizzontale. Il resto di questo articolo è incentrato sulla scalabilità orizzontale.

Nota

La scalabilità automatica si applica soprattutto alle risorse di calcolo. Sebbene sia possibile scalare orizzontalmente una coda di database o di messaggio, questo in genere comporta il partizionamento dei dati, che di solito non è automatico.

Componenti di scalabilità automatica

Una strategia di scalabilità automatica in genere coinvolge i componenti seguenti:

  • Strumentazione e monitoraggio dei sistemi a livello di applicazione, servizio e infrastruttura. Questi sistemi acquisiscono la metrica chiave, ad esempio tempi di risposta, lunghezza delle code, utilizzo della CPU e della memoria.
  • Logica decisionale che valuta le metriche rispetto alle soglie predefinite o pianifica e decide se applicare la scalabilità.
  • Componenti che ridimensionano il sistema.
  • Test, monitoraggio e ottimizzazione della strategia di scalabilità automatica in modo che funzioni come previsto.

Azure offre meccanismi di scalabilità automatica incorporati appropriati per scenari comuni. Se un servizio o una tecnologia specifica non dispone di funzionalità predefinite per la scalabilità automatica, o se i requisiti specifici della scalabilità automatica superano le funzionalità disponibili, è possibile considerare un'implementazione personalizzata. L'implementazione personalizzata raccoglie metriche di sistema e operative, le analizza e quindi ridimensiona le risorse di conseguenza.

Configurare la scalabilità automatica per una soluzione di Azure

Azure offre la scalabilità automatica incorporata per la maggior parte delle opzioni di calcolo.

Questi opzioni di calcolo usano la scalabilità automatica di Monitoraggio di Azure per offrire un set comune di funzionalità per la scalabilità automatica.

  • Funzioni di Azure differisce dalle precedenti opzioni di calcolo, in quanto non è necessario configurare le regole di scalabilità automatica. Al contrario, Funzioni di Azure alloca automaticamente la potenza di calcolo quando viene eseguito il codice, riducendo le istanze in base alle esigenze per gestire il carico. Per altre informazioni vedere Scegliere il piano di hosting corretto per Funzioni di Azure.

Infine, una soluzione personalizzata di scalabilità automatica può talvolta essere utile. Ad esempio, è possibile usare la diagnostica e le metriche basate su applicazione di Azure, insieme al codice personalizzato per monitorare ed esportare le metriche dell'applicazione. È quindi possibile definire regole personalizzate basate su queste metriche e usare le API REST di Gestione risorse per attivare la scalabilità automatica. Una soluzione personalizzata non è tuttavia facile da implementare e deve essere considerata solo se nessuno dei precedenti approcci può soddisfare i requisiti.

Usare le funzionalità di scalabilità automatica predefinite della piattaforma, nel caso soddisfino i requisiti. In caso contrario, valutare attentamente se le funzionalità di scalabilità più complesse sono davvero necessarie. Gli esempi di requisiti aggiuntivi possono includere una maggiore granularità di controllo, diversi modi per rilevare gli eventi di attivazione per la scalabilità, la scalabilità tra sottoscrizioni e la scalabilità di altri tipi di risorse.

Usare la scalabilità automatica di Monitoraggio di Azure

La scalabilità automatica di Monitoraggio di Azure offre un set comune di funzionalità di scalabilità automatica per i set di scalabilità di macchine virtuali, Servizio app di Azure e Servizio cloud di Azure. La scalabilità può essere eseguita su una pianificazione o in base a una metrica di runtime, ad esempio di uso della CPU o della memoria.

Esempi:

  • Aumentare a 10 istanze nei giorni feriali e diminuire a 4 istanze il sabato e la domenica.
  • Aumentare di un'istanza se l'uso medio della CPU è superiore al 70% e diminuire di un'istanza se l'uso della CPU è inferiore al 50%.
  • Aumentare di un'istanza se il numero di messaggi in una coda supera una determinata soglia.

Aumentare le prestazioni della risorsa quando il carico aumenta per garantire la disponibilità. Analogamente, nei periodi di utilizzo ridotto, ridurre le prestazioni, in modo da poter ottimizzare i costi. Usare sempre una combinazione di regole di scalabilità per scale-out e scale-in. In caso contrario, la scalabilità automatica viene impostata solo in una direzione finché non raggiunge la soglia (numero massimo o minimo di istanze) impostata nel profilo.

Selezionare un numero di istanze predefinito sicuro per il carico di lavoro. Viene ridimensionata in base a tale valore se il numero massimo o minimo di istanze non è impostato.

Per un elenco delle metriche predefinite, vedere Metriche comuni per la scalabilità automatica di Monitoraggio di Azure. È anche possibile implementare le metriche personalizzate tramite Application Insights.

È possibile configurare la scalabilità automatica tramite PowerShell, l'interfaccia della riga di comando di Azure, un modello di Azure Resource Manager o il portale di Azure. Per un controllo più dettagliato, usare l'API REST di Azure Resource Manager. Azure Monitoring Service Management Library e Microsoft Insights Library (anteprima) sono SDK che consentono di raccogliere metriche da diverse risorse ed eseguire il ridimensionamento automatico usando le API REST. Per le risorse in cui non è disponibile il supporto di Azure Resource Manager o se si usa Servizi cloud di Azure, è possibile usare l'API REST di Gestione dei servizi per la scalabilità automatica. In tutti gli altri casi, usare Azure Resource Manager.

Quando si usa la scalabilità automatica di Azure, considerare i punti seguenti:

  • Valutare se è possibile prevedere il carico sull'applicazione con una precisione sufficiente per usare la scalabilità automatica pianificata, aggiungendo e rimuovendo le istanze per soddisfare i picchi previsti della domanda. Se questo non è possibile, usare la scalabilità automatica reattiva basata sulle metriche di runtime per gestire le variazioni della domanda impreviste. In genere, questi approcci possono essere combinati. Creare ad esempio una strategia per aggiungere risorse in base a una pianificazione dei momenti in cui si prevede che l'applicazione sia più occupata. In questo modo è possibile garantire la disponibilità della capacità quando è necessaria, senza il ritardo nell'avvio di nuove istanze. Per ogni regola pianificata, definire le metriche che consentono la scalabilità automatica reattiva durante tale periodo per garantire che l'applicazione sia in grado di gestire picchi imprevisti ma prolungati della domanda.

  • Spesso è difficile capire la relazione tra requisiti di capacità e metrica, specialmente al momento della distribuzione iniziale di un'applicazione. Eseguire il provisioning all'inizio di una capacità aggiuntiva limitata e quindi monitorare e ottimizzare le regole di scalabilità automatica per avvicinare la capacità al carico effettivo.

  • Configurare le regole di scalabilità automatica e quindi monitorare le prestazioni dell'applicazione nel tempo. Usare i risultati del monitoraggio per regolare il modo in cui il sistema implementa la scalabilità, se necessario. Tuttavia, tenere presente che la scalabilità automatica non è un processo immediato. Richiede tempo per reagire a una metrica, ad esempio un uso medio della CPU superiore o inferiore a una soglia specificata.

  • Le regole di scalabilità automatica che usano un meccanismo di rilevamento basato su un attributo di attivazione misurato, ad esempio l'utilizzo della CPU o la lunghezza della coda, usano un valore aggregato nel tempo, invece di valori istantanei, per attivare un'azione di scalabilità automatica. Per impostazione predefinita, l'aggregazione è una media dei valori. Ciò impedisce al sistema di reagire troppo velocemente o di causare un'oscillazione rapida. Fornisce inoltre il tempo per consentire alle nuove istanze avviate automaticamente di stabilizzarsi nella modalità di esecuzione, evitando azioni di scalabilità automatica aggiuntive durante l'avvio delle nuove istanze. Per Servizi cloud di Azure e Macchine virtuali di Azure il periodo predefinito per l'aggregazione è 45 minuti, quindi può essere necessario questo periodo di tempo prima che la metrica attivi la scalabilità automatica in risposta a picchi della domanda. È possibile modificare il periodo di aggregazione tramite l'SDK, ma i periodi inferiori a 25 minuti possono causare risultati imprevisti. Per App Web il periodo medio è più breve, consentendo la disponibilità di nuove istanze in circa cinque minuti dopo una modifica della misura di attivazione media.

  • Evitare casi di instabilità in cui le azioni di riduzione e aumento del numero di istanze si succedono in continuazione. Si supponga che siano presenti due istanze e che il limite superiore sia l'80% della CPU, mentre il limite inferiore sia il 60%. Quando il carico è all'85%, viene aggiunta un'altra istanza. Dopo un certo periodo di tempo, il carico diminuisce al 60%. Prima del ridimensionamento, il servizio di scalabilità automatica calcola la distribuzione del carico totale (di tre istanze) quando un'istanza viene rimossa, portandolo al 90%. Ciò significa che sarebbe necessario aumentare di nuovo il numero di istanze. Viene quindi ignorata la riduzione del numero di istanze e i risultati di ridimensionamento previsti potrebbero non essere mai visualizzati.

    La situazione di instabilità può essere controllata scegliendo un margine adeguato tra le soglie di aumento e riduzione del numero di istanze.

  • Il ridimensionamento manuale viene reimpostato in base al numero massimo e minimo di istanze usate per la scalabilità automatica. Se si aggiorna manualmente il conteggio delle istanze impostandolo su un valore superiore o inferiore rispetto a quello massimo, il motore di scalabilità automatica utilizza automaticamente il valore minimo (se inferiore) o il valore massimo (se superiore). Ad esempio, se l'utente imposta l'intervallo tra i valori e 3 e 6, in presenza di un'istanza in esecuzione, il motore di scalabilità automatica esegue il ridimensionamento a tre istanze alla successiva esecuzione. Analogamente, se si imposta manualmente la scala su otto istanze, nell'esecuzione successiva la scalabilità automatica rieseguirà il ridimensionamento a sei istanze. La scalabilità manuale è temporanea, a meno che non si reimpostino anche le regole di scalabilità automatica.

  • Il motore di scalabilità automatica elabora un solo profilo alla volta. Se una condizione non viene soddisfatta, passa alla verifica del profilo successivo. Mantenere le metriche chiave al di fuori del profilo predefinito perché tale profilo viene controllato per ultimo. È possibile avere più regole in un profilo. In caso di aumento del numero di istanze, la scalabilità automatica viene eseguita se risulta soddisfatta una regola qualsiasi. In caso di riduzione del numero di istanze, la scalabilità automatica richiede che tutte le regole siano soddisfatte.

Per informazioni dettagliate sul ridimensionamento in Monitoraggio di Azure, vedere Procedure consigliate per la scalabilità automatica.

  • Se si configura la scalabilità automatica tramite l'SDK anziché tramite il portale, è possibile specificare una pianificazione più dettagliata durante la quale le regole sono attive. È anche possibile creare proprie metriche e usarle con o senza quelle esistenti nelle regole di scalabilità automatica. È ad esempio possibile usare contatori alternativi, come il numero di richieste al secondo o la disponibilità di memoria media oppure contatori personalizzati per misurare processi aziendali specifici.

  • Quando si esegue la scalabilità automatica di Service Fabric, i tipi di nodi nel cluster sono costituiti da set di scalabilità di macchine virtuali nel back-end, pertanto è necessario configurare le regole di scalabilità automatica per ogni tipo di nodo. Considerare il numero di nodi che devono essere disponibili prima di configurare la scalabilità automatica. Il numero minimo di nodi necessari per il tipo di nodo primario è determinato dal livello di affidabilità scelto. Per altre informazioni, vedere Aumentare o ridurre le istanze del cluster di Service Fabric con le regole di scalabilità automatica.

  • È possibile usare il portale per il collegamento di risorse come le code e le istanze del database SQL a un'istanza del servizio cloud. In questo modo è possibile accedere più facilmente alle opzioni di configurazione di scalabilità manuale e automatica separate per ognuna delle risorse collegate. Per altre informazioni, vedere Procedura: Collegare una risorsa a un servizio cloud.

  • Quando si configurano più criteri e regole, è possibile che si verifichi un conflitto. La scalabilità automatica usa le regole di risoluzione dei conflitti seguenti per garantire che sia sempre disponibile un numero sufficiente di istanze in esecuzione:

    • Le operazioni di aumento del numero di istanze hanno sempre la priorità su quelle di riduzione del numero di istanze.
    • Se si verifica un conflitto tra le operazioni di aumento del numero di istanze, la regola che avvia l'aumento maggiore del numero di istanze ha la precedenza.
    • Se si verifica un conflitto tra le operazioni di riduzione delle istanze, la regola che avvia la riduzione inferiore del numero di istanze ha la precedenza.

  • In un ambiente del servizio app, per definire le regole di scalabilità automatica è possibile usare qualsiasi metrica del pool di lavoro o del front-end. Per altre informazioni, vedere Ridimensionamento automatico e ambiente del servizio app (versione 1).

Considerazioni sulla progettazione di applicazioni

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:

  • Il sistema deve essere progettato per la scalabilità orizzontale. Evitare di fare ipotesi sulle affinità delle istanze. Non progettare soluzioni che richiedono che il codice sia sempre in esecuzione in un'istanza specifica di un processo. Quando si implementa l'aumento del numero di istanze di un servizio cloud o di sito Web, evitare di presupporre che una serie di richieste provenienti dalla stessa origine venga sempre instradata alla stessa istanza. Per lo stesso motivo, progettare servizi senza stato per evitare che richiedano l'instradamento di una serie di richieste provenienti da un'applicazione sempre alla stessa istanza di un servizio. Quando si progetta un servizio che legge i messaggi da una coda e li elabora, non presupporre quale sarà l'istanza del servizio che gestirà un messaggio specifico. La scalabilità automatica potrebbe avviare istanze aggiuntive di un servizio man mano che aumenta la lunghezza della coda. L'articolo Modello di consumer concorrenti descrive come gestire questo scenario.

  • Se la soluzione implementa un'attività a esecuzione prolungata, progettare questa attività per supportare sia l'aumento che la riduzione delle istanze. Senza la dovuta attenzione, questa operazione potrebbe impedire l'arresto corretto di un'istanza di un processo quando viene ridotto il numero di istanze del sistema o potrebbe verificarsi una perdita di dati se il processo viene terminato in modo forzato. In teoria, è consigliabile effettuare il refactoring di un'attività a esecuzione prolungata e suddividere l'elaborazione in blocchi discreti più piccoli. L'articolo Modello di pipe e filtri offre un esempio di come è possibile ottenere questo risultato.

  • In alternativa, è possibile implementare un meccanismo di checkpoint che registra informazioni sullo stato dell'attività a intervalli regolari e salva lo stato nell'archivio permanente accessibile da qualsiasi istanza del processo che esegue l'attività. In questo modo, se il processo viene arrestato, il lavoro che stava eseguendo può essere ripreso a partire dall'ultimo checkpoint mediante un'altra istanza. Esistono librerie che forniscono questa funzionalità, ad esempio NServiceBus e MassTransit. Vengono mantenuti in modo trasparente, in cui gli intervalli sono allineati all'elaborazione dei messaggi dalle code in bus di servizio di Azure.

  • Se le attività in background vengono eseguite in istanze di calcolo separate, ad esempio nei ruoli di lavoro di un'applicazione ospitata da servizi cloud, potrebbe essere necessario ridimensionare diverse parti dell'applicazione con criteri di scalabilità diversi. Ad esempio, può essere necessario distribuire altre istanze di calcolo dell'interfaccia utente senza aumentare il numero di istanze di calcolo in background o viceversa. Se si offrono diversi livelli di servizio (ad esempio pacchetti di servizi di base e premium), potrebbe essere necessario scalare orizzontalmente le risorse di calcolo per i pacchetti di servizi premium in modo più aggressivo rispetto ai pacchetti di servizi di base al fine di soddisfare i contratti di servizio.

  • Prendere in considerazione la lunghezza della coda su cui comunicano le istanze di calcolo in background e interfaccia utente. Usarlo come criterio per la strategia di scalabilità automatica. Si tratta di un indicatore possibile di uno squilibrio o di una differenza tra il carico corrente e la capacità di elaborazione dell'attività in background. C'è un attributo leggermente più complesso, ma migliore per basare le decisioni di ridimensionamento su. Usare il tempo compreso tra l'invio di un messaggio e il completamento dell'elaborazione, noto come tempo critico. Se questo valore di tempo critico è inferiore a una soglia aziendale significativa, non è necessario ridimensionare, anche se la lunghezza della coda è lunga.

    • Ad esempio, potrebbero essere presenti 50.000 messaggi in una coda, ma il tempo critico del messaggio meno recente è 500 ms e tale endpoint si occupa dell'integrazione con un servizio Web di terze parti per l'invio di messaggi di posta elettronica. È probabile che gli stakeholder aziendali considerino che sia un periodo di tempo che non giustifica la spesa aggiuntiva per il ridimensionamento.
    • D'altra parte, potrebbero essere presenti 500 messaggi in una coda, con lo stesso tempo critico di 500 ms, ma l'endpoint fa parte del percorso critico in un gioco online in tempo reale, in cui gli stakeholder aziendali hanno definito un tempo di risposta di 100 ms o meno. In questo caso, la scalabilità orizzontale avrebbe senso.
    • Per sfruttare il tempo critico nelle decisioni di ridimensionamento automatico, è utile aggiungere automaticamente le informazioni pertinenti alle intestazioni dei messaggi, mentre vengono inviate ed elaborate. Una di queste librerie che fornisce questa funzionalità è NServiceBus.

  • Se la strategia di scalabilità automatica si basa su contatori che misurano i processi aziendali, ad esempio il numero di ordini per ogni ora o il tempo di esecuzione medio di una transazione complessa, assicurarsi di capire appieno la relazione tra i risultati di questi tipi di contatori e i requisiti di capacità di calcolo effettivi. Potrebbe essere necessario implementare la scalabilità di più di un componente o unità di calcolo in risposta a cambiamenti nei contatori di processi aziendali.

  • Per impedire al sistema di implementare una scalabilità orizzontale eccessiva e per evitare i costi associati all'esecuzione di molte migliaia di istanze, provare a limitare il numero massimo di istanze che possono essere aggiunte automaticamente. La maggior parte dei meccanismi di scalabilità automatica consente di specificare il numero minimo e massimo di istanze per una regola. Prendere in considerazione anche la possibilità di ridurre gradualmente le funzionalità fornite dal sistema, se è stato distribuito il numero massimo di istanze e il sistema è ancora in overload.

  • Tenere presente che la scalabilità automatica potrebbe non essere il meccanismo più appropriato per gestire un improvviso aumento del carico di lavoro. Il provisioning e l'avvio di nuove istanze di un servizio o l'aggiunta di risorse a un sistema richiede tempo e il picco della domanda potrebbe essere passato quando queste risorse aggiuntive vengono rese disponibili. In questo scenario potrebbe essere preferibile limitare il servizio. Per altre informazioni, vedere l'articolo Modello di limitazione.

  • Se invece è necessario avere la capacità per elaborare tutte le richieste quando il volume è soggetto a fluttuazioni rapide e i costi non sono un fattore determinante, è consigliabile usare una strategia di scalabilità automatica aggressiva che avvii istanze aggiuntive più rapidamente. È anche possibile usare criteri pianificati che avviano un numero sufficiente di istanze per soddisfare il carico massimo prima che il carico sia previsto.

  • Il meccanismo di scalabilità automatica deve monitorare il processo e registrare i dettagli di ogni evento di scalabilità automatica, come la causa dell'attivazione, quali risorse sono state aggiunte o rimosse e quando. Se si crea un meccanismo di scalabilità automatica personalizzato, assicurarsi che incorpori questa funzionalità. Analizzare le informazioni per misurare l'efficacia della strategia di scalabilità automatica e ottimizzarla, se necessario. L'ottimizzazione può essere applicata sia a breve termine, man mano che i modelli di utilizzo diventano più evidenti, sia a lungo termine parallelamente all'espansione dell'azienda o all'evolversi dei requisiti dell'applicazione. Se un'applicazione raggiunge il limite superiore definito per la scalabilità automatica, il meccanismo potrebbe anche avvisare un operatore che a sua volta potrà avviare manualmente risorse aggiuntive, se necessario. Si noti che, in queste circostanze, l'operatore può anche essere responsabile della rimozione manuale di queste risorse con la riduzione del carico di lavoro.

Anche i modelli e le indicazioni seguenti possono risultare pertinenti per il proprio scenario quando si implementa la scalabilità automatica:

  • Modello di limitazione. Questo modello descrive come un'applicazione può continuare a funzionare e soddisfare i contratti di servizio quando un aumento della domanda genera un carico eccessivo sulle risorse. È possibile usare la limitazione con la scalabilità automatica per evitare che un sistema venga sovraccaricato durante l'aumento delle istanze del sistema.

  • Modello di consumer concorrenti. Questo modello descrive come implementare un pool di istanze del servizio in grado di gestire i messaggi da un'istanza dell'applicazione. La scalabilità automatica può essere usata per avviare e arrestare le istanze del servizio per soddisfare il carico di lavoro previsto. Questo modello consente a un sistema di elaborare più messaggi contemporaneamente per ottimizzare la velocità effettiva, per migliorare la scalabilità e la disponibilità e per bilanciare il carico di lavoro.

  • Monitoraggio e diagnostica. La strumentazione e la telemetria sono fondamentali per raccogliere le informazioni che consentono di gestire il processo di scalabilità automatica.