Förbereda

Slutförd

Du kommer att lägga till dina egna förbättringar i en befintlig arkitektur som uppfyller organisationens krav på hög tillförlitlighet. Här diskuterar vi bakgrundskontexten som du behöver för att lyckas med övningarna.

Problemkontext

Contoso Shoes måste vara redo för nästa uppmärksammade produktlansering, vilket förväntas skapa en betydande ökning av trafiken. Under de senaste två åren har det förekommit flera incidenter som gör att webbplatsen är offline så länge som en halv dag. Systemet testades inte helt i utvecklings-/testmiljön och vissa buggar kröp in i produktion. Felsökning och reparation tog lång tid eftersom operatorerna inte kunde identifiera rotorsakerna snabbt.

Det har funnits vissa utmaningar när vissa komponenter inte är tillgängliga. Utskalningsåtgärderna för beräkning påverkades när Azure Key Vault var felkonfigurerat. Det finns heller inga strategier för regionala avbrott. I en incident nyligen störtade hela regionen Europa, västra. Eftersom arbetsbelastningen bara kördes i den regionen var företaget tvunget att bära ekonomisk förlust tills regionen säkerhetskopierades.

Nuvarande arkitektur

För att du ska kunna slutföra den här utmaningen måste du ha en god förståelse för Contoso Shoes nuvarande arkitektur. Nu ska vi fokusera på deras API-lager.

Komponenter

Alla komponenter i den här arkitekturen distribueras till en enda region.

• Azure App Service-planens Standard S2 SKU tillhandahåller den beräkningsplattform som är värd för appen. Autoskalning är aktiverat. Utvecklingsmiljön använder SKU:n Basic B1.

• Azure App Service tillhandahåller den programplattform som kör API-koden i en container. Funktionen App Service-autentisering är aktiverad för auktorisering.

• Med distributionsfack kan du mellanlagra en distribution och sedan växla den med produktionsdistributionen. De används endast i produktion.

• Azure Container Registry lagrar den containerbaserade API-koden och skickas via CI/CD-pipelines (Continuous Integration/Continuous Delivery) som arbetsbelastningsteamet skapar och hanterar. Både produktionsmiljön och utvecklings-/testmiljön använder containerregistret.

• Azure Cosmos DB med SQL API lagrar alla tillstånd relaterade till arbetsbelastningen. Cosmos DB-databaskontot har en enda databas som innehåller några containrar i modellen delat dataflöde. Azure Cosmos-kontot använder kapacitetsläget Serverlös. Det finns en instans för produktion och en för dev/test.

• Azure Key Vault lagrar hemligheter som krävs för att API:et ska kunna göra ett HTTP POST-anrop till ett externt API från tredje part som en del av ett begärandeflöde. Programmet kommer åt hemligheterna via en Key Vault-referens i Azure App Service-appkonfigurationen. Det finns ett Key Vault för produktion och ett för dev/test.

• Azure Log Analytics används som en enhetlig mottagare för att lagra loggar och mått för alla Azure Diagnostics-inställningar för alla komponenter som används i lösningen. Det finns en arbetsyta för produktion och en för dev/test.

• Azure Application Insights används för att samla in telemetri och loggar från API:et. Application Insights använder det fristående läget och skriver inte till en dedikerad log analytics-arbetsyta. Produktion och utveckling/test delar inte en vanlig instans.

• Azure Pipelines används för CI/CD som skapar, testar och distribuerar arbetsbelastningen i förproduktions- och produktionsmiljöer. Arbetsbelastningsteamet hanterar pipelines, som även hanterar all infrastruktur i lösningen. Bicep är valet av teknik för IaC (Infrastructure-as-Code).

Designalternativ

I listan över komponenter består distributionsstämpeln av tjänster som deltar i bearbetningen av en begäran. Dessa tjänster omfattar App Services och API-koden och Cosmos DB. Stämpeln innehåller även icke-funktionella komponenter: Key Vault och Container Registry. Programmet har ett tredjepartsberoende av ett ramverk för prestanda och motståndskraft. Systemhanterade identiteter används mellan komponenterna i stämpeln.

I stämpeln är App Services konfigurerat för automatisk skalning baserat på belastning.

