Condividi tramite

Scalabilità automatica

La scalabilità automatica è il processo di allocazione dinamica delle risorse in base ai requisiti di corrispondenza delle prestazioni. Man mano che aumenta il volume di lavoro, un'applicazione può richiedere più risorse per mantenere i livelli di prestazioni desiderati e soddisfare i contratti di servizio. Man mano che la domanda diminuisce e le risorse aggiuntive non sono più necessarie, possono essere de-allocate 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:

  • Il ridimensionamento verticale, detto anche aumento e riduzione, significa modificare la capacità di una risorsa. Ad esempio, è possibile spostare un'applicazione in una macchina virtuale di dimensioni maggiori. La scalabilità verticale richiede spesso che il sistema non sia temporaneamente disponibile durante la ridistribuzione. Di conseguenza, è meno comune automatizzare la scalabilità verticale.

  • Il ridimensionamento orizzontale, detto anche scalare orizzontalmente verso l'esterno e l'interno, significa aggiungere o rimuovere 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.

Molti sistemi basati sul cloud, tra cui Microsoft Azure, supportano la scalabilità orizzontale automatica. Il resto di questo articolo è incentrato sul ridimensionamento orizzontale.

Annotazioni

La scalabilità automatica si applica principalmente alle risorse di calcolo. Sebbene sia possibile ridimensionare orizzontalmente un database o una coda di messaggi, questo processo comporta in genere il partizionamento dei dati, che in genere non è automatizzato.

Componenti di scalabilità automatica

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

  • Sistemi di strumentazione e monitoraggio a livello di applicazione, servizio e infrastruttura. Questi sistemi acquisiscono metriche chiave, ad esempio tempi di risposta, lunghezze delle code, utilizzo della CPU e utilizzo della memoria.

  • La logica decisionale valuta queste metriche di utilizzo in tempo reale rispetto a soglie o pianificazioni predefinite e decide se ridimensionare.

  • I componenti e i meccanismi eseguono l'azione di ridimensionamento. Idealmente, questi componenti e meccanismi devono essere separati dal codice del carico di lavoro stesso e gestiti come processo esterno. Il codice inattivo oppure sovraccaricato non dovrebbe essere responsabile dell'autoscalamento.

  • Test, monitoraggio e ottimizzazione delle funzionalità per la strategia di scalabilità automatica per garantire che funzioni come previsto.

Azure offre meccanismi di scalabilità automatica predefiniti che consentono di gestire scenari comuni. Se un particolare servizio o tecnologia non dispone di funzionalità di scalabilità automatica predefinite o se si hanno requisiti di scalabilità automatica specifici oltre le relative funzionalità, prendere in considerazione un'implementazione personalizzata. Un'implementazione personalizzata raccoglie le metriche operative e di sistema, analizza le metriche e ridimensiona le risorse di conseguenza.

Configurare la scalabilità automatica per una soluzione di Azure

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

Queste opzioni di calcolo usano tutte la funzionalità di scalabilità automatica di Monitoraggio di Azure per fornire un set comune di funzionalità di scalabilità automatica.

  • Funzioni di Azure differisce dalle opzioni di calcolo precedenti perché non è necessario configurare regole di scalabilità automatica. Funzioni di Azure alloca invece automaticamente la potenza di calcolo quando viene eseguito il codice. Azure Functions scala orizzontalmente in base alle esigenze per gestire il carico. Per altre informazioni, vedere Scegliere il piano di hosting corretto per Funzioni di Azure.

Una soluzione di scalabilità automatica personalizzata può talvolta essere utile. Ad esempio, è possibile usare Diagnostica di Azure e le metriche basate su applicazioni, 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 Azure Resource Manager per attivare la scalabilità automatica. Tuttavia, una soluzione personalizzata non è semplice da implementare e deve essere considerata solo se nessuno degli approcci precedenti può soddisfare i requisiti.

Se soddisfano i requisiti, usare le funzionalità di scalabilità automatica predefinite della piattaforma. In caso contrario, valutare attentamente se sono necessarie funzionalità di ridimensionamento più complesse. Esempi di altri requisiti possono includere una maggiore granularità del controllo, diversi modi per rilevare gli eventi di attivazione per il ridimensionamento, la scalabilità tra sottoscrizioni e il ridimensionamento di altri tipi di risorse.

