Gegevensplatform voor bedrijfskritieke workloads in Azure

In een bedrijfskritieke architectuur moet elke status zoveel mogelijk buiten de berekening worden opgeslagen. De keuze van technologie is gebaseerd op deze belangrijke architectuurkenmerken:

Kenmerken	Overwegingen
Prestaties	Hoeveel rekenkracht is vereist?
Latentie	Welke invloed heeft de afstand tussen de gebruiker en het gegevensarchief op latentie? Wat is het gewenste consistentieniveau met een afweging van latentie?
Responsiviteit	Is het gegevensarchief vereist om altijd beschikbaar te zijn?
Schaalbaarheid	Wat is het partitioneringsschema?
Duurzaamheid	Worden de gegevens naar verwachting langdurig? Wat is het bewaarbeleid?
Tolerantie	In het geval van een fout kan de gegevensopslag automatisch een failover uitvoeren? Welke maatregelen zijn er om de failovertijd te verminderen?
Beveiliging	Zijn de gegevens versleuteld? Kan het gegevensarchief worden bereikt via een openbaar netwerk?

In deze architectuur zijn er twee gegevensarchieven:

• Database

  Winkels met betrekking tot de workload. Het wordt aanbevolen dat alle statussen wereldwijd worden opgeslagen in een database, gescheiden van regionale stempels. Bouw redundantie door de database in verschillende regio's te implementeren. Voor bedrijfskritieke workloads moet het synchroniseren van gegevens tussen regio's het belangrijkste probleem zijn. In het geval van een fout moeten schrijfaanvragen naar de database nog steeds functioneel zijn.

  Gegevensreplicatie in een actief-actief-configuratie wordt ten zeerste aanbevolen. De toepassing moet direct verbinding kunnen maken met een andere regio. Alle exemplaren moeten lees- en schrijfaanvragen kunnen verwerken.

• Berichtbroker

  De enige stateful service in de regionale stempel is de berichtenbroker, waarin aanvragen voor een korte periode worden opgeslagen. De broker biedt de behoefte aan buffering en betrouwbare berichten. De verwerkte aanvragen worden bewaard in de globale database.

Zie Misson-kritieke richtlijnen in Well-architected Framework voor andere gegevensoverwegingen : overwegingen voor gegevensplatformen.

Database

Deze architectuur maakt gebruik van Azure Cosmos DB voor NoSQL. Deze optie wordt gekozen omdat deze de meeste functies biedt die nodig zijn in dit ontwerp:

• Schrijven in meerdere regio's

  Schrijven in meerdere regio's is ingeschakeld met replica's die zijn geïmplementeerd in elke regio waarin een stempel wordt geïmplementeerd. Elke stempel kan lokaal schrijven en Azure Cosmos DB verwerkt gegevensreplicatie en synchronisatie tussen de stempels. Deze mogelijkheid verlaagt de latentie voor geografisch gedistribueerde eindgebruikers van de toepassing aanzienlijk. De Azure Mission-Critical-referentie-implementatie maakt gebruik van technologie met meerdere masters om maximale tolerantie en beschikbaarheid te bieden.

  Zoneredundantie wordt ook ingeschakeld binnen elke gerepliceerde regio.

  Zie Schrijfbewerkingen voor meerdere regio's configureren in uw toepassingen die gebruikmaken van Azure Cosmos DB voor meer informatie over schrijfbewerkingen in meerdere regio's.

• Conflictbeheer

  De mogelijkheid om schrijfbewerkingen uit te voeren in meerdere regio's is de noodzaak om een conflictbeheermodel te gebruiken, omdat gelijktijdige schrijfbewerkingen recordconflicten kunnen veroorzaken. Last Writer Wins is het standaardmodel en wordt gebruikt voor het bedrijfskritieke ontwerp. De laatste schrijver, zoals gedefinieerd door de bijbehorende tijdstempels van de records, wint het conflict. Met Azure Cosmos DB voor NoSQL kan ook een aangepaste eigenschap worden gedefinieerd.

• Queryoptimalisatie

  Een algemene aanbeveling voor queryefficiëntie voor leesintensieve containers met een groot aantal partities is het toevoegen van een gelijkheidsfilter met de geïdentificeerde item-id. Een uitgebreide beoordeling van aanbevelingen voor queryoptimalisatie vindt u in Queryproblemen oplossen bij het gebruik van Azure Cosmos DB.