Separata miljöer används för produktion och utveckling/testning. Produktionsmiljön använder Standard SKU för App Service-planen. Företaget gjorde det här valet för att kunna förvärma programmet till en plats innan det distribueras till produktion. Utvecklings-/testmiljön använder Basic SKU för kostnadsoptimering. Båda miljöerna har sina egna instanser av tjänster. Miljöerna delar endast containerregistret.

Den containerbaserade API-koden levereras i en enda containeravbildning som körs i App Service. API:et har flera HTTP-slutpunkter som de olika klientdelarna använder för både läsningar och skrivningar. Klientdelarna ligger utanför omfånget för den här modulen, men de är i stort för den här situationens verksamhetskritiska status. Koden instrumenterades med Application Insights för att samla in viss grundläggande telemetri. Teamet som utvecklade den här koden hanterar även CI/CD-pipelinen för API-containeravbildningen och CI/CD-pipelines.

Avvägningar

Men precis som med allt finns det kompromisser med den aktuella arkitekturen. Affärskrav prioriterade kostnadsoptimering framför tillförlitlighet och drift. Arkitekturen har inte utvecklats för att hålla sig inom kostnadsgränserna. Komponenterna misslyckas när de utnyttjar de tillförlitlighetsfunktioner som plattformen erbjuder. Valet av SKU för beräkning hindrar till exempel arbetsbelastningen från att använda Tillgänglighetszoner. För telemetri används en äldre version av Application Insights som inte är integrerad med Log Analytics.

Dessutom är åtkomsten till arbetsbelastningen alltför genomgripande. Utan integrering av virtuella nätverk kan till exempel alla Azure-tjänster nås direkt via det offentliga Internet.

När lösningen utvecklades använde apputvecklingsteamet en enda Azure-prenumeration och samlokaliserar utveckling/testning och produktion i samma prenumeration för att göra verktygen enkla för DevOps-teamen. Produktionsresurser och utvecklings-/testresurser är dock inte helt isolerade. Vissa resurser delas mellan de två miljöerna, även om de fick en isolerad prenumeration från resten av Contoso Shoes lösningar.

Utvecklings-/testmiljön är också en enda miljö som delas mellan alla medlemmar i utvecklings- och QA-teamet. Valet var motiverat med tanke på teamens storlek och samordningen mellan dem behövde inte en högre grad av isolering. I takt med att teamet och lösningen utvecklades orsakade den enskilda utvecklings-/testmiljön i allt högre grad integreringskomplexitet när arbetsströmslivscykler kolliderade. Omsättningen och dess inverkan på tillförlitligheten har varit dyr.

Projektspecifikation

Företaget vill lägga till funktioner i sin lösningsarkitektur så att det kan hantera den förväntade ökningen av belastningen. Här är affärskraven:

• Skapa funktionen för att klara regionala fel genom att utöka arkitekturen till flera regioner
• Förbättra kundupplevelsen genom att betjäna klienter snabbare i en region som är geografiskt närmare dem
• Anpassa dig till Azure-översikten och dra nytta av de senaste tillförlitlighetsfunktionerna som Azure-tjänster erbjuder
• Fånga problem tidigt och identifiera deras sammanhängande inverkan i systemet genom att skapa en övergripande hälsomodell

Dessa krav är bara den prioriterade listan över deras förbättringsplaner. Programteamet är medvetna om att alla designområden måste beaktas för att den här lösningens tillförlitlighet ska uppfylla verksamhetskritiska standarder. Du kan vara säker på att de inte slutar att förbättra sin lösning och sina åtgärder när du har hjälpt dem med de aspekter som beskrivs i de kommande övningarna.

Välkommen till teamet! Contoso Shoes ser fram emot att höra dina rekommendationer.

Ställ in

I det här utmaningsprojektet får du rollen som arkitekt som hjälper Contoso Shoes att uppnå sina tillförlitlighetsresultat, med början i de prioriterade objekten i föregående avsnitt.

• Vi rekommenderar att du använder verktyget för arkitekturdiagram för att visualisera arkitekturen.
• Du behöver ingen Azure-prenumeration för den här utmaningen om du är nöjd med tjänsterna och deras funktioner.