Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Consolidare più attività o operazioni in un'unica unità di calcolo. Questo modello può aumentare l'utilizzo delle risorse di calcolo e ridurre i costi e il sovraccarico di gestione associati all'elaborazione di calcolo nelle applicazioni ospitate nel cloud.
Contesto e problema
Un'applicazione cloud spesso implementa diversi tipi di operazioni. Inizialmente, è possibile organizzare queste operazioni in unità di calcolo separate ospitate e distribuite singolarmente. Ad esempio, è possibile distribuire app Web separate del servizio app di Azure o macchine virtuali separate. Questa strategia consente di semplificare la progettazione logica della soluzione, ma se si distribuisce un numero elevato di unità di calcolo come parte della stessa applicazione, questa distribuzione può aumentare i costi di hosting di runtime e rendere la gestione del sistema più complessa.
La figura seguente illustra la struttura semplificata di una soluzione ospitata nel cloud che usa più unità di calcolo. Ogni unità di calcolo viene eseguita nel proprio ambiente virtuale. La soluzione implementa ogni funzione come attività separata che viene eseguita nella propria unità di calcolo.
Ogni unità di calcolo consuma risorse con costi associati anche quando è inattiva o usata leggermente. Questo approccio non è sempre la soluzione più conveniente.
Soluzione
Per ridurre i costi, aumentare l'utilizzo, migliorare la velocità di comunicazione e ridurre la gestione, è possibile consolidare più attività o operazioni in una singola unità di calcolo.
È possibile raggruppare le attività in base ai criteri in base alle funzionalità dell'ambiente e ai costi associati a queste funzionalità. È comune cercare attività con requisiti di scalabilità, durata ed elaborazione simili. Per ridimensionare le attività come unità, è possibile raggrupparle. Molti ambienti cloud offrono elasticità in modo da poter avviare e arrestare istanze aggiuntive di un'unità di calcolo a seconda del carico di lavoro. Ad esempio, Azure offre la scalabilità automatica che è possibile applicare al servizio app e ai set di scalabilità di macchine virtuali di Azure.
È anche possibile usare la scalabilità per determinare quali operazioni non è consigliabile raggruppare. Si considerino le attività di esempio seguenti:
- L'attività 1 esegue il polling di una coda di messaggi poco frequenti e senza distinzione tra tempo.
- L'attività 2 consente di gestire picchi di volumi elevati di traffico di rete.
L'attività 2 richiede l'elasticità per avviare e arrestare un numero elevato di unità di calcolo. Se si applica lo stesso comportamento di ridimensionamento all'attività 1, più attività sono in ascolto di messaggi poco frequenti nella stessa coda, ovvero uno spreco di risorse.
In molti ambienti cloud è possibile specificare le risorse disponibili per un'unità di calcolo, ad esempio il numero di core CPU, memoria e spazio su disco. Se si specificano più risorse, la soluzione diventa in genere più costosa. Per risparmiare denaro, un'unità di calcolo costosa deve rimanere occupata ed evitare lunghi periodi di inattività.
Se le attività richiedono un'elevata potenza della CPU in brevi picchi, è possibile consolidare queste attività in una singola unità di calcolo che fornisce la potenza necessaria. Tuttavia, bilancia questa necessità di mantenere occupate le risorse costose contro le tensioni che potrebbero verificarsi se sono sotto stress. Ad esempio, le attività a esecuzione prolungata e a elevato utilizzo di calcolo non devono condividere la stessa unità di calcolo.
Problemi e considerazioni
Quando si decide come implementare questo modello, tenere presente quanto segue:
Scalabilità ed elasticità: Molte soluzioni cloud implementano scalabilità ed elasticità delle unità di calcolo avviando e arrestando le istanze di unità. Non raggruppare le attività con requisiti di scalabilità in conflitto nella stessa unità di calcolo.
Vita: L'infrastruttura cloud ricicla periodicamente l'ambiente virtuale che ospita un'unità di calcolo. Se sono presenti molte attività a esecuzione prolungata all'interno di un'unità di calcolo, potrebbe essere necessario impedire che l'unità venga riciclata fino al termine di queste attività. In alternativa, usare un approccio di checkpoint in modo che le attività possano interrompersi correttamente e continuare da dove sono state interrotte al riavvio dell'unità di calcolo.
Frequenza di rilascio: Se l'implementazione o la configurazione di un'attività cambia frequentemente, potrebbe essere necessario arrestare l'unità di calcolo che ospita il codice aggiornato, riconfigurare e ridistribuire l'unità e quindi riavviarla. Questo processo richiede anche l'arresto, la ridistribuzione e il riavvio di tutte le altre attività all'interno della stessa unità di calcolo.
Sicurezza: Le attività nella stessa unità di calcolo potrebbero condividere lo stesso contesto di sicurezza e potrebbero essere in grado di accedere alle stesse risorse. Questa configurazione richiede un elevato livello di attendibilità tra le attività e la probabilità che un'attività non possa danneggiare o influire negativamente su un'altra. Inoltre, se si aumenta il numero di attività eseguite in un'unità di calcolo, aumenta la superficie di attacco dell'unità. Ogni attività è sicura come l'attività con la maggior parte delle vulnerabilità.
Tolleranza di errore: Se un'attività in un'unità di calcolo ha esito negativo o si comporta in modo anomalo, può influire sulle altre attività nella stessa unità. Ad esempio, se un'attività non viene avviata correttamente, può causare l'esito negativo dell'intera logica di avvio per l'unità di calcolo e può impedire l'esecuzione di altre attività nella stessa unità.
Contesa: Evitare di introdurre conflitti tra attività che competono per le risorse nella stessa unità di calcolo. Le attività che condividono la stessa unità di calcolo devono presentare caratteristiche di utilizzo delle risorse diverse. Ad esempio, due attività a elevato utilizzo di calcolo non devono trovarsi nella stessa unità di calcolo e nessuna delle due attività che utilizzano grandi quantità di memoria. È tuttavia possibile combinare un'attività a elevato utilizzo di calcolo con un'attività che richiede una grande quantità di memoria.
Annotazioni
Valutare la possibilità di consolidare le risorse di calcolo solo per i sistemi in produzione sufficientemente lunghi in modo che gli operatori e gli sviluppatori possano monitorare il sistema e creare una mappa termica che identifichi il modo in cui ogni attività usa le risorse. Questa mappa consente di determinare quali attività sono valide per la condivisione delle risorse di calcolo.
Complessità: Più attività in una singola unità di calcolo aggiungono complessità al codice nell'unità, che potrebbe rendere più difficile testare, eseguire il debug e gestire.
Architettura logica stabile: Progettare e implementare il codice in ogni attività in modo che non debba essere modificato, anche se cambia l'ambiente fisico in cui l'attività viene eseguita.
Altre strategie: Il consolidamento delle risorse di calcolo è solo un modo per ridurre i costi associati all'esecuzione simultanea di più attività. Richiede un'attenta pianificazione e monitoraggio per verificare che continui a essere un approccio efficace. Altre strategie potrebbero essere più appropriate, a seconda della natura del lavoro e della posizione in cui si trovano gli utenti delle attività.
Quando usare questo modello
Usare questo modello quando:
- Le attività non sono vantaggiose in termini di costo se vengono eseguite nelle proprie unità computazionali.
- Un'attività è spesso inattiva.
- Sarebbe costoso eseguire un'attività in un'unità dedicata.
Questo modello potrebbe non essere adatto quando:
- Le attività svolgono operazioni a tolleranza di errore critiche.
- Le attività elaborano dati estremamente sensibili o privati e richiedono il proprio contesto di sicurezza.
- Le attività devono essere eseguite nel proprio ambiente isolato in un'unità di calcolo separata.
Progettazione del carico di lavoro
Valutare come usare il modello di consolidamento delle risorse di calcolo nella progettazione di un carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. La tabella seguente fornisce indicazioni su come questo modello supporta gli obiettivi di ogni pilastro.
| Pilastro | Come questo modello supporta gli obiettivi di pilastro |
|---|---|
| L'ottimizzazione dei costi è incentrata sul mantenimento e sul miglioramento del ritorno del carico di lavoro sugli investimenti. | Questo modello ottimizza l'utilizzo delle risorse di calcolo evitando capacità di provisioning non utilizzata tramite l'aggregazione di componenti o persino interi carichi di lavoro in un'infrastruttura condivisa. - CONSOLIDAMENTO CO:14 |
| L'eccellenza operativa consente di offrire la qualità del carico di lavoro attraverso processi standardizzati e coesione del team. | Il consolidamento può portare a una piattaforma di calcolo più omogenea, che può semplificare la gestione e l'osservabilità, ridurre approcci diversi alle attività operative e ridurre la quantità di strumenti necessari. - Sistema di monitoraggio OE:07 - Progettazione di Automazione di OE:10 |
| l'efficienza delle prestazioni consente al carico di lavoro soddisfare in modo efficiente le richieste tramite ottimizzazioni di ridimensionamento, dati e codice. | Il consolidamento ottimizza l'utilizzo delle risorse di calcolo usando la capacità del nodo di riserva e riduce il provisioning eccessivo. Queste infrastrutture usano spesso istanze di calcolo con scalabilità verticale di grandi dimensioni nel pool di risorse. - PE:02 Pianificazione della capacità - PE:03 Selezionare i servizi |
Se questo modello introduce compromessi all'interno di un pilastro, considerarli contro gli obiettivi degli altri pilastri.
Esempio
È possibile distribuire questo modello in modi diversi, a seconda del servizio di calcolo. Per esempio:
Servizio App e Funzioni di Azure: Distribuire piani di Servizio App condivisi, che rappresentano l'infrastruttura del server ospitante. È possibile configurare una o più app da eseguire nelle stesse risorse di calcolo o nello stesso piano di servizio app.
App contenitore di Azure: Distribuire App contenitore negli stessi ambienti condivisi, soprattutto se è necessario gestire i servizi correlati o distribuire applicazioni diverse nella stessa rete virtuale.
Servizio Azure Kubernetes: Il servizio Azure Kubernetes è un'infrastruttura di hosting basata su contenitori in cui è possibile configurare più applicazioni o componenti dell'applicazione per l'esecuzione nella stessa risorsa di calcolo (nodi). È possibile raggruppare le risorse di calcolo in base ai requisiti di calcolo, ad esempio le esigenze di CPU o memoria (pool di nodi).
Macchine virtuali: Distribuire un singolo set di macchine virtuali per tutti i tenant da usare in modo che i costi di gestione vengano condivisi tra i tenant. I set di scalabilità di macchine virtuali supportano la gestione delle risorse condivise, il bilanciamento del carico e il ridimensionamento orizzontale delle macchine virtuali.
Calcolo basato sul consumo (serverless): Usare modelli di calcolo con pagamento in base all'esecuzione completamente gestiti che possono essere ridimensionati a zero, ad esempio il piano a consumo di funzioni e le app contenitore. Questi servizi eseguono più carichi di lavoro indipendenti in un pool globale condiviso di risorse di calcolo. Queste piattaforme allocano e rilasciano automaticamente il calcolo in modo che più applicazioni possano trarre vantaggio dal ridimensionamento elastico e dall'efficienza dei costi senza un'infrastruttura dedicata.