Distribuera Azure Spring Apps till flera regioner

Den här referensarkitekturen beskriver en metod för att köra flera Azure Spring Apps-instanser mellan regioner i en aktiv-aktiv konfiguration.

Den här designen bygger på Baslinjearkitekturen för Azure Spring Apps. Baslinjen distribuerar ett Java Spring Boot-program till flera tillgänglighetszoner i en enda region. De flera zonerna sprider programarbetsbelastningen över separata platser så att arbetsbelastningen kan tolerera lokala fel i Azure-regionen.

Men om hela regionen upplever ett avbrott blir baslinjen otillgänglig för användaren. Avsikten med den här designen är att skapa hög tillgänglighet som klarar ett regionalt avbrott.

Den här arkitekturen är användbar för att uppfylla följande mål:

• Öka programmets övergripande motståndskraft och servicenivåmål (SLO).
• Aktivera global räckvidd för programmet.
• För arbetsbelastningen närmare slutanvändaren och gör svarstiden så låg som möjligt.
• Använd en sekundär region som en redundansplats för den primära regionen och välj en aktiv-passiv design.

Om du vill öka programmets motståndskraft och tillförlitlighet kan du distribuera programmet till flera regioner. För den här designen behöver du en global router för att belastningsutjämningsbegäranden till dina program mellan regioner. Den globala routern i den här arkitekturen tar även upp andra mål.

Den största utmaningen med en installation i flera regioner är att replikera data för ditt program mellan flera regioner. Det här problemet är inte ett problem med konfigurationen av flera zoner. Azure-tillgänglighetszoner är anslutna via ett högpresterande nätverk med en svarstid på mindre än 2 ms. Den här svarstiden räcker för de flesta program.

Arkitektur

Följande diagram visar arkitekturen för den här metoden:

Komponenter

Komponenterna i den här arkitekturen är samma som baslinjearkitekturen. I följande lista markeras endast ändringarna i baslinjearkitekturen. Produktdokumentation om Azure-tjänster finns i avsnittet Relaterade resurser .

• Azure Front Door fungerar som global lastbalanserare. Den här tjänsten används på grund av dess förmåga att leverera högre tillgänglighet med lägre svarstid, större skala och cachelagring vid gränsen.

Arbetsflöde

Referensarkitekturen implementerar följande arbetsflöde:

1. Användaren skickar en begäran till HTTP-värdnamnet för programmet, till exempel www.contoso.com. Azure DNS löser begäran om det här värdnamnet till Azure Front Door.

2. Azure Front Door använder olika belastningsutjämningskonfigurationer för att vidarebefordra inkommande begäranden till den offentliga slutpunkten för Azure Application Gateway i varje region. Application Gateway-instanserna konfigureras med samma anpassade domännamn och TLS-certifikatnamn som Azure Front Door.

3. Application Gateway med integrerad Azure Web Application Firewall inspekterar begäran. Brandväggen för webbaserade program tillåter endast inkommande begäranden från den angivna Azure Front Door-profilen.

4. Application Gateway vidarebefordrar den tillåtna trafiken till IP-adressen för lastbalanseraren i den etablerade Spring Apps-instansen.

5. Den interna lastbalanseraren dirigerar endast trafiken från Application Gateway till serverdelstjänsterna. Dessa tjänster finns i Spring Apps-instansen i ett virtuellt nätverk i varje region.

6. Som en del av bearbetningen av begäran kommunicerar programmet med andra Azure-tjänster i det virtuella nätverket. Exempel är programmet som kommunicerar med Azure Key Vault för hemligheter och databasen för lagring av tillstånd.

Global distribution

Om du utformar för hög tillgänglighet kan du konfigurera den här arkitekturen i en aktiv-aktiv, aktiv-passiv med frekvent vänteläge eller aktiv-passiv med kallt vänteläge.

Ditt val beror på tillgänglighetskraven för ditt program. Den här arkitekturen använder aktiv-aktiv distribution i två regioner eftersom exempelorganisationen vill ha en global närvaro med SLA med hög drifttid (serviceavtal). Om du kör verksamhetskritiska program och vill ha högre tillgänglighet måste du använda fler än två regioner.

Aktiv-aktiv

I aktivt-aktivt läge bearbetar alla regioner begäranden samtidigt. Den största utmaningen med aktivt-aktivt läge är att behålla datasynkroniseringen mellan regionerna. Det här läget är en kostsam metod eftersom du betalar två gånger för nästan alla komponenter.

Aktiv-passiv med frekvent vänteläge