• Back-upfunctie

  Het is raadzaam om de systeemeigen back-upfunctie van Azure Cosmos DB te gebruiken voor gegevensbeveiliging. De back-upfunctie van Azure Cosmos DB biedt ondersteuning voor online back-ups en herstel van gegevens op aanvraag.

Notitie

De meeste workloads zijn niet puur OLTP. Er is een toenemende vraag naar realtime rapportage, zoals het uitvoeren van rapporten op het operationele systeem. Dit wordt ook wel HTAP (Hybrid Transactional and Analytical Processing) genoemd. Azure Cosmos DB ondersteunt deze mogelijkheid via Azure Synapse Link voor Azure Cosmos DB.

Gegevensmodel voor de workload

Gegevensmodel moet zodanig worden ontworpen dat functies die worden aangeboden door traditionele relationele databases niet vereist zijn. Bijvoorbeeld refererende sleutels, strikt rij-/kolomschema, weergaven en andere.

De workload heeft de volgende kenmerken voor gegevenstoegang:

• Leespatroon:
  • Puntleesbewerkingen: één record ophalen. Item-id en partitiesleutel worden rechtstreeks gebruikt voor maximale optimalisatie (1 RU per aanvraag).
  • Lijst leest - Catalogusitems ophalen die in een lijst moeten worden weergegeven. FeedIterator met limiet voor het aantal resultaten wordt gebruikt.
• Schrijfpatroon:
  • Kleine schrijfbewerkingen: aanvragen voegen meestal één of een klein aantal records in een transactie in.
• Ontworpen om veel verkeer van eindgebruikers te verwerken met de mogelijkheid om te schalen om de vraag naar verkeer in de volgorde van miljoenen gebruikers af te handelen.
• Kleine nettolading of gegevenssetgrootte, meestal in volgorde van KB.
• Lage reactietijd (in volgorde van milliseconden).
• Lage latentie (in volgorde van milliseconden).

Configuratie

Azure Cosmos DB is als volgt geconfigureerd:

• Het consistentieniveau is ingesteld op de standaardsessieconsistentie omdat dit het meest gebruikte niveau is voor één regio en wereldwijd gedistribueerde toepassingen. Zwakkere consistentie met een hogere doorvoer is niet nodig vanwege de asynchrone aard van schrijfverwerking en vereist geen lage latentie bij het schrijven van databases.

  Notitie

  Het consistentieniveau Sessie biedt een redelijk compromis voor latentie, beschikbaarheid en consistentiegaranties voor deze specifieke toepassing. Het is belangrijk om te begrijpen dat het consistentieniveau Sterk niet beschikbaar is voor databases met meerdere masters.

• Partitiesleutel is ingesteld /id op voor alle verzamelingen. Deze beslissing is gebaseerd op het gebruikspatroon, dat meestal 'nieuwe documenten schrijft met GUID als de id' en 'het lezen van een breed scala aan documenten op id's'. Als de toepassingscode de uniekheid van de id behoudt, worden nieuwe gegevens gelijkmatig verdeeld in partities door Azure Cosmos DB, waardoor oneindige schaal mogelijk is.

• Indexeringsbeleid wordt geconfigureerd voor verzamelingen om query's te optimaliseren. Voor het optimaliseren van de kosten en prestaties van RU's wordt een aangepast indexeringsbeleid gebruikt. Dit beleid indexeert alleen de eigenschappen die worden gebruikt in querypredicaten. De toepassing gebruikt bijvoorbeeld het tekstveld voor opmerkingen niet als filter in query's. Het is uitgesloten van het aangepaste indexeringsbeleid.

Hier volgt een voorbeeld van de implementatie met indexeringsbeleidsinstellingen met behulp van Terraform:

indexing_policy {

  excluded_path {
    path = "/description/?"
  }

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

  included_path {
    path = "/*"
  }

}

Zie Overwegingen voor toepassingsplatforms voor bedrijfskritieke workloads voor informatie over de verbinding van de toepassing met Azure Cosmos DB in deze architectuur

Berichtenservices

