Modelli di progettazione cloud che supportano l'efficienza delle prestazioni
Quando si progettano architetture dei carichi di lavoro, è consigliabile usare modelli di settore che affrontano le problematiche comuni. I modelli consentono di ottenere compromessi intenzionali all'interno dei carichi di lavoro e ottimizzare per il risultato desiderato. Possono anche contribuire a mitigare i rischi che derivano da problemi specifici, che possono influire sull'affidabilità, la sicurezza, i costi e le operazioni. Se non è stato mitigato, alla fine i rischi porteranno a inefficienze delle prestazioni. Questi modelli sono supportati dall'esperienza reale, sono progettati per la scalabilità del cloud e i modelli operativi e sono intrinsecamente indipendenti dai fornitori. L'uso di modelli noti come un modo per standardizzare la progettazione del carico di lavoro è un componente dell'eccellenza operativa.
Molti modelli di progettazione supportano direttamente uno o più pilastri dell'architettura. Modelli di progettazione che supportano il pilastro Efficienza delle prestazioni per risolvere la scalabilità, l'ottimizzazione delle prestazioni, la definizione delle priorità delle attività e la rimozione di colli di bottiglia.
Modelli di progettazione per l'efficienza delle prestazioni
La tabella seguente riepiloga i modelli di progettazione cloud che supportano gli obiettivi dell'efficienza delle prestazioni.
Modello | Summary |
---|---|
Richiesta e risposta asincrone | Migliora la velocità di risposta e la scalabilità dei sistemi separando le fasi di richiesta e risposta delle interazioni per i processi che non necessitano di risposte immediate. Usando un modello asincrono, è possibile ottimizzare la concorrenza sul lato server. È possibile usare questo modello per pianificare il lavoro da completare come consentito dalla capacità. |
Back-end per front-end | Individualizza il livello di servizio di un carico di lavoro creando servizi separati esclusivi di un'interfaccia front-end specifica. Questa separazione consente di ottimizzare in modi che potrebbero non essere possibili con un livello di servizio condiviso. Quando si gestiscono i singoli client in modo diverso, è possibile ottimizzare le prestazioni per i vincoli e le funzionalità di un client specifico. |
A scomparti | Introduce la segmentazione tra componenti per isolare il raggio di esplosione di malfunzionamenti. Questa progettazione consente a ogni testa di massa di essere scalabile singolarmente per soddisfare le esigenze dell'attività incapsulata nella testa bulk. |
Cache-aside | Ottimizza l'accesso ai dati letti di frequente introducendo una cache popolata su richiesta. La cache viene quindi usata nelle richieste successive per gli stessi dati. Questo modello è particolarmente utile con dati con un numero elevato di operazioni di lettura che non cambiano spesso e possono tollerare una certa quantità di decadimento. L'obiettivo di questa implementazione è offrire prestazioni migliori nel sistema in generale tramite l'offload di questo tipo di dati in una cache anziché l'origine dall'archivio dati. |
Coreografia | Coordina il comportamento dei componenti distribuiti autonomi in un carico di lavoro usando comunicazioni decentralizzate basate su eventi. Questo modello può offrire un'alternativa quando si verificano colli di bottiglia delle prestazioni in una topologia di orchestrazione centralizzata. |
Interruttore | Impedisce richieste continue a una dipendenza non funzionante o non disponibile. Un approccio di ripetizione degli errori può causare un utilizzo eccessivo delle risorse durante il ripristino delle dipendenze e può anche eseguire l'overload delle prestazioni in una dipendenza che sta tentando di eseguire il ripristino. |
Scontrino | Separa i dati dal flusso di messaggistica, offrendo un modo per recuperare separatamente i dati correlati a un messaggio. Questo modello migliora l'efficienza e le prestazioni degli autori di messaggi, dei sottoscrittori e del bus di messaggi stesso quando il sistema gestisce payload di dati di grandi dimensioni. Funziona riducendo le dimensioni dei messaggi e assicurando che i consumer recuperino i dati del payload solo se necessario e in un momento appropriato. |
Consumer concorrenti | Applica l'elaborazione distribuita e simultanea per gestire in modo efficiente gli elementi in una coda. Questo modello supporta la distribuzione del carico tra tutti i nodi consumer e il ridimensionamento dinamico basato sulla profondità della coda. |
Consolidamento delle risorse di calcolo | Ottimizza e consolida le risorse di calcolo aumentando la densità. Questo modello combina più applicazioni o componenti di un carico di lavoro in un'infrastruttura condivisa. Questo consolidamento ottimizza l'utilizzo delle risorse di calcolo usando la capacità del nodo di riserva per ridurre il provisioning eccessivo. Gli agenti di orchestrazione dei contenitori sono un esempio comune. Le istanze di calcolo di grandi dimensioni (con scalabilità verticale) vengono spesso usate nel pool di risorse per queste infrastrutture. |
Separazione di responsabilità per query e comandi (CQRS, Command and Query Responsibility Segregation) | Separa le operazioni di lettura e scrittura del modello di dati di un'applicazione. Questa separazione consente le ottimizzazioni di scalabilità e prestazioni mirate per lo scopo specifico di ogni operazione. Questa progettazione è più utile nelle applicazioni con un rapporto di lettura-scrittura elevato. |
Stamp di distribuzione | Fornisce un approccio per il rilascio di una versione specifica di un'applicazione e della relativa infrastruttura come unità controllata di distribuzione, in base al presupposto che le stesse versioni o versioni diverse verranno distribuite contemporaneamente. Questo modello è spesso allineato alle unità di scala definite nel carico di lavoro: poiché è necessaria capacità aggiuntiva oltre a quanto fornito da una singola unità di scala, viene distribuito un indicatore di distribuzione aggiuntivo per la scalabilità orizzontale. |
Origine eventi | Considera la modifica dello stato come serie di eventi, acquisendoli in un log non modificabile e di sola accodamento. A seconda del carico di lavoro, questo modello, in genere combinato con CQRS, una progettazione del dominio appropriata e snapshot strategico, può migliorare le prestazioni. I miglioramenti delle prestazioni sono dovuti alle operazioni di sola accodamento atomiche e all'evitare il blocco del database per operazioni di scrittura e lettura. |
Identità federativa | Delega l'attendibilità a un provider di identità esterno al carico di lavoro per la gestione degli utenti e la fornitura dell'autenticazione per l'applicazione. Quando si esegue l'offload della gestione e dell'autenticazione degli utenti, è possibile dedicare le risorse dell'applicazione ad altre priorità. |
Gatekeeper | Esegue l'offload dell'elaborazione delle richieste specificamente per l'imposizione del controllo di sicurezza e di accesso prima e dopo l'inoltro della richiesta a un nodo back-end. Questo modello viene spesso usato per implementare la limitazione a livello di gateway anziché implementare controlli di frequenza a livello di nodo. Il coordinamento dello stato della velocità tra tutti i nodi non è intrinsecamente efficiente. |
Aggregazione gateway | Semplifica le interazioni client con il carico di lavoro aggregando le chiamate a più servizi back-end in una singola richiesta. Questa progettazione può comportare meno latenza rispetto a una progettazione in cui il client stabilisce più connessioni. La memorizzazione nella cache è anche comune nelle implementazioni di aggregazione perché riduce al minimo le chiamate ai sistemi back-end. |
Offload del gateway | Offload dell'elaborazione delle richieste a un dispositivo gateway prima e dopo l'inoltro della richiesta a un nodo back-end. L'aggiunta di un gateway di offload al processo di richiesta consente di usare meno risorse per nodo perché la funzionalità è centralizzata nel gateway. È possibile ottimizzare l'implementazione della funzionalità offloaded indipendentemente dal codice dell'applicazione. È probabile che la funzionalità fornita dalla piattaforma offloaded sia già altamente efficiente. |
Routing del gateway | Instrada le richieste di rete in ingresso a vari sistemi back-end in base alle finalità delle richieste, alla logica di business e alla disponibilità back-end. Il routing del gateway consente di distribuire il traffico tra nodi del sistema per bilanciare il carico. |
Geode | Distribuisce i sistemi che operano in modalità di disponibilità attiva-attiva in più aree geografiche. Questo modello usa la replica dei dati per supportare l'ideale per la connessione di qualsiasi client a qualsiasi istanza geografica. È possibile usarla per gestire l'applicazione da un'area più vicina alla base utenti distribuita. In questo modo si riduce la latenza eliminando il traffico a lunga distanza e perché si condivide l'infrastruttura solo tra gli utenti che attualmente usano lo stesso geode. |
Monitoraggio endpoint di integrità | Consente di monitorare l'integrità o lo stato di un sistema esponendo un endpoint appositamente progettato per tale scopo. È possibile usare questi endpoint per migliorare il bilanciamento del carico instradando il traffico a solo i nodi verificati come integri. Con una configurazione aggiuntiva, è anche possibile ottenere metriche sulla capacità del nodo disponibile. |
Tabella degli indici | Ottimizza il recupero dei dati negli archivi dati distribuiti consentendo ai client di cercare metadati in modo che i dati possano essere recuperati direttamente, evitando la necessità di eseguire analisi complete dell'archivio dati. I client puntano alla partizione, alla partizione o all'endpoint, che può abilitare il partizionamento dei dati dinamici per l'ottimizzazione delle prestazioni. |
Vista materializzata | Usa le viste pre-calcolate dei dati per ottimizzare il recupero dei dati. Le viste materializzate archiviano i risultati di calcoli o query complessi senza richiedere al motore di database o al client di ricompilare per ogni richiesta. Questa progettazione riduce l'utilizzo complessivo delle risorse. |
Coda di priorità | Assicura che gli elementi con priorità più alta vengano elaborati e completati prima degli elementi con priorità più bassa. La separazione degli elementi in base alla priorità aziendale consente di concentrare le attività sulle prestazioni sul lavoro più sensibile al tempo. |
Autore/Sottoscrittore | Separa i componenti di un'architettura sostituendo la comunicazione diretta da client a servizio o da client a servizi con la comunicazione tramite un broker di messaggi intermedio o un bus di eventi. La separazione dei server di pubblicazione dai consumer consente di ottimizzare il calcolo e il codice in modo specifico per l'attività che il consumer deve eseguire per il messaggio specifico. |
Livellamento del carico basato sulle code | Controlla il livello di richieste o attività in ingresso memorizzandole nel buffer in una coda e consentendo al processore della coda di gestirle a un ritmo controllato. Questo approccio consente la progettazione intenzionale sulle prestazioni della velocità effettiva perché l'assunzione di richieste non deve essere correlata alla frequenza in cui vengono elaborate. |
Supervisione agente di pianificazione | Distribuisce e ridistribuisce in modo efficiente le attività in un sistema in base a fattori osservabili nel sistema. Questo modello usa le metriche delle prestazioni e della capacità per rilevare l'utilizzo corrente e instradare le attività a un agente con capacità. È anche possibile usarlo per classificare in ordine di priorità l'esecuzione del lavoro con priorità più alta rispetto al lavoro con priorità più bassa. |
Partizionamento orizzontale | Indirizza il carico a una destinazione logica specifica per gestire una richiesta specifica, abilitando la corilevazione per l'ottimizzazione. Quando si usa il partizionamento orizzontale nella strategia di ridimensionamento, i dati o l'elaborazione sono isolati in una partizione, quindi compete per le risorse solo con altre richieste indirizzate a tale partizione. È anche possibile usare il partizionamento orizzontale per ottimizzare in base all'area geografica. |
Collaterale | Estende la funzionalità di un'applicazione incapsulando attività non primarie o trasversali in un processo complementare esistente insieme all'applicazione principale. È possibile spostare le attività trasversali in un singolo processo in grado di ridimensionare più istanze del processo principale, riducendo la necessità di distribuire funzionalità duplicate per ogni istanza dell'applicazione. |
Hosting di contenuto statico | Ottimizza la distribuzione di contenuto statico ai client del carico di lavoro usando una piattaforma di hosting progettata a tale scopo. L'offload della responsabilità a un host esternalizzato consente di ridurre la congestione e consente di usare la piattaforma dell'applicazione solo per distribuire la logica di business. |
Limitazione | Impone limiti alla velocità effettiva o alla velocità effettiva delle richieste in ingresso a una risorsa o a un componente. 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 adiacenti rumorosi. |
Passepartout | Concede l'accesso con restrizioni di sicurezza a una risorsa senza usare una risorsa intermedia per proxyre l'accesso. In questo modo, l'elaborazione viene eseguita come relazione esclusiva tra il client e la risorsa senza richiedere un componente ambassador che deve gestire tutte le richieste client in modo efficiente. Il vantaggio dell'uso di questo modello è più significativo quando il proxy non aggiunge valore alla transazione. |
Passaggi successivi
Esaminare i modelli di progettazione cloud che supportano gli altri pilastri di Azure Well-Architected Framework: