Overwegingen voor gegevensplatforms voor bedrijfskritieke workloads in Azure

De selectie van een effectief toepassingsgegevensplatform is een ander cruciaal beslissingsgebied, dat verregaande gevolgen heeft voor andere ontwerpgebieden. Azure biedt uiteindelijk een groot aantal relationele, niet-relationele en analytische gegevensplatforms, die sterk verschillen in capaciteit. Het is daarom essentieel dat belangrijke niet-functionele vereisten volledig worden overwogen naast andere beslissingsfactoren, zoals consistentie, operabiliteit, kosten en complexiteit. De mogelijkheid om te werken in een schrijfconfiguratie voor meerdere regio's heeft bijvoorbeeld een kritieke invloed op geschiktheid voor een wereldwijd beschikbaar platform.

Dit ontwerpgebied breidt zich uit over het toepassingsontwerp en biedt belangrijke overwegingen en aanbevelingen om de selectie van een optimaal gegevensplatform te informeren.

Belangrijk

Dit artikel maakt deel uit van de azure Well-Architected mission-critical workload series. Als u niet bekend bent met deze reeks, raden we u aan te beginnen met wat een bedrijfskritieke workload is?

De vier vs big data

De 'Four Vs of Big Data' biedt een framework om de vereiste kenmerken voor een maximaal beschikbaar gegevensplatform beter te begrijpen en hoe gegevens kunnen worden gebruikt om de bedrijfswaarde te maximaliseren. In deze sectie wordt daarom besproken hoe de kenmerken Volume, Velocity, Variety en Veracity op conceptueel niveau kunnen worden toegepast om een gegevensplatform te ontwerpen met behulp van de juiste gegevenstechnologieën.

• V-olume: hoeveel gegevens binnenkomen om de opslagcapaciteit en tieringvereisten te informeren. Dit is de grootte van de gegevensset.
• Velocity: de snelheid waarmee gegevens worden verwerkt, hetzij als batches of continue stromen- dat de snelheid van de stroom is.
• Vriety: de organisatie en indeling van gegevens, het vastleggen van gestructureerde, semi-gestructureerde en ongestructureerde indelingen: gegevens in meerdere winkels of typen.
• V-eracity: omvat de herkomst en curatie van overwogen gegevenssets voor governance en gegevenskwaliteitsgarantie - die nauwkeurigheid van de gegevens is.

Overwegingen bij het ontwerpen

Inhoud

• Bestaande (indien van toepassing) en verwachte toekomstige gegevensvolumes op basis van geraamde gegevensgroeipercentages die zijn afgestemd op bedrijfsdoelstellingen en -plannen.

  • Het gegevensvolume moet de gegevens zelf en indexen, logboeken, telemetrie en andere toepasselijke gegevenssets omvatten.
  • Grote bedrijfskritieke en bedrijfskritieke toepassingen genereren en opslaan doorgaans dagelijks grote volumes (GB en TB).
  • Er kunnen aanzienlijke kosteneffecten zijn met betrekking tot gegevensuitbreiding.

• Het gegevensvolume kan fluctueren vanwege veranderende bedrijfsomstandigheden of huishoudprocedures.

• Gegevensvolume kan een grote invloed hebben op de prestaties van gegevensplatformquery's.

• Er kan een grote impact zijn op het bereiken van volumelimieten voor het gegevensplatform.

  • Leidt dit tot downtime? en zo ja, voor hoe lang?
  • Wat zijn de beperkingsprocedures? en moeten toepassingswijzigingen worden gewijzigd?
  • Is er een risico op gegevensverlies?

• Functies zoals Time to Live (TTL) kunnen worden gebruikt om gegevensgroei te beheren door records automatisch te verwijderen na een verstreken tijd, met behulp van het maken of wijzigen van records.

  • Azure Cosmos DB biedt bijvoorbeeld een ingebouwde TTL-mogelijkheid .

Snelheid

• De snelheid waarmee gegevens worden verzonden uit verschillende toepassingsonderdelen en de doorvoervereisten voor hoe snel gegevens moeten worden doorgevoerd en opgehaald, zijn essentieel voor het bepalen van een optimale gegevenstechnologie voor belangrijke workloadscenario's.

  • De aard van de doorvoervereisten verschilt per workloadscenario, zoals de vereisten voor lezen of schrijven.
    • Analytische workloads moeten bijvoorbeeld doorgaans geschikt zijn voor een grote leesdoorvoer.
  • Wat is de vereiste doorvoer? En hoe wordt verwacht dat de doorvoer groeit?
  • Wat zijn de vereisten voor gegevenslatentie bij P50/P99 onder referentiebelastingsniveaus?

• Mogelijkheden zoals het ondersteunen van een vergrendelingsvrij ontwerp, indexafstemming en consistentiebeleid zijn essentieel voor het bereiken van hoge doorvoer.

  • Bij het optimaliseren van de configuratie voor hoge doorvoer worden afwegingen in rekening gebracht, wat volledig moet worden begrepen.
  • Persistentie- en berichtenpatronen, zoals CQRS en Gebeurtenisbronnen, kunnen worden gebruikt om de doorvoer verder te optimaliseren.

• Belastingniveaus fluctueren natuurlijk voor veel toepassingsscenario's, waarbij natuurlijke pieken een voldoende mate van elasticiteit vereisen om de variabele vraag af te handelen terwijl doorvoer en latentie behouden blijven.

  • Flexibele schaalbaarheid is essentieel om variabele doorvoer- en belastingniveaus effectief te ondersteunen zonder capaciteitsniveaus te overprovisioneren.
    • Zowel lees- als schrijfdoorvoer moet worden geschaald op basis van toepassingsvereisten en belasting.
    • Zowel verticale als horizontale schaalbewerkingen kunnen worden toegepast om te reageren op veranderende belastingniveaus.

• De impact van doorvoerd dips kan variëren op basis van het workloadscenario.

  • Is er sprake van onderbreking van de connectiviteit?
  • Retourneren afzonderlijke bewerkingen foutcodes terwijl het besturingsvlak blijft werken?
  • Activeert het gegevensplatform bandbreedtebeperking, en zo ja, voor hoe lang?

• De fundamentele aanbeveling voor het ontwerpen van toepassingen voor het gebruik van een actief-actieve geografische distributie introduceert uitdagingen met betrekking tot gegevensconsistentie.

  • Er is een afweging tussen consistentie en prestaties met betrekking tot volledige ACID transactionele semantiek en traditioneel vergrendelingsgedrag.
    • Het minimaliseren van de schrijflatentie komt ten koste van gegevensconsistentie.

• In een schrijfconfiguratie voor meerdere regio's moeten wijzigingen worden gesynchroniseerd en samengevoegd tussen alle replica's, met waar nodig conflictoplossing, en dit kan van invloed zijn op prestatieniveaus en schaalbaarheid.

• Alleen-lezen replica's (intraregio en tussen regio's) kunnen worden gebruikt om de latentie van roundtrips te minimaliseren en verkeer te distribueren om de prestaties, doorvoer, beschikbaarheid en schaalbaarheid te verbeteren.

• Een cachelaag kan worden gebruikt om de leesdoorvoer te verhogen om de gebruikerservaring en reactietijden van end-to-endclients te verbeteren.

  • Verlooptijden en beleidsregels van de cache moeten worden overwogen om de recentheid van gegevens te optimaliseren.

Variëteit

• Het gegevensmodel, gegevenstypen, gegevensrelaties en het beoogde querymodel zijn sterk van invloed op beslissingen van het gegevensplatform.

  • Vereist de toepassing een relationeel gegevensmodel of ondersteunt deze een variabele-schema of een niet-relationeel gegevensmodel?
  • Hoe worden de querygegevens van de toepassing uitgevoerd? En zijn query's afhankelijk van databaselaagconcepten zoals relationele joins? Of biedt de toepassing dergelijke semantiek?

• De aard van gegevenssets die door de toepassing worden beschouwd, kan variëren, van ongestructureerde inhoud, zoals afbeeldingen en video's, of meer gestructureerde bestanden zoals CSV en Parquet.

  • Workloads van samengestelde toepassingen hebben doorgaans verschillende gegevenssets en bijbehorende vereisten.

• Naast relationele of niet-relationele gegevensplatforms, kunnen grafiek- of sleutelwaardegegevensplatforms ook geschikt zijn voor bepaalde gegevensworkloads.

  • Sommige technologieën zijn geschikt voor gegevensmodellen met variabele schema's, waarbij gegevensitems semantisch vergelijkbaar zijn en/of samen worden opgeslagen en opgevraagd, maar structureel verschillen.

• In een microservicearchitectuur kunnen afzonderlijke toepassingsservices worden gebouwd met afzonderlijke scenario-geoptimaliseerde gegevensarchieven in plaats van afhankelijk van één monolithisch gegevensarchief.

  • Ontwerppatronen zoals SAGA kunnen worden toegepast om consistentie en afhankelijkheden tussen verschillende gegevensarchieven te beheren.
    • Directe query's tussen databases kunnen co-locatiebeperkingen opleggen.
  • Het gebruik van meerdere gegevenstechnologieën zorgt voor een zekere mate van beheeroverhead voor het onderhouden van omvattende technologieën.

• De functiesets voor elke Azure-service verschillen in talen, SDK's en API's, die van grote invloed kunnen zijn op het configuratieniveau dat kan worden toegepast.

• Mogelijkheden voor geoptimaliseerde afstemming met het gegevensmodel en omvattende gegevenstypen zijn sterk van invloed op beslissingen van het gegevensplatform.

  • Querylagen, zoals opgeslagen procedures en object-relationele mappers.
  • Taalneutrale querymogelijkheden, zoals een beveiligde REST API-laag.
  • Mogelijkheden voor bedrijfscontinuïteit, zoals back-up en herstel.

• Analytische gegevensarchieven ondersteunen doorgaans polyglotopslag voor verschillende typen gegevensstructuren.

  • Analytische runtime-omgevingen, zoals Apache Spark, kunnen integratiebeperkingen hebben voor het analyseren van polyglot-gegevensstructuren.

• In een bedrijfscontext kan het gebruik van bestaande processen en hulpprogramma's, en de continuïteit van vaardigheden, een aanzienlijke invloed hebben op het ontwerp en de selectie van gegevenstechnologieën op het gegevensplatform.

Waarheidsgetrouwheid

• Er moeten verschillende factoren worden overwogen om de nauwkeurigheid van gegevens in een toepassing te valideren en het beheer van deze factoren kan een aanzienlijke invloed hebben op het ontwerp van het gegevensplatform.

  • Gegevensconsistentie.
  • Platformbeveiligingsfuncties.
  • Gegevensbeheer.
  • Wijzigingsbeheer en schemaontwikkeling.
  • Afhankelijkheden tussen gegevenssets.

