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:

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

Definizioni

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.

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.

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 di modelli di carico diversi e le strategie di ridimensionamento corrispondenti:

• Statico: Ogni notte entro 11 PM EST, il numero di utenti attivi dell'applicazione scende al di sotto di 100 e l'utilizzo della CPU per i server app scende di 90% in tutti i nodi. Per gestire questo problema, è possibile pianificare la riduzione delle prestazioni dei nodi di calcolo al numero minimo (2) tra le 11 e le 6:00 est.

• Dinamica, regolare e prevedibile: Ogni lunedì mattina, 1000 dipendenti in più aree accedono al sistema ERP. Per gestire questo problema, è possibile pianificare la scalabilità orizzontale dei nodi di calcolo alla normale capacità giornaliera prima dell'avvio del lavoro della prima area.

• 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. Per risolvere questo problema, è possibile definire una scalabilità orizzontale pianificata delle istanze di calcolo e di database al mattino del lancio di un prodotto e ridurre le prestazioni dopo una settimana.

• 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 didei 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 nelle loro case. Per gestire questo problema, è possibile impostare soglie di scalabilità automatica per tenere conto dei picchi di traffico non pianificati.

Adattare le strategie di ridimensionamento per adattarsi a singoli componenti o flussi

Non esiste alcuna strategia di ridimensionamento adatta alle dimensioni. I diversi servizi cloud hanno diversi gradi di supporto per il ridimensionamento e diversi approcci alla scalabilità. Per questo motivo, è importante comprendere in che modo il ridimensionamento è supportato e implementato in tutti i componenti del carico di lavoro per progettare la strategia di scalabilità complessiva. È possibile applicare strategie di ridimensionamento a livello di singolo componente o a livello di flusso, a seconda della progettazione dell'architettura. Quando si determina come implementare la scalabilità nel carico di lavoro, considerare questi fattori:

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

• 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. Progettare il carico di lavoro in modo che sia senza stato nella misura pratica.

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

• Gestione delle attività a esecuzione prolungata. Progettare un'attività a esecuzione prolungata per supportare sia l'aumento del numero di istanze che il ridimensionamento. 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.

Scelta della tecnologia appropriata

Facendo scelte tecnologiche ben informate tenendo conto del ridimensionamento, il carico di lavoro sarà in grado di garantire che il carico di lavoro possa soddisfare gli obiettivi di affidabilità man mano che il carico di lavoro evolve. Ricercare le capacità di ridimensionamento offerte per diverse risorse che offrono funzionalità simili e scegliere la combinazione migliore per i piani di crescita futuri. Ad esempio, potrebbero essere disponibili diverse opzioni per gli archivi dati che possono ospitare il tipo specifico di database che verranno usati. Tuttavia, una scelta potrebbe avere funzionalità di scalabilità migliori predefinite rispetto ad altre, che potrebbero renderla una scelta migliore per il carico di lavoro.

• Sfruttare i vantaggi dei servizi che vengono ridimensionati automaticamente. Quando è pratico, usare i servizi SaaS che vengono ridimensionati automaticamente senza alcuna configurazione o input. I servizi globali come Microsoft Entra ID offrono questa funzionalità. Le soluzioni serverless offrono anche la scalabilità automatica e possono essere scelte valide per molti casi d'uso.

• Sfruttare i vantaggi dei servizi che offrono scalabilità predefinita. Molti servizi PaaS offrono funzionalità di scalabilità integrate e facili da usare che è possibile configurare per soddisfare i requisiti di affidabilità. Ad esempio, è possibile configurare il ridimensionamento della velocità effettiva per Cosmos DB per soddisfare i requisiti specifici.

Automatizzare il ridimensionamento

Automatizzare le operazioni di ridimensionamento per i componenti del carico di lavoro in modo pratico. Quando si usano risorse con funzionalità di scalabilità automatica configurabile, compilare la logica di configurazione nel codice di distribuzione IaC (Infrastructure-as-Code). Quando si usano risorse che non offrono scalabilità automatica predefinita, compilare l'automazione per eseguire operazioni di ridimensionamento usando strumenti di automazione nativi e includere il codice di automazione nel codice IaC.

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.

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.

Scegliere le unità di scala appropriate

Basare la strategia di ridimensionamento sulle unità di scala, ovvero il raggruppamento logico dei componenti da ridimensionare insieme e gli incrementi di scala da usare (ad esempio passando da uno SKU di macchina virtuale a un altro). Le opzioni da considerare sono:

