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 mogelijkheden. 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 essentieel invloed op de geschiktheid voor een wereldwijd beschikbaar platform.

Dit ontwerpgebied breidt zich uit op het ontwerp van toepassingen en biedt belangrijke overwegingen en aanbevelingen voor de selectie van een optimaal gegevensplatform.

Belangrijk

Dit artikel maakt deel uit van de reeks bedrijfskritische workloads van Azure Well-Architected . Als u niet bekend bent met deze reeks, raden we u aan te beginnen met wat is een essentiële workload?

De vier versus big data

De 'Vier versus big data' bieden 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 verkend hoe de kenmerken Volume, Velocity, Variety en Veracity op conceptueel niveau kunnen worden toegepast om een gegevensplatform te helpen ontwerpen met behulp van de juiste gegevenstechnologieën.

• Volume: hoeveel gegevens er binnenkomen om te voldoen aan de vereisten voor opslagcapaciteit en lagen, dat is de grootte van de gegevensset.
• Velocity: de snelheid waarmee gegevens worden verwerkt, hetzij als batches of als continue stromen, dat is de snelheid van de stroom.
• Variety: de organisatie en de indeling van gegevens, het vastleggen van gestructureerde, semi-gestructureerde en ongestructureerde indelingen, dat zijn gegevens in meerdere winkels of typen.
• Veracity: omvat de herkomst en curatie van beschouwde gegevenssets voor governance en gegevenskwaliteitsbewaking. Dit is de nauwkeurigheid van de gegevens.

Overwegingen bij het ontwerp

Volume

• Bestaande (indien van toepassing) en verwachte toekomstige gegevensvolumes op basis van geraamde gegevensgroeisnelheden 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).
  • Gegevensuitbreiding kan aanzienlijke kosten met zich meebrengen.

• Het gegevensvolume kan fluctueren als gevolg van veranderende bedrijfsomstandigheden of schoonmaakprocedures.

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

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

  • Leidt dit tot downtime? En zo ja, voor hoe lang?
  • Wat zijn de risicobeperkingsprocedures? en zijn toepassingswijzigingen vereist voor de beperking?
  • Is er een risico op gegevensverlies?

• Functies zoals Time to Live (TTL) kunnen worden gebruikt om de groei van gegevens 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 vanuit 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 scenario's met veel lees- of schrijfbewerkingen.
    • Analytische workloads moeten bijvoorbeeld doorgaans een grote leesdoorvoer hebben.
  • Wat is de vereiste doorvoer? En hoe zal de doorvoer naar verwachting groeien?
  • Wat zijn de vereisten voor gegevenslatentie op P50/P99 onder referentiebelastingsniveaus?

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

  • Het optimaliseren van de configuratie voor hoge doorvoer veroorzaakt compromissen, die volledig moeten worden begrepen.
  • Persistentie- en berichtpatronen, zoals CQRS en Event Sourcing, kunnen worden gebruikt om de doorvoer verder te optimaliseren.

• Belastingsniveaus fluctueren van nature voor veel toepassingsscenario's, waarbij natuurlijke pieken een voldoende mate van elasticiteit vereisen om de variabele vraag te verwerken met behoud van doorvoer en latentie.

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

• De impact van doorvoerdips kan variëren, afhankelijk van het workloadscenario.

  • Is er sprake van een onderbreking van de connectiviteit?
  • Zullen afzonderlijke bewerkingen foutcodes retourneren terwijl het besturingsvlak blijft werken?
  • Wordt beperking door het gegevensplatform geactiveerd en zo ja, hoe lang?

• De fundamentele aanbeveling voor toepassingsontwerp voor het gebruik van een actief-actief geografische distributie brengt uitdagingen met betrekking tot gegevensconsistentie met zich mee.

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

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

• Alleen-lezenreplica's (binnen regio's en regio's) kunnen worden gebruikt om retourlatentie 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 end-to-end reactietijden van de client te verbeteren.

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

Verscheidenheid

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

  • Is voor de toepassing een relationeel gegevensmodel vereist of kan deze ondersteuning bieden voor een variabel schema of een niet-relationeel gegevensmodel?
  • Hoe voert de toepassing query's uit op gegevens? En zijn query's afhankelijk van concepten in de databaselaag, zoals relationele joins? Of biedt de toepassing dergelijke semantiek?

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

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

• Naast relationele of niet-relationele gegevensplatformen kunnen grafiek- of sleutelwaardegegevensplatformen ook geschikt zijn voor bepaalde gegevensworkloads.

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

• In een microservicearchitectuur kunnen afzonderlijke toepassingsservices worden gebouwd met afzonderlijke, voor scenario's geoptimaliseerde gegevensarchieven in plaats van afhankelijk te zijn 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 beperkingen voor co-locatie opleggen.
  • Het gebruik van meerdere gegevenstechnologieën voegt een zekere mate van beheeroverhead toe om de omvattende technologieën te onderhouden.

• De functiesets voor elke Azure-service verschillen van taal, SDK's en API's, wat een grote invloed kan hebben op het niveau van configuratieafstemming dat kan worden toegepast.

• Mogelijkheden voor geoptimaliseerde afstemming met het gegevensmodel en de omvattende gegevenstypen zijn sterk van invloed op beslissingen over 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 ondernemingscontext kunnen het gebruik van bestaande processen en hulpmiddelen en de continuïteit van vaardigheden een belangrijke invloed hebben op het ontwerp en de selectie van gegevenstechnologieën van het gegevensplatform.