• In elke gedistribueerde toepassing met meerdere gegevensreplica's is er een afweging tussen consistentie en latentie, zoals uitgedrukt in de cap - en PACELC-theorems .

  • Wanneer lezers en schrijvers afzonderlijk worden gedistribueerd, moet een toepassing ervoor kiezen om ofwel de snelste beschikbare versie van een gegevensitem te retourneren, zelfs als het verouderd is in vergelijking met een just-completed schrijfbewerking (update) van dat gegevensitem in een andere replica, of de meest recente versie van het gegevensitem, wat extra latentie kan veroorzaken om de meest recente status te bepalen en te verkrijgen.
  • Consistentie en beschikbaarheid kunnen worden geconfigureerd op platformniveau of op het niveau van afzonderlijke gegevensaanvragen.
  • Wat is de gebruikerservaring als gegevens moeten worden geleverd vanuit een replica die het dichtst bij de gebruiker ligt, die niet de meest recente status van een andere replica weergeeft? Kan de toepassing ondersteuning bieden voor verouderde gegevens?

• Wanneer in een schrijfcontext met meerdere regio's hetzelfde gegevensitem wordt gewijzigd in twee afzonderlijke schrijfreplica's voordat een van beide wijzigingen kan worden gerepliceerd, wordt er een conflict gemaakt dat moet worden opgelost.

  • Gestandaardiseerde beleidsregels voor conflictoplossing, zoals 'Last Write Wins', of een aangepaste strategie met aangepaste logica kunnen worden toegepast.

• De implementatie van beveiligingsvereisten kan de doorvoer of prestaties nadelig beïnvloeden.

• Versleuteling at-rest kan in de toepassingslaag worden geïmplementeerd met behulp van versleuteling aan de clientzijde en/of de gegevenslaag met behulp van versleuteling aan de serverzijde, indien nodig.

• ondersteuning voor Azure verschillende versleutelingsmodellen, waaronder versleuteling aan de serverzijde die gebruikmaakt van door de service beheerde sleutels, door de klant beheerde sleutels in Key Vault of door de klant beheerde sleutels op door de klant beheerde hardware.

  • Met versleuteling aan de clientzijde kunnen sleutels worden beheerd in Key Vault of een andere veilige locatie.

• MACsec (IEEE 802.1AE MAC) gegevenskoppelingsversleuteling wordt gebruikt om al het verkeer tussen Azure-datacenters in het Microsoft backbone-netwerk te beveiligen.

  • Pakketten worden versleuteld en ontsleuteld op de apparaten voordat ze worden verzonden, waardoor fysieke 'man-in-the-middle' of snooping/wiretapping-aanvallen worden voorkomen.

• Verificatie en autorisatie voor het gegevensvlak en het besturingsvlak.

  • Hoe verifieert en autoriseert het gegevensplatform toegang tot toepassingen en operationele toegang?

• Waarneembaarheid door platformstatus en gegevenstoegang te bewaken.

  • Hoe wordt waarschuwingen toegepast op voorwaarden buiten acceptabele operationele grenzen?

Aanbevelingen voor ontwerpen

Inhoud

• Zorg ervoor dat toekomstige gegevensvolumes die zijn gekoppeld aan organische groei niet groter zijn dan de mogelijkheden van het gegevensplatform.

  • Voorspel de groeipercentages van gegevens die zijn afgestemd op bedrijfsplannen en gebruik vastgestelde tarieven om doorlopende capaciteitsvereisten te informeren.
  • Vergelijk aggregaties en gegevensrecordvolumes met gegevensplatformlimieten.
  • Als er een risico bestaat dat limieten in uitzonderlijke omstandigheden worden bereikt, moet u ervoor zorgen dat er operationele risico's zijn om downtime en gegevensverlies te voorkomen.

• Bewaak het gegevensvolume en valideer het op basis van een capaciteitsmodel, rekening houdend met schaallimieten en verwachte gegevensgroeipercentages.

  • Zorg ervoor dat schaalbewerkingen zijn afgestemd op de vereisten voor opslag, prestaties en consistentie.
  • Wanneer een nieuwe schaaleenheid wordt geïntroduceerd, moeten onderliggende gegevens mogelijk worden gerepliceerd. Dit kost tijd en brengt waarschijnlijk een prestatiestraf in terwijl de replicatie plaatsvindt. Zorg er dus voor dat deze bewerkingen buiten kritieke kantooruren worden uitgevoerd, indien mogelijk.

• Definieer toepassingsgegevenslagen om gegevenssets te classificeren op basis van gebruik en kritiek om het verwijderen of offloaden van oudere gegevens te vergemakkelijken.

  • Overweeg gegevenssets te classificeren in 'dynamische', 'warme' en 'koude' ('archief')-lagen.
    • De basisverwijzingsimplementaties maken bijvoorbeeld gebruik van Azure Cosmos DB om dynamische gegevens op te slaan die actief worden gebruikt door de toepassing, terwijl Azure Storage wordt gebruikt voor 'koude' bewerkingsgegevens voor analytische doeleinden.

• Configureer huishoudprocedures om de groei van gegevens te optimaliseren en gegevensefficiëntie te stimuleren, zoals queryprestaties en het beheren van gegevensuitbreiding.

  • Configureer de TTL-vervaldatum (Time-To-Live) voor gegevens die niet meer nodig zijn en die geen analytische waarde voor de lange termijn hebben.
    • Valideer of oude gegevens veilig kunnen worden gelaagd naar secundaire opslag of dat ze rechtop kunnen worden verwijderd, zonder nadelige gevolgen voor de toepassing.
  • Offload niet-kritieke gegevens naar secundaire koude opslag, maar onderhoud deze voor analytische waarde en om te voldoen aan de controlevereisten.
  • Verzamel telemetrie- en gebruiksstatistieken van het gegevensplatform om DevOps-teams in staat te stellen voortdurend huishoudvereisten en 'juiste grootte' gegevensarchieven te evalueren.

• Overweeg in overeenstemming met een microservicetoepassingsontwerp het gebruik van meerdere verschillende gegevenstechnologieën parallel, met geoptimaliseerde gegevensoplossingen voor specifieke workloadscenario's en volumevereisten.

  • Vermijd het maken van één monolithisch gegevensarchief waarbij gegevensvolume uit uitbreiding moeilijk te beheren kan zijn.

Snelheid

• Het gegevensplatform moet inherent worden ontworpen en geconfigureerd om hoge doorvoer te ondersteunen, waarbij workloads zijn gescheiden in verschillende contexten om de prestaties te maximaliseren met behulp van geoptimaliseerde scenariogegevensoplossingen.

  • Zorg ervoor dat lees- en schrijfdoorvoer voor elk gegevensscenario kan worden geschaald op basis van verwachte belastingspatronen, met voldoende tolerantie voor onverwachte afwijkingen.
  • Scheid verschillende gegevensworkloads, zoals transactionele en analytische bewerkingen, in afzonderlijke prestatiecontexten.

• Load level through the use of asynchronous non-blocking messaging, bijvoorbeeld using the CQRS or Event Sourcing patterns.

  • Er kan latentie zijn tussen schrijfaanvragen en wanneer er nieuwe gegevens beschikbaar zijn om te lezen, wat mogelijk invloed heeft op de gebruikerservaring.
    • Dit effect moet worden begrepen en aanvaardbaar in de context van belangrijke bedrijfsvereisten.

• Zorg voor flexibele schaalbaarheid ter ondersteuning van variabele doorvoer- en belastingniveaus.

  • Als de belastingniveaus zeer vluchtig zijn, kunt u overwegen om capaciteitsniveaus te overprovisioneren om ervoor te zorgen dat de doorvoer en prestaties behouden blijven.
  • Test en valideer de impact op workloads van samengestelde toepassingen wanneer de doorvoer niet kan worden onderhouden.

• Prioriteit geven aan systeemeigen Azure-gegevensservices met geautomatiseerde schaalbewerkingen om een snelle reactie op volatiliteit op belastingsniveau te vergemakkelijken.

  • Configureer automatisch schalen op basis van drempelwaarden voor de service en toepassingsset.
  • Schalen moet initiëren en voltooien in tijdsbestekken die consistent zijn met bedrijfsvereisten.
  • Voor scenario's waarbij handmatige interactie nodig is, stelt u geautomatiseerde operationele 'playbooks' in die kunnen worden geactiveerd in plaats van handmatige operationele acties uit te voeren.
    • Overweeg of geautomatiseerde triggers kunnen worden toegepast als onderdeel van volgende technische investeringen.

• Bewaak de lees- en schrijfdoorvoer van toepassingsgegevens op basis van P50/P99-latentievereisten en stem af op een toepassingscapaciteitsmodel.

• Overtollige doorvoer moet correct worden verwerkt door het gegevensplatform of de toepassingslaag en vastgelegd door het statusmodel voor operationele weergave.

• Implementeer caching voor 'hot'-gegevensscenario's om reactietijden te minimaliseren.

  • Pas het juiste beleid toe voor het verlopen van caches en huisbeheer om te voorkomen dat gegevens worden gegroeid.
    • Cache-items laten verlopen wanneer de back-upgegevens worden gewijzigd.
    • Als de verlooptijd van de cache strikt op TTL (Time-To-Live) is gebaseerd, moet de impact en klantervaring van het leveren van verouderde gegevens worden begrepen.

Variëteit

• In overeenstemming met het principe van een systeemeigen ontwerp in de cloud en Azure wordt het ten zeerste aanbevolen om prioriteit te geven aan beheerde Azure-services om de complexiteit van operationele en beheer te verminderen en te profiteren van toekomstige platforminvesteringen van Microsoft.

• In overeenstemming met het toepassingsontwerpprincipe van losjes gekoppelde microservicearchitecturen kunnen afzonderlijke services gebruikmaken van afzonderlijke gegevensarchieven en gegevenstechnologieën die zijn geoptimaliseerd voor scenario's.

  • Identificeer de typen gegevensstructuur die door de toepassing worden verwerkt voor specifieke workloadscenario's.
  • Vermijd het maken van een afhankelijkheid van één monolithisch gegevensarchief.
    • Bekijk het SAGA-ontwerppatroon waarin afhankelijkheden tussen gegevensarchieven bestaan.

• Controleer of de vereiste mogelijkheden beschikbaar zijn voor geselecteerde gegevenstechnologieën.

  • Zorg voor ondersteuning voor vereiste talen en SDK-mogelijkheden. Niet elke mogelijkheid is beschikbaar voor elke taal/SDK op dezelfde manier.

Waarheidsgetrouwheid

• Gebruik een gegevensplatform met meerdere regio's en distribueer replica's over regio's voor maximale betrouwbaarheid, beschikbaarheid en prestaties door gegevens dichter bij toepassingseindpunten te verplaatsen.

  • Distribueer gegevensreplica's over Beschikbaarheidszones (AZ's) binnen een regio (of gebruik zone-redundante servicelagen) om de beschikbaarheid binnen regio's te maximaliseren.

• Wanneer consistentievereisten dit mogelijk maken, gebruikt u een ontwerp voor gegevensplatforms voor meerdere regio's om de algehele wereldwijde beschikbaarheid en betrouwbaarheid te maximaliseren.

  • Houd rekening met zakelijke vereisten voor conflictoplossing wanneer hetzelfde gegevensitem wordt gewijzigd in twee afzonderlijke schrijfreplica's voordat een van beide wijzigingen kan worden gerepliceerd en er dus een conflict ontstaat.
    • Gebruik waar mogelijk gestandaardiseerde beleidsregels voor conflictoplossing, zoals 'Laatste wint'.
      • Als een aangepaste strategie met aangepaste logica vereist is, moet u ervoor zorgen dat CI/CD DevOps-procedures worden toegepast om aangepaste logica te beheren.

• Test en valideer back-up- en herstelmogelijkheden en failoverbewerkingen via chaostests binnen continue leveringsprocessen.

• Voer prestatiebenchmarks uit om ervoor te zorgen dat doorvoer- en prestatievereisten niet worden beïnvloed door het opnemen van vereiste beveiligingsmogelijkheden, zoals versleuteling.

  • Zorg ervoor dat continue leveringsprocessen belastingstests overwegen op basis van bekende prestatiebenchmarks.

• Wanneer u versleuteling toepast, wordt het sterk aanbevolen om door de service beheerde versleutelingssleutels te gebruiken om de beheercomplexiteit te verminderen.

  • Als er een specifieke beveiligingsvereiste is voor door de klant beheerde sleutels, moet u ervoor zorgen dat de juiste procedures voor sleutelbeheer worden toegepast om de beschikbaarheid, back-up en rotatie van alle overwogen sleutels te garanderen.

Notitie

Bij de integratie met een bredere organisatie-implementatie is het essentieel dat een toepassingsgerichte benadering wordt toegepast op het inrichten en gebruiken van gegevensplatformonderdelen in een toepassingsontwerp.

Om de betrouwbaarheid te maximaliseren is het essentieel dat afzonderlijke gegevensplatformonderdelen op de juiste wijze reageren op de toepassingsstatus via operationele acties die andere toepassingsonderdelen kunnen bevatten. In een scenario waarin extra gegevensplatformbronnen nodig zijn, is het schalen van het gegevensplatform samen met andere toepassingsonderdelen volgens een capaciteitsmodel waarschijnlijk vereist, mogelijk via het inrichten van extra schaaleenheden. Deze aanpak wordt uiteindelijk beperkt als er een harde afhankelijkheid is van een gecentraliseerd operations-team om problemen met betrekking tot het gegevensplatform in isolatie op te lossen.

Uiteindelijk introduceert het gebruik van gecentraliseerde gegevensservices (dat is Centrale IT DBaaS) operationele knelpunten die de flexibiliteit aanzienlijk belemmeren via een grotendeels niet-gecontextualiseerde beheerervaring en moeten worden vermeden in een bedrijfskritieke of bedrijfskritieke context.

Aanvullende naslaginformatie

Aanvullende richtlijnen voor gegevensplatforms zijn beschikbaar in de Azure-toepassing Architectuurhandleiding.

• Beslissingsstructuur voor Azure Data Store
• Criteria voor het kiezen van een gegevensarchief
• Niet-relationele gegevensarchieven
• Relationele OLTP-gegevensarchieven

Wereldwijd gedistribueerd gegevensarchief met meerdere regio's schrijven

Om volledig tegemoet te komen aan de wereldwijd gedistribueerde actief-actieve aspiraties van een toepassingsontwerp, is het raadzaam om een gedistribueerd gegevensplatform voor meerdere regio's te overwegen, waarbij wijzigingen in afzonderlijke schrijfbare replica's worden gesynchroniseerd en samengevoegd tussen alle replica's, met waar nodig conflictoplossing.

Belangrijk

De microservices vereisen mogelijk niet allemaal een gedistribueerd gegevensarchief voor schrijven in meerdere regio's. Daarom moet rekening worden gehouden met de architectuurcontext en zakelijke vereisten van elk workloadscenario.

Azure Cosmos DB biedt een wereldwijd gedistribueerd en maximaal beschikbaar NoSQL-gegevensarchief, met schrijfbewerkingen in meerdere regio's en geen consistente out-of-the-box. De ontwerpoverwegingen en aanbevelingen in deze sectie richten zich daarom op optimaal Gebruik van Azure Cosmos DB.

Ontwerpoverwegingen

Azure Cosmos DB

• Azure Cosmos DB slaat gegevens op in containers, die zijn geïndexeerd, op rijen gebaseerde transactionele archieven die zijn ontworpen om snelle transactionele lees- en schrijfbewerkingen mogelijk te maken met reactietijden in de volgorde van milliseconden.

• Azure Cosmos DB ondersteunt meerdere verschillende API's met verschillende functiesets, zoals SQL, Cassandra en MongoDB.

  • Azure Cosmos DB voor NoSQL van de eerste partij biedt de rijkste functieset en is doorgaans de API waar nieuwe mogelijkheden eerst beschikbaar komen.

• Azure Cosmos DB ondersteunt gateway- en directe connectiviteitsmodi, waarbij Direct connectiviteit via TCP naar back-end azure Cosmos DB-replicaknooppunten faciliteert voor betere prestaties met minder netwerkhops, terwijl Gateway HTTPS-connectiviteit biedt met front-endgatewayknooppunten.

  • De directe modus is alleen beschikbaar wanneer u de Azure Cosmos DB for NoSQL gebruikt en momenteel alleen wordt ondersteund op .NET- en Java SDK-platforms.

• Binnen regio's met beschikbaarheidszone biedt Azure Cosmos DB redundantieondersteuning voor beschikbaarheidszone (AZ) voor hoge beschikbaarheid en tolerantie voor zonefouten binnen een regio.

• Azure Cosmos DB onderhoudt vier replica's van gegevens binnen één regio en wanneer beschikbaarheidszoneredundantie (AZ) is ingeschakeld, zorgt Azure Cosmos DB ervoor dat gegevensreplica's in meerdere AZ's worden geplaatst om te beschermen tegen zonegebonden fouten.

  • Het Paxos-consensusprotocol wordt toegepast om quorum te bereiken tussen replica's binnen een regio.

• Een Azure Cosmos DB-account kan eenvoudig worden geconfigureerd om gegevens over meerdere regio's te repliceren om het risico te beperken dat één regio niet meer beschikbaar is.

  • Replicatie kan worden geconfigureerd met schrijfbewerkingen in één regio of schrijfbewerkingen in meerdere regio's.
    • Bij schrijfbewerkingen in één regio wordt een primaire hubregio gebruikt om alle schrijfbewerkingen te verwerken en als deze hubregio niet meer beschikbaar is, moet er een failoverbewerking plaatsvinden om een andere regio te promoten als schrijfbaar.
    • Met schrijfbewerkingen voor meerdere regio's kunnen toepassingen schrijven naar elke geconfigureerde implementatieregio, waarmee wijzigingen tussen alle andere regio's worden gerepliceerd. Als een regio niet beschikbaar is, worden de resterende regio's gebruikt om schrijfverkeer te verwerken.

• In een schrijfconfiguratie voor meerdere regio's kunnen conflicten optreden bijwerken (invoegen, vervangen, verwijderen) waarbij schrijvers hetzelfde item in meerdere regio's gelijktijdig bijwerken.

• Azure Cosmos DB biedt twee beleidsregels voor conflictoplossing, die kunnen worden toegepast om conflicten automatisch op te lossen.

  • Last Write Wins (LWW) past een tijdsynchronisatieklokprotocol toe met behulp van een door het systeem gedefinieerde tijdstempeleigenschap _ts als het pad naar conflictoplossing. Als van een conflict het item met de hoogste waarde voor het pad voor conflictoplossing de winnaar wordt en als meerdere items dezelfde numerieke waarde hebben, selecteert het systeem een winnaar, zodat alle regio's kunnen convergeren naar dezelfde versie van het vastgelegde item.
    • Met verwijderingsconflicten wint de verwijderde versie altijd het invoegen of vervangen van conflicten, ongeacht de waarde van het pad voor conflictoplossing.
    • Last Write Wins is het standaardbeleid voor conflictoplossing.
    • Wanneer u Azure Cosmos DB for NoSQL gebruikt, kan een aangepaste numerieke eigenschap, zoals een aangepaste tijdstempeldefinitie, worden gebruikt voor conflictoplossing.
  • Met aangepaste oplossingsbeleidsregels kunnen door de toepassing gedefinieerde semantiek conflicten afstemmen met behulp van een geregistreerde samenvoegprocedure die automatisch wordt aangeroepen wanneer conflicten worden gedetecteerd.
    • Het systeem biedt precies eenmaal garantie voor de uitvoering van een samenvoegprocedure als onderdeel van het toezeggingsprotocol.
    • Een aangepast conflictoplossingsbeleid is alleen beschikbaar met Azure Cosmos DB voor NoSQL en kan alleen worden ingesteld tijdens het maken van containers.

• In een schrijfconfiguratie voor meerdere regio's is er een afhankelijkheid van één Azure Cosmos DB-hubregio om alle conflictoplossingen uit te voeren, waarbij het Paxos-consensusprotocol is toegepast om quorum te bereiken tussen replica's binnen de hubregio.

  • Het platform biedt een berichtbuffer voor schrijfconflicten binnen de hubregio om het laadniveau te bepalen en redundantie te bieden voor tijdelijke fouten.
    • De buffer kan een paar minuten aan schrijfupdates opslaan waarvoor consensus is vereist.

De strategische richting van het Azure Cosmos DB-platform is het verwijderen van deze afhankelijkheid van één regio voor conflictoplossing in een schrijfconfiguratie voor meerdere regio's, waarbij gebruik wordt gemaakt van een 2-fase Paxos-benadering om quorum te bereiken op globaal niveau en binnen een regio.

• De primaire hubregio wordt bepaald door de eerste regio waar Azure Cosmos DB is geconfigureerd.

  • Er is een volgorde van prioriteit geconfigureerd voor extra satellietimplementatieregio's voor failoverdoeleinden.

• Het gegevensmodel en partitionering tussen logische en fysieke partities spelen een belangrijke rol bij het bereiken van optimale prestaties en beschikbaarheid.

• Wanneer azure Cosmos DB wordt geïmplementeerd met één schrijfregio, kan deze worden geconfigureerd voor automatische failover op basis van een gedefinieerde failoverprioriteit, rekening houdend met alle replica's van leesregio's.

• De RTO van het Azure Cosmos DB-platform is ~10-15 minuten, waarbij de verstreken tijd wordt vastgelegd voor het uitvoeren van een regionale failover van de Azure Cosmos DB-service als een catastrofale ramp die van invloed is op de hubregio.

  • Deze RTO is ook relevant in een schrijfcontext voor meerdere regio's, gezien de afhankelijkheid van één hubregio voor conflictoplossing.
    • Als de hubregio niet meer beschikbaar is, mislukken schrijfbewerkingen naar andere regio's nadat de berichtbuffer is gevuld, omdat conflictoplossing pas kan optreden nadat de service een failover heeft uitgevoerd en er een nieuwe hubregio tot stand is gebracht.