I aktivt-passivt läge med frekvent vänteläge tar den sekundära regionen inte emot några begäranden från Azure Front Door så länge den primära regionen är aktiv. Kontrollera att du replikerar programdata från din primära till din sekundära region. Om ett fel inträffar i din primära region måste du ändra rollerna för dina serverdelsdatabaser och redundansväxla all trafik via Azure Front Door till din sekundära region.

I aktivt-passivt läge förväntas redundansen ta lite tid, vilket gör det enklare att se till att alla data förblir synkroniserade. Aktiv-passivt läge med frekvent vänteläge är dock lika kostsamt som att arbeta med aktivt-aktivt läge.

Aktiv-passiv med kallt vänteläge

I aktivt-passivt läge med kallt vänteläge har den primära regionen alla resurser och hanterar trafik. Den sekundära regionen kan ha färre komponenter eller komponenter med lägre beräkningsresurser. Teknikvalen beror på hur mycket stilleståndstid som är acceptabel enligt affärskraven. Omfattningen av konfigurationen av den sekundära regionen påverkar också kostnaderna. Kontrollera att det finns minst programdata i den sekundära regionen.

Som nämnts inkluderar aktivt-passivt läge redundans som tar lite tid, så det är lättare att hålla alla data synkroniserade. Aktiv-passivt läge med kallt vänteläge är den mest kostnadseffektiva metoden eftersom du inte distribuerar alla resurser till båda regionerna.

Om hela lösningskonfigurationen använder mallar kan du enkelt distribuera en sekundär region med kallt vänteläge genom att skapa dess resurser efter behov. Du kan använda Terraform-, Bicep- eller Azure Resource Manager-mallar och automatisera infrastrukturkonfigurationen i en CI/CD-pipeline (kontinuerlig integrering/kontinuerlig distribution). Du bör regelbundet testa konfigurationen genom att återskapa den sekundära regionen för att säkerställa att mallarna kan distribueras i en nödsituation.

Mönstret för distributionsstämplar rekommenderas eftersom flera oberoende kopior av ett program eller en komponent kan distribueras från en enda mall till flera regioner.

Jämförelse av läge

I följande tabell sammanfattas det arbete som krävs för att synkronisera data för varje läge och jämför kostnaden.

Routning mellan regioner

Den här referensarkitekturen använder geografiska noder (Geodes) där alla regioner kan hantera alla begäranden.

Azure Front Door har konfigurerats med samma routning mellan de två distributionsregionerna. Azure Front Door tillhandahåller även andra trafikroutningsmetoder till ursprunget. Om du vill dirigera klienter till deras närmaste ursprung är svarstidsbaserad routning mest meningsfull. Om du utformar för en aktiv-passiv lösning är prioritetsbaserad routning lämpligare.

Referensarkitekturexemplet använder en belastningsutjämningsregel med samma vikt mellan de två regionerna. Azure Front Door har konfigurerats med:

• En anpassad domän och ett TLS-certifikat (Transport Layer Security) med samma namn som programmets värdnamn, www.contoso.comtill exempel .

• Ett ursprung per region där programmet distribueras, där varje ursprung är en Azure Application Gateway-instans .

Layout för resursgrupp

Använd Azure-resursgrupper för att hantera resurser som distribueras till varje region som en enda samling. Överväg att placera den primära regionen, den sekundära regionen och Azure Front Door i separata resursgrupper, enligt följande diagram:

Diagrammet visar följande konfiguration av resursgrupper:

• Azure Front Door distribueras i Application-shared resursgruppen.
• Alla resurser som finns i regionen Europa, västra (weu) distribueras i Application-weu resursgruppen.
• Resurser som finns i regionen USA, östra (eus) finns i Application-eus resursgruppen.
• Resurser som finns i regionen Japan, östra (jae) finns i Application-jae resursgruppen.

Resurser i samma resursgrupp delar samma livscykel och kan enkelt skapas och tas bort tillsammans. Varje region har en egen uppsättning resurser i en dedikerad resursgrupp som följer en namngivningskonvention baserat på regionnamnet. Azure Front Door finns i en egen resursgrupp eftersom den måste finnas även om andra regioner läggs till eller tas bort.

Konfiguration av omvänd proxy

Azure Front Door utför global belastningsutjämning mellan regioner. Den här omvända proxyn hjälper till att distribuera trafiken om du distribuerar en arbetsbelastning till flera regioner. Som ett alternativ kan du använda Azure Traffic Manager. Traffic Manager är en DNS-baserad trafiklastbalanserare som endast lastbalanseras på domännivå.