Waarheidsgetrouwheid

• Er moet rekening worden gehouden met verschillende factoren om de nauwkeurigheid van gegevens binnen 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 schema-evolutie.
  • Afhankelijkheden tussen gegevenssets.

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

  • Wanneer lezers en schrijvers duidelijk zijn gedistribueerd, moet een toepassing ervoor kiezen om de snelst beschikbare versie van een gegevensitem te retourneren, zelfs als het verouderd is in vergelijking met een zojuist voltooide schrijfbewerking (update) van dat gegevensitem in een andere replica, of de meest recente versie van het gegevensitem, die 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 moesten worden geleverd vanuit een replica die zich het dichtst bij de gebruiker bevindt en die niet de meest recente status van een andere replica weergeeft? Dat wil zeggen dat de toepassing ondersteuning biedt voor het leveren van verouderde gegevens?

• Wanneer in een schrijfcontext voor 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 een negatieve invloed hebben op de doorvoer of prestaties.

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

• Azure ondersteunt 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) data-linkversleuteling wordt gebruikt om al het verkeer te beveiligen dat wordt verplaatst tussen Azure-datacenters op het Microsoft-backbone-netwerk.

  • 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 de toegang tot toepassingen en operationele toegang?

• Waarneembaarheid door platformstatus en gegevenstoegang te bewaken.

  • Hoe wordt waarschuwingen toegepast voor voorwaarden buiten aanvaardbare operationele grenzen?

Ontwerpaanbeveling

Volume

• Zorg ervoor dat toekomstige gegevensvolumes die zijn gekoppeld aan organische groei naar verwachting niet de mogelijkheden van het gegevensplatform overschrijden.

  • Voorspel de groeipercentages van gegevens die zijn afgestemd op bedrijfsplannen en gebruik vastgestelde tarieven om te informeren over doorlopende capaciteitsvereisten.
  • Vergelijk aggregatie- en recordvolumes per gegevens met de limieten van het gegevensplatform.
  • Als er een risico bestaat dat limieten in uitzonderlijke omstandigheden worden bereikt, moet u ervoor zorgen dat er operationele oplossingen zijn om downtime en gegevensverlies te voorkomen.

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

  • 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 er wordt waarschijnlijk een prestatievermindering toegepast tijdens replicatie. Zorg er dus voor dat deze bewerkingen, indien mogelijk, buiten kritieke kantooruren worden uitgevoerd.

• 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 de lagen 'dynamisch', 'warm' en 'koud' ('archief').
    • De basisreferentie-implementaties maken bijvoorbeeld gebruik van Azure Cosmos DB voor het opslaan van 'dynamische' gegevens die actief worden gebruikt door de toepassing, terwijl Azure Storage wordt gebruikt voor 'koude' bewerkingsgegevens voor analytische doeleinden.

• Configureer schoonmaakprocedures 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 geen analytische waarde voor de lange termijn hebben.
    • Controleer of oude gegevens veilig kunnen worden gelaagd naar secundaire opslag of kunnen worden verwijderd, zonder dat dit nadelige gevolgen heeft 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 gegevensplatformtelemetrie en gebruiksstatistieken om DevOps-teams in staat te stellen voortdurend de vereisten voor het huishouden en de juiste grootte van gegevensarchieven te evalueren.

• In overeenstemming met het ontwerp van een microservicetoepassing kunt u overwegen om meerdere verschillende gegevenstechnologieën parallel te gebruiken, met geoptimaliseerde gegevensoplossingen voor specifieke workloadscenario's en volumevereisten.

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

Snelheid

• Het gegevensplatform moet inherent zijn ontworpen en geconfigureerd voor ondersteuning van hoge doorvoer, met workloads gescheiden in verschillende contexten om de prestaties te maximaliseren met behulp van gegevensoplossingen die zijn geoptimaliseerd voor scenario's.

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

• Laadniveau door het gebruik van asynchrone niet-blokkerende berichten, bijvoorbeeld met behulp van de patronen CQRS of Event Sourcing .

  • Er kan latentie zijn tussen schrijfaanvragen en het moment waarop nieuwe gegevens beschikbaar komen om te lezen, wat van invloed kan zijn op de gebruikerservaring.
    • Deze impact moet worden begrepen en acceptabel zijn in de context van belangrijke bedrijfsvereisten.

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

  • Als belastingsniveaus zeer volatiel zijn, kunt u overwegen om capaciteitsniveaus te veel in te stellen om ervoor te zorgen dat de doorvoer en prestaties behouden blijven.
  • Test en valideer de impact op samengestelde toepassingsworkloads wanneer de doorvoer niet kan worden onderhouden.

• Geef prioriteit aan azure-systeemeigen gegevensservices met geautomatiseerde schaalbewerkingen om snel te reageren op volatiliteit op belastingniveau.

  • Configureer automatische schaalaanpassing op basis van drempelwaarden voor interne services en toepassingen.
  • Schalen moet worden gestart en voltooid in een tijdsbestek dat consistent is met de bedrijfsvereisten.
  • Voor scenario's waarin 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 probleemloos worden verwerkt door het gegevensplatform of de toepassingslaag en worden vastgelegd door het statusmodel voor operationele weergave.

