Suggerimenti per la progettazione di una strategia di scalabilità affidabile

  • Articolo

Si applica a questa raccomandazione per l'affidabilità di Azure Well-Architected Framework:

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 quello 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 delle risorse ridimensionate.

Strategie di progettazione chiave

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 di 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.

  • Dinamica, 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 dedescrizione possono riscontrare un improvviso aumento del traffico dopo un uragano o un altro evento di alluvione quando le persone nelle aree colpite devono asciugare le stanze 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 possono essere:

  • Statico: è disponibile una scalabilità pianificata dei nodi di calcolo al conteggio minimo (2) tra le 11.00 e le 6.00 est.

  • Dinamica, regolare e prevedibile: si dispone di una scalabilità orizzontale pianificata dei nodi di calcolo alla normale capacità giornaliera prima che la prima area inizi il lavoro.

  • Dinamica, irregolare e prevedibile: si definisce una scalabilità singola pianificata 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.

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.

  • I componenti che non possono essere ridimensionati. Un esempio è costituito da database relazionali di grandi dimensioni che non dispongono di partizionamento orizzontale abilitato e non può essere sottoposto a refactoring senza alcun impatto significativo. Documentare i limiti delle risorse pubblicati dal provider di servizi cloud e monitorare attentamente tali risorse. Includere queste risorse specifiche nella pianificazione futura per la migrazione a servizi scalabili.

  • Il tempo necessario per eseguire l'operazione di ridimensionamento in modo da pianificare correttamente l'operazione prima che il carico aggiuntivo colpisca l'infrastruttura. Ad esempio, se un componente come Gestione API richiede 45 minuti per la scalabilità, la modifica della soglia di ridimensionamento al 65% invece del 90% potrebbe essere utile per la scalabilità precedente e la preparazione per 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 scalando 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 sessione) implementata. La persistenza 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 più 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. È utile anche basare la progettazione della scalabilità su stamp come unità di scala. Consente inoltre di controllare strettamente 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 rispecchiarlo in base alle esigenze.

Compromesso: la scalabilità verticale ha implicazioni in termini di costi, quindi ottimizzare la strategia per ridurre al più presto le prestazioni per mantenere i costi sotto controllo. Assicurarsi che l'automazione che si sta impiegando per aumentare le prestazioni abbia 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 non integrate per la scalabilità automatica, 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 app servizio Azure Kubernetes e Azure Container.

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 di 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. Per le procedure consigliate, vedere la guida di Monitoraggio di Azure .

Compromessi

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 potrebbe 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 relative all'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 eseguito 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 dai servizi cloud, potrebbe essere necessario ridimensionare parti diverse dell'applicazione usando criteri di ridimensionamento 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 servizi 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 in base alla quale 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 momento in cui è stata completata l'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. Tuttavia, 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 della 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 il numero eccessivo 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. Valutare anche la possibilità di ridurre normalmente 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 passare per il momento 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.

Al contrario, se è necessaria la capacità per elaborare tutte le richieste quando il volume varia rapidamente e il costo non è un fattore determinante, è consigliabile usare 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

Vedere le linee guida per il ridimensionamento dell'architettura di riferimento di base del servizio Azure Kubernetes.

Elenco di controllo per l'affidabilità

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'affidabilità