Preparazione
Si aggiungeranno miglioramenti personalizzati a un'architettura esistente che soddisfi i requisiti di affidabilità elevata dell'organizzazione. In questo caso verrà illustrato il contesto in background che è necessario avere successo con gli esercizi.
Contesto del problema
Contoso Shoes deve essere pronta per il prossimo lancio di un prodotto di alto profilo, che dovrebbe creare un aumento significativo del traffico. Negli ultimi due anni si sono verificati diversi incidenti che hanno reso il sito Web offline anche per mezza giornata. Il sistema non è stato testato completamente nell'ambiente di sviluppo/test e alcuni bug sono stati inseriti nell'ambiente di produzione. La risoluzione dei problemi e la correzione richiedevano molto tempo, perché gli operatori non erano in grado di identificare rapidamente le cause radice.
Ci sono stati alcuni problemi quando alcuni componenti non erano disponibili. Le operazioni di scale-out sul calcolo sono state interessate quando l'Azure Key Vault è stato configurato in modo errato. Inoltre, non sono presenti strategie per interruzioni regionali. In un recente incidente, l'intera regione dell'Europa occidentale è stata bloccata. Poiché il carico di lavoro era in esecuzione solo in tale area, l'azienda doveva sopportare una perdita finanziaria fino al backup dell'area.
Architettura corrente
Per completare questa sfida, è necessario avere una buona conoscenza dell'architettura corrente di Contoso Shoes. Si esaminerà ora il livello API.
Componenti
Tutti i componenti di questa architettura vengono distribuiti in una singola area.
piano di servizio di app Azure Lo SKU S2 Standard fornisce la piattaforma di calcolo che ospita l'app. La scalabilità automatica è abilitata. L'ambiente di sviluppo usa lo SKU Basic B1.
Servizio app di Azure fornisce la piattaforma applicazione che esegue il codice API in un contenitore. La funzionalità di autenticazione servizio app è abilitata per l'autorizzazione.
Slot di distribuzione consentono di allestire una distribuzione e di scambiarla con la distribuzione di produzione. Vengono usati solo in produzione.
Registro Azure Container archivia il codice DELL'API in contenitori e viene eseguito il push tramite pipeline di integrazione continua/recapito continuo (CI/CD) che il team del carico di lavoro crea e gestisce. Sia l'ambiente di produzione che quello di sviluppo/test usano il registro contenitori.
Azure Cosmos DB con l'API SQL archivia tutto lo stato correlato al carico di lavoro. L'account del database Cosmos DB include un singolo database che contiene alcuni contenitori nel modello di velocità effettiva condivisa. L'account Azure Cosmos usa la modalità di capacità serverless. C'è un'istanza per la produzione e una per sviluppo/test.
Azure Key Vault archivia i segreti necessari per l'API per effettuare una chiamata HTTP POST a un'API esterna di terze parti come parte di un flusso di richieste. L'applicazione accede ai segreti tramite un riferimento a Key Vault nella configurazione dell'app del servizio app Azure. C'è una Key Vault per la produzione e una per sviluppo/test.
Azure Log Analytics viene usato come sink unificato per archiviare i log e le metriche per tutte le impostazioni di Diagnostica di Azure per tutti i componenti usati nella soluzione. C'è un area di lavoro per la produzione e una per sviluppo/test.
Azure Application Insights viene usato per acquisire dati di telemetria e log dall'API. Application Insights utilizza la modalità autonoma, senza scrivere in un’area di lavoro dedicato all'analisi dei registri. La produzione e il test non condividono un'istanza comune.
Azure Pipelines viene usato per CI/CD che compila, testa e distribuisce il carico di lavoro in ambienti di preproduzione e produzione. Il team del carico di lavoro gestisce le pipeline, che gestiscono anche tutta l'infrastruttura nella soluzione. Bicep è la scelta della tecnologia per infrastructure-as-Code (IaC).
Scelte di progettazione
Nell'elenco dei componenti, il timbro di distribuzione è costituito da servizi che partecipano all'elaborazione di una richiesta. Questi servizi includono servizio app e il codice API e Cosmos DB. Lo stamp include anche componenti non funzionali: Key Vault e Registro Contenitori. L'applicazione dipende da terzi da un framework per le prestazioni e la resilienza. Le identità gestite dal sistema vengono usate tra i componenti del timbro.
Nel timbro, Servizi app è configurato per ridimensionare automaticamente in base al carico.
Vengono utilizzati ambienti separati per la produzione e per il sviluppo/test. L'ambiente di produzione usa lo SKU Standard del piano servizio app. L'azienda ha scelto di preavvisare l'applicazione in uno slot prima di distribuirla nell'ambiente di produzione. L'ambiente di sviluppo/test usa lo SKU Basic per l'ottimizzazione dei costi. Entrambi gli ambienti hanno istanze personalizzate di servizi. Gli ambienti condividono solo il Registro Container.
Il codice API in contenitori viene recapitato in un'unica immagine contenitore eseguita in servizio app. L'API ha più endpoint HTTP usati dai vari front-end sia per le letture che per le scritture. I front-end non rientrano nell'ambito di questo modulo, ma rientrano nell'ambito dello stato cruciale di questa situazione. Il codice è stato instrumentato con Application Insights per acquisire alcuni dati di telemetria di base. Il team che ha sviluppato questo codice gestisce anche la pipeline CI/CD per l'immagine del contenitore API e le pipeline CI/CD.
Svantaggi
Tuttavia, come per ogni cosa, l'architettura corrente presenta dei compromessi. I requisiti aziendali hanno dato priorità all'ottimizzazione dei costi rispetto all'affidabilità e all'operatività. Per rispettare i limiti di costo, l'architettura non si è evoluta. I componenti non rientrano quando si sfruttano le funzionalità di affidabilità offerte dalla piattaforma. Ad esempio, la scelta della SKU per l'elaborazione impedisce al carico di lavoro di utilizzare le zone di disponibilità. Per i dati di telemetria, viene usata una versione precedente di Application Insights che non è integrata con Log Analytics.
Inoltre, l'accesso al carico di lavoro è eccessivamente pervasivo. Ad esempio, senza alcuna integrazione di reti virtuali, tutti i servizi Azure possono essere raggiunti direttamente attraverso la rete Internet pubblica.
Quando è stata sviluppata la soluzione, il team di sviluppo di app ha usato una singola sottoscrizione di Azure, individuando sviluppo/test e produzione nella stessa sottoscrizione per semplificare gli strumenti per i team DevOps. Tuttavia, le risorse di produzione e le risorse di sviluppo/test non sono completamente isolate. Alcune risorse vengono condivise tra i due ambienti, anche se hanno ottenuto una sottoscrizione isolata dal resto delle soluzioni di Contoso Shoes.
Inoltre, l'ambiente di sviluppo/test è un singolo ambiente condiviso tra tutti i membri del team di sviluppo e controllo di qualità. La scelta è stata giustificata dalle dimensioni dei team e il coordinamento tra di essi non richiedeva un grado di isolamento maggiore. Man mano che il team e la soluzione si sono evoluti, il singolo ambiente di sviluppo/test ha causato sempre più complessità di integrazione man mano che i cicli di vita del flusso di lavoro si sono scontrati. L'abbandono e il suo impatto sull'affidabilità sono stati costosi.
Specifica del progetto
L'azienda vuole aggiungere funzionalità all'architettura della soluzione in modo che sia in grado di gestire l'aumento previsto del carico. Ecco i requisiti aziendali:
- Creare la capacità di resistere a guasti regionali estendendo l'architettura a più regioni
- Migliorare l'esperienza del cliente offrendo ai clienti una maggiore velocità in un'area geograficamente più vicina
- Allinearsi alla roadmap di Azure e sfruttare le funzionalità di affidabilità più recenti offerte dai servizi di Azure
- Individuare precocemente i problemi e rilevarne l'impatto a cascata nel sistema costruendo un modello di salute generale
Questi requisiti sono solo l'elenco con priorità dei loro piani di miglioramento. Il team dell'applicazione è consapevole che tutte le aree di progettazione devono essere considerate per portare l'affidabilità di questa soluzione agli standard cruciali. In ogni caso, non si smetterà di migliorare la propria soluzione e le proprie operazioni dopo avere affrontato gli aspetti trattati nei prossimi esercizi.
Benvenuto nel team! Contoso Shoes è in attesa di ascoltare le raccomandazioni.
Attrezzaggio
In questo progetto di verifica si assumerà il ruolo di architetto che aiuterà Contoso Shoes a ottenere i risultati di affidabilità, a partire dagli elementi con priorità nella sezione precedente.
- È consigliabile usare lo strumento di diagramma dell'architettura per visualizzare l'architettura.
- Non è necessaria un abbonamento di Azure per questa sfida se si ha familiarità con i servizi e le relative funzionalità.