Utilizzare la funzionalità di autoscaling di Azure Monitor

La funzionalità di scalabilità automatica di Azure Monitor offre un set comune di funzionalità di scalabilità automatica per i set di scalabilità delle macchine virtuali, l'App Service e i servizi cloud di Azure. Il ridimensionamento può essere eseguito in base a una pianificazione o in base a una metrica di runtime, ad esempio l'utilizzo della CPU o della memoria.

Si considerino gli esempi seguenti:

  • Ridimensionare fino a 10 istanze nei giorni feriali e ridimensionare a quattro istanze il sabato e la domenica.

  • Aggiungere un'istanza se l'utilizzo medio della CPU è superiore a 70%e ridurre di un'istanza se l'utilizzo della CPU scende al di sotto di 50%.

  • Scalare di un'istanza se il numero di messaggi in una coda supera una certa soglia.

Aumentare le prestazioni della risorsa quando il carico aumenta per garantire la disponibilità. A volte di basso utilizzo, ridurre le prestazioni in modo da poter ottimizzare i costi. Usare sempre una combinazione di regole di scalabilità orizzontale e scalabilità verticale. In caso contrario, la scalabilità automatica viene eseguita solo in una direzione fino a raggiungere la soglia (numero massimo o minimo di istanze) impostata nel profilo.

Selezionare un numero di istanze predefinito sicuro per il carico di lavoro. La risorsa 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 il ridimensionamento automatico di Monitoraggio di Azure. È anche possibile implementare metriche personalizzate usando Application Insights.

