Azure Spring Apps implementeren in meerdere regio's

In deze referentiearchitectuur wordt een benadering beschreven voor het uitvoeren van meerdere Azure Spring Apps-exemplaren in verschillende regio's in een actief-actief-configuratie.

Dit ontwerp is gebaseerd op de basislijnarchitectuur van Azure Spring Apps. Met de basislijn wordt een Java Spring Boot-toepassing geïmplementeerd in meerdere beschikbaarheidszones binnen één regio. De meerdere zones verspreiden de toepassingsworkload over afzonderlijke locaties, zodat de workload lokale fouten binnen de Azure-regio kan tolereren.

Als de hele regio echter een storing ondervindt, is de basislijn niet meer beschikbaar voor de gebruiker. Het doel van dit ontwerp is om hoge beschikbaarheid te bouwen die bestand is tegen regionale storingen.

Deze architectuur is handig om te voldoen aan de volgende doelstellingen:

• Verhoog de algehele tolerantie en serviceniveaudoelstelling (SLO) van de toepassing.
• Wereldwijd bereik voor de toepassing inschakelen.
• Breng de workload dichter bij de eindgebruiker en maak latentie zo laag mogelijk.
• Gebruik een secundaire regio als failoversite voor de primaire regio en kies voor een actief-passief ontwerp.

Als u de tolerantie en betrouwbaarheid van toepassingen wilt vergroten, kunt u de toepassing implementeren in meerdere regio's. Voor dit ontwerp hebt u een globale router nodig om aanvragen te verdelen over uw toepassingen in verschillende regio's. De globale router in deze architectuur heeft ook betrekking op andere doelen.

De grootste uitdaging bij het instellen van meerdere regio's is het repliceren van de gegevens voor uw toepassing tussen meerdere regio's. Dit probleem is geen probleem met de installatie met meerdere zones. Azure-beschikbaarheidszones zijn verbonden door een netwerk met hoge prestaties met een retourlatentie van minder dan 2 ms. Deze latentieperiode is voldoende voor de meeste toepassingen.

Architectuur

In het volgende diagram ziet u de architectuur voor deze benadering:

Onderdelen

De onderdelen van deze architectuur zijn hetzelfde als de basislijnarchitectuur. In de volgende lijst worden alleen de wijzigingen in de basislijnarchitectuur gemarkeerd. Zie de sectie Gerelateerde resources voor productdocumentatie over Azure-services.

• Azure Front Door fungeert als de globale load balancer. Deze service wordt gebruikt vanwege de mogelijkheid om hogere beschikbaarheid te bieden met een lagere latentie, grotere schaal en caching aan de rand.

Workflow

De referentiearchitectuur implementeert de volgende werkstroom:

1. De gebruiker verzendt een aanvraag naar de HTTP-hostnaam van de toepassing, zoals www.contoso.com. Azure DNS zet de aanvraag voor deze hostnaam om in Azure Front Door.

2. Azure Front Door maakt gebruik van verschillende taakverdelingsconfiguraties om de binnenkomende aanvragen door te sturen naar het openbare eindpunt van Azure-toepassing Gateway in elke regio. De Application Gateway-exemplaren worden geconfigureerd met dezelfde aangepaste domeinnaam en TLS-certificaatnaam als Azure Front Door.

3. Application Gateway met geïntegreerde Azure Web Application Firewall inspecteert de aanvraag. Web Application Firewall staat binnenkomende aanvragen alleen toe vanuit het opgegeven Azure Front Door-profiel.

4. Application Gateway stuurt het toegestane verkeer door naar het IP-adres van de load balancer in het ingerichte Spring Apps-exemplaar.

5. De interne load balancer stuurt alleen het verkeer van Application Gateway naar de back-endservices. Deze services worden gehost in een Spring Apps-exemplaar in een virtueel netwerk in elke regio.

6. Als onderdeel van de verwerking van de aanvraag communiceert de toepassing met andere Azure-services binnen het virtuele netwerk. Voorbeelden hiervan zijn de toepassing die communiceert met Azure Key Vault voor geheimen en de database voor het opslaan van de status.

Wereldwijde distributie

