Dela via

Dataplattform för verksamhetskritiska arbetsbelastningar i Azure

  • Artikel

I en verksamhetskritisk arkitektur måste alla tillstånd lagras utanför beräkningen så mycket som möjligt. Valet av teknik baseras på dessa viktiga arkitektoniska egenskaper:

Egenskaper Att tänka på
Prestanda Hur mycket beräkning krävs?
Svarstid Vilken inverkan kommer avståndet mellan användaren och datalagret att ha på svarstiden? Vilken är önskad konsekvensnivå med kompromissen om svarstid?
Responsivitet Måste datalagret alltid vara tillgängligt?
Skalbarhet Vad är partitioneringsschemat?
Varaktighet Förväntas data vara långvariga? Vad är kvarhållningsprincipen?
Motståndskraft Kan datalagret redundansväsnas automatiskt i händelse av ett fel? Vilka åtgärder har vidtagits för att minska redundanstiden?
Säkerhet Krypteras data? Kan datalagringen nås via det offentliga nätverket?

I den här arkitekturen finns det två datalager:

  • Databas

    Butiker som är relaterade till arbetsbelastningen. Vi rekommenderar att alla tillstånd lagras globalt i en databas som är skild från regionala stämplar. Skapa redundans genom att distribuera databasen mellan regioner. För verksamhetskritiska arbetsbelastningar bör synkronisering av data mellan regioner vara det främsta problemet. I händelse av ett fel bör även skrivbegäranden till databasen fortfarande fungera.

    Datareplikering i en aktiv-aktiv konfiguration rekommenderas starkt. Programmet bör kunna ansluta direkt till en annan region. Alla instanser ska kunna hantera läs- och skrivbegäranden.

  • Meddelandekö

    Den enda tillståndskänsliga tjänsten i den regionala stämpeln är meddelandekoordinatorn, som lagrar begäranden under en kort period. Mäklaren tjänar behovet av buffring och tillförlitliga meddelanden. Bearbetade begäranden sparas i den globala databasen.

Andra dataöverväganden finns i Misson-critical guidance in Well-architected Framework: Data platform considerations (Misson-critical guidance in Well-architected Framework: Data platform considerations).

Databas

Den här arkitekturen använder Azure Cosmos DB för NoSQL. Det här alternativet väljs eftersom det innehåller de flesta funktioner som behövs i den här designen:

  • Skrivning i flera regioner

    Skrivning i flera regioner aktiveras med repliker som distribueras till varje region där en stämpel distribueras. Varje stämpel kan skriva lokalt och Azure Cosmos DB hanterar datareplikering och synkronisering mellan stämplarna. Den här funktionen minskar svarstiden avsevärt för geografiskt distribuerade slutanvändare av programmet. Referensimplementeringen för Azure Mission-Critical använder teknik med flera original för att ge maximal återhämtning och tillgänglighet.

    Zonredundans aktiveras också inom varje replikerad region.

    Mer information om skrivningar i flera regioner finns i Konfigurera skrivningar i flera regioner i dina program som använder Azure Cosmos DB.

  • Konflikthantering

    Med möjligheten att utföra skrivningar i flera regioner är det nödvändigt att införa en konflikthanteringsmodell eftersom samtidiga skrivningar kan medföra postkonflikter. Last Writer Wins är standardmodellen och används för designen Verksamhetskritisk. Den sista skrivaren, som definieras av de associerade tidsstämplarna för posterna, vinner konflikten. Azure Cosmos DB för NoSQL gör det också möjligt att definiera en anpassad egenskap.

  • Frågeoptimering

    En allmän rekommendation för frågeeffektivitet för läsintensiva containrar med ett stort antal partitioner är att lägga till ett likhetsfilter med itemID identifierat. En djupgående genomgång av rekommendationer för frågeoptimering finns i Felsöka frågeproblem när du använder Azure Cosmos DB.

  • Säkerhetskopieringsfunktion

    Vi rekommenderar att du använder den inbyggda säkerhetskopieringsfunktionen i Azure Cosmos DB för dataskydd. Säkerhetskopieringsfunktionen i Azure Cosmos DB stöder onlinesäkerhetskopior och dataåterställning på begäran.

Kommentar

De flesta arbetsbelastningar är inte enbart OLTP. Det finns en ökande efterfrågan på realtidsrapportering, till exempel att köra rapporter mot driftsystemet. Detta kallas även HTAP (hybridtransaktions- och analysbearbetning). Azure Cosmos DB stöder den här funktionen via Azure Synapse Link för Azure Cosmos DB.

Datamodell för arbetsbelastningen