È possibile configurare la scalabilità automatica usando 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 Resource Manager. La libreria di gestione di monitoraggio di Azure e la libreria di Microsoft Insights (in anteprima) sono SDK che consentono di raccogliere metriche da risorse diverse ed eseguire la scalabilità automatica usando le API REST. Per le risorse in cui il supporto di Resource Manager non è disponibile 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 Resource Manager.

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

  • Valutare se è possibile prevedere il carico sull'applicazione in modo accurato per usare la scalabilità automatica pianificata, aggiungendo e rimuovendo istanze per soddisfare i picchi previsti della domanda. Se non riesci a farlo, usa la scalabilità automatica reattiva basata sulle metriche del tempo di esecuzione per gestire variazioni imprevedibili della domanda. In genere, è possibile combinare questi approcci.

    Ad esempio, creare una strategia che aggiunge risorse in base a una pianificazione degli orari in cui si sa che l'applicazione è più trafficato. Risorse aggiuntive consentono di garantire che la capacità sia disponibile quando necessario, senza alcun ritardo dall'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 possa gestire picchi sostenuti ma imprevedibili della domanda.

  • Spesso è difficile comprendere la relazione tra metriche e requisiti di capacità, soprattutto quando un'applicazione viene inizialmente distribuita. Configurare una capacità aggiuntiva all'inizio 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 di questo monitoraggio per regolare il modo in cui il sistema viene ridimensionato, se necessario. Tenere tuttavia presente che la scalabilità automatica non è un processo istantaneo. Può volerci del tempo per reagire a una metrica, come quando l'utilizzo medio della CPU supera o scende al di sotto di una soglia specificata.

  • Le regole di scalabilità automatica che usano un meccanismo di rilevamento basato su un attributo trigger misurato usano un valore aggregato nel tempo, anziché valori istantanei, per attivare un'azione di scalabilità automatica. Gli attributi del trigger includono l'utilizzo della CPU o la lunghezza della coda. Per impostazione predefinita, l'aggregazione è una media dei valori. Questo approccio impedisce al sistema di reagire troppo rapidamente o causare un'oscillazione rapida. Consente anche il tempo necessario affinché le nuove istanze, avviate automaticamente, si stabilizzino nella modalità operativa. Altre azioni di scalabilità automatica non possono verificarsi durante l'avvio delle nuove istanze. Per Servizi cloud di Azure e Macchine virtuali di Azure, il periodo predefinito per l'aggregazione è di 45 minuti. Può quindi essere necessario fino a questo lasso di tempo affinché la misura attivi la scalabilità automatica in risposta ai picchi della domanda. È possibile modificare il periodo di aggregazione usando l'SDK, ma i periodi di meno di 25 minuti potrebbero causare risultati imprevedibili. Per la funzionalità Web Apps di App Service, il periodo di calcolo della media è più breve, consentendo la disponibilità di nuove istanze in circa cinque minuti dopo una modifica al valore medio di attivazione.

  • Evitare il flapping, dove le azioni di scalabilità orizzontale e verticale continuano ad alternarsi. Si supponga che siano presenti due istanze. Il limite massimo è 80% CPU e il limite inferiore è 60%. Quando il carico è a 85%, viene aggiunta un'altra istanza. Dopo qualche tempo, il carico diminuisce a 60%. Prima che il servizio di scalabilità automatica venga ridimensionato, calcola la distribuzione del carico totale (di tre istanze) quando un'istanza viene rimossa, portandola a 90%. Sarebbe necessario scalare nuovamente immediatamente. Pertanto, evita il ridimensionamento e potrebbe non visualizzare mai il risultato di ridimensionamento previsto.

    La situazione di flapping può essere controllata scegliendo un margine adeguato tra le soglie scale-out e scale-in.

  • La scalabilità manuale viene reimpostata in base al numero massimo e minimo di istanze usate per la scalabilità automatica. Se si aggiorna manualmente il numero di istanze a un valore superiore o inferiore al valore massimo, il motore di scalabilità automatica torna automaticamente al valore minimo (se inferiore) o al massimo (se superiore). Ad esempio, si imposta l'intervallo compreso tra tre e sei. Se si dispone di un'istanza in esecuzione, il motore di scalabilità automatica ridimensiona a tre istanze alla successiva esecuzione. Analogamente, se si imposta manualmente la scala su otto istanze, la scala automatica la riporta a sei istanze nella sua esecuzione successiva. Il ridimensionamento manuale è temporaneo, a meno che non si reimpostano anche le regole di scalabilità automatica.

  • Il motore di scalabilità automatica elabora un solo profilo alla volta. Se una condizione non viene soddisfatta, verifica la presenza del profilo successivo. Mantenere le metriche chiave fuori dal profilo predefinito perché il profilo è stato controllato per ultimo. All'interno di un profilo è possibile avere più regole. In caso di scalabilità orizzontale, la scalabilità automatica si attiva se si soddisfa una qualsiasi regola. La scalabilità automatica su larga scala richiede che tutte le regole siano soddisfatte.

    Per altre informazioni sulla scalabilità di Monitoraggio di Azure, vedere Procedure consigliate per la scalabilità automatica.

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

  • Quando si ridimensiona automaticamente Service Fabric, i tipi di nodo nel cluster sono costituiti da set di scalabilità di macchine virtuali nel back-end, quindi è necessario configurare le regole di scalabilità automatica per ogni tipo di nodo. Prendere in considerazione il numero di nodi che è necessario avere prima di configurare la scalabilità automatica. Il livello di affidabilità determina il numero minimo di nodi necessari per il tipo di nodo primario. Per altre informazioni, vedere Ridimensionare un cluster di Service Fabric in o in uscita usando le regole di scalabilità automatica.

  • È possibile usare il portale per collegare risorse come istanze e code del database SQL di Azure a un'istanza del servizio cloud. Questo metodo consente di accedere più facilmente alle opzioni di configurazione di scalabilità manuale e automatica separate per ognuna delle risorse collegate. Per altre informazioni, vedere Gestire i servizi cloud di Azure.

  • Quando si configurano più criteri e regole, possono entrare in conflitto tra loro. La scalabilità automatica utilizza le seguenti regole di risoluzione dei conflitti per garantire che ci sia sempre un numero sufficiente di istanze in esecuzione.

    • Le operazioni di scalabilità orizzontale hanno sempre la precedenza sulle operazioni di riduzione di scala.

    • Quando le operazioni di ridimensionamento orizzontale sono in conflitto, la regola che comporta l'aumento maggiore del numero di istanze ha la precedenza.

    • Quando le operazioni di ridimensionamento sono in conflitto, la regola che avvia la riduzione minima del numero di istanze ha la precedenza.

  • In un ambiente del servizio app è possibile usare qualsiasi pool di lavoro o metrica front-end per definire regole di scalabilità automatica. Per ulteriori informazioni, vedere la panoramica di App Service Environment.