• Ridimensionamento delle risorse singolarmente: potrebbe essere necessario ridimensionare solo singole macchine virtuali o database.

• Ridimensionamento di un componente completo contemporaneamente: Ad esempio, potrebbe essere disponibile un'API di microservizio costituita da un servizio app, un database e code che devono essere ridimensionati contemporaneamente.

• Ridimensionamento della soluzione completa: per carichi di lavoro complessi o cruciali, la scalabilità dell'intera soluzione come stamp di distribuzione può semplificare la strategia di scalabilità. 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.

Ottimizzare il tempo di inizializzazione delle unità di scala

Quando si progetta la strategia di scalabilità, tenere presente che i diversi servizi vengono ridimensionati in scala cronologica diversa. Esistono alcuni servizi che vengono ridimensionati quasi istantaneamente e altri che si ridimensionano molto più lentamente. Ad esempio, le istanze di Gestione API possono richiedere fino a 45 minuti per completare le operazioni di ridimensionamento. Per tenere conto della scala cronologica dell'operazione di ridimensionamento, pianificare correttamente l'esecuzione dell'operazione di ridimensionamento prima che il carico di carico aumentato previsto raggiunge il carico di lavoro. Altre raccomandazioni da considerare includono:

• Pre-inizializzare i nodi che verranno distribuiti per ridurre il tempo necessario per l'inizializzazione.

• Consentire un tempo di buffer intorno alle modifiche di configurazione prima di apportare ulteriori modifiche o usare il sistema in modo non comune. Ad esempio, è possibile deallocare un'istanza back-end del gateway app tramite una modifica della regola. È necessario attendere che le connessioni vengano svuotate da tale istanza prima che possa essere rimossa in modo sicuro.

• Eseguire il over-provisioning delle risorse per gestire un carico maggiore durante la scalabilità. È possibile assicurarsi che le macchine virtuali vengano eseguite normalmente a 75% capacità di utilizzo per garantire che possano gestire un carico maggiore mentre viene eseguita la scalabilità orizzontale.

• Ottimizzare le soglie di ridimensionamento con il monitoraggio. Usare il monitoraggio della capacità per assicurarsi che le soglie di ridimensionamento attivino le operazioni di ridimensionamento.

Ridimensionare gli archivi dati usando il partizionamento orizzontale e il partizionamento

Ottimizzare l'affidabilità del patrimonio di dati includendolo nella strategia di scalabilità. Il partizionamento dei dati distribuisce un database tra risorse di archiviazione logiche o fisiche, rimuovendo singoli punti di errore. Scegliere la strategia di partizionamento migliore per il caso d'uso.

• Partizionamento orizzontale (partizionamento orizzontale): le partizioni (partizioni) vengono inserite in archivi dati separati, ma tutte le partizioni hanno lo stesso schema. Ogni partizione contiene un subset del database. Si tratta di un approccio efficace per ottimizzare l'affidabilità, in quanto consente di facilitare il bilanciamento del carico e di ridurre al minimo l'onere delle operazioni durante la gestione dei problemi. Le partizioni possono essere replicate per una maggiore affidabilità.

• Partizionamento verticale: ogni partizione contiene un subset dei campi per gli elementi nell'archivio dati. I campi vengono divisi in base al modello di utilizzo.

• Partizionamento funzionale: i dati vengono aggregati in base al modo in cui ogni contesto delimitato nel sistema usa i dati.

Valutare la possibilità di combinare queste strategie quando si progetta uno schema di partizionamento. Ad esempio, è possibile dividere i dati in partizioni e quindi usare il partizionamento verticale per suddividere ulteriormente i dati in ogni partizione.

Ottimizzare la strategia di partizione per la scalabilità. Analizzare i modelli di accesso ai dati per determinare quali operazioni richiedono la maggior parte delle risorse di elaborazione e bilanciare le partizioni per garantire che ognuna disponga di risorse sufficienti per gestire i requisiti di scalabilità.

Per indicazioni dettagliate sul partizionamento e il partizionamento orizzontale, vedere la guida alla progettazione

Monitorare le operazioni di ridimensionamento

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 in modo proattivo le informazioni per misurare l'efficacia della strategia di scalabilità automatica e ottimizzarla, se necessario.

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

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.

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.