Datamodellen bör utformas så att funktioner som erbjuds av traditionella relationsdatabaser inte krävs. Till exempel sekundärnycklar, strikt rad-/kolumnschema, vyer och andra.

Arbetsbelastningen har följande egenskaper för dataåtkomst:

  • Läsmönster:
    • Punktläsningar – Hämtar en enskild post. Objekt-ID och partitionsnyckel används direkt för maximal optimering (1 RU per begäran).
    • Listläsningar – Hämta katalogobjekt som ska visas i en lista. FeedIterator med gräns för antalet resultat används.
  • Skrivmönster:
    • Små skrivningar – Begäranden infogar vanligtvis ett enskilt eller ett litet antal poster i en transaktion.
  • Utformad för att hantera hög trafik från slutanvändare med möjlighet att skala för att hantera trafikefterfrågan i storleksordningen miljontals användare.
  • Liten nyttolast eller datamängdsstorlek – vanligtvis i ordning efter KB.
  • Låg svarstid (efter millisekunder).
  • Låg svarstid (i storleksordningen millisekunder).

Konfiguration

Azure Cosmos DB konfigureras på följande sätt:

  • Konsekvensnivån är inställd på standardkonsekvensen för sessioner eftersom den är den mest använda nivån för enskilda regioner och globalt distribuerade program. Svagare konsekvens med högre dataflöde behövs inte på grund av den asynkrona typen av skrivbearbetning och kräver inte låg svarstid vid databasskrivning.

    Kommentar

    Sessionskonsekvensnivån erbjuder en rimlig kompromiss för svarstider, tillgänglighet och konsekvensgarantier för det här specifika programmet. Det är viktigt att förstå att stark konsekvensnivå inte är tillgänglig för skrivdatabaser med flera original.

  • Partitionsnyckeln är inställd på /id för alla samlingar. Det här beslutet baseras på användningsmönstret, som främst "skriver nya dokument med GUID som ID" och "läser många olika dokument efter ID". Förutsatt att programkoden bibehåller sin ID-unikhet fördelas nya data jämnt i partitioner av Azure Cosmos DB, vilket möjliggör oändlig skala.

  • Indexeringsprincipen konfigureras för samlingar för att optimera frågor. För att optimera RU-kostnader och prestanda används en anpassad indexeringsprincip. Den här principen indexerar endast de egenskaper som används i frågepredikat. Programmet använder till exempel inte kommentarstextfältet som ett filter i frågor. Den exkluderades från den anpassade indexeringsprincipen.

Här är ett exempel från implementeringen som visar indexeringsprincipinställningar med Terraform:

indexing_policy {

  excluded_path {
    path = "/description/?"
  }

  excluded_path {
    path = "/comments/text/?"
  }

  included_path {
    path = "/*"
  }

}

Information om anslutning från programmet till Azure Cosmos DB i den här arkitekturen finns i Överväganden för programplattform för verksamhetskritiska arbetsbelastningar

Meddelandetjänster

Verksamhetskritiska system använder ofta meddelandetjänster för meddelande- eller händelsebearbetning. Dessa tjänster främjar lös koppling och fungerar som en buffert som isolerar systemet mot oväntade toppar i efterfrågan.

  • Azure Service Bus rekommenderas för meddelandebaserade arbetsbelastningar när du hanterar meddelanden med högt värde.
  • Azure Event Hubs rekommenderas för händelsebaserade system som bearbetar stora mängder händelser eller telemetri.

Följande är designöverväganden och rekommendationer för Azure Service Bus Premium och Azure Event Hubs i en verksamhetskritisk arkitektur.

Hantera belastning

Meddelandesystemet måste kunna hantera det dataflöde som krävs (som i MB per sekund). Tänk också på följande:

  • Systemets icke-funktionella krav (NFR) bör ange den genomsnittliga meddelandestorleken och det högsta antalet meddelanden/sekund som varje stämpel måste stödja. Den här informationen kan användas för att beräkna den nödvändiga högsta MB/sekunden per stämpel.
  • Effekten av en redundansväxling måste beaktas vid beräkning av den nödvändiga högsta MB/sekunden per stämpel.
  • För Azure Service Bus bör NFR ange alla avancerade Service Bus-funktioner, till exempel sessioner och de-duping-meddelanden. Dessa funktioner påverkar dataflödet för Service Bus.
  • Dataflödet för Service Bus med de nödvändiga funktionerna ska beräknas genom testning som MB/sekund per meddelandeenhet (MU). Mer information om det här avsnittet finns i Service Bus Premium- och Standard-meddelandenivåer.
  • Dataflödet för Azure Event Hubs bör beräknas genom testning som MB/sekund per dataflödesenhet (TU) för standardnivån eller bearbetningsenheten (PU) för premiumnivån. Mer information om det här avsnittet finns i Skala med Event Hubs.
  • Ovanstående beräkningar kan användas för att verifiera att meddelandetjänsten kan hantera den nödvändiga belastningen per stämpel och det antal skalningsenheter som krävs för att uppfylla belastningen.
  • I avsnittet åtgärder beskrivs automatisk skalning.