• Implementeer caching voor scenario's met 'dynamische' gegevens om reactietijden te minimaliseren.

  • Pas de juiste beleidsregels toe voor het verlopen van de cache en het huishouden om te voorkomen dat de gegevens groeien.
    • Cache-items laten verlopen wanneer de back-upgegevens worden gewijzigd.
    • Als het verlopen van de cache uitsluitend op time-to-live (TTL) is gebaseerd, moet de impact en klantervaring van het leveren van verouderde gegevens worden begrepen.

Verscheidenheid

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

• In overeenstemming met het toepassingsontwerpprincipe van losjes gekoppelde microservicearchitecturen, staat u afzonderlijke services toe om afzonderlijke gegevensarchieven en voor scenario's geoptimaliseerde gegevenstechnologieën te gebruiken.

  • 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 waarbij 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 het ontwerp van een gegevensplatform voor meerdere regio's en distribueer replica's over regio's voor maximale betrouwbaarheid, beschikbaarheid en prestaties door gegevens dichter bij toepassingseindpunten te plaatsen.

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

• Waar consistentievereisten dit toestaan, gebruikt u een ontwerp voor schrijfgegevensplatforms in meerdere regio's om de algehele wereldwijde beschikbaarheid en betrouwbaarheid te maximaliseren.

  • Houd rekening met bedrijfsvereisten voor conflictoplossing wanneer hetzelfde gegevensitem wordt gewijzigd in twee afzonderlijke schrijfreplica's voordat een van beide wijzigingen kan worden gerepliceerd en er een conflict ontstaat.
    • Gebruik waar mogelijk gestandaardiseerde beleidsregels voor conflictoplossing, zoals 'Laatste wint'
      • Als een aangepaste strategie met aangepaste logica is vereist, 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 de doorvoer- en prestatievereisten niet worden beïnvloed door de vereiste beveiligingsmogelijkheden, zoals versleuteling.

  • Zorg ervoor dat continue leveringsprocessen rekening houden met belastingstests 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 integratie met een bredere organisatie-implementatie is het essentieel dat een toepassingsgerichte benadering wordt toegepast voor de inrichting en werking van gegevensplatformonderdelen in een toepassingsontwerp.

Om de betrouwbaarheid te maximaliseren, is het van cruciaal belang dat afzonderlijke gegevensplatformonderdelen op de juiste manier reageren op de status van de toepassing via operationele acties die andere toepassingsonderdelen kunnen bevatten. In een scenario waarin bijvoorbeeld extra gegevensplatformresources nodig zijn, is het schalen van het gegevensplatform samen met andere toepassingsonderdelen volgens een capaciteitsmodel waarschijnlijk vereist, mogelijk door het inrichten van extra schaaleenheden. Deze benadering wordt uiteindelijk beperkt als er een harde afhankelijkheid van een gecentraliseerd operationeel team is om problemen met betrekking tot het gegevensplatform geïsoleerd op te lossen.

Uiteindelijk leidt het gebruik van gecentraliseerde gegevensservices (DBaaS voor centrale IT) tot operationele knelpunten die de flexibiliteit aanzienlijk belemmeren door een grotendeels niet-gecontextualiseerde beheerervaring, en die moeten worden vermeden in een bedrijfskritieke of bedrijfskritieke context.

Aanvullende naslaginformatie

Aanvullende richtlijnen voor het gegevensplatform zijn beschikbaar in de architectuurhandleiding voor Azure-toepassing.

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

Wereldwijd gedistribueerd schrijfgegevensarchief voor meerdere regio's

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

Belangrijk

De microservices vereisen mogelijk niet allemaal een gedistribueerd schrijfgegevensarchief voor meerdere regio's, dus er moet rekening worden gehouden met de architecturale context en bedrijfsvereisten van elk workloadscenario.

Azure Cosmos DB biedt een wereldwijd gedistribueerd en maximaal beschikbaar NoSQL-gegevensarchief, met schrijfbewerkingen voor meerdere regio's en standaard instelbare consistentie. De ontwerpoverwegingen en aanbevelingen in deze sectie zijn daarom gericht op optimaal gebruik van Azure Cosmos DB.

Overwegingen bij het ontwerpen

Azure Cosmos DB

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

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

  • De eigen Azure Cosmos DB for NoSQL biedt de rijkste functieset en is doorgaans de API waar nieuwe mogelijkheden het eerst beschikbaar komen.

• Azure Cosmos DB ondersteunt gateway- en directe connectiviteitsmodi, waarbij Direct connectiviteit via TCP naar azure Cosmos DB-replicaknooppunten in de back-end faciliteert voor verbeterde 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 wordt momenteel alleen ondersteund op .NET- en Java SDK-platformen.