De strategische richting van het Azure Cosmos DB-platform is het verminderen van de RTO tot ~5 minuten door failovers op partitieniveau toe te staan.

• RTO (Recovery Point Objectives) en Recovery Time Objectives (RTO) kunnen worden geconfigureerd via consistentieniveaus, met een afweging tussen duurzaamheid en doorvoer van gegevens.

  • Azure Cosmos DB biedt minimaal RTO van 0 voor een ontspannen consistentieniveau met schrijfbewerkingen in meerdere regio's of een RPO van 0 voor een sterke consistentie met regio voor één schrijfbewerking.

• Azure Cosmos DB biedt een SLA van 99,999% voor zowel lees- als schrijfbaarheid voor databaseaccounts die zijn geconfigureerd met meerdere Azure-regio's als beschrijfbaar.

  • De SLA wordt vertegenwoordigd door het percentage maandelijkse uptime, dat wordt berekend als 100% - gemiddelde foutpercentage.
  • Het gemiddelde foutpercentage wordt gedefinieerd als de som van foutpercentages voor elk uur in de factureringsmaand, gedeeld door het totale aantal uren in de factureringsmaand, waarbij de foutfrequentie het totale aantal mislukte aanvragen is, gedeeld door totaalaanvragen gedurende een bepaald interval van één uur.

• Azure Cosmos DB biedt een SLA van 99,99% voor doorvoer, consistentie, beschikbaarheid en latentie voor databaseaccounts die zijn afgestemd op één Azure-regio wanneer deze is geconfigureerd met een van de vijf consistentieniveaus.

  • Een SLA van 99,99% is ook van toepassing op databaseaccounts die meerdere Azure-regio's omvatten die zijn geconfigureerd met een van de vier soepele consistentieniveaus.

• Er zijn twee typen doorvoer die kunnen worden ingericht in Azure Cosmos DB, standaard en automatische schaalaanpassing, die worden gemeten met behulp van aanvraageenheden per seconde (RU/s).

  • Standaarddoorvoer wijst resources toe die nodig zijn om een opgegeven RU/s-waarde te garanderen.
    • Standard wordt elk uur gefactureerd voor ingerichte doorvoer.
  • Automatisch schalen definieert een maximale doorvoerwaarde en Azure Cosmos DB wordt automatisch omhoog of omlaag geschaald, afhankelijk van de belasting van de toepassing, tussen de maximale doorvoerwaarde en een minimum van 10% van de maximale doorvoerwaarde.
    • Automatische schaalaanpassing wordt elk uur gefactureerd voor de maximale verbruikte doorvoer.

• Statische ingerichte doorvoer met een variabele workload kan leiden tot beperkingsfouten, wat van invloed is op de waargenomen beschikbaarheid van toepassingen.

  • Automatische schaalaanpassing beschermt tegen beperkingsfouten door Azure Cosmos DB in staat te stellen zo nodig omhoog te schalen, terwijl kostenbeveiliging behouden blijft door omlaag te schalen wanneer de belasting afneemt.

• Wanneer Azure Cosmos DB wordt gerepliceerd in meerdere regio's, worden de ingerichte aanvraageenheden (RU's) per regio gefactureerd.

• Er is een aanzienlijke kosten delta tussen een configuratie voor schrijfbewerkingen in meerdere regio's en schrijfbewerkingen voor één regio, waardoor in veel gevallen een azure Cosmos DB-gegevensplatform met meerdere masters kan kosten.

Lezen/schrijven in één regio	Schrijven in één regio - Dubbele regio lezen	Lezen/schrijven in twee regio's
1 RU	2 RU	4 RU

De verschillen tussen schrijven in één regio en schrijven in meerdere regio's zijn in feite kleiner dan de verhouding 1:2 die in de bovenstaande tabel wordt weergegeven. Meer in het bijzonder zijn er kosten voor gegevensoverdracht tussen regio's die zijn gekoppeld aan schrijfupdates in een configuratie met één schrijfbewerking, die niet binnen de RU-kosten wordt vastgelegd, net als bij de schrijfconfiguratie voor meerdere regio's.

• Verbruikte opslag wordt gefactureerd als een vast tarief voor de totale hoeveelheid opslagruimte (GB) die wordt verbruikt om gegevens en indexen gedurende een bepaald uur te hosten.

• Session is het standaard en meest gebruikte consistentieniveau , omdat gegevens in dezelfde volgorde worden ontvangen als schrijfbewerkingen.

• Azure Cosmos DB ondersteunt verificatie via een Microsoft Entra-identiteit of Azure Cosmos DB-sleutels en resourcetokens, die overlappende mogelijkheden bieden.

• Het is mogelijk om bewerkingen voor resourcebeheer uit te schakelen met behulp van sleutels of resourcetokens om sleutels en resourcetokens alleen te beperken tot gegevensbewerkingen, waardoor fijnmazige toegangsbeheer voor resources mogelijk is met behulp van op rollen gebaseerd toegangsbeheer (RBAC) van Microsoft Entra.

  • Als u de toegang tot het besturingsvlak beperkt via sleutels of resourcetokens, worden besturingsvlakbewerkingen voor clients uitgeschakeld met behulp van Azure Cosmos DB SDK's en moeten ze daarom grondig worden geëvalueerd en getest.
  • De disableKeyBasedMetadataWriteAccess instelling kan worden geconfigureerd via ARM-sjabloon-IaC-definities of via een ingebouwd Azure Policy.

• Microsoft Entra RBAC-ondersteuning in Azure Cosmos DB is van toepassing op beheerbewerkingen voor accounts en resources.

  • Toepassingsbeheerders kunnen roltoewijzingen maken voor gebruikers, groepen, service-principals of beheerde identiteiten om toegang tot resources en bewerkingen op Azure Cosmos DB-resources te verlenen of te weigeren.
  • Er zijn verschillende ingebouwde RBAC-rollen beschikbaar voor roltoewijzing en aangepaste RBAC-rollen kunnen ook worden gebruikt om specifieke combinaties van bevoegdheden te vormen.
    • Cosmos DB-accountlezer maakt alleen-lezentoegang tot de Azure Cosmos DB-resource mogelijk.
    • DocumentDB-accountbijdrager maakt het beheer van Azure Cosmos DB-accounts mogelijk, inclusief sleutels en roltoewijzingen, maar schakelt geen toegang tot gegevensvlak in.
    • Cosmos DB-operator, die vergelijkbaar is met Inzender voor DocumentDB-accounts, maar biedt niet de mogelijkheid om sleutels of roltoewijzingen te beheren.

• Azure Cosmos DB-resources (accounts, databases en containers) kunnen worden beveiligd tegen onjuiste wijziging of verwijdering met behulp van resourcevergrendelingen.

  • Resourcevergrendelingen kunnen worden ingesteld op account-, database- of containerniveau.
  • Een resourcevergrendeling die is ingesteld op een resource, wordt overgenomen door alle onderliggende resources. Een resourcevergrendeling die is ingesteld op het Azure Cosmos DB-account, wordt bijvoorbeeld overgenomen door alle databases en containers binnen het account.
  • Resourcevergrendelingen zijn alleen van toepassing op besturingsvlakbewerkingen en voorkomen geen gegevensvlakbewerkingen, zoals het maken, wijzigen of verwijderen van gegevens.
  • Als de toegang tot het besturingsvlak niet beperkt is, disableKeyBasedMetadataWriteAccesskunnen clients besturingsvlakbewerkingen uitvoeren met behulp van accountsleutels.

• De Azure Cosmos DB-wijzigingenfeed biedt een op tijd geordende feed met wijzigingen in gegevens in een Azure Cosmos DB-container.

  • De wijzigingenfeed bevat alleen invoeg- en updatebewerkingen naar de Azure Cosmos DB-broncontainer; Het bevat geen verwijderingen.

• De wijzigingenfeed kan worden gebruikt om een afzonderlijk gegevensarchief te onderhouden van de primaire container die door de toepassing wordt gebruikt, met doorlopende updates voor het doelgegevensarchief dat wordt ingevoerd door de wijzigingenfeed van de broncontainer.

  • De wijzigingenfeed kan worden gebruikt om een secundair archief te vullen voor aanvullende redundantie van het gegevensplatform of voor volgende analytische scenario's.

• Als verwijderingsbewerkingen regelmatig van invloed zijn op de gegevens in de broncontainer, is het archief dat door de wijzigingenfeed wordt ingevoerd, onnauwkeurig en worden verwijderde gegevens niet weerspiegeld.

  • Een patroon voor voorlopig verwijderen kan worden geïmplementeerd zodat gegevensrecords worden opgenomen in de wijzigingenfeed.
    • In plaats van expliciet gegevensrecords te verwijderen, worden gegevensrecords bijgewerkt door een vlag (bijvoorbeeld IsDeleted) in te stellen om aan te geven dat het item wordt beschouwd als verwijderd.
    • Elk doelgegevensarchief dat door de wijzigingenfeed wordt ingevoerd, moet items detecteren en verwerken met een verwijderde vlag ingesteld op Waar; in plaats van voorlopig verwijderde gegevensrecords op te slaan, moet de bestaande versie van de gegevensrecord in het doelarchief worden verwijderd.
  • Een korte TTL (Time-To-Live) wordt meestal gebruikt met het patroon voor voorlopig verwijderen, zodat in Azure Cosmos DB automatisch verlopen gegevens worden verwijderd, maar pas nadat deze worden weergegeven in de wijzigingenfeed, waarbij de verwijderde vlag is ingesteld op Waar.
    • Hiermee wordt de oorspronkelijke verwijderingsintentie uitgevoerd terwijl de verwijdering ook wordt doorgegeven via de wijzigingenfeed.

• Azure Cosmos DB kan worden geconfigureerd als een analytische opslag, waarmee een kolomindeling wordt toegepast voor geoptimaliseerde analytische query's om de complexiteit en latentieproblemen op te lossen die optreden met de traditionele ETL-pijplijnen.

• Azure Cosmos DB maakt automatisch een back-up van gegevens met regelmatige tussenpozen zonder dat dit van invloed is op de prestaties of beschikbaarheid, en zonder ru/s te verbruiken.

