Controllare il consumo delle risorse usate da un'istanza di un'applicazione, un singolo tenant o un intero servizio. Questa scelta può consentire al sistema di continuare a funzionare e soddisfare i contratti di servizio, anche quando un aumento della domanda genera un carico particolarmente intenso sulle risorse.
Contesto e problema
Il carico in un'applicazione cloud varia in genere nel tempo in base al numero di utenti attivi o ai tipi di attività che stanno eseguendo. Ad esempio, è probabile che più utenti siano attivi durante l'orario di lavoro oppure al sistema potrebbe essere richiesto di eseguire un'analisi impegnativa a livello di calcolo alla fine di ogni mese. È possibile anche che si verifichino picchi improvvisi e imprevisti nell'attività. Se i requisiti di elaborazione del sistema superano la capacità delle risorse disponibili, è possibile che le prestazioni non siano soddisfacenti e persino che si verifichi un errore del sistema. Se il sistema deve soddisfare un livello di servizio concordato, questo errore potrebbe non essere accettabile.
Sono disponibili molte strategie per la gestione del carico variabile nel cloud, a seconda degli obiettivi aziendali per l'applicazione. Una strategia consiste nell'usare la scalabilità automatica per associare le risorse di cui è stato effettuato il provisioning alle esigenze dell'utente in qualsiasi momento. Questa strategia è in grado di soddisfare in modo coerente la richiesta dell'utente, ottimizzando al contempo i costi in esecuzione. Tuttavia, mentre la scalabilità automatica può attivare il provisioning di più risorse, questo provisioning non è immediato. Se la domanda cresce rapidamente, è possibile che le risorse in un intervallo di tempo non siano sufficienti.
Soluzione
Una strategia alternativa alla scalabilità automatica consiste nel consentire alle applicazioni di usare le risorse solo fino a un limite e di limitarle al raggiungimento di questo limite. Il sistema deve monitorare la modalità di utilizzo delle risorse in modo che, quando l'utilizzo supera la soglia, sia possibile limitare le richieste provenienti da uno o più utenti. Ciò consente al sistema di continuare a funzionare e soddisfare tutti i contratti di servizio (SLA) applicati. Per altre informazioni sul monitoraggio dell'utilizzo delle risorse, vedere Indicazioni sulla strumentazione e la telemetria.
Il sistema potrebbe implementare diverse strategie di limitazione, tra cui:
Rifiutare le richieste da un singolo utente che ha già effettuato l'accesso alle API di sistema più di n volte al secondo in un determinato periodo di tempo. Per tale scopo è necessario che il sistema calcoli l'utilizzo delle risorse per ogni tenant o utente che esegue un'applicazione. Per altre informazioni, vedere le indicazioni sulla misurazione del servizio.
Disabilitare o degradare la funzionalità di servizi non essenziali selezionati in modo che i servizi essenziali possano essere eseguiti senza problemi con risorse sufficienti. Ad esempio, se l'applicazione sta trasmettendo l'output video, potrebbe passare a una risoluzione inferiore.
Usare il livellamento del carico per regolare il volume di attività; questo approccio è descritto in maggior dettaglio nello schema di livellamento del carico basato sulle code. In un ambiente multi-tenant questo approccio ridurrà le prestazioni per ogni tenant. Se il sistema deve supportare un insieme di tenant con contratti di servizio diversi, le operazioni i tenant di alto valore possono essere eseguite immediatamente. Le richieste di altri tenant possono essere tratenute e gestite quando il backlog è diminuito. Il modello di coda priorità può essere usato per implementare questo approccio, in quanto potrebbe esporre endpoint diversi per i diversi livelli di servizio/priorità.
Rinviare operazioni eseguite per conto di tenant o di applicazioni con priorità più bassa. Queste operazioni possono essere sospese o limitate, con un'eccezione generata per informare il tenant che il sistema è occupato e che l'operazione dovrebbe essere ritentata successivamente.
È consigliabile prestare attenzione quando si esegue l'integrazione con alcuni servizi di terze parti che potrebbero diventare non disponibili o restituire errori. Ridurre il numero di richieste simultanee elaborate in modo che i log non si riempiano inutilmente di errori. È anche possibile evitare i costi associati a tentativi inutili di elaborazione delle richieste che non riuscirebbero a causa del servizio di terze parti. Quindi, quando le richieste vengono elaborate correttamente, tornare alla normale elaborazione delle richieste senza errori. Una libreria che implementa questa funzionalità è NServiceBus.
La figura mostra un grafo ad area per l'utilizzo delle risorse (una combinazione di memoria, CPU, larghezza di banda e di altri fattori) rispetto al tempo per cui le applicazioni usano le tre funzioni. Una funzione è un'area di funzionalità, ad esempio un componente che esegue una serie specifica di attività, una parte del codice che esegue un calcolo complesso o un elemento che fornisce un servizio, ad esempio una cache in memoria. Queste funzioni sono etichettate come A, B e C.
L'area immediatamente sotto la linea per una funzione indica le risorse usate dalle applicazioni quando richiamano questa funzione. Ad esempio, l'area sotto la riga per la Funzione A mostra le risorse usate dalle applicazioni che usano la Funzione A e l'area tra le righe per la Funzione A e la Funzione B indica le risorse usate dalle applicazioni che richiamano la Funzione B. L'aggregazione delle aree per ogni funzione mostra l'utilizzo totale delle risorse del sistema.
La figura precedente illustra gli effetti delle operazioni di rinvio. Appena prima del tempo T1, le risorse totali assegnate a tutte le applicazioni che usano queste funzioni raggiungono una soglia, il limite di utilizzo di risorse. A questo punto, le applicazioni rischiano di esaurire le risorse disponibili. In questo sistema, la Funzione B è meno critica della Funzione A o della Funzione C e quindi è stata temporaneamente disattivata rilasciando le risorse che stava usando. Tra i tempi T1 e T2, le applicazioni che usano la Funzione A e la Funzione C continuano a funzionare normalmente. Alla fine, l'utilizzo delle risorse di queste due funzioni diminuisce al punto in cui, al tempo T2, è disponibile una capacità sufficiente per abilitare nuovamente la Funzione B.
Gli approcci di scalabilità automatica e limitazione possono anche essere combinati per mantenere reattive le applicazioni e in linea con i contratti di servizio. Se si prevede che la domanda rimanga elevata, la limitazione fornisce una soluzione temporanea mentre il sistema aumenta il numero di istanze. A questo punto, è possibile ripristinare la funzionalità completa del sistema.
La figura seguente mostra un grafo ad area sull'utilizzo generale delle risorse da parte di tutte le applicazioni eseguite in un sistema rispetto al tempo e illustra come è possibile combinare la limitazione delle richieste con la scalabilità automatica.
All'ora T1 viene raggiunta la soglia che specifica il limite flessibile di utilizzo di risorse. A questo punto, il sistema può iniziare a aumentare il numero di istanze. Tuttavia, se le nuove risorse non diventano disponibili abbastanza rapidamente, le risorse esistenti potrebbero essere esaurite e il sistema potrebbe non riuscire. Per evitare questo problema, il sistema viene limitato temporaneamente, come descritto in precedenza. Quando la scalabilità automatica è stata completata e le risorse aggiuntive sono disponibili, la limitazione può essere rilassata.
Considerazioni e problemi
Prima di decidere come implementare questo schema, è opportuno considerare quanto segue:
Limitare le richieste di un'applicazione e scegliere la strategia sono decisioni che influiscono sull'intera progettazione di un sistema. Non è facile aggiungere la limitazione delle richieste dopo l'implementazione di un sistema ed è quindi opportuno valutare questa scelta all'inizio del processo di progettazione.
La limitazione delle richieste deve essere eseguita rapidamente. Il sistema deve essere in grado di rilevare un aumento di attività e reagire di conseguenza. Il sistema deve anche essere in grado di ripristinare lo stato originale rapidamente dopo che il carico è diminuito. A tale scopo è necessario che vengano costantemente acquisiti e monitorati i dati sulle prestazioni appropriati.
Se un servizio deve negare temporaneamente una richiesta utente, deve restituire un codice di errore specifico, ad esempio 429 ("Troppe richieste") e 503 ("Server Troppo occupato") in modo che l'applicazione client possa comprendere che il motivo del rifiuto di soddisfare una richiesta è dovuto alla limitazione.
- HTTP 429 indica che l'applicazione chiamante ha inviato troppe richieste in un intervallo di tempo e ha superato un limite predeterminato.
- HTTP 503 indica che il servizio non è pronto per gestire la richiesta. La causa comune è che il servizio riscontra picchi di carico più temporanei del previsto.
L'applicazione client può attendere prima di ritentare la richiesta. È necessario includere un'intestazione Retry-After HTTP per supportare il client nella scelta della strategia di ripetizione dei tentativi.
La limitazione delle richieste può essere usata come misura temporanea mentre il sistema scala automaticamente. In alcuni casi, è preferibile limitare semplicemente la limitazione, anziché ridimensionare, se un burst di attività è improvviso e non dovrebbe essere di lunga durata perché il ridimensionamento può aggiungere notevolmente ai costi di esecuzione.
Se la limitazione viene usata come misura temporanea mentre un sistema esegue la scalabilità automatica e se le richieste di risorse aumentano molto rapidamente, il sistema potrebbe non essere in grado di continuare a funzionare, anche quando si opera in modalità limitata. Se questa condizione non è accettabile, è consigliabile, prendere in considerazione la possibilità di mantenere maggiori riserve di capacità e di configurare una scalabilità automatica più aggressiva.
Normalizzare i costi delle risorse per operazioni diverse perché in genere non comportano costi di esecuzione uguali. Ad esempio, i limiti di limitazione potrebbero essere inferiori per le operazioni di lettura e superiori per le operazioni di scrittura. Non considerando il costo di un'operazione può comportare un esaurimento della capacità e l'esposizione di un potenziale vettore di attacco.
La modifica dinamica della configurazione del comportamento di limitazione in fase di esecuzione è consigliabile. Se un sistema affronta un carico anomalo che la configurazione applicata non può gestire, potrebbero essere necessari limiti di limitazione per aumentare o diminuire per stabilizzare il sistema e mantenere il passo con il traffico corrente. Le distribuzioni costose, rischiose e lente non sono auspicabili a questo punto. L'uso della configurazione della limitazione dei criteri di archiviazione configurazione esterna viene esternalizzato e può essere modificato e applicato senza distribuzioni.
Quando usare questo modello
Usare questo schema:
Per garantire che un sistema continui a soddisfare i contratti di servizio.
Per evitare a un singolo tenant di monopolizzare le risorse fornite da un'applicazione.
Per gestire i picchi di attività.
Per ottimizzare i costi di un sistema limitando i livelli massimi di risorse necessari per mantenerlo funzionante.
Progettazione del carico di lavoro
Un architetto deve valutare il modo in cui il modello di limitazione può essere usato nella progettazione del carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. Ad esempio:
| Concetto fondamentale | Come questo modello supporta gli obiettivi di pilastro |
|---|---|
| Le decisioni di progettazione dell'affidabilità consentono al carico di lavoro di diventare resilienti a malfunzionamenti e di assicurarsi che venga ripristinato in uno stato completamente funzionante dopo che si verifica un errore. | Si progettano i limiti per evitare l'esaurimento delle risorse che potrebbero causare malfunzionamenti. È anche possibile usare questo modello come meccanismo di controllo in un piano di riduzione delle prestazioni normale. - RE:07 Conservazione automatica |
| Le decisioni di progettazione della sicurezza consentono di garantire la riservatezza, l'integrità e la disponibilità dei dati e dei sistemi del carico di lavoro. | È possibile progettare i limiti per evitare l'esaurimento delle risorse che potrebbe causare abusi automatici del sistema. - controlli di rete edizione Standard:06 - risorse di protezione avanzata edizione Standard:08 |
| L'ottimizzazione dei costi è incentrata sul mantenimento e sul miglioramento del ritorno del carico di lavoro sugli investimenti. | I limiti applicati possono informare la modellazione dei costi e possono anche essere direttamente collegati al modello aziendale dell'applicazione. Inseriscono anche limiti superiori chiari sull'utilizzo, che possono essere inseriti nel dimensionamento delle risorse. - Modello di costo CO:02 - CO:12 Costi di ridimensionamento |
| L'efficienza delle prestazioni consente al carico di lavoro di soddisfare in modo efficiente le richieste tramite ottimizzazioni in termini di scalabilità, dati, codice. | Quando il sistema è sottoposto a una domanda elevata, questo modello consente di ridurre la congestione che può causare colli di bottiglia delle prestazioni. È anche possibile usarlo per evitare in modo proattivo scenari di vicini rumorosi. - PE:02 Pianificazione della capacità - PE:05 Ridimensionamento e partizionamento |
Come per qualsiasi decisione di progettazione, prendere in considerazione eventuali compromessi rispetto agli obiettivi degli altri pilastri che potrebbero essere introdotti con questo modello.
Esempio
La figura finale illustra come implementare la limitazione delle richieste in un sistema multi-tenant. Gli utenti di ciascuna organizzazione tenant accedono a un'applicazione ospitata nel cloud dove compilano e inviano sondaggi. L'applicazione contiene la strumentazione che monitora la velocità con cui questi utenti inviano richieste all'applicazione.
Per impedire agli utenti di un tenant di compromettere i tempi di risposta e la disponibilità dell'applicazione per tutti gli altri utenti, il numero di richieste al secondo che gli utenti di qualsiasi tenant possono inviare viene limitato. L'applicazione blocca le richieste che superano questo limite.
Passaggi successivi
Le indicazioni seguenti possono essere rilevanti anche quando si implementa questo modello:
- Indicazioni sulla strumentazione e la telemetria. La limitazione dipende dalla raccolta di informazioni sulla frequenza di utilizzo di un servizio. Descrive come generare e acquisire informazioni di monitoraggio personalizzate.
- Indicazioni sulla misurazione del servizio. Viene descritto come misurare l'uso dei servizi per comprendere come vengono usati. Queste informazioni possono essere utili per determinare come limitare un servizio.
- Scalabilità automatica. La limitazione delle richieste può essere usata come misura provvisoria mentre un sistema esegue la scalabilità automatica o per non rendere necessaria questa operazione. Contiene informazioni sulle strategie di scalabilità automatica.
Risorse correlate
I modelli seguenti possono essere rilevanti anche quando si implementa questo modello:
- Schema di livellamento del carico basato sulle code. Il livellamento del carico basato sulle code è un meccanismo di utilizzo comune per implementare la limitazione delle richieste. Una coda può fungere da buffer che aiuta a bilanciare la velocità con cui le richieste inviate da un'applicazione vengono recapitate a un servizio.
- Schema di coda di priorità. Un sistema può usare l'accodamento prioritario nell'ambito della strategia di limitazione per garantire le prestazioni per le applicazioni strategiche o di livello superiore, riducendo al contempo le prestazioni delle applicazioni meno importanti.
- Modello di archivio di configurazione esterno. La centralizzazione e l'esternalizzazione dei criteri di limitazione offrono la possibilità di modificare la configurazione in fase di esecuzione senza la necessità di una ridistribuzione. I servizi possono sottoscrivere le modifiche di configurazione, applicando la nuova configurazione immediatamente, per stabilizzare un sistema.