• Binnen regio's waarvoor beschikbaarheidszones zijn ingeschakeld, biedt Azure Cosmos DB redundantieondersteuning voor beschikbaarheidszones (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 AZ-redundantie (Beschikbaarheidszone) is ingeschakeld, zorgt Azure Cosmos DB ervoor dat gegevensreplica's worden geplaatst in meerdere AZ's om te beschermen tegen zonefouten.

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

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

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

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

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

  • LWW (Last Write Wins) past een klokprotocol voor tijdsynchronisatie toe met een door het systeem gedefinieerde tijdstempeleigenschap _ts als pad naar conflictoplossing. Als van een conflict het item met de hoogste waarde voor het conflictoplossingspad 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.
    • Bij verwijderingsconflicten wint de verwijderde versie altijd van conflicten tussen invoegen of vervangen, ongeacht de waarde van het pad voor conflictoplossing.
    • Last Write Wins is het standaardbeleid voor conflictoplossing.
    • Wanneer u Azure Cosmos DB voor NoSQL gebruikt, kan een aangepaste numerieke eigenschap, zoals een aangepaste tijdstempeldefinitie, worden gebruikt voor het oplossen van conflicten.
  • Aangepast oplossingsbeleid maakt toepassingsgedefinieerde semantiek mogelijk om conflicten af te stemmen met behulp van een geregistreerde samenvoegingsprocedure die automatisch wordt aangeroepen wanneer er conflicten worden gedetecteerd.
    • Het systeem biedt exact één keer garantie voor de uitvoering van een samenvoegingsprocedure 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 de container.

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

  • Het platform biedt een berichtenbuffer voor schrijfconflicten binnen de hubregio op laadniveau en biedt redundantie voor tijdelijke fouten.
    • De buffer kan enkele 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 tweefasige Paxos-benadering om quorum op globaal niveau en binnen een regio te bereiken.

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

  • Er wordt een prioriteitsvolgorde geconfigureerd voor extra satellietimplementatieregio's voor failoverdoeleinden.

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

• Bij implementatie met één schrijfregio kan Azure Cosmos DB worden geconfigureerd voor automatische failover op basis van een gedefinieerde failoverprioriteit, rekening houdend met alle leesregioreplica's.

• De RTO die door het Azure Cosmos DB-platform wordt geleverd, duurt ongeveer 10-15 minuten, waarbij de verstreken tijd wordt vastgelegd voor het uitvoeren van een regionale failover van de Azure Cosmos DB-service als een catastrofe ramp de hubregio beïnvloedt.

  • 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 worden uitgevoerd als er een failover van de service wordt uitgevoerd en 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.

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

  • Azure Cosmos DB biedt een minimale RTO van 0 voor een ontspannen consistentieniveau met schrijfbewerkingen in meerdere regio's of een RPO van 0 voor 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 schrijfbaar.

  • De SLA wordt vertegenwoordigd door het maandelijkse uptimepercentage, dat wordt berekend als 100% - gemiddeld foutpercentage.
  • Het gemiddelde foutpercentage wordt gedefinieerd als de som van de fouttarieven voor elk uur in de factureringsmaand gedeeld door het totale aantal uren in de factureringsmaand, waarbij het foutpercentage het totale aantal mislukte aanvragen is gedeeld door het totaal aantal aanvragen 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 gericht 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 versoepelde 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 per uur gefactureerd voor ingerichte doorvoer.
  • Automatisch schalen definieert een maximale doorvoerwaarde en Azure Cosmos DB schaalt automatisch omhoog of omlaag, 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.

• Statisch 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 te schakelen om naar behoefte omhoog te schalen, terwijl kostenbeveiliging wordt gehandhaafd door terug 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 kostenverschil tussen een schrijfconfiguratie voor meerdere regio's en schrijfbewerkingen met één regio, waardoor een Azure Cosmos DB-gegevensplatform met meerdere masters in veel gevallen onbetaalbaar kan zijn.

Lezen/schrijven in één regio	Schrijfbewerkingen in één regio - Leesbewerkingen in twee regio's	Lezen/schrijven in twee regio's
1 RU	2 RU	4 RU

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

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

• 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 te beperken tot alleen gegevensbewerkingen, waardoor nauwkeurig toegangsbeheer voor resources mogelijk is met behulp van Microsoft Entra op rollen gebaseerd toegangsbeheer (RBAC).

  • Als u de toegang tot het besturingsvlak via sleutels of resourcetokens beperkt, worden bewerkingen op het besturingsvlak uitgeschakeld voor clients die gebruikmaken van Azure Cosmos DB SDK's en moeten ze daarom grondig worden geëvalueerd en getest.
  • De disableKeyBasedMetadataWriteAccess instelling kan worden geconfigureerd via IaC-definities van ARM-sjabloon of via een ingebouwde 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 te verlenen of te weigeren tot resources en bewerkingen in Azure Cosmos DB-resources.
  • 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 beheer van Azure Cosmos DB-accounts mogelijk, inclusief sleutels en roltoewijzingen, maar biedt geen toegang tot gegevensvlak.
    • Cosmos DB Operator, die vergelijkbaar is met DocumentDB-accountbijdrager, maar niet de mogelijkheid biedt om sleutels of roltoewijzingen te beheren.

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

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

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

  • De wijzigingenfeed bevat alleen invoeg- en updatebewerkingen voor 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 gevoed door de wijzigingenfeed van de broncontainer.

  • De wijzigingenfeed kan worden gebruikt om een secundair archief te vullen voor extra gegevensplatformredundantie of voor volgende analytische scenario's.

• Als verwijderingsbewerkingen regelmatig van invloed zijn op de gegevens in de broncontainer, is de opslag die door de wijzigingenfeed wordt gevoed onnauwkeurig en niet-reflecterend voor verwijderde gegevens.

  • Er kan een patroon voor voorlopig verwijderen worden geïmplementeerd, zodat gegevensrecords worden opgenomen in de wijzigingenfeed.
    • In plaats van gegevensrecords expliciet te verwijderen, worden gegevensrecords bijgewerkt door een vlag in te stellen (bijvoorbeeld IsDeleted) om aan te geven dat het item als verwijderd wordt beschouwd.
    • Elk doelgegevensarchief dat door de wijzigingenfeed wordt gevoed, moet items detecteren en verwerken met een verwijderde vlag die is 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 Azure Cosmos DB verlopen gegevens automatisch verwijdert, maar pas nadat deze zijn weergegeven in de wijzigingenfeed met de markering Verwijderd 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, waarbij een kolomindeling wordt toegepast voor geoptimaliseerde analytische query's om de complexiteit en latentieuitdagingen aan te pakken die optreden bij de traditionele ETL-pijplijnen.