Als u ontwerpt voor hoge beschikbaarheid, kunt u deze architectuur instellen in een actief-actief, actief-passief met hot stand-by of actief-passief met koude stand-bymodus.

Uw keuze is afhankelijk van de beschikbaarheidsvereisten voor uw toepassing. Deze architectuur maakt gebruik van actief-actieve implementatie in twee regio's omdat de voorbeeldorganisatie een wereldwijde aanwezigheid wil hebben met een SLA met hoge uptime (Service Level Agreement). Als u bedrijfskritieke toepassingen uitvoert en hogere beschikbaarheid wilt, moet u meer dan twee regio's gebruiken.

Actief-actief

In de modus actief-actief verwerken alle regio's gelijktijdig aanvragen. De grootste uitdaging met de actief-actieve modus is het houden van de gegevenssynchronisatie tussen de regio's. Deze modus is een dure benadering omdat u twee keer betaalt voor bijna alle onderdelen.

Actief-passief met hot stand-by

In de modus actief-passief met hot stand-by ontvangt de secundaire regio geen aanvragen van Azure Front Door zolang de primaire regio actief is. Zorg ervoor dat u uw toepassingsgegevens repliceert van uw primaire naar uw secundaire regio. Als er een fout optreedt in uw primaire regio, moet u de rollen van uw back-enddatabases wijzigen en een failover uitvoeren van al het verkeer via Azure Front Door naar uw secundaire regio.

In de actief-passieve modus duurt failover naar verwachting enige tijd, waardoor het eenvoudiger is om ervoor te zorgen dat alle gegevens gesynchroniseerd blijven. De actief-passieve modus met hot stand-by is echter net zo kostbaar als het werken met de actief-actieve modus.

Actief-passief met koude stand-by

In de modus actief-passief met koude stand-by heeft de primaire regio alle resources en dient het verkeer. De secundaire regio bevat mogelijk minder onderdelen of onderdelen met lagere rekenresources. De technologische keuzes zijn afhankelijk van hoeveel downtime acceptabel is volgens de bedrijfsvereisten. De omvang van uw secundaire regio-instelling is ook van invloed op de kosten. Zorg ervoor dat ten minste toepassingsgegevens aanwezig zijn in de secundaire regio.

Zoals vermeld, omvat de actief-passieve modus een failover die enige tijd in beslag neemt, zodat het eenvoudiger is om alle gegevens gesynchroniseerd te houden. De modus Actief-passief met koude stand-by is de meest rendabele benadering, omdat u niet alle resources in beide regio's implementeert.

Als uw hele installatie van de oplossing sjablonen gebruikt, kunt u eenvoudig een koude stand-by secundaire regio implementeren door de resources indien nodig te maken. U kunt Terraform-, Bicep- of Azure Resource Manager-sjablonen gebruiken en het instellen van de infrastructuur automatiseren in een CI/CD-pijplijn (continuous integration/continuous deployment). U moet uw configuratie regelmatig testen door uw secundaire regio opnieuw te maken om ervoor te zorgen dat uw sjablonen in noodgevallen kunnen worden geïmplementeerd.

Het patroon implementatiestempels wordt aanbevolen omdat meerdere onafhankelijke kopieën van een toepassing of onderdeel kunnen worden geïmplementeerd vanuit één sjabloon naar meerdere regio's.

Modusvergelijking

De volgende tabel bevat een overzicht van de inspanningen die nodig zijn voor het synchroniseren van gegevens voor elke modus en vergelijkt de kosten.

Routering tussen regio's

Deze referentiearchitectuur maakt gebruik van geografische knooppunten (Geodes) waar elke regio elke aanvraag kan verwerken.

Azure Front Door is geconfigureerd met gelijke routering tussen de twee implementatieregio's. Azure Front Door biedt ook andere verkeersrouteringsmethoden voor oorsprong. Als u clients naar hun dichtstbijzijnde oorsprong wilt routeren, is routering op basis van latentie het meest zinvol. Als u ontwerpt voor een actief-passieve oplossing, is routering op basis van prioriteit beter geschikt.