Azure Front Door har integrerade nätverk för innehållsleverans (CDN) som levererar innehåll från Microsofts globala gränsnätverk med närvaropunkter (PoPs) distribuerade runt om i världen.

Den aktuella lösningen använder två omvända proxyservrar för att upprätthålla konsekvens med baslinjearkitekturen. Azure Front Door är den globala routern. Application Gateway fungerar som en lastbalanserare per region. I de flesta fall krävs inte den här konfigurationen. Du kan ta bort Application Gateway om du uppfyller följande krav:

• Eftersom Azure Web Application Firewall är kopplat till Application Gateway måste du koppla brandväggen för webbprogram till Azure Front Door-tjänsten i stället.
• Du behöver ett sätt att se till att inkommande anrop endast kommer från din Azure Front Door-instans. Du kan lägga till X-Azure-FDID header kontrollen och ip-intervallkontrollen för Azure Front Door i Spring Cloud Gateway-programmet. Mer information finns i Använda Azure Front Door som omvänd proxy med Spring Cloud Gateway.

Information om olika scenarier med omvänd proxy, hur du konfigurerar dem och deras säkerhetsöverväganden finns i Exponera Azure Spring Apps via en omvänd proxy.

Serverdelsdatabas

För distribution i flera regioner måste du ha en strategi för datareplikering. När programmet är tillgängligt mellan regioner bör data synkroniseras så att användarna inte ser inaktuella data.

Den aktuella arkitekturen använder en MySQL-databas för serverdelsdatabasen, men den här konfigurationen hanterar inte datasynkronisering. När du väljer en databasteknik kontrollerar du hur du bäst replikerar och synkroniserar data mellan regioner. Ett alternativ är Azure SQL Database, som har en aktiv geo-replikeringsfunktion som ger en kontinuerligt synkroniserad, läsbar sekundär databas för en primär databas.

Du kan använda den här funktionen i följande scenarier:

• Om din sekundära region är ett kallt vänteläge som inte tar emot aktiva begäranden
• Så här redundansväxlar du om din primära region misslyckas
• Konfigurera primära och sekundära databaser med privata länkanslutningar till sina respektive regioner via peering för virtuella nätverk mellan de två regionerna.

En annan metod är att använda Azure Cosmos DB. Den här tjänsten kan distribuera data globalt genom att transparent replikera data till alla regioner i ditt Azure Cosmos DB-konto. Du kan också konfigurera Azure Cosmos DB med flera skrivregioner. Mer information finns i Geode-mönster.

Automatiserad distribution

Automatisera distributionen av infrastruktur och programkod så mycket som möjligt.

Automatisering av infrastrukturdistributioner garanterar att infrastrukturen konfigureras på samma sätt, vilket bidrar till att undvika konfigurationsavvikelser, till exempel mellan regioner. Infrastrukturautomatisering kan också testa redundansväxlingsåtgärder.

För programdistribution kontrollerar du att dina distributionssystem riktar in sig på de flera regioner som de behöver distribuera till. Du kan också använda flera regioner i en blågrön eller kanariebaserad distributionsstrategi. Med dessa distributionsstrategier distribuerar du nya versioner av program till en region för testning och till andra regioner efter att testningen har lyckats.

Prestanda och skalbarhet   

Den här arkitekturen passar bättre än baslinjearkitekturen för att uppfylla programkraven eftersom den sprider belastningen över regioner. Om du konfigurerar Azure Front Door för att dirigera begäranden baserat på svarstid får användarna bättre svarstider eftersom begäranden dirigeras till de regioner som är närmast dem.

Beroende på databaskonfigurationen kan du få extra svarstid när data behöver synkroniseras mellan regioner. Du kan övervinna den här svarstiden med hjälp av Azure Cosmos DB med en mer avslappnad konsekvensnivå.

Den här referensarkitekturen har flera komponenter som kan skalas automatiskt baserat på mått:

• Azure Front Door kan autoskalning baserat på efterfrågan. Du kan använda andra Azure Front Door-funktioner som trafikacceleration och cachelagringsfunktioner för att föra tillgångar närmare dina slutanvändare.
• Application Gateway stöder automatisk skalning. Mer information finns i Skala Application Gateway v2 och Brandvägg för webbprogram v2.
• Azure Spring Apps stöder även autoskalning. Mer information finns i Konfigurera autoskalning för program.

Kostnadsöverväganden

Den här lösningen fördubblar effektivt kostnadsuppskattningarna för baslinjearkitekturen.

De viktigaste faktorerna för kostnader som är associerade med lösningen för flera regioner är:

• De primära och sekundära databaserna måste använda samma tjänstnivå. Annars kanske den sekundära databasen inte hänger med i replikeringsändringarna.
• Betydande trafik mellan regioner ökar kostnaderna. Nätverkstrafik mellan Azure-regioner medför avgifter.

Om du vill hantera dessa kostnader bör du överväga följande rekommendationer för implementeringen:

• Använd nedskalade versioner av resurser som Azure Spring Apps och Application Gateway i väntelägesregionen och skala bara upp resurserna när vänteläget blir aktivt.
• Om dina affärsscenarier tillåter kan du skapa en aktiv-passiv konfiguration för att spara på kostnaderna.
• Implementera en konfiguration med flera zoner i en enda region för att uppfylla affärsbehoven för tillgänglighet och återhämtning. Det här alternativet kan vara mer kostnadseffektivt eftersom du bara betalar för de flesta resurser en gång.
• Välj den alternativa konfiguration som endast använder en omvänd proxy för att spara på kostnaderna. Tänk på att du måste använda extra konfiguration för att upprätthålla säkerheten för det här alternativet.

Vi uppskattade kostnaden för tjänster i den här arkitekturen med Priskalkylatorn för Azure med hjälp av rimliga standardvärden för ett småskaligt program. Du kan uppdatera den här uppskattningen baserat på de förväntade dataflödesvärdena för ditt program.

Övriga beaktanden

Designövervägandena för arkitekturen för flera zoner gäller även för lösningen för flera regioner som beskrivs i den här artikeln. Granska följande punkter i kontexten för arkitekturen för flera regioner:

• Nätverkssäkerhet. Det är viktigt att styra kommunikationen via nätverket. Den här lösningen tillåter endast inkommande samtal från Azure Front Door, där anropen dirigeras till Application Gateway i varje region. Från Application Gateway dirigerar anropen till serverdelens Azure Spring Apps-tjänst. Kommunikation från Azure Spring Apps till stödtjänster som Key Vault styrs också med hjälp av privata slutpunkter. Mer information finns i Baslinjearkitektur: Nätverkssäkerhet.

• Identitets- och åtkomsthantering. Implementera säkrare åtkomst med hjälp av hanterade identiteter för att ansluta mellan olika komponenter. Ett exempel är hur Azure Spring Apps använder en hanterad identitet för att ansluta till Key Vault. Mer information finns i Baslinjearkitektur: Identitets- och åtkomsthantering.

• Övervakning. Du kan lägga till instrumentation och aktivera distribuerad spårning för att samla in data från programmet. Kombinera datakällan med plattformsdiagnostik för att få en inblick i ditt program från slutpunkt till slutpunkt. Mer information finns i Baslinjearkitektur: Övervakning.

• Hemlig hantering. Lösningen för flera regioner lagrar programhemligheter och certifikat i ett enda nyckelvalv. Mer information finns i Baslinjearkitektur: Hemlig hantering.

Scenariodistribution

En distribution för den här referensarkitekturen finns i referensarkitekturen för flera regioner i Azure Spring Apps på GitHub. Distributionen använder Terraform-mallar.

Om du vill distribuera arkitekturen följer du de stegvisa anvisningarna.

Deltagare

Microsoft underhåller det här innehållet. Följande deltagare utvecklade det ursprungliga innehållet.

Huvudförfattare:

• Gitte Vermeiren | FastTrack för Azure Engineer

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg

Om du vill integrera den här arbetsbelastningen med delade tjänster som hanteras av centrala team i din organisation distribuerar du den i en Azure-programlandningszon.

Relaterade resurser

Dokumentation om De Azure-tjänster och funktioner som används i den här arkitekturen finns i följande artiklar:

• Azure Spring Apps
• Azure Front Door
• Azure Application Gateway v2
• Azure Database for MySQL
• Azure Key Vault
• Azure DNS
• Azure Web Application Firewall
• Azure Private Link
• Microsoft Entra-hanterade identiteter för Azure-resurser

Vi rekommenderar följande guider för en djupare förståelse av de konfigurationsalternativ som ingår i den här arkitekturen:

• Exponera Azure Spring Apps via en omvänd proxy
• Blå/grön distribution med hög tillgänglighet för program
• Bevara det ursprungliga HTTP-värdnamnet mellan en omvänd proxy och dess serverdelswebbprogram

Den här arkitekturen är utformad i linje med grundpelarna i Microsoft Azure Well-Architected Framework. Vi rekommenderar att du granskar designprinciperna för varje pelare.