Considerazioni sulla progettazione delle applicazioni

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 un miglioramento delle prestazioni del sistema. Quando si progetta una strategia di scalabilità automatica, tenere presente quanto segue:

  • Il sistema deve essere progettato per essere scalabile orizzontalmente. Evitare di fare ipotesi sull'affinità di istanza. Non progettare soluzioni che richiedono che il codice sia sempre in esecuzione in un'istanza specifica di un processo. Quando si ridimensiona un servizio cloud o un sito Web orizzontalmente, non si presuppone che una serie di richieste provenienti dalla stessa origine venga sempre instradata alla stessa istanza. Per lo stesso motivo, progettare i servizi in modo che siano senza stato per evitare di necessitare una serie di richieste da un'applicazione che vengano sempre indirizzate alla stessa istanza del servizio. Quando si progetta un servizio che legge i messaggi da una coda e li elabora, non fare ipotesi su quale istanza del servizio gestisce un messaggio specifico. La scalabilità automatica può avviare più istanze di un servizio man mano che aumenta la lunghezza della coda. Il modello dei consumatori concorrenti descrive come gestire questo scenario.

  • Se la soluzione implementa un'attività a esecuzione prolungata, progettare questa attività per supportare sia la scalabilità verso l'esterno che verso l'interno. Senza una progettazione corretta, un'attività di questo tipo potrebbe impedire l'arresto pulito di un'istanza di un processo quando il sistema viene scalato verso l'interno. Oppure potrebbe perdere dati se il processo viene terminato forzatamente. Idealmente, effettuare il refactoring di un'attività a esecuzione prolungata e suddividere l'elaborazione eseguita in blocchi più piccoli e discreti. Per un esempio, vedere Modello tubi e filtri.

  • In alternativa, è possibile implementare un meccanismo di checkpoint che registra informazioni sullo stato dell'attività a intervalli regolari. Salvare queste informazioni sullo stato nell'archiviazione durevole a cui può accedere qualsiasi istanza del processo che esegue l'attività. Pertanto, se il processo viene arrestato, il lavoro che stava eseguendo può essere ripreso dall'ultimo checkpoint utilizzando un'altra istanza. Sono disponibili librerie che forniscono questa funzionalità, ad esempio NServiceBus e MassTransit. Mantengono in modo trasparente lo stato di persistenza, in cui gli intervalli sono allineati all'elaborazione dei messaggi provenienti dalle code nel bus di servizio di Azure.

  • Quando le attività in background vengono eseguite in istanze di calcolo separate, ad esempio nei ruoli di lavoro di un'applicazione ospitata dai servizi cloud, potrebbe essere necessario ridimensionare parti diverse dell'applicazione usando criteri di scalabilità diversi. Ad esempio, potrebbe essere necessario distribuire più istanze di calcolo dell'interfaccia utente senza aumentare il numero di istanze di calcolo in background o l'opposto. È possibile offrire diversi livelli di servizio, ad esempio pacchetti di servizio basic e Premium. Potrebbe essere necessario aumentare le risorse di calcolo per i pacchetti di servizio Premium in modo più aggressivo rispetto alle risorse per i pacchetti di servizio di base. Questo approccio consente di soddisfare gli accordi sul livello di servizio.