In het voorbeeld van de referentiearchitectuur wordt een taakverdelingsregel met gelijke gewicht tussen de twee regio's gebruikt. Azure Front Door is geconfigureerd met:

• Een aangepast domein en een TLS-certificaat (Transport Layer Security) met dezelfde naam als de hostnaam van de toepassing, zoals www.contoso.com.

• Eén oorsprong per regio waar de toepassing wordt geïmplementeerd, waarbij elke oorsprong een Azure-toepassing Gateway-exemplaar is.

Indeling van resourcegroep

Gebruik Azure-resourcegroepen om resources te beheren die in elke regio zijn geïmplementeerd als één verzameling. Overweeg om de primaire regio, secundaire regio en Azure Front Door in afzonderlijke resourcegroepen te plaatsen, zoals wordt weergegeven in het volgende diagram:

In het diagram ziet u de volgende configuratie van resourcegroepen:

• Azure Front Door wordt geïmplementeerd in de Application-shared resourcegroep.
• Alle resources die worden gehost in de regio Europa - west (weu) worden geïmplementeerd in de Application-weu resourcegroep.
• Resources die worden gehost in de regio VS - oost (eus) worden gehost in de Application-eus resourcegroep.
• Resources die worden gehost in de regio Japan - oost (jae) worden gehost in de Application-jae resourcegroep.

Resources in dezelfde resourcegroep delen dezelfde levenscyclus en kunnen eenvoudig samen worden gemaakt en verwijderd. Elke regio heeft een eigen set resources in een toegewezen resourcegroep die een naamconventie volgt op basis van de regionaam. Azure Front Door bevindt zich in een eigen resourcegroep, omdat deze moet bestaan, zelfs als andere regio's worden toegevoegd of verwijderd.

Omgekeerde proxy instellen

Azure Front Door zorgt voor wereldwijde taakverdeling tussen regio's. Deze omgekeerde proxy helpt het verkeer te distribueren als u een workload in meerdere regio's implementeert. Als alternatief kunt u Azure Traffic Manager gebruiken. Traffic Manager is een op DNS gebaseerde load balancer voor verkeer die alleen op domeinniveau wordt verdeeld.