• Azure Cosmos DB maakt met regelmatige tussenpozen automatisch back-ups van gegevens 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 met een periodiek interval worden gemaakt en de gegevens worden hersteld door een aanvraag bij het ondersteuningsteam te maken.
    • De standaardperiode voor periodieke back-upretentie is acht uur en het standaardback-upinterval is vier uur, wat betekent dat standaard alleen de laatste twee back-ups worden opgeslagen.
    • Het back-upinterval en de retentieperiode kunnen binnen het account worden geconfigureerd.
      • De maximale retentieperiode is een maand met een minimaal back-upinterval van één uur.
      • Er is een roltoewijzing aan de Azure'Cosmos DB-accountlezerrol' vereist om redundantie van back-upopslag te configureren.
    • Er zijn twee back-ups zonder extra kosten opgenomen, maar voor extra back-ups worden extra kosten in rekening gebracht.
    • Standaard worden periodieke back-ups opgeslagen in afzonderlijke Geo-Redundant Storage (GRS) die niet rechtstreeks toegankelijk is.
      • Back-upopslag bevindt zich in de primaire hubregio en wordt gerepliceerd naar de gekoppelde regio via onderliggende opslagreplicatie.
      • De redundantieconfiguratie van het onderliggende back-upopslagaccount kan worden geconfigureerd in Zone-redundante opslag of Locally-Redundant Storage.
    • 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 verlengd tot ten minste zeven dagen binnen acht uur na de gebeurtenis voor gegevensverlies.
    • Met een herstelbewerking wordt een nieuw Azure Cosmos DB-account gemaakt 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 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 voor continue back-up kunt u 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 in elke Azure-regio waarin het Azure Cosmos DB-account bestaat.
      • Continue back-ups worden opgeslagen in dezelfde Azure-regio als elke Azure Cosmos DB-replica, met behulp van Locally-Redundant Storage (LRS) of Zone Redundant Storage (ZRS) binnen regio's die ondersteuning bieden voor Beschikbaarheidszones.
    • Een selfserviceherstel kan worden uitgevoerd met behulp van de Azure Portal- of IaC-artefacten, zoals ARM-sjablonen.
    • Er gelden verschillende beperkingen voor continue back-up.
      • De modus voor continue back-up is momenteel niet beschikbaar in een schrijfconfiguratie voor meerdere regio's.
      • Alleen Azure Cosmos DB voor NoSQL en Azure Cosmos DB voor MongoDB kunnen op dit moment worden geconfigureerd voor continue back-up.
      • Als TTL is geconfigureerd voor een container, kunnen herstelde gegevens die de TTL hebben overschreden , onmiddellijk worden verwijderd
    • Met een herstelbewerking wordt een nieuw Azure Cosmos DB-account gemaakt 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 niet omkeerbaar.

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

  • Back-ups bevatten geen firewallinstellingen, toegangsbeheerlijsten 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.
  • Azure Synapse Analytische opslaggegevens van 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 waarin periodieke en continue benaderingen niet geschikt zijn.

  • Een aangepaste aanpak brengt aanzienlijke kosten en extra administratieve overhead met zich mee, die moeten worden begrepen en zorgvuldig moeten worden beoordeeld.
    • Algemene herstelscenario's moeten worden gemodelleerd, zoals de beschadiging of verwijdering van een account, database, container op gegevensitem.
    • Er moeten schoonmaakprocedures worden geïmplementeerd om wildgroei van back-ups 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 bevat twee mogelijke opties voor het implementeren van aangepaste back-ups.

  • Azure Cosmos DB-wijzigingenfeed om gegevens naar een afzonderlijke opslagfaciliteit te schrijven.
    • Een Azure-functie of een equivalent toepassingsproces maakt gebruik van de wijzigingenfeedprocessor om te binden aan de wijzigingenfeed en items te verwerken in opslag.
  • Zowel continue als periodieke (batchgewijze) aangepaste back-ups kunnen worden geïmplementeerd met behulp van de wijzigingenfeed.
  • De Azure Cosmos DB-wijzigingenfeed bevat nog geen verwijderingen, dus 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 betrouwbaarheidsupdates biedt.
  • Azure Data Factory-connector voor Azure Cosmos DB (Azure Cosmos DB voor NoSQL- of MongoDB-API-connectors) om gegevens te kopiëren.
    • Azure Data Factory (ADF) ondersteunt handmatige uitvoering en triggers voor planning, tumblingvensters en op gebeurtenissen gebaseerde triggers.
      • 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 van de indelingsuitvoering.
    • 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 trapsgewijs effect 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.

Ontwerpaanbeveling

Azure Cosmos DB

• Gebruik Azure Cosmos DB als het primaire gegevensplatform waar de vereisten dit toestaan.