Altri criteri di ridimensionamento

  • Prendere in considerazione la lunghezza della coda su cui le istanze di calcolo dell'interfaccia utente e di background comunicano. Usarlo come criterio per la strategia di scalabilità automatica. Questi criteri possono indicare uno squilibrio o 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 temporale 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 momento critico del messaggio più vecchio è 500 ms e quell'endpoint sta gestendo l'integrazione con un servizio web del partner per l'invio di email. Gli stakeholder aziendali potrebbero non considerare questo scenario abbastanza urgente da giustificare il costo dell'espansione.

    • D'altra parte, potrebbero esserci 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 tal caso, espandere il numero di istanze ha senso.

    • Per utilizzare in modo efficace il tempo fondamentale nelle decisioni di scalabilità automatica, è utile che una libreria aggiunga automaticamente le informazioni pertinenti alle intestazioni dei messaggi durante la trasmissione e l'elaborazione. Una di queste librerie che fornisce questa funzionalità è NServiceBus.

  • Se si basa la strategia di scalabilità automatica sui contatori che misurano i processi aziendali, assicurarsi di comprendere appieno la relazione tra i risultati di questi tipi di contatori e i requisiti effettivi di capacità di calcolo. Esempi di contatori includono il numero di ordini effettuati ogni ora o il runtime medio di una transazione complessa. Potrebbe essere necessario ridimensionare più componenti o unità di calcolo in risposta alle modifiche apportate ai contatori dei processi aziendali.

  • Per evitare che un sistema tenti di aumentare il numero eccessivo di istanze, è consigliabile limitare il numero massimo di istanze che possono essere aggiunte automaticamente. Questo approccio evita anche i costi associati all'esecuzione di molte migliaia di istanze. La maggior parte dei meccanismi di scalabilità automatica consente di specificare il numero minimo e massimo di istanze per una regola. È inoltre consigliabile ridurre correttamente le funzionalità fornite dal sistema se si distribuisce il numero massimo di istanze e il sistema è ancora sovraccarico.

  • Tieni presente che la scalabilità automatica potrebbe non essere il meccanismo più appropriato per gestire un improvviso picco nel carico di lavoro. La configurazione e l'avvio di nuove istanze di un servizio richiedono tempo o l'aggiunta di risorse a un sistema. E il picco della domanda potrebbe trascorrere nel tempo in cui queste risorse aggiuntive sono disponibili. In questo scenario, potrebbe essere preferibile limitare il servizio. Per altre informazioni, vedere Pattern di throttling.

  • Viceversa, se è necessaria la capacità per elaborare tutte le richieste quando il volume fluttua rapidamente, è consigliabile usare una strategia di scalabilità automatica aggressiva che avvia istanze aggiuntive più rapidamente. Assicurarsi che il costo non sia un fattore determinante. È 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 di scalabilità automatica e registrare i dettagli di ogni evento di scalabilità automatica. Questi dettagli includono ciò che ha attivato l'evento, quali risorse sono state aggiunte o rimosse e quando si è verificato. Se si crea un meccanismo di scalabilità automatica personalizzato, assicurarsi che incorpora questa funzionalità. Analizzare le informazioni per misurare l'efficacia della strategia di scalabilità automatica e ottimizzarla, se necessario. È possibile ottimizzare entrambi a breve termine, man mano che i modelli di utilizzo diventano più evidenti e a lungo termine, man mano che l'azienda si espande o i requisiti dell'applicazione si evolve. Se un'applicazione raggiunge il limite massimo definito per la scalabilità automatica, il meccanismo potrebbe anche avvisare un operatore che potrebbe avviare manualmente risorse aggiuntive, se necessario. In queste circostanze, l'operatore potrebbe anche essere responsabile della rimozione manuale di queste risorse dopo la riduzione del carico di lavoro.

I modelli e le indicazioni seguenti potrebbero essere rilevanti anche per lo scenario durante l'implementazione della scalabilità automatica:

  • Il modello di limitazione descrive come un'applicazione può continuare a funzionare e soddisfare i contratti di servizio quando un aumento della domanda comporta un carico estremo sulle risorse. La limitazione può essere utilizzata con l'autoscaling per evitare che un sistema venga sovraccaricato durante l'espansione del sistema.

  • Il modello dei consumatori concorrenti descrive come implementare un pool di istanze di servizio capaci di gestire messaggi provenienti da qualsiasi istanza applicativa. La scalabilità automatica può essere usata per avviare e arrestare le istanze del servizio in modo che corrispondano al carico di lavoro previsto. Questo approccio consente a un sistema di elaborare più messaggi contemporaneamente per ottimizzare la velocità effettiva, migliorare la scalabilità e la disponibilità e bilanciare il carico di lavoro.

  • Il monitoraggio e la diagnostica, inclusa la strumentazione e le metriche, sono fondamentali per raccogliere le informazioni che possono guidare il processo di scalabilità automatica.