Een geografisch gedistribueerde architectuur ontwerpen
Azure is een wereldwijd systeem. Door een architectuur te ontwerpen die zich in meer dan één Azure-regio bevindt, kunnen we een toepassing bouwen die zelfs bestand is tegen rampen die de gehele regio omspannen.
Uw portal voor het bijhouden van wijzigingen is schaalbaar omdat deze is gemaakt met behulp van een groot aantal Azure-resources die kunnen worden geschaald. Het is ook bestand tegen veel fouten, omdat de onderdelen 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 waarvoor een failover kan worden uitgevoerd naar een tweede regio als er een storing is in VS - oost.
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.
Architectuur van de oorspronkelijke web-app
Laten we eens kijken hoe het architectuurontwerp van de portal voor het bijhouden van de portal 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 in de regio VS - oost te implementeren. Hoewel de resourcegroep ons niet beperkt tot het gebruik van dezelfde Azure-regio voor de opgenomen resources, hebben we besloten de regio VS - oost te gebruiken voor alle resources die in onze toepassing zijn geïmplementeerd.
In onze toepassing worden drie categorieën Azure-resources gebruikt. 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.
| Service | Beschrijving |
|---|---|
| Azure DNS | We hebben Azure DNS geconfigureerd om onze DNS-records in Azure te hosten. Met Azure DNS kunnen we onze DNS-records beheren met behulp van onze Azure-referenties in Azure Portal. |
| Application Gateway | De load balancer van Application Gateway is zo geconfigureerd dat verkeer tussen meerdere exemplaren van de web-front-end wordt verdeeld. Deze service bevindt zich in één Azure-regio. |
| Azure CDN | We hebben Azure CDN geconfigureerd om de levering van niet-beveiligde statische inhoud, zoals afbeeldingen voor de inhoud van onze website, te maximaliseren. Met deze globale service wordt statische inhoud opgeslagen op aanwezigheidspunten over de hele wereld. |
Toepassingsonderdelen
De portal voor het bijhouden van wijzigingen maakt gebruik van de volgende services ter ondersteuning van de vereisten voor code, cache en tijdelijke opslag.
| Service | 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 wijzigingen 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 wijzigingen maakt gebruik van Azure Function-apps om alle achtergrondtaken uit te voeren. Sommige van deze taken worden gepland volgens een regelmatig schema en andere taken worden uitgevoerd op de berichten in een wachtrij. |
| Azure Storage-wachtrijen | De portal voor bijhouden maakt gebruik van Azure Storage-wachtrijen met Azure Function-apps. De portal voor het bijhouden van wijzigingen plaatst de gegenereerde berichten in de wachtrij van waaruit de Function-apps deze berichten verwerken. |
| Redis Cache | De portal voor het bijhouden van wijzigingen maakt gebruik van een Redis Cache tussen de front-end app-service en de gegevensopslagsystemen om de prestaties van query's te maximaliseren. |
| Azure Blob-opslag | 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 in de portal voor het bijhouden van wijzigingen ingeschakeld. 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.
| Service | Beschrijving |
|---|---|
| Azure SQL-database | We slaan relationele gegevens op, zoals bestellings- en klantgegevens in Azure SQL Database. |
| Cosmos DB | We slaan semi-gestructureerde gegevens op, waaronder onze productcatalogus in Cosmos DB. |
Problemen met de oorspronkelijke architectuur
De bestaande architectuur voor de portal voor het bijhouden van wijzigingen 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 aanvragen naar deze nieuw gemaakte exemplaren routeren.
Er zijn echter scenario's waarin ons architectuurontwerp uitdagingen heeft om te overwinnen of zelfs te mislukken. Laten we eens kijken naar elk scenario om een beter inzicht te krijgen in de gevolgen voor de portal voor het bijhouden van wijzigingen.
Regionale storingen
Enkele significante gebeurtenissen hebben de mogelijkheid om een onderbreking in een volledige Azure-regio te veroorzaken. 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 ongebruikelijk en veel bedrijven denken dat ze dat risico kunnen dragen. Het gevolg van een regionale storing waarbij de portal voor het bijhouden van wijzigingen wordt uitgeschakeld, is echter zo'n hoog risico dat het managementteam van het bedrijf heeft besloten dit risico te elimineren.
Overeenkomsten op serviceniveau
De meeste Azure-services bieden een Service Level Agreement (SLA) of een gegarandeerde uptime. Wanneer we een toepassingsarchitectuur ontwerpen die uit meerdere Azure-services bestaat, berekenen we de algemene SLA voor de app als een combinatie van de SLA's van alle andere services.
U berekent deze SLA door de SLA's van de Component Services met elkaar te vermenigvuldigen. Stel dat onze app bestaat uit Azure-app Service (SLA van 99,95%) en Microsoft Entra-id (SLA van 99,9%). De berekende SLA is dan 99,85%.
Als dit percentage voor uptime niet voldoende is voor onze toepassing, kunnen we ervoor zorgen dat de toepassing een failover naar een andere regio uitvoert.
Wereldwijde, 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 om meerdere regio's te ondersteunen. We kunnen bijvoorbeeld de optie voor geografisch redundante opslag gebruiken in het Azure Storage-account waarin statische inhoud wordt opgeslagen. Met geografisch redundante opslag worden blobs naar een andere regio gerepliceerd.
In de volgende tabel ziet u welke onderdelen globaal, regionaal en configureerbaar zijn.
| Onderdeel | 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-opslag | 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 | Configureerbaar | 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 behandelt alle aanvragen van de onderdelen onder normale omstandigheden. Als een noodgeval een regionale storing veroorzaakt, wordt er voor de toepassing een failover uitgevoerd naar de regio VS - west.
We gaan nu op hoog niveau 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 wereldwijde 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 een enkele 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.
Toepassingsservices
Microsoft Entra ID is een globaal systeem en hoeft niet te worden gewijzigd.
Azure Storage-accounts kunnen worden geconfigureerd om inhoud naar meerdere regio's te repliceren. 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 er een failover plaatsvindt.
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 vormen een paar met andere regio's in dezelfde geografie. Binnen deze paren worden updates en gepland onderhoud slechts op één regio tegelijkertijd uitgevoerd. Als er een storing optreedt die van invloed is op meerdere regio's, wordt voor ten minste één regio in elk paar prioriteit gegeven voor snel herstel.
U kunt het best een architectuur met twee regio's voor uw app in de twee regio's in een regiopaar plaatsen. Bijvoorbeeld: VS - oost vormt een paar met VS - west. Ons voorgestelde ontwerp maakt gebruik van VS - oost voor de actieve regio en VS - west voor de stand-byregio.