• Voor bedrijfskritieke workloadscenario's configureert u Azure Cosmos DB met een schrijfreplica binnen 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 verbruik van regionale RU's te optimaliseren.
  • De schrijfconfiguratie voor meerdere regio's brengt aanzienlijke kosten met zich mee en moet alleen prioriteit krijgen voor workloadscenario's die maximale betrouwbaarheid vereisen.

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

  • Configureer de toepassing om de lokale Azure Cosmos DB-leesreplica te gebruiken om de leesprestaties te optimaliseren.

• Selecteer een optimale hub-implementatieregio waar conflictoplossing plaatsvindt in een schrijfconfiguratie voor meerdere regio's en alle schrijfbewerkingen worden uitgevoerd in een schrijfconfiguratie 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 de vereiste mogelijkheden, zoals Beschikbaarheidszones ondersteuning.

• Configureer Azure Cosmos DB met beschikbaarheidszoneredundantie (AZ) in alle implementatieregio's met AZ-ondersteuning om tolerantie voor zonefouten binnen een regio te garanderen.

• Gebruik Azure Cosmos DB for NoSQL omdat dit de meest uitgebreide functieset biedt, met name als het gaat om het afstemmen van 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 met 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 'hops' van het netwerk.

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

• Definieer een partitioneringsstrategie voor zowel logische als fysieke partities om de gegevensdistributie te optimaliseren op basis van 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 verandert.
  • 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 ervoor te zorgen dat zelfs RU-verbruik en opslagdistributie over fysieke partities wordt gegarandeerd.
  • Voer leesquery's uit op de gepartitioneerde kolom om het RU-verbruik en de latentie te verminderen.

• Indexering is ook cruciaal 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; indexen ontwerpen 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 tot metagegevens op basis van sleutels van Azure Cosmos DB uit door de ingebouwde Azure Policy toe te passen.

• Schakel Azure Monitor in voor het verzamelen van belangrijke metrische gegevens en diagnostische logboeken, 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 wereldwijde resources binnen het toepassingsontwerp.
  • Gebruik metrische gegevens van Azure Monitor om te bepalen of verkeerspatronen van toepassingen geschikt zijn voor automatische schaalaanpassing.

• Evalueer verkeerspatronen van toepassingen om een optimale optie te selecteren voor ingerichte doorvoertypen.

  • Overweeg om ingerichte doorvoer automatisch te schalen om de vraag naar workloads automatisch af te schalen.

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

• Wanneer u AKS als rekenplatform gebruikt: selecteer voor query-intensieve workloads een AKS-knooppunt-SKU die versneld netwerken heeft ingeschakeld om latentie en CPU-jitters te verminderen.

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

• Laadniveau door het gebruik van asynchrone niet-blokkerende berichten binnen systeemstromen, waarmee updates naar Azure Cosmos DB worden geschreven.

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

• Configureer het Azure Cosmos DB-account voor continue back-ups om een fijne 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 sterk aanbevolen om herstelprocedures uit te voeren voor niet-productieresources en -gegevens, als onderdeel van de standaardvoorbereiding voor bedrijfscontinuïteit.

• 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 voor Back-up en herstel van Azure Cosmos DB toe.

  • BR-1: Zorgen voor regelmatige geautomatiseerde back-ups
  • BR-3: Valideer alle back-ups, 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, die een kolomindeling toepast 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 voor meerdere regio's mogelijk niet direct van toepassing. In dergelijke gevallen is het essentieel dat gebruikte relationele technologieën worden ontworpen en geconfigureerd om de actief-actief-aspiraties van een toepassingsontwerp in meerdere regio's te handhaven.

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

Overwegingen bij het ontwerpen

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

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

  • Sharding wordt bijvoorbeeld vaak toegepast in SaaS-platforms 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, bedreigingsbewaking 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 databases worden ondersteund in dezelfde of verschillende regio's.
  • Secundaire replica's kunnen ook worden gebruikt voor alleen-lezen querytoegang om de leesprestaties te optimaliseren.
  • Failover moet handmatig worden gestart, maar kan worden verpakt in geautomatiseerde operationele procedures.

• Azure SQL Database biedt automatische failovergroepen, 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.

• Premium- of Bedrijfskritiek servicelaagdatabasereplica's 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 beschikbaarheid van 99,99% volgens de basislijn voor alle servicelagen, maar biedt een hogere SLA van 99,995% voor de Bedrijfskritiek- of Premium-lagen in regio's die ondersteuning bieden voor beschikbaarheidszones.

  • 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 laag Azure SQL Database Bedrijfskritiek een RTO (Recovery Time Objective) van 30 seconden voor 100% van de geïmplementeerde uren.

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

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

• De 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 vanuit een geografisch redundante back-up.

Azure Database For PostgreSQL

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

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

• Hyperscale (Citus) biedt dynamische schaalbaarheid via 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 kunnen in veel gevallen werkrol-CPU's parallel gebruiken om de kosten te optimaliseren.

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

• Flexibele server biedt kostenefficiëntie voor niet-productieworkloads door de mogelijkheid om de server te stoppen/starten en een burstbare 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 reserveringskorting voor één server of hyperscale (Citus) reserveringskorting.

Ontwerpaanbeveling

