Raccomandazioni per la progettazione di una strategia di scalabilità affidabile
Si applica a questa raccomandazione per l'affidabilità del framework ben progettato di Azure:
| RE:06 | Implementare una strategia di scalabilità tempestiva e affidabile a livello di applicazione, dati e infrastruttura. |
|---|
Guida correlata: Partizionamento dei dati
Questa guida descrive le raccomandazioni per la progettazione di una strategia di scalabilità affidabile.
Definizioni
| Termine | Definizione |
|---|---|
| Scalabilità verticale | Approccio di ridimensionamento che aggiunge capacità di calcolo alle risorse esistenti. |
| Scalabilità orizzontale | Approccio di ridimensionamento che aggiunge istanze di un determinato tipo di risorsa. |
| Scalabilità automatica | Approccio di ridimensionamento che aggiunge o rimuove automaticamente le risorse quando viene soddisfatto un set di condizioni. |
Nota
Le operazioni di ridimensionamento possono essere statiche (ridimensionamento giornaliero pianificato regolarmente per soddisfare i normali modelli di carico), automatico (processo automatizzato in risposta alle condizioni soddisfatte) o manuale (un operatore esegue un'operazione di ridimensionamento una tantum in reazione a una modifica imprevista del carico). Sia il ridimensionamento verticale che orizzontale possono essere eseguiti tramite uno di questi metodi. Tuttavia, il ridimensionamento verticale automatico richiede uno sviluppo di automazione personalizzato aggiuntivo e può causare tempi di inattività a seconda della scalabilità delle risorse.
Strategie di progettazione chiave
Progettare in base ai modelli di carico
Per progettare una strategia di scalabilità affidabile per i carichi di lavoro, concentrarsi sull'identificazione dei modelli di carico per l'utente e i flussi di sistema per ogni carico di lavoro che porta a un'operazione di ridimensionamento. Ecco alcuni esempi dei diversi modelli di carico:
Statico: ogni notte entro 11 PM EST, il numero di utenti attivi è inferiore a 100 e l'utilizzo della CPU per i server app scende del 90% in tutti i nodi.
Dinamica, regolare e prevedibile: ogni lunedì mattina, 1000 dipendenti in più aree accedono al sistema ERP.
Dinamica, irregolare e prevedibile: il lancio di un prodotto avviene il primo giorno del mese e sono presenti dati cronologici dei lanci precedenti sul modo in cui il traffico aumenta in queste situazioni.
Dinamico, irregolare e imprevedibile: un evento su larga scala causa un picco della domanda di un prodotto. Ad esempio, le aziende manifatturiere e la vendita di deifiers possono sperimentare un improvviso aumento del traffico dopo un uragano o un altro evento di alluvione quando le persone nelle aree colpite devono asciugare i locali nella loro casa.
Dopo aver identificato questi tipi di modelli di carico, è possibile:
Identificare il modo in cui la modifica del carico associata a ogni modello influisce sull'infrastruttura.
Creare l'automazione per risolvere il ridimensionamento in modo affidabile.
Per gli esempi precedenti, le strategie di ridimensionamento potrebbero essere:
Statico: è disponibile una scalabilità pianificata dei nodi di calcolo al conteggio minimo (2) tra le 11 e le 16:00 est.
Dinamica, regolare e prevedibile: è disponibile una scalabilità orizzontale pianificata dei nodi di calcolo alla normale capacità giornaliera prima dell'avvio del lavoro della prima area.
Dinamica, irregolare e prevedibile: si definisce una scalabilità pianificata una tantum delle istanze di calcolo e di database al mattino del lancio di un prodotto e si esegue il ridimensionamento dopo una settimana.
Dinamica, irregolare e imprevedibile: sono state definite soglie di scalabilità automatica per tenere conto dei picchi di traffico non pianificati.
Automatizzare le strategie di ridimensionamento
Quando si progetta l'automazione del ridimensionamento, assicurarsi di tenere conto di questi problemi:
Tutti i componenti del carico di lavoro devono essere candidati per l'implementazione del ridimensionamento. Nella maggior parte dei casi, i servizi globali come Microsoft Entra ID vengono ridimensionati automaticamente e in modo trasparente per l'utente e i clienti. Assicurarsi di comprendere le funzionalità di ridimensionamento dei controller di ingresso e uscita di rete e della soluzione di bilanciamento del carico.
Questi componenti che non possono essere ridimensionati. Un esempio è costituito da database relazionali di grandi dimensioni che non hanno il partizionamento orizzontale abilitato e che non possono essere refactoring senza alcun impatto significativo. Documentare i limiti delle risorse pubblicati dal provider di servizi cloud e monitorare attentamente tali risorse. Includere tali risorse specifiche nella pianificazione futura per la migrazione a servizi scalabili.
Tempo necessario per eseguire l'operazione di ridimensionamento in modo da pianificare correttamente l'operazione prima che il carico aggiuntivo raggiunge l'infrastruttura. Ad esempio, se un componente come Gestione API richiede 45 minuti per ridimensionare, la regolazione della soglia di ridimensionamento al 65% invece del 90% potrebbe aiutare a ridimensionare in precedenza e preparare l'aumento previsto del carico.
Relazione dei componenti del flusso in termini di ordine delle operazioni di scalabilità. Assicurarsi di non eseguire inavvertitamente l'overload di un componente downstream ridimensionando prima un componente upstream.
Tutti gli elementi dell'applicazione con stato che potrebbero essere interrotti da un'operazione di ridimensionamento e da qualsiasi affinità di sessione (o persistenza della sessione) implementata. La permanentità può limitare la capacità di ridimensionamento e introduce singoli punti di errore.
Potenziali colli di bottiglia. La scalabilità orizzontale non risolve ogni problema di prestazioni. Ad esempio, se il database back-end è il collo di bottiglia, non è utile aggiungere altri server Web. Identificare e risolvere i colli di bottiglia nel sistema prima di aggiungere altre istanze. Le parti con stato del sistema sono le cause più probabili dei colli di bottiglia.
Seguendo il modello di progettazione dello stamp di distribuzione è utile per la gestione complessiva dell'infrastruttura. Basare la progettazione del ridimensionamento sui francobolli come unità di scala è utile anche. Consente inoltre di controllare rigorosamente le operazioni di ridimensionamento tra più carichi di lavoro e subset di carichi di lavoro. Invece di gestire le pianificazioni di ridimensionamento e le soglie di scalabilità automatica di molte risorse distinte, è possibile applicare un set limitato di definizioni di ridimensionamento a un indicatore di distribuzione e quindi eseguire il mirroring in base alle esigenze.
Compromesso: la scalabilità verticale ha implicazioni sui costi, quindi ottimizzare la strategia per ridurre le prestazioni il prima possibile per mantenere i costi sotto controllo. Assicurarsi che l'automazione che si sta impiegando per aumentare le prestazioni include anche trigger per ridurre le prestazioni.
Facilitazione di Azure
Una funzionalità di scalabilità automatica è disponibile in molti servizi di Azure. Consente di configurare facilmente le condizioni per ridimensionare automaticamente le istanze orizzontalmente. Alcuni servizi hanno funzionalità limitate o senza funzionalità predefinite per il ridimensionamento automatico, quindi assicurarsi di documentare questi casi e definire i processi per gestire il ridimensionamento.
Molti servizi di Azure offrono API che è possibile usare per progettare operazioni di ridimensionamento automatico personalizzate usando Automazione di Azure, ad esempio gli esempi di codice in Ridimensionamento automatico delle hub IoT di Azure. È possibile usare strumenti come KEDA per la scalabilità automatica guidata dagli eventi, disponibile in servizio Azure Kubernetes e app contenitore di Azure.
La scalabilità automatica di Monitoraggio di Azure offre un set comune di funzionalità di scalabilità automatica per Azure set di scalabilità di macchine virtuali, servizio app Azure, App Azure Spring e altro ancora. 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. Vedere la guida di Monitoraggio di Azure per le procedure consigliate.
Svantaggi
Considerazioni sulla 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:
Il sistema deve essere progettato per la scalabilità orizzontale. 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 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 può avviare più istanze 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 prestare attenzione, un'attività di questo tipo potrebbe impedire l'arresto pulito di un'istanza di un processo quando il sistema viene ridimensionato. In alternativa, potrebbe perdere dati se il processo termina forzatamente. In teoria, è consigliabile effettuare il refactoring di un'attività a esecuzione prolungata e suddividere l'elaborazione in blocchi discreti più piccoli. Il modello Pipe e filtri fornisce un esempio di come è possibile ottenere questa soluzione.
In alternativa, è possibile implementare un meccanismo di checkpoint che registra informazioni sullo stato dell'attività a intervalli regolari. È quindi possibile salvare questo stato in una risorsa di archiviazione durevole 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 dall'ultimo checkpoint da un'altra istanza. Sono disponibili 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.
Quando le attività in background vengono eseguite in istanze di calcolo separate, ad esempio nei ruoli di lavoro di un'applicazione ospitata in servizi cloud, potrebbe essere necessario ridimensionare parti diverse dell'applicazione usando criteri di scalabilità diversi. Ad esempio, potrebbe essere necessario distribuire istanze di calcolo aggiuntive 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 servizio basic e Premium, potrebbe essere necessario aumentare le risorse di calcolo per i pacchetti di servizio Premium in modo più aggressivo rispetto ai pacchetti di servizio di base per soddisfare i contratti di servizio.
Prendere in considerazione la lunghezza della coda su cui comunicano istanze di calcolo in background e interfaccia utente. Usarlo come criterio per la strategia di scalabilità automatica. Questo problema è un possibile indicatore di uno squilibrio o di una differenza tra il carico corrente e la capacità di elaborazione dell'attività in background. Un attributo leggermente più complesso ma migliore su cui basare le decisioni di ridimensionamento consiste nell'usare il tempo tra l'invio di un messaggio e il completamento dell'elaborazione. Questo intervallo è 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 tempo critico del messaggio meno recente è 500 ms e l'endpoint sta gestendo l'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 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, l'aumento del numero di istanze avrebbe senso.
Per usare il tempo critico nelle decisioni di scalabilità automatica, è utile aggiungere automaticamente le informazioni pertinenti alle intestazioni dei messaggi durante l'invio e l'elaborazione. Una libreria che fornisce questa funzionalità è NServiceBus.
Se si basa la strategia di scalabilità automatica su contatori che misurano i processi aziendali, ad esempio il numero di ordini effettuati all'ora o il tempo medio di esecuzione di una transazione complessa, assicurarsi di comprendere appieno la relazione tra i risultati di questi tipi di contatori e i requisiti effettivi di capacità di calcolo. 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 eccessivamente il numero di istanze e di evitare i costi associati all'esecuzione di molte migliaia di istanze, è consigliabile limitare il numero massimo di istanze aggiunte automaticamente. 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 il numero massimo di istanze è stato distribuito e il sistema è ancora sovraccarico.
Tenere presente che la scalabilità automatica potrebbe non essere il meccanismo più appropriato per gestire un improvviso burst in un 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 trascorrere nel tempo in cui sono disponibili queste risorse aggiuntive. In questo scenario, potrebbe essere preferibile limitare il servizio. Per altre informazioni, vedere l'articolo Modello di limitazione.
Viceversa, se è necessaria la capacità per elaborare tutte le richieste quando il volume fluttua rapidamente e il costo non è un fattore determinante, valutare l'uso di una strategia di scalabilità automatica aggressiva che avvia più rapidamente istanze. È 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 (cosa ha attivato, 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 massimo definito per la scalabilità automatica, il meccanismo potrebbe anche avvisare un operatore che potrebbe avviare manualmente altre risorse, se necessario. In queste circostanze, l'operatore potrebbe anche essere responsabile della rimozione manuale di queste risorse dopo la facilità del carico di lavoro.
Esempio
Fare riferimento alle linee guida per il ridimensionamento dell'architettura di riferimento della baseline del servizio Azure Kubernetes.
Collegamenti correlati
- Ridimensionamento dell'efficienza delle prestazioni
- Procedure consigliate per la scalabilità automatica
Elenco di controllo per l'affidabilità
Fare riferimento al set completo di raccomandazioni.