Een geografisch gedistribueerde architectuur ontwerpen
Azure is een globaal systeem. Door een architectuur te ontwerpen die aanwezig is in meer dan één Azure-regio, kunnen we een toepassing bouwen die bestand is tegen zelfs regiobrede rampen.
Uw portal voor het bijhouden van verzendingen is schaalbaar omdat deze is gebouwd met behulp van een reeks Azure-resources die kunnen worden geschaald. Het is ook bestand tegen veel storingen, omdat de componenten meerdere exemplaren kunnen hebben. Uw raad van bestuur is echter bezorgd geworden dat een grootschalige ramp een onderbreking kan veroorzaken omdat de portal volledig is opgenomen in de Azure-regio VS - oost. U wilt een gewijzigde architectuur voorstellen die een failover naar een tweede regio kan uitvoeren als VS - oost mislukt.
Hier leert u hoe u de architectuur van onze toepassing aanpast ter ondersteuning van een geografisch gedistribueerde toepassing. We zien ook waarom dergelijke architectuur voordelig is voor bedrijfskritieke toepassingen.
Oorspronkelijke web-app-architectuur
Laten we eens kijken naar het architectuurontwerp van de portal voor het bijhouden en de onderdelen die in de oplossing worden gebruikt. Nadat we hebben begrepen hoe we alle onderdelen gebruiken, kunnen we onderzoeken hoe we elk van deze onderdelen kunnen ondersteunen in scenario's met georedundantie.
Het ontwerp van de trackingportal is gebaseerd op de referentiearchitectuur die in het volgende diagram wordt weergegeven.
U ziet hoe onze toepassing gebruikmaakt van één Azure-resourcegroep. Met deze resourcegroep kunnen we al onze resources logisch groeperen en beheren en vereenvoudigt het beheer. We hebben ervoor gekozen om deze resourcegroep te implementeren in de regio VS - oost. Hoewel de resourcegroep ons niet beperkt tot het gebruik van dezelfde Azure-regio voor de opgenomen resources, hebben we besloten om de regio VS - oost te gebruiken voor alle resources die in onze toepassing zijn geïmplementeerd.
Onze toepassing maakt gebruik van drie categorieën Azure-resources. Laten we eens kijken naar elke categorie en kijken welke resources worden gebruikt.
Netwerkonderdelen
De portal voor het bijhouden van gegevens maakt gebruik van de volgende netwerkservices.
| Dienst | Beschrijving |
|---|---|
| Azure DNS | We hebben Azure DNS geconfigureerd voor het hosten van onze DNS-records in Azure. Met Azure DNS kunnen we onze DNS-records beheren met behulp van onze Azure-referenties in Azure Portal. |
| Application Gateway | We hebben de Load Balancer van Application Gateway geconfigureerd om verkeer tussen meerdere exemplaren van de webfront-end te verdelen. Deze service is gelokaliseerd in één Azure-regio. |
| Azure CDN | We hebben Azure CDN geconfigureerd om de levering van onbeveiligde statische inhoud te maximaliseren, zoals afbeeldingen voor de inhoud van onze website. Met deze globale service wordt statische inhoud opgeslagen op aanwezigheidspunten over de hele wereld. |
Toepassingsonderdelen
De portal voor het bijhouden van gegevens maakt gebruik van de volgende services ter ondersteuning van vereisten voor code, cache en tussenliggende opslag.
| Dienst | Beschrijving |
|---|---|
| Microsoft Entra ID | Gebruikers hebben toegang tot de portal voor tracering met behulp van Microsoft Entra-accounts. De directory en het account worden automatisch wereldwijd gerepliceerd. |
| Azure App Service | De portal voor het bijhouden van gegevens maakt gebruik van twee Azure App Services. De eerste voert een set dynamische webpagina's en de tweede een web-API uit. |
| Azure Function-apps | De portal voor het bijhouden van gegevens maakt gebruik van Azure Function-apps om alle achtergrondtaken uit te voeren. Sommige van deze taken worden volgens een normaal schema uitgevoerd en andere taken worden uitgevoerd op de berichten in een wachtrij. |
| Azure Storage Queues | Het volgportaal maakt gebruik van Azure Storage-wachtrijen met Azure Function-apps. De portal voor het bijhouden plaatst gegenereerde berichten in de wachtrij van waaruit de functie-apps deze berichten verwerken. |
| Redis-cache | De portal voor het bijhouden van gegevens maakt gebruik van een Redis-cache tussen de front-end-app-service en de systemen voor gegevensopslag om de prestaties van query's te maximaliseren. |
| Azure Blob Storage | Statische inhoud, zoals afbeeldingen en videobestanden, worden bewaard als binaire grote objecten (blobs) in een Azure Storage-account en worden geleverd via azure CDN. |
| Azure Search | We hebben Azure Search ingeschakeld op de trackingportal. Met Azure Search kunnen we alle inhoud doorzoekbaar maken en zoeksuggesties en fuzzy zoekresultaten aan onze gebruikers leveren. |
Onderdelen voor gegevensopslag
In de portal voor het bijhouden wordt gebruikgemaakt van de volgende permanente opslagservices.
| Dienst | Beschrijving |
|---|---|
| Azure SQL Database | We slaan relationele gegevens op, zoals order- en klantgegevens in Azure SQL Database. |
| Cosmos DB | We slaan semi-gestructureerde gegevens op, inclusief onze productcatalogus in Cosmos DB. |
Problemen met de oorspronkelijke architectuur
De bestaande architectuur voor het volgportal is ontworpen om schaalbaarheid en beschikbaarheid mogelijk te maken.
Als de vraag bijvoorbeeld hoog is en reacties op webaanvragen van gebruikers traag zijn, kunt u overwegen om meer exemplaren van de front-endweb-app toe te voegen in De App Service. Hier kan de Application Gateway verzoeken doorsturen naar deze zojuist gemaakte exemplaren.
Er zijn echter scenario's waarin ons architectuurontwerp uitdagingen heeft om te overwinnen of zelfs te mislukken. Laten we kijken naar elk scenario om een beter inzicht te krijgen in de impact op het volgportaal.
Regionale fouten
Sommige belangrijke gebeurtenissen hebben het potentieel om een hele Azure-regio te onderbreken. Azure-datacenters zijn ontworpen om zeer tolerant te zijn, maar een enorme weersevenement, zoals een orkaan of overstroming, kan de service uit de regio verstoren.
Deze gebeurtenissen zijn ongebruikelijke gebeurtenissen en veel bedrijven denken dat ze dat risico kunnen dragen. Het gevolg van een regionale storing bij het uitschakelen van de trackingportal is echter van een dergelijk hoog risico dat het leidinggevend team van het bedrijf heeft besloten het risico te elimineren.
Serviceovereenkomsten
De meeste Azure-services bieden een SLA (Service Level Agreement) of een garantie voor uptime. Wanneer we een toepassingsarchitectuur ontwerpen die bestaat uit meerdere Azure-services, berekenen we de algemene SLA voor de app als een samengestelde sla van alle andere service-SLA's.
U berekent deze SLA door de SLA's van de onderdeelservices samen te vermenigvuldigen. Stel dat onze app bestaat uit Azure App Service (99,95% SLA) en Microsoft Entra ID (99,9% SLA). De uiteindelijke berekende SLA is 99,85%.
Als dit percentage uptime niet voldoende is voor onze toepassing, kunnen we ervoor zorgen dat de toepassing een failover naar een andere regio uitvoert.
Globale, regionale en configureerbare onderdelen
In ons ontwerp zijn sommige onderdelen standaard wereldwijd en niet kwetsbaar voor een regionale storing.
Sommige onderdelen zijn beperkt tot één regio, bijvoorbeeld de Application Gateway. We moeten een alternatieve service voor deze typen onderdelen selecteren.
Sommige onderdelen kunnen worden geconfigureerd ter ondersteuning van meerdere regio's. We kunnen bijvoorbeeld de optie Geo-Redundant Storage (GRS) gebruiken in het Azure Storage-account waarin statische inhoud wordt opgeslagen. GRS repliceert blobs naar een andere regio.
In de volgende tabel ziet u welke onderdelen globaal, regionaal en configureerbaar zijn.
| Bestanddeel | Ondersteuning voor meerdere regio's | Opmerkingen |
|---|---|---|
| Azure DNS | Globaal | Er zijn geen wijzigingen nodig. |
| Application Gateway | Regionaal | Elk exemplaar van Application Gateway bevindt zich in één regio. |
| Azure CDN | Globaal | Er zijn geen wijzigingen nodig, inhoud wordt standaard globaal in de cache opgeslagen. |
| Microsoft Entra ID | Globaal | Er zijn geen wijzigingen nodig. |
| Azure App Service | Regionaal | Elk exemplaar van de app bevindt zich in één regio. |
| Azure Function Apps | Regionaal | Elk exemplaar van de functie-app bevindt zich in één regio. |
| Azure Storage-wachtrijen | Configureerbaar | U kunt ervoor kiezen om een Azure Storage-account te repliceren naar meerdere regio's. |
| Azure Redis Cache | Regionaal | Elk exemplaar van de cache bevindt zich in één regio. |
| Azure Blob Storage | Configureerbaar | U kunt ervoor kiezen om een Azure Storage-account te repliceren naar meerdere regio's. |
| Azure Search | Regionaal | Elk exemplaar van de zoekservice bevindt zich in één regio. |
| Azure SQL Database | Instelbaar | U kunt geo-replicatie gebruiken om gegevens te synchroniseren met meerdere regio's. |
| Azure Cosmos DB | Configureerbaar | U kunt geo-replicatie gebruiken om gegevens te synchroniseren met meerdere regio's. |
Voorgestelde gedistribueerde architectuur
Na enig onderzoek stelt u de architectuur voor, zoals wordt weergegeven in het volgende diagram.
In dit ontwerp is er een actieve regio (VS - oost) en een stand-byregio (VS - west). De regio VS - oost verwerkt alle aanvragen door de onderdelen onder normale omstandigheden. Als een noodgeval een regionale storing veroorzaakt, voert de toepassing een failover uit naar de regio VS - west.
Laten we eens op hoofdlijnen bekijken hoe u de oorspronkelijke architectuur hebt gewijzigd. We verkennen deze wijzigingen in meer detail in latere eenheden.
Netwerken
Azure DNS en Azure CDN zijn standaard globale systemen en zijn al bestand tegen regionale storingen. We laten ze op hun plaats.
Wanneer we een Azure Application Gateway maken, wijzen we de service toe aan één regio. We verwijderen dit beveiligingsprobleem door deze service te vervangen door Azure Front Door. Front Door kan meerdere App Services peilen en de App Service-failover van de regio VS - oost naar de regio VS - west verwerken.
Applicatiediensten
Microsoft Entra ID is een globaal systeem en hoeft niet te worden gewijzigd.
Azure Storage-accounts kunnen worden geconfigureerd voor het repliceren van inhoud naar meerdere regio's. We gebruiken een van de geografisch redundante opslagopties om onze configuratie te wijzigen.
De andere onderdelen, waaronder de App Service, Functie-apps, de Redis-cache en Azure Search, zijn regionaal. We maken dubbele exemplaren van deze onderdelen in de regio VS - west in ons nieuwe architectuurontwerp. In dit ontwerp kan de nieuwe regio het overnemen wanneer zich een failover voordoet.
Gegevensopslag
Azure SQL Database en Azure Cosmos DB ondersteunen beide geo-replicatie van gegevens naar andere regio's. We configureren deze services voor het repliceren van gegevens in VS - oost naar de equivalente services in VS - west.
Regionale paren
Een Azure-regio is een gebied met één geografie die een of meer Azure-datacenters bevat. Alle regio's zijn gekoppeld aan andere regio's in dezelfde geografie. Binnen deze paren worden updates en gepland onderhoud uitgevoerd op slechts één regio tegelijk. Als er een fout optreedt die van invloed is op meerdere regio's, krijgt ten minste één regio in elk paar prioriteit voor snel herstel.
De best practice is om een tweeregio-architectuur voor uw app te plaatsen in de twee regio's van een regionaal paar. Als voorbeeld: Oost-VS werkt samen met West-VS. Ons voorgestelde ontwerp maakt gebruik van VS - oost voor de actieve regio en VS - west voor de stand-byregio.