Varje meddelande måste bearbetas

Azure Service Bus Premium-nivån är den rekommenderade lösningen för värdefulla meddelanden som bearbetningen måste garanteras för. Följande är information om det här kravet när du använder Azure Service Bus Premium:

  • För att säkerställa att meddelanden överförs korrekt till och godkänns av asynkron meddelandekö bör meddelandeproducenterna använda en av de Service Bus API-klienter som stöds. API:er som stöds returneras endast från en sändningsåtgärd om meddelandet har sparats i kön/ämnet.

  • För att säkerställa att meddelanden på bussen bearbetas bör du använda PeekLock-mottagningsläget. Det här läget aktiverar bearbetning minst en gång. Följande beskriver processen:

    • Meddelandet som konsumenten tar emot meddelandet som ska bearbetas.
    • Konsumenten får ett exklusivt lås på meddelandet under en viss tidsperiod.
    • Om konsumenten bearbetar meddelandet skickar det en bekräftelse tillbaka till asynkron meddelandekö och meddelandet tas bort från kön.
    • Om en bekräftelse inte tas emot av koordinatorn under den tilldelade tidsperioden, eller om hanteraren uttryckligen avger meddelandet, släpps det exklusiva låset. Meddelandet är sedan tillgängligt för andra konsumenter att bearbeta meddelandet.
    • Om ett meddelande inte har bearbetats ett konfigurerbart antal gånger, eller om hanteraren vidarebefordrar meddelandet till kön med obeställbara meddelanden.
      • För att säkerställa att meddelanden som skickas till kön med obeställbara meddelanden hanteras bör kön med obeställbara meddelanden övervakas och aviseringar anges.
      • Systemet bör ha verktyg för att operatörer ska kunna inspektera, korrigera och skicka meddelanden igen.

  • Eftersom meddelanden kan bearbetas mer än en gång bör meddelandehanterare göras idempotent.

Idempotent meddelandebearbetning

I RFC 7231 står det i Hypertext Transfer Protocol: "A ... metoden anses vara idempotent om den avsedda effekten på servern för flera identiska begäranden med den metoden är samma som effekten för en enda sådan begäran."

En vanlig metod för att göra meddelandehantering idempotent är att kontrollera ett beständigt arkiv, till exempel en databas, om meddelandet redan har bearbetats. Om den har bearbetats skulle du inte köra logiken för att bearbeta den igen.

  • Det kan finnas situationer där bearbetningen av meddelandet omfattar databasåtgärder, särskilt infogning av nya poster med databasgenererade identifierare. Nya meddelanden kan skickas till asynkron meddelandekö, som innehåller dessa identifierare. Eftersom det inte finns distribuerade transaktioner som omfattar både databasen och meddelandekoordinatorn kan det finnas ett antal komplikationer som kan uppstå om processen som kör koden misslyckas. Se följande exempelsituationer:
    • Koden som genererar meddelandena kan köras innan databastransaktionen checkas in, vilket är hur många utvecklare som arbetar med mönstret Arbetsenhet. Dessa meddelanden kan komma undan om felet uppstår mellan att anropa asynkron meddelandekö och be om att databastransaktionen ska checkas in. När transaktionen återställs ångras även dessa databasgenererade ID:n, vilket gör dem tillgängliga för annan kod som kan köras samtidigt. Detta kan göra att mottagare av de meddelanden som inte skickas bearbetar fel databasposter, vilket skadar systemets övergripande konsekvens och korrekthet.
    • Om utvecklare placerar koden som genererar meddelandet när databastransaktionen är klar kan processen fortfarande misslyckas mellan dessa åtgärder (transaktionen har checkats in – meddelandet skickas). När det händer går meddelandet igenom bearbetningen igen, men den här gången ser idempotence guard-satsen att den redan har bearbetats (baserat på de data som lagras i databasen). Satsen hoppar över meddelandet som genererar kod, i tron att allt gjordes senast. Underordnade system, som förväntade sig att ta emot meddelanden om den slutförda processen, tar inte emot något. Den här situationen resulterar återigen i ett övergripande tillstånd av inkonsekvens.
  • Lösningen på ovanstående problem omfattar användning av mönstret Transaktionell utkorg, där utgående meddelanden lagras åt sidan, i samma transaktionslager som affärsdata. Meddelandena skickas sedan till meddelandekoordinatorn när det första meddelandet har bearbetats.
  • Eftersom många utvecklare inte är bekanta med dessa problem eller deras lösningar, för att garantera att dessa tekniker tillämpas konsekvent i ett verksamhetskritiskt system, föreslår vi att du har funktionerna i utkorgen och interaktionen med meddelandeköer omslutna i någon form av bibliotek. All kodbearbetning och sändning av transaktionsmässigt viktiga meddelanden bör använda det biblioteket i stället för att interagera direkt med meddelandekoordinatorn.

