Raccomandazioni per la progettazione di una strategia di scalabilità affidabile

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

Guida correlata:Partizionamento dei dati

Questa guida descrive le raccomandazioni per la progettazione di una strategia di scalabilità affidabile.

Definizioni

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 le 11.00 est, il numero di utenti attivi è inferiore a 100 e l'utilizzo della CPU per i server app scende di 90% in tutti i nodi.

• dinamica, regolare e prevedibile: ogni lunedì mattina, 1000 dipendenti in più aree accedono al sistema ERP.

• dinamico, irregolare e prevedibile: il lancio di un prodotto avviene il primo giorno del mese e sono presenti dati cronologici dei precedenti lanci 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 che producono e vendono deumidificatori possono sperimentare un improvviso aumento del traffico dopo un uragano o un altro evento di alluvione quando le persone nelle aree colpite hanno bisogno di asciugare le stanze nelle loro case.

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: È prevista una riduzione programmata dei tuoi nodi di calcolo al numero minimo (2) tra le 23:00 e le 6:00 EST.

• Dinamica, regolare e prevedibile: hai un ampliamento pianificato dei nodi di calcolo alla normale capacità giornaliera prima che la prima regione inizi a lavorare.

• dinamico, 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.

Automatizzare le strategie di ridimensionamento

Quando si progetta l'automazione del ridimensionamento, assicurarsi di tenere conto di questi problemi:

• Che tutti i componenti del tuo carico di lavoro siano candidati per l'implementazione di soluzioni di scaling. Nella maggior parte dei casi, i servizi globali come Microsoft Entra ID si ridimensionano automaticamente e in modo trasparente per voi e i vostri clienti. Assicurarsi di comprendere le funzionalità di ridimensionamento dei controller di ingresso e uscita di rete e della soluzione di bilanciamento del carico.

• Quei componenti che non possono essere scalati. Un esempio è costituito da database relazionali di grandi dimensioni che non hanno il partizionamento orizzontale abilitato e che non possono essere ristrutturati senza un 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.

• Il 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 la scalabilità, modificare la soglia di ridimensionamento su 65% anziché 90% potrebbe aiutare a ridimensionare in precedenza e preparare l'aumento previsto del carico.

• Relazione dei componenti del flusso in termini di ordine di operazioni di scalabilità. Assicurarsi di non caricare eccessivamente un componente a valle ridimensionando prima un componente a monte.

• Tutti gli elementi con stato dell'applicazione che potrebbero essere interrotti da un'operazione di ridimensionamento e qualsiasi affinità di sessione implementata. L'aderenza può limitare la capacità di scalare e introduce punti unici di guasto.

• 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 a stato del sistema sono la causa più probabile dei colli di bottiglia.

Seguire il modello di progettazione del timbro di distribuzione aiuta nella 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 modello di distribuzione e quindi replicarle su altri modelli in base alle esigenze.

Tradeoff: L'aumento di scala ha implicazioni sui costi; quindi, ottimizza la tua strategia per ridurre la scala il più presto possibile, aiutando a 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 dell'hub IoT di Azure. È possibile usare strumenti come KEDA per la scalabilità automatica guidata dagli eventi, disponibile in servizio Azure Kubernetes e App Azure Container.

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 di Azure, il servizio app di Azure, le Azure Spring Apps 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. L'aggiunta di risorse a un sistema o l'esecuzione di più istanze di un processo non garantisce che le prestazioni del sistema migliorino. 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 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 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. Idealmente, effettuare il refactoring di un'attività a esecuzione prolungata e suddividere l'elaborazione eseguita in blocchi più piccoli e discreti. Il modello Pipes and Filters fornisce un esempio di come si possa 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 punto di controllo 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 le istanze di calcolo dell'interfaccia utente e di background comunicano. 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, scalare orizzontalmente avrebbe senso.

Per utilizzare efficacemente il tempo critico nelle decisioni di scalabilità automatica, è utile disporre di una libreria che aggiunga 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.

Si ricordi che la scalabilità automatica potrebbe non essere il meccanismo più appropriato per gestire un improvviso aumento nel 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 il modello di limitazione .

Viceversa, se hai bisogno della capacità di elaborare tutte le richieste quando il volume fluttua rapidamente e il costo non è un fattore determinante, prendi in considerazione l'uso di una strategia di scalabilità automatica aggressiva che avvia più istanze in modo più rapido. È 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 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 altre risorse, se necessario. In queste circostanze, l'operatore potrebbe anche essere responsabile della rimozione manuale di queste risorse dopo la riduzione del carico di lavoro.

Esempio

Fare riferimento all'architettura di riferimento del servizio Azure Kubernetes baseline per le indicazioni sulla scalabilità.

Collegamenti correlati

• scalabilità dell'efficienza delle prestazioni
• Procedure consigliate per la scalabilità automatica

Elenco di controllo per l'affidabilità

Fare riferimento al set completo di raccomandazioni.