• Azure Cosmos DB kan worden geconfigureerd volgens twee verschillende back-upmodi.

  • Periodiek is de standaardback-upmodus voor alle accounts, waarbij back-ups worden gemaakt met een periodiek interval en de gegevens worden hersteld door een aanvraag te maken bij het ondersteuningsteam.
    • De standaardperiode voor periodieke back-upretentie is acht uur en het standaardback-upinterval is vier uur, wat betekent dat alleen de laatste twee back-ups standaard worden opgeslagen.
    • Het back-upinterval en de bewaarperiode kunnen binnen het account worden geconfigureerd.
      • De maximale bewaarperiode wordt verlengd tot een maand met een minimaal back-upinterval van één uur.
      • Een roltoewijzing aan de Rol van Azure Cosmos DB-accountlezer is vereist voor het configureren van redundantie van back-upopslag.
    • Twee back-upkopieën zijn gratis inbegrepen, maar extra back-ups kosten.
    • Periodieke back-ups worden standaard opgeslagen in afzonderlijke GEOGRAFISCH redundante opslag (GRS) die niet rechtstreeks toegankelijk is.
      • Back-upopslag bestaat in de primaire hubregio en wordt gerepliceerd naar de gekoppelde regio via onderliggende opslagreplicatie.
      • De redundantieconfiguratie van het onderliggende back-upopslagaccount kan worden geconfigureerd voor zone-redundante opslag of lokaal redundante opslag.
    • Voor het uitvoeren van een herstelbewerking is een ondersteuningsaanvraag vereist, omdat klanten niet rechtstreeks een herstelbewerking kunnen uitvoeren.
      • Voordat u een ondersteuningsticket opent, moet de bewaarperiode voor back-ups worden verhoogd tot ten minste zeven dagen binnen acht uur na de gebeurtenis voor gegevensverlies.
    • Met een herstelbewerking maakt u een nieuw Azure Cosmos DB-account waarin gegevens worden hersteld.
      • Een bestaand Azure Cosmos DB-account kan niet worden gebruikt voor herstellen
      • Standaard wordt een nieuw Azure Cosmos DB-account met de naam <Azure_Cosmos_account_original_name>-restored<n> gebruikt.
        • Deze naam kan worden aangepast, bijvoorbeeld door de bestaande naam opnieuw te gebruiken als het oorspronkelijke account is verwijderd.
    • Als de doorvoer is ingericht op databaseniveau, vindt back-up en herstel plaats op databaseniveau
      • Het is niet mogelijk om een subset van containers te selecteren die u wilt herstellen.
  • Met de modus Continue back-up kunt u binnen de afgelopen 30 dagen herstellen naar elk tijdstip.
    • Herstelbewerkingen kunnen worden uitgevoerd om terug te keren naar een bepaald tijdstip (PITR) met een granulariteit van één seconde.
    • Het beschikbare venster voor herstelbewerkingen is maximaal 30 dagen.
      • Het is ook mogelijk om de instantiestatus van de resource te herstellen.
    • Continue back-ups worden gemaakt binnen elke Azure-regio waar het Azure Cosmos DB-account bestaat.
      • Continue back-ups worden opgeslagen in dezelfde Azure-regio als elke Azure Cosmos DB-replica, met behulp van lokaal redundante opslag (LRS) of zone-redundante opslag (ZRS) binnen regio's die ondersteuning bieden voor Beschikbaarheidszones.
    • Een selfserviceherstel kan worden uitgevoerd met behulp van Azure Portal of IaC-artefacten zoals ARM-sjablonen.
    • Er zijn verschillende beperkingen met Continue back-up.
      • De modus voor continue back-up is momenteel niet beschikbaar in een configuratie voor schrijfbewerkingen in meerdere regio's.
      • Op dit moment kunnen alleen Azure Cosmos DB voor NoSQL en Azure Cosmos DB voor MongoDB worden geconfigureerd voor continue back-up.
      • Als een container TTL heeft geconfigureerd, kunnen herstelde gegevens die de TTL hebben overschreden, onmiddellijk worden verwijderd
    • Met een herstelbewerking maakt u een nieuw Azure Cosmos DB-account voor herstel naar een bepaald tijdstip.
    • Er zijn extra opslagkosten voor continue back-ups en herstelbewerkingen.

• Bestaande Azure Cosmos DB-accounts kunnen worden gemigreerd van periodiek naar doorlopend, maar niet van doorlopend naar periodiek; migratie is in één richting en kan niet worden omgedraaid.