Bedrijfskritieke systemen maken vaak gebruik van berichtenservices voor bericht- of gebeurtenisverwerking. Deze services bevorderen losse koppeling en fungeren als een buffer waarmee het systeem wordt geïsoleerd tegen onverwachte pieken in de vraag.

• Azure Service Bus wordt aanbevolen voor werkbelastingen op basis van berichten bij het verwerken van berichten met een hoge waarde.
• Azure Event Hubs wordt aanbevolen voor op gebeurtenissen gebaseerde systemen die grote hoeveelheden gebeurtenissen of telemetrie verwerken.

Hieronder volgen ontwerpoverwegingen en aanbevelingen voor Azure Service Bus Premium en Azure Event Hubs in een essentiële architectuur.

Belasting verwerken

Het berichtensysteem moet de vereiste doorvoer (zoals in MB per seconde) kunnen verwerken. Overweeg de volgende:

• De niet-functionele vereisten (NFR's) van het systeem moeten de gemiddelde berichtgrootte opgeven en het piekaantal berichten/seconde dat elke stempel moet ondersteunen. Deze informatie kan worden gebruikt om de vereiste piek MB/seconde per stempel te berekenen.
• De impact van een failover moet worden overwogen bij het berekenen van de vereiste piek MB/seconde per stempel.
• Voor Azure Service Bus moeten de NFR's geavanceerde Service Bus-functies opgeven, zoals sessies en het ongedaan maken van berichten. Deze functies zijn van invloed op de doorvoer van Service Bus.
• De doorvoer van Service Bus met de vereiste functies moet worden berekend door middel van testen als MB/seconde per berichteneenheid (MU). Zie Service Bus Premium- en Standard Messaging-lagen voor meer informatie over dit onderwerp.
• De doorvoer van Azure Event Hubs moet worden berekend door te testen als MB/seconde per doorvoereenheid (TU) voor de standard-laag of verwerkingseenheid (PU) voor de Premium-laag. Zie Schalen met Event Hubs voor meer informatie over dit onderwerp.
• De bovenstaande berekeningen kunnen worden gebruikt om te valideren dat de berichtenservice de vereiste belasting per stempel kan verwerken en het vereiste aantal schaaleenheden dat nodig is om aan die belasting te voldoen.
• In de sectie Bewerkingen wordt automatisch schalen besproken.

Elk bericht moet worden verwerkt

De Premium-laag van Azure Service Bus is de aanbevolen oplossing voor hoogwaardige berichten waarvoor de verwerking moet worden gegarandeerd. Hieronder vindt u informatie over deze vereiste bij het gebruik van Azure Service Bus Premium:

• Om ervoor te zorgen dat berichten correct worden overgedragen naar en geaccepteerd door de broker, moeten berichtproducenten een van de ondersteunde Service Bus API-clients gebruiken. Ondersteunde API's worden alleen geretourneerd vanuit een verzendbewerking als het bericht is behouden in de wachtrij/het onderwerp.

• Als u ervoor wilt zorgen dat berichten in de bus worden verwerkt, moet u de ontvangstmodus PeekLock gebruiken. Met deze modus wordt ten minste eenmaal verwerking ingeschakeld. Hieronder ziet u een overzicht van het proces:

  • De gebruiker van het bericht ontvangt het bericht dat moet worden verwerkt.
  • De consument krijgt een exclusieve vergrendeling op het bericht voor een bepaalde tijdsduur.
  • Als de consument het bericht heeft verwerkt, wordt er een bevestiging teruggestuurd naar de broker en wordt het bericht uit de wachtrij verwijderd.
  • Als een bevestiging niet wordt ontvangen door de broker in de toegewezen periode of als de handler het bericht expliciet afgeeft, wordt de exclusieve vergrendeling vrijgegeven. Het bericht is vervolgens beschikbaar voor andere consumenten om het bericht te verwerken.
  • Als een bericht een configureerbaar aantal keren niet is verwerkt, of als de handler het bericht doorstuurt naar de wachtrij met dode letters.
    • Om ervoor te zorgen dat berichten die naar de wachtrij met dode brieven worden verzonden, worden uitgevoerd, moet de wachtrij met dode letters worden bewaakt en moeten waarschuwingen worden ingesteld.
    • Het systeem moet hulpprogramma's hebben voor operators om berichten te kunnen inspecteren, corrigeren en opnieuw verzenden.

• Omdat berichten mogelijk meer dan één keer kunnen worden verwerkt, moeten berichthandlers idempotent worden gemaakt.

Idempotent berichtverwerking

In RFC 7231 geeft het Hypertext Transfer Protocol aan: "A ... methode wordt beschouwd als idempotent als het beoogde effect op de server van meerdere identieke aanvragen met die methode hetzelfde is als het effect voor één dergelijke aanvraag."

Een veelvoorkomende techniek voor het afhandelen van berichten met idempotent is het controleren van een permanent archief, zoals een database, als het bericht al is verwerkt. Als deze is verwerkt, zou u de logica niet opnieuw uitvoeren om deze te verwerken.

• Er kunnen situaties zijn waarin de verwerking van het bericht databasebewerkingen omvat, met name het invoegen van nieuwe records met door de database gegenereerde id's. Nieuwe berichten kunnen worden verzonden naar de broker, die deze id's bevatten. Omdat er geen gedistribueerde transacties zijn die zowel de database als de berichtenbroker omvatten, kunnen er een aantal complicaties optreden als het proces dat de code uitvoert mislukt. Bekijk de volgende voorbeeldsituaties:
  • De code die de berichten verzendt, kan worden uitgevoerd voordat de databasetransactie wordt doorgevoerd. Dit is het aantal ontwikkelaars dat werkt met behulp van het patroon Werkeenheid. Deze berichten kunnen ontsnappen als de fout optreedt tussen het aanroepen van de broker en het vragen of de databasetransactie moet worden doorgevoerd. Wanneer de transactie wordt teruggedraaid, worden deze door de database gegenereerde id's ook ongedaan gemaakt, waardoor ze beschikbaar blijven voor andere code die mogelijk tegelijkertijd wordt uitgevoerd. Dit kan ertoe leiden dat geadresseerden van de ontsnapte berichten de verkeerde databasevermeldingen verwerken, wat de algehele consistentie en juistheid van uw systeem nadelig beïnvloedt.
  • Als ontwikkelaars de code plaatsen die het bericht verzendt nadat de databasetransactie is voltooid, kan het proces nog steeds mislukken tussen deze bewerkingen (transactie doorgevoerd - bericht verzonden). Als dat gebeurt, wordt het bericht opnieuw verwerkt, maar deze keer ziet de idempotence guard-component dat het al is verwerkt (op basis van de gegevens die zijn opgeslagen in de database). Met de component wordt het bericht overgeslagen dat code wordt verzonden, omdat wordt aangenomen dat alles de laatste keer is voltooid. Downstreamsystemen die verwachtten meldingen te ontvangen over het voltooide proces, ontvangen niets. Deze situatie leidt opnieuw tot een algehele inconsistentie.
• De oplossing voor de bovenstaande problemen omvat het gebruik van het patroon Transactioneel Postvak UIT, waarbij de uitgaande berichten worden opgeslagen aan de zijkant, in hetzelfde transactionele archief als de zakelijke gegevens. De berichten worden vervolgens verzonden naar de berichtenbroker, wanneer het eerste bericht is verwerkt.
• Omdat veel ontwikkelaars niet bekend zijn met deze problemen of hun oplossingen, om ervoor te zorgen dat deze technieken consistent worden toegepast in een bedrijfskritiek systeem, raden we u aan de functionaliteit van het postvak UIT en de interactie met de berichtenbroker in een bepaalde bibliotheek te hebben. Alle codeverwerking en het verzenden van transactioneel significante berichten moeten gebruikmaken van die bibliotheek, in plaats van rechtstreeks met de berichtenbroker te communiceren.
  • Bibliotheken die deze functionaliteit implementeren in .NET zijn NServiceBus en MassTransit.

Hoge beschikbaarheid en herstel na noodgevallen

De berichtenbroker moet beschikbaar zijn voor producenten om berichten en consumenten te verzenden om ze te ontvangen. Hieronder vindt u meer informatie over deze vereiste:

• Gebruik de Premium-laag, die ondersteuning biedt voor beschikbaarheidszones in ondersteunende regio's om de hoogste beschikbaarheid met Service Bus te garanderen. Met beschikbaarheidszones worden berichten en metagegevens gerepliceerd in drie verschillende datacenters in dezelfde regio.
• Gebruik ondersteunde Service Bus- of Event Hubs-SDK's om automatisch lees- of schrijffouten opnieuw uit te voeren.
• Overweeg actief-actieve replicatie- of actief-passieve replicatiepatronen om te isoleren tegen regionale rampen.

Notitie

Azure Service Bus Geo-disaster recovery repliceert alleen metagegevens tussen regio's. Met deze functie worden berichten niet gerepliceerd.

Controleren

Het berichtensysteem fungeert als buffer tussen berichtproducenten en consumenten. Er zijn belangrijke indicatortypen die u moet bewaken in een bedrijfskritiek systeem dat waardevolle inzichten biedt die hieronder worden beschreven:

• Beperking : beperking geeft aan dat het systeem niet over de vereiste resources beschikt om de aanvraag te verwerken. Zowel Service Bus als Event Hubs bieden ondersteuning voor het bewaken van beperkte aanvragen. U moet een waarschuwing geven voor deze indicator.
• Wachtrijdiepte : een wachtrijdiepte die groeit, kan erop wijzen dat berichtprocessors niet werken of dat er onvoldoende processors zijn om de huidige belasting te verwerken. De wachtrijdiepte kan worden gebruikt om de logica voor automatisch schalen van handlers te informeren.
  • Voor Service Bus wordt de wachtrijdiepte weergegeven als aantal berichten
  • Voor Event Hubs moeten de consumenten de wachtrijdiepte per partitie berekenen en de metrische gegevens naar uw bewakingssoftware pushen. Voor elke leesbewerking krijgt de consument het volgnummer van de huidige gebeurtenis en de gebeurteniseigenschappen van de laatste enqueuedgebeurtenis. De consument kan de offset berekenen.
• Wachtrij met onbestelbare berichten: berichten in de wachtrij met dode letters vertegenwoordigen berichten die niet kunnen worden verwerkt. Voor deze berichten is meestal handmatige tussenkomst vereist. Waarschuwingen moeten worden ingesteld in de wachtrij met dode letters.
  • Service Bus heeft een wachtrij met dead-letter en een metrische waarde DeadLetteredMessages.
  • Voor Event Hubs moet deze functionaliteit aangepaste logica zijn die is ingebouwd in de consument.
• CPU/geheugengebruik : CPU en geheugen moeten worden bewaakt om ervoor te zorgen dat het berichtensysteem voldoende resources heeft om de huidige belasting te verwerken. Zowel Service Bus Premium als Event Hubs Premium maken CPU- en geheugengebruik beschikbaar.
  • Berichteneenheden (MU's) worden gebruikt in Service Bus om resources zoals CPU en geheugen voor een naamruimte te isoleren. CPU en geheugen die boven een drempelwaarde stijgen, kunnen erop wijzen dat er onvoldoende MU's zijn geconfigureerd, terwijl onder andere drempelwaarden vallen, kan worden aangegeven dat er te veel MU's zijn geconfigureerd. Deze indicatoren kunnen worden gebruikt om MU's automatisch te schalen.
  • De Premium-laag van Event Hubs maakt gebruik van verwerkingseenheden (PU's) om resources te isoleren, terwijl de standard-laag doorvoereenheden (TU's) gebruikt. Voor deze lagen is geen interactie met CPU/geheugen vereist om PU's of RU's automatisch te vergroten.

Statuscontrole

De status van het berichtensysteem moet worden overwogen in de statuscontroles voor een bedrijfskritieke toepassing. Houd rekening met de volgende factoren:

• Het berichtensysteem fungeert als buffer tussen berichtproducenten en consumenten. De stempel kan als gezond worden beschouwd als producenten berichten kunnen verzenden naar de broker en als consumenten berichten van de broker kunnen verwerken.
• De statuscontrole moet ervoor zorgen dat berichten naar het berichtensysteem kunnen worden verzonden.

Volgende stappen

Implementeer de referentie-implementatie om volledig inzicht te krijgen in de resources en de configuratie die in deze architectuur wordt gebruikt.

Implementatie: Bedrijfskritiek online