• Overweeg sharding om relationele databases te partitioneren op basis van verschillende toepassings- en gegevenscontexten, zodat u door platformbeperkingen kunt navigeren, schaalbaarheid en beschikbaarheid kunt maximaliseren en fouten kunt isoleren.

  • Deze aanbeveling is vooral gangbaar wanneer in het toepassingsontwerp rekening wordt gehouden met drie of meer Azure-regio's, omdat beperkingen van relationele technologie wereldwijd gedistribueerde gegevensplatforms aanzienlijk kunnen belemmeren.
  • Sharding is niet geschikt voor alle toepassingsscenario's, dus een contextuele evaluatie is vereist.

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

Azure SQL Database

• Gebruik de Business-Critical servicelaag 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 te informeren over de vereisten voor reken- en opslagresources.
    • Overweeg gereserveerde capaciteit om mogelijke kostenoptimalisaties te bieden.

• Configureer het Zone-Redundant-implementatiemodel om Bedrijfskritiek databasereplica's binnen dezelfde regio over Beschikbaarheidszones te spreiden.

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

• Gebruik groepen voor automatische failover om transparante failover naar een secundaire regio te bieden, waarbij geo-replicatie wordt toegepast om replicatie naar extra implementatieregio's te bieden voor leesoptimalisatie en databaseredundantie.

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

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

Belangrijk

Voor toepassingen die meer dan vier implementatieregio's overwegen, moet serieus worden overwogen sharding of herstructurering van de toepassing om schrijftechnologieën voor meerdere regio's te ondersteunen, zoals Azure Cosmos DB. Als dit echter niet haalbaar is binnen het workloadscenario van de toepassing, is het raadzaam om een regio binnen één geografie te verhogen naar een primaire status die een geo-gerepliceerd exemplaar omvat naar een gelijkmatiger gedistribueerde leestoegang.

• Configureer de toepassing om replica-exemplaren voor leesquery's op te vragen 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 belastingsniveaus 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, met behulp van bewaking en waarschuwingen om waar nodig geautomatiseerde operationele actie te stimuleren.

  • Zorg ervoor dat belangrijke metrische gegevens over queryprestaties zijn opgenomen, zodat er snel actie kan worden ondernomen wanneer de service afneemt.

• Optimaliseer query's, tabellen en databases met behulp van Query Performance Insights en algemene prestatieaanbevelingen 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 versleuteling in rust.

  • Als door de klant beheerde sleutels of versleuteling aan de clientzijde (AlwaysEncrypted) is vereist, moet u ervoor zorgen dat sleutels op de juiste wijze flexibel 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 serverconfiguratie Hyperscale (Citus) om de beschikbaarheid op meerdere knooppunten te maximaliseren.

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

  • Overweeg de Reserveringskorting van Hyperscale (Citus) om mogelijke 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 end-to-end-reactietijden van de client te verbeteren voor gegevensscenario's met dynamische lagen.

Azure biedt verschillende services met toepasselijke mogelijkheden voor het opslaan van sleutelgegevensstructuren 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 ontwerp

• 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 in het toepassingsplatform zelf.

Azure Cache voor Redis

• Redis-cache is een open source NoSQL-sleutelwaarde in het geheugen.

• 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.

  • Bij implementatie 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.
  • Bij implementatie in drie Beschikbaarheidszones binnen één Azure-regio wordt een SLA voor connectiviteit van 99,99% geboden.

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

• Met geo-replicatie zijn ook kosten voor gegevensoverdracht tussen regio's 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 naar nieuwe exemplaren worden gemigreerd.

Ontwerpaanbeveling

• 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 het opslopen van de cache om te voorkomen dat gegevens worden opgelopen.

  • Overweeg om cache-items te laten verlopen wanneer de back-upgegevens worden gewijzigd.

Azure Cache voor Redis

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

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

• Implementeer replica-exemplaren met behulp van geo-replicatie in een actieve configuratie in alle overwogen 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 inzicht wanneer de cache moet worden geschaald.

• Optimaliseer de verbindingstolerantie door logica voor opnieuw proberen, time-outs te implementeren en een singleton-implementatie van de Redis-verbindingsmultiplexer te gebruiken.

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

Analytische scenario's

Het komt steeds vaker voor dat bedrijfskritieke toepassingen analytische scenario's beschouwen als een middel om extra waarde te verkrijgen uit omvattende gegevensstromen. Analytische scenario's voor toepassingen en operationele (AIOps) vormen daarom een cruciaal aspect van een zeer betrouwbaar gegevensplatform.

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

Description	Analytische	Transactioneel
Toepassing	Zeer grote hoeveelheden gegevens analyseren ('big data')	Zeer grote hoeveelheden afzonderlijke transacties verwerken
Geoptimaliseerd voor	Query's en aggregaties voor veel records lezen	CRUD-query's (Create/Read/Update/Delete) in bijna realtime op enkele records
Belangrijkste kenmerken	- Samenvoegen uit 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 toegang tot gegevens met opslag in het geheugen

Azure Synapse biedt een zakelijk analytisch platform dat relationele en niet-relationele gegevens combineert met Spark-technologieën, met behulp van ingebouwde integratie met Azure-services zoals Azure Cosmos DB om analyse van big data mogelijk te maken. De ontwerpoverwegingen en aanbevelingen in deze sectie zijn daarom gericht op optimale Azure Synapse en azure Cosmos DB-gebruik voor analytische scenario's.

Overwegingen bij het ontwerp