Azure Front Door heeft geïntegreerde netwerken voor contentlevering (CDN's) die inhoud leveren uit het wereldwijde edge-netwerk van Microsoft met aanwezigheidspunten (PoPs) verspreid over de hele wereld.

De huidige oplossing maakt gebruik van twee omgekeerde proxy's om consistentie te behouden met de basislijnarchitectuur. Azure Front Door is de wereldwijde router. Application Gateway fungeert als een load balancer per regio. In de meeste gevallen is deze installatie niet vereist. U kunt Application Gateway verwijderen als u voldoet aan de volgende vereisten:

• Omdat Azure Web Application Firewall is gekoppeld aan Application Gateway, moet u Web Application Firewall in plaats daarvan koppelen aan de Azure Front Door-service.
• U hebt een manier nodig om ervoor te zorgen dat binnenkomende oproepen alleen afkomstig zijn van uw Azure Front Door-exemplaar. U kunt de X-Azure-FDID header controle en de IP-adresbereiken van Azure Front Door toevoegen in de Spring Cloud Gateway-toepassing. Zie Azure Front Door gebruiken als omgekeerde proxy met Spring Cloud Gateway voor meer informatie.

Zie Azure Spring Apps beschikbaar maken via een omgekeerde proxy voor informatie over verschillende scenario's voor omgekeerde proxy's, het instellen ervan en de bijbehorende beveiligingsoverwegingen.

Back-enddatabase

Voor implementatie in meerdere regio's moet u een strategie voor gegevensreplicatie hebben. Wanneer de toepassing beschikbaar is in verschillende regio's, moeten gegevens worden gesynchroniseerd, zodat gebruikers geen verouderde gegevens zien.

De huidige architectuur maakt gebruik van een MySQL-database voor de back-enddatabase, maar deze configuratie heeft geen betrekking op gegevenssynchronisatie. Wanneer u een databasetechnologie kiest, controleert u hoe u gegevens het beste kunt repliceren en synchroniseren tussen regio's. Een optie is de Azure SQL Database, die een actieve functie voor geo-replicatie heeft die een continu gesynchroniseerde, leesbare secundaire database voor een primaire database biedt.

U kunt deze functie gebruiken in de volgende scenario's:

• Als uw secundaire regio een koude stand-by is die geen actieve aanvragen ontvangt
• Failover uitvoeren als uw primaire regio mislukt
• Primaire en secundaire databases instellen met private link-verbindingen met hun respectieve regio's via peering van virtuele netwerken tussen de twee regio's.

Een andere benadering is het gebruik van Azure Cosmos DB. Deze service kan gegevens wereldwijd distribueren door de gegevens transparant te repliceren naar alle regio's in uw Azure Cosmos DB-account. U kunt Azure Cosmos DB ook configureren met meerdere schrijfregio's. Zie Geode-patroon voor meer informatie.

Geautomatiseerde implementatie

Automatiseer uw infrastructuurimplementatie en toepassingscode-implementaties zoveel mogelijk.

Het automatiseren van infrastructuurimplementaties garandeert dat de infrastructuur identiek is geconfigureerd, wat helpt bij het voorkomen van configuratiedrift, zoals tussen regio's. Automatisering van infrastructuur kan ook failover-overschakelingsbewerkingen testen.

Zorg ervoor dat uw implementatiesystemen zich richten op de meerdere regio's waarnaar ze moeten implementeren voor toepassingsimplementatie. U kunt ook meerdere regio's gebruiken in een blauwgroene of kanarie-implementatiestrategie. Met deze implementatiestrategieën kunt u nieuwe versies van toepassingen implementeren in één regio voor testen en naar andere regio's nadat het testen is geslaagd.

Prestaties en schaalbaarheid

Deze architectuur is beter geschikt dan de basislijnarchitectuur om te voldoen aan de toepassingsvereisten, omdat deze de belasting over regio's verspreidt. Als u Azure Front Door configureert om aanvragen te routeren op basis van latentie, krijgen gebruikers betere reactietijden omdat aanvragen worden doorgestuurd naar de regio's die het dichtst bij hen liggen.

Afhankelijk van uw database-instelling kan er extra latentie optreden wanneer gegevens tussen regio's moeten worden gesynchroniseerd. U kunt deze latentie oplossen met behulp van Azure Cosmos DB met een meer ontspannen consistentieniveau.

Deze referentiearchitectuur heeft verschillende onderdelen die automatisch kunnen worden geschaald op basis van metrische gegevens:

• Azure Front Door kan automatisch schalen op basis van aanvraag. U kunt andere Functies van Azure Front Door gebruiken, zoals verkeersversnelling en cachingmogelijkheden om assets dichter bij uw eindgebruikers te brengen.
• Application Gateway ondersteunt automatisch schalen. Zie Application Gateway v2 en Web Application Firewall v2 schalen voor meer informatie.
• Azure Spring Apps biedt ook ondersteuning voor automatisch schalen. Zie Automatische schaalaanpassing instellen voor toepassingen voor meer informatie.

Kostenoverwegingen

Deze oplossing verdubbelt effectief de kostenramingen van de basislijnarchitectuur.

De belangrijkste stuurprogramma's voor kosten die zijn gekoppeld aan de oplossing voor meerdere regio's zijn onder andere:

• De primaire en secundaire databases moeten dezelfde servicelaag gebruiken; anders kan de secundaire database mogelijk geen replicatiewijzigingen bijhouden.
• Aanzienlijk verkeer tussen regio's verhoogt de kosten. Netwerkverkeer tussen Azure-regio's brengt kosten in rekening.

Als u deze kosten wilt beheren, moet u rekening houden met deze aanbevelingen voor uw implementatie:

• Gebruik uitgeschaalde versies van resources zoals Azure Spring Apps en Application Gateway in de stand-byregio en schaal de resources alleen omhoog wanneer de stand-by actief wordt.
• Als uw bedrijfsscenario's zijn toegestaan, maakt u een actief-passieve installatie om kosten te besparen.
• Implementeer een installatie met meerdere zones in één regio om te voldoen aan de bedrijfsbehoeften voor beschikbaarheid en tolerantie. Deze optie kan rendabeler zijn omdat u slechts één keer betaalt voor de meeste resources.
• Kies de alternatieve installatie die slechts één omgekeerde proxy gebruikt om kosten te besparen. Houd er rekening mee dat u extra configuratie moet toepassen om de beveiliging van dit alternatief te behouden.

We hebben de kosten van services in deze architectuur geschat met de Azure-prijscalculator met behulp van redelijke standaardwaarden voor een kleinschalige toepassing. U kunt deze schatting bijwerken op basis van de verwachte doorvoerwaarden voor uw toepassing.

Andere overwegingen

De ontwerpoverwegingen voor de basislijnarchitectuur met meerdere zones zijn ook van toepassing op de oplossing voor meerdere regio's die in dit artikel worden beschreven. Bekijk de volgende punten in de context van de architectuur voor meerdere regio's:

• Netwerkbeveiliging. Het is belangrijk om de communicatie via het netwerk te beheren. Met deze oplossing kunnen alleen binnenkomende oproepen vanuit Azure Front Door worden gerouteerd naar Application Gateway in elke regio. Vanuit Application Gateway worden de aanroepen gerouteerd naar de back-endservice van Azure Spring Apps. Communicatie van Azure Spring Apps naar ondersteunende services zoals Key Vault wordt ook beheerd met behulp van privé-eindpunten. Zie Basislijnarchitectuur: Netwerkbeveiliging voor meer informatie.

• Identiteits- en toegangsbeheer. Implementeer veiligere toegang door beheerde identiteiten te gebruiken om verbinding te maken tussen verschillende onderdelen. Een voorbeeld is hoe Azure Spring Apps een beheerde identiteit gebruikt om verbinding te maken met Key Vault. Zie Basislijnarchitectuur: Identiteits- en toegangsbeheer voor meer informatie.

• Bewaking. U kunt instrumentatie toevoegen en gedistribueerde tracering inschakelen om gegevens van de toepassing te verzamelen. Combineer deze gegevensbron met platformdiagnose om een end-to-end inzicht te krijgen in uw toepassing. Zie Basislijnarchitectuur: Bewaking voor meer informatie.

• Geheimbeheer. De oplossing voor meerdere regio's slaat de toepassingsgeheimen en -certificaten op in één sleutelkluis. Zie Basislijnarchitectuur: Geheimbeheer voor meer informatie.

Scenario-implementatie

Een implementatie voor deze referentiearchitectuur is beschikbaar in de referentiearchitectuur voor meerdere regio's in Azure Spring Apps op GitHub. De implementatie maakt gebruik van Terraform-sjablonen.

Volg de stapsgewijze instructies om de architectuur te implementeren.

Medewerkers

Microsoft onderhoudt deze inhoud. De volgende inzender heeft de oorspronkelijke inhoud ontwikkeld.

Hoofdauteur:

• Gitte Vermeiren | FastTrack voor Azure Engineer

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Als u deze workload wilt integreren met gedeelde services die worden beheerd door centrale teams in uw organisatie, implementeert u deze in een landingszone van een Azure-toepassing.

Verwante resources

Raadpleeg de volgende artikelen voor documentatie over de Azure-services en -functies die in deze architectuur worden gebruikt:

• Azure Spring Apps
• Azure Front Door
• Azure-toepassing Gateway v2
• Azure Database for MySQL
• Azure Key Vault
• Azure DNS
• Azure Web Application Firewall
• Azure Private Link
• Door Microsoft Entra beheerde identiteiten voor Azure-resources

U wordt aangeraden de volgende handleidingen te volgen voor een beter begrip van de configuratieopties die bij deze architectuur horen:

• Azure Spring Apps beschikbaar maken via een omgekeerde proxy
• Blauw/groen-implementatie met hoge beschikbaarheid voor toepassingen
• Behoud de oorspronkelijke HTTP-hostnaam tussen een omgekeerde proxy en de bijbehorende back-endwebtoepassing

Deze architectuur is ontworpen in overeenstemming met de pijlers van het Microsoft Azure Well-Architected Framework. We raden u aan de ontwerpprincipes voor elke pijler te bekijken.