Hög tillgänglighet och haveriberedskap

Meddelandekoordinatorn måste vara tillgänglig för producenter att skicka meddelanden och konsumenter för att ta emot dem. Följande är information om detta krav:

  • För att säkerställa högsta tillgänglighet med Service Bus använder du premiumnivån, som har stöd för tillgänglighetszoner i stödregioner. Med tillgänglighetszoner replikeras meddelanden och metadata mellan tre olika datacenter i samma region.
  • Använd Service Bus- eller Event Hubs-SDK:er som stöds för att automatiskt försöka läsa eller skriva fel igen.
  • Överväg aktiv-aktiv replikering eller aktiva-passiva replikeringsmönster för att isolera mot regionala katastrofer.

Kommentar

Geo-haveriberedskap i Azure Service Bus replikerar endast metadata mellan regioner. Den här funktionen replikerar inte meddelanden.

Övervakning

Meddelandesystemet fungerar som en buffert mellan meddelandeproducenter och konsumenter. Det finns viktiga indikatortyper som du bör övervaka i ett verksamhetskritiskt system som ger värdefulla insikter som beskrivs nedan:

  • Begränsning – Begränsning anger att systemet inte har de resurser som krävs för att bearbeta begäran. Både Service Bus och Event Hubs stöder övervakning av begränsade begäranden. Du bör avisera om den här indikatorn.
  • Ködjup – Ett ködjup som växer kan tyda på att meddelandeprocessorer inte fungerar eller att det inte finns tillräckligt med processorer för att hantera den aktuella belastningen. Ködjup kan användas för att informera om automatisk skalningslogik för hanterare.
    • För Service Bus exponeras ködjupet som antal meddelanden
    • För Event Hubs måste konsumenterna beräkna ködjup per partition och skicka måttet till din övervakningsprogramvara. För varje läsning hämtar konsumenten sekvensnumret för den aktuella händelsen och händelseegenskaperna för den senaste begärda händelsen. Konsumenten kan beräkna förskjutningen.
  • Kö med obeställbara meddelanden – Meddelanden i kön med obeställbara meddelanden representerar meddelanden som inte kunde bearbetas. Dessa meddelanden kräver vanligtvis manuella åtgärder. Aviseringar ska anges i kön med obeställbara meddelanden.
    • Service Bus har en kö med obeställbara bokstäver och ett DeadLetteredMessages-mått.
    • För Event Hubs måste den här funktionen vara anpassad logik inbyggd i konsumenten.
  • CPU-/minnesanvändning – CPU och minne bör övervakas för att säkerställa att meddelandesystemet har tillräckligt med resurser för att bearbeta den aktuella belastningen. Både Service Bus Premium och Event Hubs Premium exponerar CPU- och minnesanvändning.
    • Meddelandeenheter (MUs) används i Service Bus för att isolera resurser som PROCESSOR och minne för ett namnområde. Cpu och minne som överskrider ett tröskelvärde kan tyda på att det inte finns tillräckligt många MU:er konfigurerade, medan lägre än andra tröskelvärden kan tyda på att det finns för många MU:er konfigurerade. Dessa indikatorer kan användas för automatisk skalning av MUs.
    • Event Hubs Premium-nivån använder bearbetningsenheter (PUs) för att isolera resurser, medan standardnivån använder dataflödesenheter (TUs). Dessa nivåer kräver inte interaktion med CPU/minne för att automatiskt blåsa upp PUs eller TUs.

Hälsokontroll

Meddelandesystemets hälsotillstånd måste beaktas i hälsokontrollerna för ett verksamhetskritiskt program. Överväg följande faktorer:

  • Meddelandesystemet fungerar som en buffert mellan meddelandeproducenter och konsumenter. Stämpeln kan ses som felfri om producenterna kan skicka meddelanden till mäklaren och om konsumenterna kan bearbeta meddelanden från koordinatorn.
  • Hälsokontrollen bör se till att meddelanden kan skickas till meddelandesystemet.

Nästa steg

Distribuera referensimplementeringen för att få en fullständig förståelse för de resurser och deras konfiguration som används i den här arkitekturen.

Implementering: Verksamhetskritisk online