• Elke Azure Cosmos DB-back-up bestaat uit de gegevens zelf en configuratiegegevens voor ingerichte doorvoer, indexeringsbeleid, implementatieregio('s) en TTL-instellingen voor containers.

  • Back-ups bevatten geen firewallinstellingen, lijsten voor toegangsbeheer voor virtuele netwerken, instellingen voor privé-eindpunten, consistentie-instellingen (een account wordt hersteld met sessieconsistentie), opgeslagen procedures, triggers, UDF's of instellingen voor meerdere regio's.
    • Klanten zijn verantwoordelijk voor het opnieuw implementeren van mogelijkheden en configuratie-instellingen. Deze worden niet hersteld via azure Cosmos DB-back-up.
  • Analytische opslaggegevens van Azure Synapse Link zijn ook niet opgenomen in Azure Cosmos DB-back-ups.

• Het is mogelijk om een aangepaste back-up- en herstelmogelijkheid te implementeren voor scenario's waarbij periodieke en doorlopende benaderingen niet geschikt zijn.

  • Een aangepaste aanpak introduceert aanzienlijke kosten en extra administratieve overhead, die moet worden begrepen en zorgvuldig moeten worden beoordeeld.
    • Veelvoorkomende herstelscenario's moeten worden gemodelleerd, zoals beschadiging of verwijdering van een account, database, container, op gegevensitem.
    • Huishoudprocedures moeten worden geïmplementeerd om back-upgroei te voorkomen.
  • Azure Storage of een alternatieve gegevenstechnologie kan worden gebruikt, zoals een alternatieve Azure Cosmos DB-container.
    • Azure Storage en Azure Cosmos DB bieden systeemeigen integraties met Azure-services zoals Azure Functions en Azure Data Factory.

• De Documentatie van Azure Cosmos DB geeft twee mogelijke opties aan voor het implementeren van aangepaste back-ups.

  • Azure Cosmos DB-wijzigingenfeed voor het schrijven van gegevens naar een afzonderlijke opslagfaciliteit.
    • Een Azure-functie of gelijkwaardig toepassingsproces maakt gebruik van de verwerker van de wijzigingenfeed om de wijzigingenfeed te binden en items in de opslag te verwerken.
  • Zowel continue als periodieke (batchgewijze) aangepaste back-ups kunnen worden geïmplementeerd met behulp van de wijzigingenfeed.
  • De Wijzigingenfeed van Azure Cosmos DB weerspiegelt nog geen verwijderingen, dus er moet een patroon voor voorlopig verwijderen worden toegepast met behulp van een booleaanse eigenschap en TTL.
    • Dit patroon is niet vereist wanneer de wijzigingenfeed volledige updates biedt.
  • Azure Data Factory-connector voor Azure Cosmos DB (Azure Cosmos DB for NoSQL - of MongoDB-API-connectors ) om gegevens te kopiëren.
    • Azure Data Factory (ADF) ondersteunt handmatige uitvoering en planning, Tumblingvenster en triggers op basis van gebeurtenissen.
      • Biedt ondersteuning voor zowel Storage als Event Grid.
    • ADF is voornamelijk geschikt voor periodieke aangepaste back-up-implementaties vanwege de batchgeoriënteerde indeling.
      • Het is minder geschikt voor continue back-up-implementaties met frequente gebeurtenissen vanwege de overhead voor de uitvoering van orchestration.
    • ADF ondersteunt Azure Private Link voor scenario's met hoge netwerkbeveiliging

Azure Cosmos DB wordt gebruikt in het ontwerp van veel Azure-services, dus een aanzienlijke regionale storing voor Azure Cosmos DB heeft een trapsgewijze invloed op verschillende Azure-services binnen die regio. De precieze impact op een bepaalde service is sterk afhankelijk van hoe het onderliggende serviceontwerp gebruikmaakt van Azure Cosmos DB.

Aanbevelingen voor ontwerpen

Azure Cosmos DB

• Gebruik Azure Cosmos DB als het primaire gegevensplatform waar vereisten zijn toegestaan.

• Voor bedrijfskritieke workloadscenario's configureert u Azure Cosmos DB met een schrijfreplica in elke implementatieregio om de latentie te verminderen en maximale redundantie te bieden.

  • Configureer de toepassing om prioriteit te geven aan het gebruik van de lokale Azure Cosmos DB-replica voor schrijf- en leesbewerkingen om de belasting, prestaties en regionale RU/s-verbruik van toepassingen te optimaliseren.
  • De configuratie voor schrijfbewerkingen voor meerdere regio's heeft aanzienlijke kosten en moet alleen prioriteit krijgen voor workloadscenario's waarvoor maximale betrouwbaarheid is vereist.

• Voor minder kritieke workloadscenario's geeft u prioriteit aan het gebruik van configuratie voor schrijfbewerkingen met één regio (bij gebruik van Beschikbaarheidszones) met wereldwijd gedistribueerde leesreplica's, omdat dit een hoge mate van betrouwbaarheid van het gegevensplatform (99,999% SLA voor lees-, 99,995% SLA voor schrijfbewerkingen) biedt voor een aantrekkelijker prijsniveau.

  • Configureer de toepassing voor het gebruik van de lokale Leesreplica van Azure Cosmos DB om de leesprestaties te optimaliseren.

• Selecteer een optimale hub-implementatieregio waarin conflictoplossing plaatsvindt in een configuratie voor schrijfbewerkingen in meerdere regio's en alle schrijfbewerkingen worden uitgevoerd in een configuratie met één regio.

  • Houd rekening met de afstand ten opzichte van andere implementatieregio's en de bijbehorende latentie bij het selecteren van een primaire regio en vereiste mogelijkheden, zoals Beschikbaarheidszones ondersteuning.

• Configureer Azure Cosmos DB met az-redundantie (availability zone) in alle implementatieregio's met AZ-ondersteuning om tolerantie te garanderen voor zonegebonden fouten binnen een regio.

• Gebruik Azure Cosmos DB voor NoSQL omdat deze de meest uitgebreide functieset biedt, met name wat betreft het afstemmen van de prestaties.

  • Alternatieve API's moeten voornamelijk worden overwogen voor migratie- of compatibiliteitsscenario's.
    • Wanneer u alternatieve API's gebruikt, controleert u of de vereiste mogelijkheden beschikbaar zijn in de geselecteerde taal en SDK om optimale configuratie en prestaties te garanderen.

• Gebruik de modus Directe verbinding om de netwerkprestaties te optimaliseren via directe TCP-connectiviteit met back-end azure Cosmos DB-knooppunten, met een verminderd aantal netwerkhops.

De SLA van Azure Cosmos DB wordt berekend door het gemiddelde van mislukte aanvragen, die mogelijk niet rechtstreeks overeenkomen met een foutbudget van 99,999% van de betrouwbaarheidslaag. Bij het ontwerpen voor slo van 99,999% is het daarom essentieel om te plannen voor regionale en meerdere regio's van Azure Cosmos DB om niet beschikbaar te zijn, zodat een terugvalopslagtechnologie wordt geplaatst als er een fout optreedt, zoals een persistente berichtenwachtrij voor volgende herhaling.

• Definieer een partitioneringsstrategie voor zowel logische als fysieke partities om de gegevensdistributie te optimaliseren volgens het gegevensmodel.

  • Minimaliseer partitieoverkoepelende query's.
  • Test en valideer de partitioneringsstrategie iteratief om optimale prestaties te garanderen.

• Selecteer een optimale partitiesleutel.

  • De partitiesleutel kan niet worden gewijzigd nadat deze in de verzameling is gemaakt.
  • De partitiesleutel moet een eigenschapswaarde zijn die niet wordt gewijzigd.
  • Selecteer een partitiesleutel met een hoge kardinaliteit, met een breed scala aan mogelijke waarden.
  • De partitiesleutel moet het RU-verbruik en de gegevensopslag gelijkmatig verdelen over alle logische partities om zelfs RU-verbruik en opslagdistributie over fysieke partities te garanderen.
  • Voer leesquery's uit op de gepartitioneerde kolom om het RU-verbruik en de latentie te verminderen.

• Indexering is ook van cruciaal belang voor prestaties, dus zorg ervoor dat indexuitsluitingen worden gebruikt om RU/s en opslagvereisten te verminderen.

  • Indexeer alleen de velden die nodig zijn voor het filteren binnen query's; ontwerpindexen voor de meest gebruikte predicaten.

• Maak gebruik van de ingebouwde foutafhandeling, nieuwe pogingen en bredere betrouwbaarheidsmogelijkheden van de Azure Cosmos DB SDK.

  • Implementeer logica voor opnieuw proberen binnen de SDK op clients.

• Gebruik door de service beheerde versleutelingssleutels om de beheercomplexiteit te verminderen.

  • Als er een specifieke beveiligingsvereiste is voor door de klant beheerde sleutels, moet u ervoor zorgen dat de juiste procedures voor sleutelbeheer worden toegepast, zoals back-up en rotatie.

• Schakel schrijftoegang op basis van sleutels van Azure Cosmos DB uit door het ingebouwde Azure Policy toe te passen.

• Schakel Azure Monitor in om belangrijke metrische gegevens en diagnostische logboeken te verzamelen, zoals ingerichte doorvoer (RU/s).

  • Routeer operationele gegevens van Azure Monitor naar een Log Analytics-werkruimte die is toegewezen aan Azure Cosmos DB en andere globale resources binnen het toepassingsontwerp.
  • Gebruik metrische gegevens van Azure Monitor om te bepalen of toepassingsverkeerspatronen geschikt zijn voor automatisch schalen.

• Evalueer toepassingsverkeerspatronen om een optimale optie te selecteren voor ingerichte doorvoertypen.

  • Overweeg om de ingerichte doorvoer automatisch te schalen om de vraag naar workload automatisch te herverdelen.

• Evalueer microsoft-prestatietips voor Azure Cosmos DB om de configuratie aan de clientzijde en serverzijde te optimaliseren voor verbeterde latentie en doorvoer.

• Wanneer u AKS als rekenplatform gebruikt: selecteer voor queryintensieve workloads een AKS-knooppunt-SKU waarvoor versneld netwerken zijn ingeschakeld om latentie en CPU-jitters te verminderen.

• Voor implementaties van één schrijfregio wordt het sterk aanbevolen om Azure Cosmos DB te configureren voor automatische failover.

• Load level through the use of asynchronous non-blocking messaging within system flows, which write updates to Azure Cosmos DB.

  • Houd rekening met patronen zoals scheiding van opdracht- en queryverantwoordelijkheid en gebeurtenisbronnen.

• Configureer het Azure Cosmos DB-account voor continue back-ups om een nauwkeurige granulariteit van herstelpunten in de afgelopen 30 dagen te verkrijgen.

  • Overweeg het gebruik van Azure Cosmos DB-back-ups in scenario's waarin ingesloten gegevens of het Azure Cosmos DB-account worden verwijderd of beschadigd.
  • Vermijd het gebruik van een aangepaste back-upbenadering, tenzij dit absoluut noodzakelijk is.

• Het wordt ten zeerste aanbevolen om herstelprocedures uit te voeren voor niet-productiebronnen en -gegevens, als onderdeel van de voorbereiding van de standaardbedrijfscontinuïteitsbewerking.

• Definieer IaC-artefacten om configuratie-instellingen en -mogelijkheden van een back-upherstel van Azure Cosmos DB opnieuw tot stand te brengen.

• Evalueer en pas de richtlijnen voor azure-beveiligingsbasislijnbeheer toe voor Azure Cosmos DB Backup en Recovery.

  • BR-1: Regelmatige geautomatiseerde back-ups garanderen
  • BR-3: Alle back-ups valideren, inclusief door de klant beheerde sleutels
  • BR-4, Risico van verloren sleutels beperken

• Voor analytische workloads waarvoor beschikbaarheid in meerdere regio's is vereist, gebruikt u de analytische opslag van Azure Cosmos DB, waarmee een kolomindeling wordt toegepast voor geoptimaliseerde analytische query's.

Relationele gegevenstechnologieën

Voor scenario's met een zeer relationeel gegevensmodel of afhankelijkheden van bestaande relationele technologieën is het gebruik van Azure Cosmos DB in een schrijfconfiguratie met meerdere regio's mogelijk niet rechtstreeks van toepassing. In dergelijke gevallen is het essentieel dat de gebruikte relationele technologieën zijn ontworpen en geconfigureerd om de actieve aspiraties voor meerdere regio's van een toepassingsontwerp te handhaven.

Azure biedt veel beheerde relationele gegevensplatforms, waaronder Azure SQL Database en Azure Database voor algemene OSS-relationele oplossingen, waaronder MySQL, PostgreSQL en MariaDB. De ontwerpoverwegingen en aanbevelingen in deze sectie richten zich daarom op het optimale gebruik van Azure SQL Database en Azure Database OSS-smaken om de betrouwbaarheid en wereldwijde beschikbaarheid te maximaliseren.

Ontwerpoverwegingen

• Hoewel relationele gegevenstechnologieën kunnen worden geconfigureerd om leesbewerkingen eenvoudig te schalen, worden schrijfbewerkingen doorgaans beperkt om één primair exemplaar te doorlopen, waardoor een aanzienlijke beperking voor schaalbaarheid en prestaties wordt ingesteld.

• Sharding kan worden toegepast om gegevens en verwerking te distribueren over meerdere identieke gestructureerde databases, waarbij databases horizontaal worden gepartitioneerd om door platformbeperkingen te navigeren.

  • Sharding wordt bijvoorbeeld vaak toegepast op SaaS-platformen met meerdere tenants om groepen tenants te isoleren in afzonderlijke gegevensplatformconstructies.

Azure SQL-database

• Azure SQL Database biedt een volledig beheerde database-engine die altijd wordt uitgevoerd op de nieuwste stabiele versie van de SQL Server-database-engine en het onderliggende besturingssysteem.

  • Biedt intelligente functies, zoals het afstemmen van prestaties, het bewaken van bedreigingen en evaluaties van beveiligingsproblemen.

• Azure SQL Database biedt ingebouwde regionale hoge beschikbaarheid en kant-en-klare geo-replicatie om leesreplica's over Azure-regio's te distribueren.

  • Met geo-replicatie blijven secundaire databasereplica's alleen-lezen totdat een failover wordt gestart.
  • Maximaal vier secundaire bestanden worden ondersteund in dezelfde of verschillende regio's.
  • Secundaire replica's kunnen ook worden gebruikt voor alleen-lezen querytoegang om leesprestaties te optimaliseren.
  • Failover moet handmatig worden gestart, maar kan worden verpakt in geautomatiseerde operationele procedures.

• Azure SQL Database biedt groepen voor automatische failover, waarmee databases worden gerepliceerd naar een secundaire server en transparante failover mogelijk is als er een fout opgetreden is.

  • Groepen voor automatische failover ondersteunen geo-replicatie van alle databases in de groep naar slechts één secundaire server of instantie in een andere regio.
  • Groepen voor automatische failover worden momenteel niet ondersteund in de Hyperscale-servicelaag.
  • Secundaire databases kunnen worden gebruikt om leesverkeer te offloaden.

• Databasereplica's van premium- of Bedrijfskritiek-servicelagen kunnen zonder extra kosten worden gedistribueerd over Beschikbaarheidszones.

  • De besturingsring wordt ook gedupliceerd in meerdere zones als drie gateway-ringen (GW).
    • De routering naar een specifieke gatewayring wordt beheerd door Azure Traffic Manager.
  • Wanneer u de Bedrijfskritiek-laag gebruikt, is zone-redundante configuratie alleen beschikbaar wanneer de Gen5-rekenhardware is geselecteerd.

• Azure SQL Database biedt een SLA voor 99,99% beschikbaarheid van basislijn 99,99% in alle servicelagen, maar biedt een hogere SLA van 99,995% voor de Bedrijfskritiek- of Premium-lagen in regio's die beschikbaarheidszones ondersteunen.

  • Azure SQL Database-Bedrijfskritiek- of Premium-lagen die niet zijn geconfigureerd voor zone-redundante implementaties hebben een SLA voor beschikbaarheid van 99,99%.

• Wanneer deze is geconfigureerd met geo-replicatie, biedt de Azure SQL Database Bedrijfskritiek-laag een RTO (Recovery Time Objective) van 30 seconden gedurende 100% van de geïmplementeerde uren.

• Wanneer deze is geconfigureerd met geo-replicatie, heeft de Azure SQL Database Bedrijfskritiek-laag een RPO (Recovery Point Objective) van 5 seconden gedurende 100% van de geïmplementeerde uren.

• De Azure SQL Database Hyperscale-laag, wanneer deze is geconfigureerd met ten minste twee replica's, heeft een SLA voor beschikbaarheid van 99,99%.

• Rekenkosten die zijn gekoppeld aan Azure SQL Database kunnen worden verlaagd met behulp van een reserveringskorting.

  • Het is niet mogelijk om gereserveerde capaciteit toe te passen voor DTU-databases.

• Herstel naar een bepaald tijdstip kan worden gebruikt om een database en ingesloten gegevens te retourneren naar een eerder tijdstip.

• Geo-herstel kan worden gebruikt om een database te herstellen van een geografisch redundante back-up.

Azure Database For PostgreSQL

• Azure Database For PostgreSQL wordt aangeboden in drie verschillende implementatieopties:

  • Eén server, SLA 99,99%
  • Flexibele server, die redundantie van beschikbaarheidszones biedt, SLA 99,99%
  • Hyperscale (Citus), SLA 99,95% wanneer de modus Hoge beschikbaarheid is ingeschakeld.

• Hyperscale (Citus) biedt dynamische schaalbaarheid door middel van sharding zonder toepassingswijzigingen.

  • Het distribueren van tabelrijen over meerdere PostgreSQL-servers is essentieel om schaalbare query's in Hyperscale (Citus) te garanderen.
  • Meerdere knooppunten kunnen gezamenlijk meer gegevens bevatten dan een traditionele database, en in veel gevallen kunnen werkrol-CPU's parallel worden gebruikt om de kosten te optimaliseren.

• Automatische schaalaanpassing kan worden geconfigureerd via runbookautomatisering om elasticiteit te garanderen als reactie op veranderende verkeerspatronen.

• Flexibele server biedt kostenefficiëntie voor niet-productieworkloads door de mogelijkheid om de server te stoppen/starten en een burstable rekenlaag die geschikt is voor workloads waarvoor geen continue rekencapaciteit is vereist.

• Er worden geen extra kosten in rekening gebracht voor back-upopslag voor maximaal 100% van de totale ingerichte serveropslag.

  • Extra verbruik van back-upopslag wordt in rekening gebracht op basis van verbruikte GB/maand.

• De rekenkosten die zijn gekoppeld aan Azure Database for PostgreSQL, kunnen worden verlaagd met behulp van een reserveringskorting voor één server of hyperscale (Citus) reserveringskorting.

Aanbevelingen voor ontwerpen

• Overweeg sharding om relationele databases te partitioneren op basis van verschillende toepassings- en gegevenscontexten, om te helpen door platformbeperkingen te navigeren, schaalbaarheid en beschikbaarheid te maximaliseren en foutisolatie.

  • Deze aanbeveling wordt vooral gebruikt wanneer het toepassingsontwerp drie of meer Azure-regio's beschouwt, omdat relationele technologiebeperkingen wereldwijd gedistribueerde gegevensplatforms aanzienlijk kunnen belemmeren.
  • Sharding is niet geschikt voor alle toepassingsscenario's, dus er is een contextuele evaluatie vereist.

• Prioriter het gebruik van Azure SQL Database waar relationele vereisten bestaan vanwege de volwassenheid ervan op het Azure-platform en een breed scala aan betrouwbaarheidsmogelijkheden.

Azure SQL-database

• Gebruik de servicelaag Bedrijfskritiek om de betrouwbaarheid en beschikbaarheid te maximaliseren, inclusief toegang tot kritieke tolerantiemogelijkheden.

• Gebruik het verbruiksmodel op basis van vCore om de onafhankelijke selectie van reken- en opslagresources te vergemakkelijken, afgestemd op de vereisten voor workloadvolume en doorvoer.

  • Zorg ervoor dat een gedefinieerd capaciteitsmodel wordt toegepast om de vereisten voor reken- en opslagresources te informeren.
    • Overweeg gereserveerde capaciteit om potentiële kostenoptimalisaties te bieden.

• Configureer het zone-redundante implementatiemodel om Bedrijfskritiek databasereplica's binnen dezelfde regio in Beschikbaarheidszones te verspreiden.

• Gebruik Actieve geo-replicatie om leesbare replica's binnen alle implementatieregio's te implementeren (maximaal vier).

• Gebruik Automatische failovergroepen om transparante failover naar een secundaire regio te bieden, waarbij geo-replicatie is toegepast om replicatie te bieden naar aanvullende implementatieregio's voor leesoptimalisatie en databaseredundantie.

  • Voor toepassingsscenario's die beperkt zijn tot slechts twee implementatieregio's, moet prioriteit worden gegeven aan het gebruik van groepen voor automatische failover.

• Overweeg geautomatiseerde operationele triggers, op basis van waarschuwingen die zijn afgestemd op het statusmodel van de toepassing, om failovers uit te voeren naar geo-gerepliceerde exemplaren als een fout van invloed is op de primaire en secundaire binnen de groep voor automatische failover.

Belangrijk

Voor toepassingen die meer dan vier implementatieregio's overwegen, moet er serieus aandacht worden besteed aan sharding in toepassingsbereik of het herstructureren van de toepassing ter ondersteuning van schrijftechnologieën voor meerdere regio's, zoals Azure Cosmos DB. Als dit echter niet haalbaar is in het scenario met toepassingsworkloads, is het raadzaam om een regio binnen één geografie te verhogen naar een primaire status die een geografisch gerepliceerd exemplaar omvat om gelijkmatiger gedistribueerde leestoegang te krijgen.

• Configureer de toepassing om query's uit te voeren op replica-exemplaren voor leesquery's om de leesprestaties te optimaliseren.

• Gebruik Azure Monitor en Azure SQL Analytics voor bijna realtime operationele inzichten in Azure SQL DB voor de detectie van betrouwbaarheidsincidenten.

• Gebruik Azure Monitor om het gebruik voor alle databases te evalueren om te bepalen of ze de juiste grootte hebben.

  • Zorg ervoor dat CD-pijplijnen belastingstests overwegen onder representatieve belastingniveaus om het juiste gedrag van het gegevensplatform te valideren.

• Bereken een metrische status voor databaseonderdelen om de status te observeren ten opzichte van bedrijfsvereisten en resourcegebruik, waarbij bewaking en waarschuwingen worden gebruikt om waar nodig geautomatiseerde operationele actie te stimuleren.

  • Zorg ervoor dat belangrijke metrische gegevens over queryprestaties zijn opgenomen, zodat snelle actie kan worden ondernomen wanneer servicedegradatie plaatsvindt.

• Optimaliseer query's, tabellen en databases met behulp van Query Performance Insights en algemene aanbevelingen voor prestaties van Microsoft.

• Implementeer logica voor opnieuw proberen met behulp van de SDK om tijdelijke fouten te beperken die van invloed zijn op azure SQL Database-connectiviteit.

• Geef prioriteit aan het gebruik van door de service beheerde sleutels bij het toepassen van TDE (Transparent Data Encryption) aan de serverzijde voor at-rest-versleuteling.

  • Als door de klant beheerde sleutels of versleuteling aan de clientzijde (AlwaysEncrypted) is vereist, moet u ervoor zorgen dat sleutels op de juiste wijze tolerant zijn met back-ups en geautomatiseerde rotatiefaciliteiten.

• Overweeg het gebruik van herstel naar een bepaald tijdstip als een operationeel playbook om ernstige configuratiefouten te herstellen.

Azure Database For PostgreSQL

• Flexibele server wordt aanbevolen om deze te gebruiken voor bedrijfskritieke workloads vanwege de ondersteuning van de beschikbaarheidszone.

• Wanneer u Hyperscale (Citus) gebruikt voor bedrijfskritieke workloads, schakelt u de modus Hoge beschikbaarheid in om de SLA-garantie van 99,95% te ontvangen.

• Gebruik de Hyperscale-serverconfiguratie (Citus) om de beschikbaarheid op meerdere knooppunten te maximaliseren.

• Definieer een capaciteitsmodel voor de toepassing om de vereisten voor reken- en opslagresources binnen het gegevensplatform te informeren.

  • Overweeg de Reserveringskorting van Hyperscale (Citus) om potentiële kostenoptimalisaties te bieden.

Opslaan in cache voor gegevens in dynamische lagen

Een cachelaag in het geheugen kan worden toegepast om een gegevensplatform te verbeteren door de leesdoorvoer aanzienlijk te verhogen en de reactietijden van end-to-endclients te verbeteren voor gegevensscenario's met dynamische lagen.

Azure biedt verschillende services met toepasselijke mogelijkheden voor het opslaan van belangrijke gegevensstructuren in de cache, met Azure Cache voor Redis geplaatst om leestoegang van het gegevensplatform te abstraheren en te optimaliseren. Deze sectie richt zich daarom op het optimale gebruik van Azure Cache voor Redis in scenario's waarin extra leesprestaties en duurzaamheid van gegevenstoegang vereist zijn.

Overwegingen bij het ontwerpen

• Een cachelaag biedt extra duurzaamheid voor gegevenstoegang, omdat zelfs als een storing van invloed is op de onderliggende gegevenstechnologieën, een momentopname van toepassingsgegevens nog steeds toegankelijk is via de cachelaag.

• In bepaalde workloadscenario's kan caching in het geheugen worden geïmplementeerd binnen het toepassingsplatform zelf.

Azure Cache voor Redis

• Redis Cache is een open source NoSQL-sleutelwaarde in het geheugenopslagsysteem.

• De Enterprise- en Enterprise Flash-lagen kunnen worden geïmplementeerd in een actief-actief-configuratie in Beschikbaarheidszones binnen een regio en verschillende Azure-regio's via geo-replicatie.

  • Wanneer deze wordt geïmplementeerd in ten minste drie Azure-regio's en drie of meer Beschikbaarheidszones in elke regio, waarbij actieve geo-replicatie is ingeschakeld voor alle cache-exemplaren, biedt Azure Cache voor Redis een SLA van 99,999% voor connectiviteit met één regionaal cache-eindpunt.
  • Wanneer deze in drie Beschikbaarheidszones binnen één Azure-regio wordt geïmplementeerd, wordt er een SLA voor 99,99% connectiviteit geboden.

• De Enterprise Flash-laag wordt uitgevoerd op een combinatie van RAM en flash niet-vluchtige geheugenopslag, en hoewel dit een kleine prestatiestraf introduceert, maakt het ook zeer grote cachegrootten mogelijk, tot 13 TB met clustering.

• Bij geo-replicatie zijn kosten voor gegevensoverdracht tussen regio's ook van toepassing, naast de directe kosten die zijn gekoppeld aan cache-exemplaren.

• De functie Geplande updates bevat geen Azure-updates of -updates die zijn toegepast op het onderliggende VM-besturingssysteem.

• Er is een toename van het CPU-gebruik tijdens een uitschaalbewerking terwijl gegevens worden gemigreerd naar nieuwe exemplaren.

Aanbevelingen voor ontwerpen

• Overweeg een geoptimaliseerde cachelaag voor 'dynamische' gegevensscenario's om de leesdoorvoer te verhogen en de reactietijden te verbeteren.

• Pas de juiste beleidsregels toe voor het verlopen van de cache en huishouding om te voorkomen dat gegevens groeien.

  • Overweeg om cache-items te laten verlopen wanneer de back-up van gegevens wordt gewijzigd.

Azure Cache voor Redis

• Gebruik de Premium- of Enterprise-SKU om de betrouwbaarheid en prestaties te maximaliseren.

  • Voor scenario's met zeer grote gegevensvolumes moet de Enterprise Flash-laag worden overwogen.
  • Voor scenario's waarbij alleen passieve geo-replicatie is vereist, kan de Premium-laag ook worden overwogen.

• Implementeer replica-exemplaren met geo-replicatie in een actieve configuratie in alle implementatieregio's.

• Zorg ervoor dat replica-exemplaren worden geïmplementeerd in Beschikbaarheidszones binnen elke beschouwde Azure-regio.

• Gebruik Azure Monitor om Azure Cache voor Redis te evalueren.

  • Bereken een statusscore voor regionale cacheonderdelen om de status te observeren ten opzichte van bedrijfsvereisten en resourcegebruik.
  • Bekijk en waarschuw voor belangrijke metrische gegevens, zoals hoog CPU-gebruik, hoog geheugengebruik, hoge serverbelasting en verwijderde sleutels voor inzichten wanneer de cache moet worden geschaald.

• Optimaliseer de verbindingstolerantie door logica voor opnieuw proberen, time-outs en het gebruik van een singleton-implementatie van de Redis-verbindings multiplexer te implementeren.

• Configureer geplande updates om de dagen en tijden voor te schrijven dat Redis Server-updates worden toegepast op de cache.

Analytische scenario's

Het is steeds gebruikelijker voor bedrijfskritieke toepassingen om analytische scenario's te overwegen als een middel om extra waarde te stimuleren van omvattende gegevensstromen. Analytische scenario's voor toepassingen en operationele toepassingen (AIOps) vormen daarom een cruciaal aspect van zeer betrouwbare gegevensplatforms.

Analytische en transactionele workloads vereisen verschillende mogelijkheden en optimalisaties voor het gegevensplatform voor acceptabele prestaties binnen hun respectieve contexten.

Beschrijving	Analytisch	Transactioneel
Toepassing	Zeer grote hoeveelheden gegevens analyseren ('big data')	Zeer grote hoeveelheden afzonderlijke transacties verwerken
Geoptimaliseerd voor	Query's en aggregaties lezen over veel records	Bijna realtime CRUD-query's (Create/Read/Update/Delete) over enkele records
Belangrijkste kenmerken	- Samenvoegen vanuit gegevensbronnen van record - Opslag op basis van kolommen - Gedistribueerde opslag - Parallelle verwerking - Gedenormaliseerd - Lees- en schrijfbewerkingen met lage gelijktijdigheid - Optimaliseren voor opslagvolume met compressie	- Gegevensbron van record voor toepassing - Opslag op basis van rijen - Aaneengesloten opslag - Symmetrische verwerking -Genormaliseerd - Lees- en schrijfbewerkingen met hoge gelijktijdigheid, indexupdates - Optimaliseren voor snelle gegevenstoegang met in-memory opslag

Azure Synapse biedt een analytisch platform voor ondernemingen dat relationele en niet-relationele gegevens combineert met Spark-technologieën, met behulp van ingebouwde integratie met Azure-services zoals Azure Cosmos DB om big data-analyses te vergemakkelijken. De ontwerpoverwegingen en aanbevelingen in deze sectie richten zich daarom op optimaal Gebruik van Azure Synapse en Azure Cosmos DB voor analytische scenario's.

Overwegingen bij het ontwerpen

• Traditioneel worden grootschalige analytische scenario's gefaciliteerd door gegevens te extraheren in een afzonderlijk gegevensplatform dat is geoptimaliseerd voor volgende analytische query's.
  • ETL-pijplijnen (Extract, Transform, and Load) worden gebruikt om gegevens te extraheren, verbruiken doorvoer en beïnvloeden de prestaties van transactionele werkbelastingen.
  • Het niet vaak uitvoeren van ETL-pijplijnen om de doorvoer- en prestatieimpact te verminderen, resulteert in analytische gegevens die minder up-to-date zijn.
  • EtL-pijplijnontwikkeling en onderhoudsoverhead neemt toe naarmate gegevenstransformaties complexer worden.
    • Als brongegevens bijvoorbeeld vaak worden gewijzigd of verwijderd, moeten ETL-pijplijnen rekening houden met deze wijzigingen in de doelgegevens voor analytische query's via een additief/geversiede benadering, dumpen en opnieuw laden of in-place wijzigingen in de analytische gegevens. Elk van deze benaderingen heeft een afgeleide impact, zoals het opnieuw maken of bijwerken van de index.

Azure Cosmos DB

• Analytische query's die worden uitgevoerd op transactionele gegevens van Azure Cosmos DB, worden doorgaans geaggregeerd over partities over grote hoeveelheden gegevens, waarbij aanzienlijke RU-doorvoer (Request Unit) wordt verbruikt, wat de prestaties van omringende transactionele workloads kan beïnvloeden.

• De analytische opslag van Azure Cosmos DB biedt een geschematiseerd, volledig geïsoleerd kolomgeoriënteerd gegevensarchief waarmee grootschalige analyses op Azure Cosmos DB-gegevens van Azure Synapse mogelijk zijn zonder dat dit van invloed is op transactionele workloads van Azure Cosmos DB.

  • Wanneer een Azure Cosmos DB-container is ingeschakeld als analytische opslag, wordt intern een nieuw kolomarchief gemaakt op basis van de operationele gegevens in de container. Dit kolomarchief wordt los van het rijgeoriënteerde transactiearchief voor de container bewaard.
  • Bewerkingen voor het maken, bijwerken en verwijderen van de operationele gegevens worden automatisch gesynchroniseerd met de analytische opslag, dus er is geen wijzigingsfeed- of ETL-verwerking vereist.
  • Gegevenssynchronisatie van de operationele gegevens naar de analytische opslag verbruikt geen doorvoeraanvraageenheden (RU's) die zijn ingericht voor de container of database. Er is geen invloed op de prestaties van transactionele workloads. Analytische opslag vereist geen toewijzing van extra RU's in een Azure Cosmos DB-database of -container.
  • Automatisch synchroniseren is het proces waarbij wijzigingen in operationele gegevens automatisch worden gesynchroniseerd met de analytische opslag. De latentie voor automatisch synchroniseren duurt meestal minder dan twee (2) minuten.
    • De latentie voor automatisch synchroniseren kan maximaal vijf (5) minuten duren voor een database met gedeelde doorvoer en een groot aantal containers.
    • Zodra automatisch synchroniseren is voltooid, kunnen de meest recente gegevens worden opgevraagd vanuit Azure Synapse.
  • Analytische opslag maakt gebruik van een prijsmodel op basis van verbruik dat kosten in rekening brengt voor het volume van gegevens en het aantal lees- en schrijfbewerkingen. Prijzen voor analytische opslag zijn gescheiden van de prijzen voor transactionele winkels.

• Met behulp van Azure Synapse Link kan de analytische opslag van Azure Cosmos DB rechtstreeks vanuit Azure Synapse worden opgevraagd. Dit maakt no-ETL, Hybrid Transactional-Analytical Processing (HTAP) van Synapse mogelijk, zodat Azure Cosmos DB-gegevens in bijna realtime kunnen worden opgevraagd met andere analytische workloads van Synapse.

• De analytische opslag van Azure Cosmos DB is niet standaard gepartitioneerd.

  • Voor bepaalde queryscenario's worden de prestaties verbeterd door analytische opslaggegevens te partitioneren met behulp van sleutels die vaak worden gebruikt in querypredicaten.
  • Partitionering wordt geactiveerd door een taak in Azure Synapse die een Spark-notebook uitvoert met behulp van Synapse Link, waarmee de gegevens uit de analytische opslag van Azure Cosmos DB worden geladen en naar het gepartitioneerde Synapse-archief worden geschreven in het primaire opslagaccount van de Synapse-werkruimte.

• Serverloze Azure Synapse Analytics SQL-pools kunnen query's uitvoeren op de analytische opslag via automatisch bijgewerkte weergaven of via SELECT / OPENROWSET opdrachten.

• Azure Synapse Analytics Spark-pools kunnen query's uitvoeren op de analytische opslag via automatisch bijgewerkte Spark-tabellen of de spark.read opdracht.

• Gegevens kunnen ook worden gekopieerd uit de analytische opslag van Azure Cosmos DB in een toegewezen Synapse SQL-pool met behulp van Spark, zodat ingerichte Azure Synapse SQL-poolbronnen kunnen worden gebruikt.

• Azure Cosmos DB Analytical Store-gegevens kunnen worden opgevraagd met Azure Synapse Spark.

  • Met Spark-notebooks kunnen Combinaties van Spark-dataframes analytische gegevens van Azure Cosmos DB aggregeren en transformeren met andere gegevenssets en andere geavanceerde Synapse Spark-functionaliteit gebruiken, waaronder het schrijven van getransformeerde gegevens naar andere winkels of het trainen van AIOps Machine Learning-modellen.

• De Wijzigingenfeed van Azure Cosmos DB kan ook worden gebruikt voor het onderhouden van een afzonderlijk secundair gegevensarchief voor analytische scenario's.

Azure Synapse

• Azure Synapse combineert analysemogelijkheden, waaronder SQL-datawarehousing, Spark big data en Data Explorer voor logboek- en tijdreeksanalyse.

  • Azure Synapse maakt gebruik van gekoppelde services om verbindingen met andere services te definiëren, zoals Azure Storage.
  • Gegevens kunnen worden opgenomen in Synapse Analytics via Copy-activiteit uit ondersteunde bronnen. Hierdoor kunnen gegevensanalyses in Synapse worden uitgevoerd zonder dat dit van invloed is op het brongegevensarchief, maar extra tijd- en kosten- en latentieoverhead als gevolg van gegevensoverdracht.
  • Gegevens kunnen ook ter plaatse worden opgevraagd in ondersteunde externe archieven, waardoor de overhead van gegevensopname en -verplaatsing wordt vermeden. Azure Storage met Data Lake Gen2 is een ondersteund archief voor geëxporteerde Synapse- en Log Analytics-gegevens kan worden opgevraagd via Synapse Spark.

• Azure Synapse Studio combineert opname- en querytaken.

  • Brongegevens, waaronder Azure Cosmos DB Analytical Store-gegevens en Log Analytics-exportgegevens, worden opgevraagd en verwerkt om business intelligence en andere geaggregeerde analytische gebruiksvoorbeelden te ondersteunen.

Aanbevelingen voor ontwerpen

• Zorg ervoor dat analytische workloads geen invloed hebben op transactionele toepassingsworkloads om transactionele prestaties te behouden.

Application Analytics

• Gebruik Azure Synapse Link met Azure Cosmos DB Analytical Store om analyses uit te voeren op operationele gegevens van Azure Cosmos DB door een geoptimaliseerd gegevensarchief te maken, wat geen invloed heeft op de transactionele prestaties.

  • Schakel Azure Synapse Link in op Azure Cosmos DB-accounts.
  • Maak een container die is ingeschakeld voor analytische opslag of schakel een bestaande container in voor analytische opslag.
  • Verbind de Azure Synapse-werkruimte met de analytische opslag van Azure Cosmos DB om analytische workloads in Azure Synapse in te schakelen om query's uit te voeren op Azure Cosmos DB-gegevens. Gebruik een verbindingsreeks met een alleen-lezen Azure Cosmos DB-sleutel.

• Prioriteit geven aan de analytische opslag van Azure Cosmos DB met Azure Synapse Link in plaats van de Azure Cosmos DB-wijzigingenfeed te gebruiken om een analytische gegevensopslag te onderhouden.

  • De Azure Cosmos DB-wijzigingenfeed is mogelijk geschikt voor zeer eenvoudige analytische scenario's.

AIOps en Operational Analytics

• Maak één Azure Synapse-werkruimte met gekoppelde services en gegevenssets voor elk Azure Storage-bronaccount waarnaar operationele gegevens van resources worden verzonden.

• Maak een toegewezen Azure Storage-account en gebruik dit als het primaire opslagaccount van de werkruimte om de catalogusgegevens en metagegevens van de Synapse-werkruimte op te slaan. Configureer deze met hiërarchische naamruimte om Azure Data Lake Gen2 in te schakelen.

  • Behoud de scheiding tussen de analytische brongegevens en synapse-werkruimtegegevens en metagegevens.
    • Gebruik geen regionale of globale Azure Storage-accounts waarin operationele gegevens worden verzonden.

Volgende stap

Bekijk de overwegingen voor netwerkoverwegingen.

Netwerk en connectiviteit