• Van oudsher worden grootschalige analytische scenario's mogelijk gemaakt door gegevens te extraheren in een afzonderlijk gegevensplatform dat is geoptimaliseerd voor volgende analytische query's.
  • ETL-pijplijnen (Extract, Transform en Load) worden gebruikt om gegevens te extraheren die de doorvoer verbruiken en invloed hebben op de prestaties van transactionele werkbelastingen.
  • Het af en toe uitvoeren van ETL-pijplijnen om de impact op doorvoer en prestaties te verminderen, resulteert in analytische gegevens die minder up-to-date zijn.
  • De overhead voor het ontwikkelen en onderhouden van ETL-pijplijnen neemt toe naarmate gegevenstransformaties complexer worden.
    • Als brongegevens bijvoorbeeld regelmatig worden gewijzigd of verwijderd, moeten ETL-pijplijnen rekening houden met deze wijzigingen in de doelgegevens voor analytische query's via een additieve/versiegerichte 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 indexen.

Azure Cosmos DB

• Analytische query's die worden uitgevoerd op transactionele azure Cosmos DB-gegevens, worden doorgaans samengevoegd tussen partities over grote hoeveelheden gegevens, waardoor aanzienlijke RU-doorvoer (Request Unit) wordt verbruikt, wat van invloed kan zijn op de prestaties van de omringende transactionele workloads.

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

  • Wanneer een Azure Cosmos DB-container is ingeschakeld als analytische opslag, wordt er intern een nieuwe kolomopslag gemaakt op basis van de operationele gegevens in de container. Dit kolomarchief wordt gescheiden van het rijgeoriënteerde transactiearchief voor de container behouden.
  • De bewerkingen Maken, Bijwerken en Verwijderen voor de operationele gegevens worden automatisch gesynchroniseerd met de analytische opslag, zodat er geen wijzigingenfeed of ETL-verwerking vereist is.
  • Gegevenssynchronisatie van de operationele naar de analytische opslag verbruikt geen aanvraageenheden voor doorvoer (RU's) die zijn ingericht op 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.
  • Automatische synchronisatie is het proces waarbij wijzigingen in operationele gegevens automatisch worden gesynchroniseerd met de analytische opslag. De latentie van Automatisch synchroniseren is meestal minder dan twee (2) minuten.
    • Latentie van Automatische synchronisatie kan maximaal vijf (5) minuten zijn voor een database met gedeelde doorvoer en een groot aantal containers.
    • Zodra automatische synchronisatie 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. De prijzen van analytische winkels zijn gescheiden van de prijzen van transactionele winkels.

• Met Azure Synapse Link kunt u rechtstreeks vanuit Azure Synapse query's uitvoeren op de analytische opslag van Azure Cosmos DB. Dit maakt no-ETL, Hybrid Transactional-Analytical Processing (HTAP) van Synapse mogelijk, zodat Azure Cosmos DB-gegevens in bijna realtime samen met andere analytische workloads van Synapse kunnen worden opgevraagd.

• 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. Hiermee worden de gegevens uit de analytische opslag van Azure Cosmos DB geladen en naar het gepartitioneerde Synapse-archief in het primaire opslagaccount van de Synapse-werkruimte geschreven.

• Azure Synapse Analytics SQL serverloze pools kunnen een query uitvoeren op de analytische opslag via automatisch bijgewerkte weergaven of via SELECT / OPENROWSET opdrachten.

• Azure Synapse Analytics Spark-pools kunnen een query 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 naar een toegewezen Synapse SQL-pool met behulp van Spark, zodat ingerichte Azure Synapse SQL-poolresources kunnen worden gebruikt.

• Gegevens uit de analytische opslag van Azure Cosmos DB kunnen worden opgevraagd met Azure Synapse Spark.

  • Met Spark-notebooks kunt u combinaties van Spark-dataframes gebruiken om analytische gegevens van Azure Cosmos DB samen te voegen en te transformeren met andere gegevenssets, en andere geavanceerde Synapse Spark-functionaliteit te gebruiken, waaronder het schrijven van getransformeerde gegevens naar andere archieven of het trainen van AIOps Machine Learning-modellen.

• De Azure Cosmos DB-wijzigingenfeed 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 tijdreeksanalyses.

  • Azure Synapse maakt gebruik van gekoppelde services om verbindingen met andere services, zoals Azure Storage, te definiëren.
  • Gegevens kunnen worden opgenomen in Synapse Analytics via Copy-activiteit van ondersteunde bronnen. Dit maakt gegevensanalyse in Synapse mogelijk zonder dat dit van invloed is op het brongegevensarchief, maar voegt overhead toe aan tijd, kosten en latentie 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 ondersteunde opslag voor Synapse en geëxporteerde Log Analytics-gegevens kunnen 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 ter ondersteuning van business intelligence en andere geaggregeerde analytische gebruiksvoorbeelden.

Ontwerpaanbeveling

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

Application Analytics

• Gebruik Azure Synapse Link met de analytische opslag van Azure Cosmos DB 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 azure Cosmos DB-gegevens op te vragen. Gebruik een verbindingsreeks met een Azure Cosmos DB-sleutel met het kenmerk Alleen-lezen.

• Geef prioriteit 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 voor de werkruimte om de gegevens en metagegevens van de Synapse-werkruimtecatalogus 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 de gegevens en metagegevens van de Synapse-werkruimte.
    • Gebruik niet een van de regionale of globale Azure Storage-accounts waarin operationele gegevens worden verzonden.

Volgende stap

Bekijk de overwegingen voor netwerkoverwegingen.

Netwerk en connectiviteit