Een geografisch gedistribueerde toepassingsarchitectuur ontwerpen
Wanneer onze netwerkonderdelen aanvragen routeren naar meerdere regio's om de gevolgen van een regionale storing te beperken, moeten we toepassingsservices ontwerpen die kunnen reageren op deze aanvragen in zowel primaire als stand-byregio's.
Zoals eerder is gezegd, zijn we van plan Azure Front Door te configureren met back-endtoewijzing met prioriteit. We wijzen de regio VS - oost toe als primaire regio en de regio VS - west als onze stand-byregio. Wanneer er een regionale fout optreedt, worden aanvragen omgeleid naar de App Service in de niet-compatibele regio. We moeten resources in elke regio configureren ter ondersteuning van deze failovers voor gebruikerstoegang, gerepliceerde opslag en toepassingscode.
Hier onderzoeken we de toepassingsservices in onze oplossing en bepalen of ze moeten worden aangepast om te kunnen functioneren in een architectuur met meerdere regio's. We kijken met name naar Active Directory, statische inhoudsopslag, web-apps, web-API's, wachtrijen, Azure-functies en gegevenscaches.
Microsoft Entra ID
In onze portal voor het bijhouden van zendingen kunnen gebruikers de levering van hun aankopen bijhouden door een traceringsnummer in te voeren. Echter, reguliere gebruikers kunnen zich registreren voor een lidmaatschap om toegang te krijgen tot geavanceerde functies, zoals de snelheid van bezorging en andere statistieken. We hebben de trackingportal ontwikkeld om gebruikersaccounts op te slaan in Microsoft Entra ID.
Microsoft Entra ID is standaard ontworpen als een globaal systeem. Als zodanig is het niet kwetsbaar voor regionale storingen en hoeven we dit onderdeel van het systeem niet te wijzigen.
Azure Blob Storage
Statische inhoud, zoals afbeeldingen en video's, worden opgeslagen in Azure Storage-accounts als Binaire grote objecten (Blobs) en worden geleverd aan gebruikers via het Azure CDN.
In ons oorspronkelijke ontwerp bevindt het opslagaccount zich in één regio, omdat we ervoor hebben gekozen lokaal redundante opslag (LRS) te gebruiken. Onze gegevens worden alleen gerepliceerd binnen één datacenter met LRS. Het opslagaccount is daarom niet beschikbaar als er een regionale storing in deze configuratie is. Alle statische inhoud die al in de cache van het CDN is opgeslagen, blijft beschikbaar voor gebruikers.
Hetzelfde geldt voor Zone Redundant Storage (ZRS). Hoewel gegevens worden gerepliceerd naar verschillende datacenters in deze configuratie, bevinden al deze datacenters zich nog steeds in dezelfde regio. Een regionale storing is ook van invloed op het opslagaccount in deze configuratie.
In ons ontwerp vertrouwen we sterk op onze CDN-configuratie om statische inhoud in de cache op te cachen. Tijdens een storing kan een gebruiker mogelijk een statisch bestand aanvragen dat zich nog niet in de CDN-cache bevindt. Deze aanvraag zou resulteren in een afbeelding of video die niet kan worden weergegeven.
We kunnen deze mogelijkheid elimineren door het opslagaccount naar meerdere regio's te repliceren wanneer we een geografisch redundante opslagoptie kiezen. Er is ook een optie voor alleen-lezenreplicatie beschikbaar om te voorkomen dat statische inhoud wordt toegevoegd tijdens een regionale storing.
We hebben twee opties waaruit u kunt kiezen wanneer we georedundantie moeten inschakelen. Deze opties zijn Read-Access Geo-Redundant Storage (RA-GRS) en Read-Access Geo-Zone-Redundant Storage (RA-GZRS). De keuze die we maken, is afhankelijk van ons budget en het percentage van de tijd die we nodig hebben.
Azure App Service- en Azure Function-Apps
Onze portal voor het bijhouden van zendingen implementeert twee Azure App Services. De eerste App Service fungeert als host voor een web-app die de gebruikersgerichte webinterface implementeert en de tweede fungeert als host voor een web-API die door mobiele apps wordt gebruikt om verzendingsgegevens bij te houden. Al onze achtergrondtaken worden uitgevoerd als Azure Function-apps.
In ons oorspronkelijke ontwerp wordt elke Azure App Service gelokaliseerd in één Azure-regio. We maken een tweede App Service in de secundaire regio (VS - west) en implementeren het webproject daar ter ondersteuning van de nieuwe architectuur voor meerdere regio's. We configureren de prioriteitsrouteringsmodus van Azure Front Door om aanvragen naar onze secundaire regio te verzenden wanneer de primaire regio niet beschikbaar is.
Om ervoor te zorgen dat de failover zo soepel mogelijk verloopt, moet u ervoor zorgen dat de webtoepassing geen sessiestatusgegevens in het geheugen opslaat. We wijzigen onze website om ervoor te zorgen dat we niet eindigen op gegevensverlies. Als onze code bijvoorbeeld een lijst met de verzendingen van gebruikers in het geheugen opslaat, gaat deze lijst verloren als er een failover is opgetreden.
Elke webaanvraag wordt verwerkt zonder dat dit van invloed is op de andere wanneer er geen sessiestatus wordt opgeslagen. Als er een failover plaatsvindt in het midden van de sessie van een gebruiker, moet de failover transparant zijn voor de gebruiker.
We brengen een vergelijkbare wijziging aan in onze Azure Function-apps. We maken een afzonderlijk exemplaar van de Azure-functie in de secundaire regio en implementeren dezelfde aangepaste code als deze wordt uitgevoerd in de primaire regio.
Belangrijk
Wanneer u een update implementeert naar de aangepaste code in de App Service- of Functie-app-service, moet u deze distribueren naar alle exemplaren van de App Service. Als u dit proces wilt automatiseren, bevat Azure DevOps hulpprogramma's die u kunnen helpen.
Azure Storage-wachtrijen
In onze oorspronkelijke architectuur met één regio hebben we een wachtrij in een Azure Storage-account gebruikt om de communicatie tussen de App Service en de functie-app te beheren. Wanneer de web-app of de web-API een achtergrondtaak moet uitvoeren, wordt er een bericht met alle vereiste informatie in de wachtrij geplaatst. De functie-app bewaakt de wachtrij voor nieuwe berichten en voert de achtergrondtaak uit door de benodigde query's uit te voeren op de gegevensarchieven.
We kunnen een hoge vraag in webaanvragen op een ordelijke manier beheren wanneer we een wachtrij op deze manier gebruiken. Wanneer er veel achtergrondtaken moeten worden uitgevoerd, kan de wachtrij worden opgebouwd, maar worden taken niet verwijderd. Ze blijven in de wachtrij totdat ze worden verwerkt. De functie-apps verwerken de wachtrij en verkleinen de grootte zodra de vraag afneemt. Als de vraag zich blijft voordoen, verhogen we het aantal exemplaren van de functie-app.
Voor de multiregioversie van de portal voor het bijhouden van zendingen moeten we ervoor zorgen dat wachtrijitems niet verloren gaan wanneer er een failover plaatsvindt. Onze wachtrij is gedefinieerd in Azure Storage en we kunnen een redundantieoptie gebruiken voor geo-replicatie.
Houd er rekening mee dat we geen redundantieoptie voor leestoegang kunnen gebruiken, omdat onze wachtrij lees- en schrijfbewerkingen ondersteunt. De App Service moet items toevoegen aan de wachtrij en de functie-app moet voltooide items uit de wachtrij verwijderen. Gebruik in plaats daarvan Geo-Redundant Storage (GRS) of Geo-Zone-Redundant Storage (GZRS).
Azure Redis Cache
We gebruiken Azure Redis Cache om de prestaties van gegevensopslag te maximaliseren. Redis slaat alle queryresultaten die zijn gegenereerd op basis van onze apps in de cache op wanneer ze gegevens uit onze database aanvragen. Verdere query's voor vergelijkbare gegevens hebben geen databasequery nodig en worden opgehaald uit de Redis-cache.
Voor de multi-regio architectuur maken we een Redis Cache-exemplaar in zowel primaire als standby-regio's. Houd er rekening mee dat wanneer er een failover plaatsvindt, de Redis-cache in de stand-byregio waarschijnlijk leeg is. Deze lege cache veroorzaakt geen fouten, maar de prestaties kunnen tijdelijk afnemen, omdat gegevens de nieuwe cache vullen.