Maximaal beschikbare webtoepassing voor meerdere regio's

Deze voorbeeldarchitectuur is gebaseerd op de voorbeeldarchitectuur van de basiswebtoepassing en breidt deze uit om het volgende weer te geven:

• Bewezen procedures voor het verbeteren van schaalbaarheid en prestaties in een Azure-app Service-webtoepassing
• Een Azure-app-servicetoepassing uitvoeren in meerdere regio's om hoge beschikbaarheid te bereiken

Architectuur

Een Visio-bestand van deze architectuur downloaden.

Workflow

Deze werkstroom heeft betrekking op de aspecten van meerdere regio's van de architectuur en bouwt voort op de Basic-webtoepassing.

• Primaire en secundaire regio. In deze architectuur worden twee regio's gebruikt voor hogere beschikbaarheid. De toepassing wordt geïmplementeerd in elke regio. Het netwerkverkeer wordt gewoonlijk gerouteerd naar de primaire regio. Als de primaire regio niet beschikbaar is, wordt het verkeer gerouteerd naar de secundaire regio.
• Front Door. Azure Front Door is de aanbevolen load balancer voor implementaties in meerdere regio's. Het is geïntegreerd met Web Application Firewall (WAF) om te beschermen tegen veelvoorkomende aanvallen en maakt gebruik van de systeemeigen functionaliteit voor het opslaan van inhoud van Front Door. In deze architectuur wordt Front Door geconfigureerd voor prioriteitsroutering , waarmee al het verkeer naar de primaire regio wordt verzonden, tenzij het niet meer beschikbaar is. Als de primaire regio niet beschikbaar is, stuurt Front Door al het verkeer naar de secundaire regio.
• Geo-replicatie van opslagaccounts, SQL Database en/of Azure Cosmos DB.

Onderdelen

Belangrijke technologieën die worden gebruikt om deze architectuur te implementeren:

• Microsoft Entra ID is een cloudservice voor identiteits- en toegangsbeheer waarmee werknemers toegang hebben tot cloud-apps die zijn ontwikkeld voor uw organisatie.
• Azure DNS is een service voor het hosten van DNS-domeinen die naamomzetting biedt met behulp van de Microsoft Azure-infrastructuur. Door uw domeinen in Azure te hosten, kunt u uw DNS-records met dezelfde referenties, API's, hulpprogramma's en facturering beheren als voor uw andere Azure-services. Als u een aangepaste domeinnaam wilt gebruiken (zoals contoso.com), maakt u DNS-records die de aangepaste domeinnaam toewijzen aan het IP-adres. Zie Configure a custom domain name in Azure App Service (Een aangepaste domeinnaam configureren in Azure App Service) voor meer informatie.
• Azure Content Delivery Network is een wereldwijde oplossing voor het leveren van inhoud met hoge bandbreedte door deze in de cache op strategisch geplaatste fysieke knooppunten over de hele wereld te plaatsen.
• Azure Front Door is een load balancer van laag 7. In deze architectuur worden HTTP-aanvragen doorgestuurd naar de webfront-end. Front Door biedt ook een Web Application Firewall (WAF) die de toepassing beschermt tegen veelvoorkomende aanvallen en beveiligingsproblemen. Front Door wordt ook gebruikt voor een CDN-oplossing (Content Delivery Network ) in dit ontwerp.
• Azure-app Service is een volledig beheerd platform voor het maken en implementeren van cloudtoepassingen. Hiermee kunt u een set rekenresources definiëren voor een web-app om uit te voeren, web-apps te implementeren en implementatiesites te configureren.
• Azure Function Apps kan worden gebruikt om achtergrondtaken uit te voeren. Functies worden aangeroepen door een trigger, zoals een timergebeurtenis of een bericht dat in de wachtrij wordt geplaatst. Gebruik Durable Functions voor langlopende stateful taken.
• Azure Storage is een cloudopslagoplossing voor moderne scenario's voor gegevensopslag, die maximaal beschikbaar, zeer schaalbaar, duurzaam en veilig opslag biedt voor verschillende gegevensobjecten in de cloud.
• Azure Redis Cache is een krachtige cachingservice die een in-memory gegevensarchief biedt voor het sneller ophalen van gegevens, op basis van de opensource-implementatie redis-cache.
• Azure SQL Database is een relationele database-as-a-service in de cloud. SQL Database deelt de codebasis met de database-engine van Microsoft SQL Server.
• Azure Cosmos DB is een wereldwijd gedistribueerde, volledig beheerde, lage latentie, multimodel- en multiquery-API-database voor het beheren van gegevens op grote schaal.
• Azure Cognitive Search kan worden gebruikt om zoekfunctionaliteit toe te voegen, zoals zoeksuggesties, fuzzy zoeken en taalspecifieke zoekopdrachten. Azure Search wordt doorgaans in combinatie met andere gegevensopslag gebruikt, met name als de primaire gegevensopslag strikte consistentie vereist. In deze benadering slaat u de gezaghebbende gegevens op in de andere gegevensopslag en de zoekindex in Azure Search. Azure Search kan ook worden gebruikt om uit meerdere locaties voor gegevensopslag één zoekindex te consolideren.

Scenariodetails

Er zijn verschillende algemene benaderingen voor het bereiken van hoge beschikbaarheid in verschillende regio's:

• Actief/passief met hot stand-by: verkeer gaat naar de ene regio, terwijl de andere wacht op hot stand-by. Hot stand-by betekent dat de App Service in de secundaire regio wordt toegewezen en altijd wordt uitgevoerd.

• Actief/passief met koude stand-by: verkeer gaat naar de ene regio, terwijl de andere wacht op koude stand-by. Koude stand-by betekent dat de App Service in de secundaire regio pas wordt toegewezen als deze nodig is voor failover. Deze methode is goedkoper qua uitvoering, maar het duurt langer om het systeem weer online te brengen na uitval.

• Actief/actief: beide regio's zijn actief en aanvragen worden verdeeld over de verschillende regio's. Als één regio niet meer beschikbaar is, wordt deze uit de rotatie gehaald.

Deze verwijzing richt zich op actief/passief met hot stand-by.

Potentiële gebruikscases

Deze gebruiksvoorbeelden kunnen profiteren van een implementatie met meerdere regio's:

• Ontwerp een bedrijfscontinuïteits- en noodherstelplan voor LoB-toepassingen.

• Implementeer bedrijfskritieke toepassingen die worden uitgevoerd op Windows of Linux.

• Verbeter de gebruikerservaring door toepassingen beschikbaar te houden.

Aanbevelingen

Uw vereisten kunnen afwijken van de architectuur die hier wordt beschreven. Gebruik de aanbevelingen in deze sectie als uitgangspunt.

Regioparen

Elke Azure-regio is gekoppeld aan een andere regio binnen dezelfde geografie. Over het algemeen kiest u regioparen uit dezelfde regio (bijvoorbeeld VS - oost 2 en VS - centraal). Dit heeft de volgende voordelen:

• Als er sprake is van een grote storing, krijgt herstel van ten minste één regio van elk paar prioriteit.
• Geplande Azure-systeemupdates worden na elkaar uitgerold voor gekoppelde regio's om eventuele downtime tot een minimum te beperken.
• In de meeste gevallen bevinden regioparen zich binnen dezelfde geografie om te voldoen aan gegevenslocatievereisten.

Controleer wel of alle Azure-services die nodig zijn voor uw toepassing in beide regio's worden ondersteund. Raadpleeg Services per regio. Zie Bedrijfscontinuïteit en herstel na noodgevallen (BCDR): gekoppelde Azure-regio's voor meer informatie over regioparen.

Resourcegroepen

Overweeg om de primaire regio, secundaire regio en Front Door in afzonderlijke resourcegroepen te plaatsen. Met deze toewijzing kunt u de resources beheren die in elke regio zijn geïmplementeerd als één verzameling.

App Service-apps

We raden aan om de webtoepassing en de web-API te maken als afzonderlijke App Service-apps. Op die manier kunt u ze in afzonderlijke App Service-abonnementen uitvoeren, zodat ze afzonderlijk kunnen worden geschaald. Als u aanvankelijk geen behoefte hebt aan een dergelijke schaalbaarheid, kunt u de apps in hetzelfde abonnement implementeren en ze desgewenst later verplaatsen naar afzonderlijke abonnementen.

Front Door-configuratie

Routering. Front Door ondersteunt verschillende routeringsmechanismen. Gebruik prioriteitsroutering voor het scenario dat in dit artikel wordt beschreven. Met deze instelling verzendt Front Door alle aanvragen naar de primaire regio, tenzij het eindpunt voor die regio onbereikbaar wordt. Op dat moment wordt automatisch een Failover-schakeling naar de secundaire regio uitgevoerd. Stel de oorspronkelijke pool in met verschillende prioriteitswaarden, 1 voor de actieve regio en 2 of hoger voor de stand-by- of passieve regio.

Statustest. Front Door gebruikt een HTTPS-test om de beschikbaarheid van elke back-end te bewaken. De test geeft Front Door een pass/fail-test voor failover naar de secundaire regio. De test wordt uitgevoerd door een aanvraag naar een opgegeven URL-pad te verzenden. Als deze aanvraag niet resulteert in een 200-respons binnen een time-outperiode, mislukt de test. U kunt de frequentie van de statustest, het aantal monsters dat is vereist voor evaluatie en het aantal geslaagde steekproeven configureren dat is vereist om de oorsprong als gezond te markeren. Als Front Door de oorsprong als gedegradeerd markeert, wordt er een failover uitgevoerd naar de andere oorsprong. Zie Statustests voor meer informatie.

Maak als best practice een statustestpad in uw toepassingsoorsprong waarmee de algehele status van de toepassing wordt gerapporteerd. Deze statustest moet kritieke afhankelijkheden controleren, zoals de App Service-apps, de opslagwachtrij en SQL Database. Anders kan de test een goede oorsprong rapporteren wanneer kritieke onderdelen van de toepassing daadwerkelijk mislukken. Aan de andere kant moet u de statustest ook niet gebruiken om services met een lagere prioriteit te controleren. Bijvoorbeeld: als een e-mailservice uitvalt, kan de toepassing overschakelen naar een tweede provider of e-mailberichten pas later verzenden. Zie Het patroon Statuseindpuntbewaking voor meer informatie over dit ontwerppatroon.

Het beveiligen van oorsprongen van internet is een essentieel onderdeel van het implementeren van een openbaar toegankelijke app. Raadpleeg de implementatie van inkomend verkeer voor netwerkbeveiliging voor meer informatie over de aanbevolen ontwerp- en implementatiepatronen van Microsoft voor het beveiligen van de binnenkomende communicatie van uw app met Front Door.

CDN. Gebruik de systeemeigen CDN-functionaliteit van Front Door om statische inhoud in de cache op te cachen. Het belangrijkste voordeel van een CDN is dat u de latentie voor gebruikers vermindert, omdat inhoud wordt gecached op een randserver die geografisch dicht bij de gebruiker is gelegen. CDN kan ook de belasting van de toepassing verminderen, omdat het betreffende verkeer niet door de toepassing wordt verwerkt. Front Door biedt bovendien dynamische siteversnelling , zodat u een betere algehele gebruikerservaring voor uw web-app kunt bieden dan beschikbaar zou zijn met alleen statische inhoud in cache opslaan.

SQL Database

Gebruik actieve geo-replicatie en groepen voor automatische failover om uw databases tolerant te maken. Met actieve geo-replicatie kunt u uw databases vanuit de primaire regio repliceren naar een of meer (maximaal vier) andere regio's. Groepen voor automatische failover bouwen voort op actieve geo-replicatie door een failover naar een secundaire database uit te voeren zonder codewijzigingen in uw apps. Failovers kunnen handmatig of automatisch worden uitgevoerd op basis van beleidsdefinities die u maakt. Als u groepen voor automatische failover wilt gebruiken, moet u de verbindingsreeksen configureren met de failover verbindingsreeks automatisch gemaakt voor de failovergroep, in plaats van de verbindingsreeks s van de afzonderlijke databases.

Azure Cosmos DB

Azure Cosmos DB ondersteunt geo-replicatie tussen regio's in een actief-actief patroon met meerdere schrijfregio's. U kunt ook één regio aanwijzen als de beschrijfbare regio en de andere als alleen-lezen replica's. Als er een regionale storing is, kunt u een failover uitvoeren door een andere regio te selecteren als de schrijfregio. De client-SDK verzendt automatisch schrijfaanvragen naar de huidige schrijfregio, dus u hoeft de configuratie van de client niet bij te werken na een failover. Zie Globale gegevensdistributie met Azure Cosmos DB voor meer informatie.

Storage

Gebruik Geografisch redundante opslag met leestoegang (RA-GRS) voor Azure Storage. Met RA-GRS worden de gegevens gerepliceerd naar een secundaire regio. U hebt alleen-lezentoegang tot de gegevens in de secundaire regio via een afzonderlijk eindpunt. Door de gebruiker geïnitieerde failover naar de secundaire regio wordt ondersteund voor geografisch gerepliceerde opslagaccounts. Als u een failover van een opslagaccount initieert, worden DNS-records automatisch bijgewerkt om het secundaire opslagaccount het nieuwe primaire opslagaccount te maken. Failovers moeten alleen worden uitgevoerd wanneer u denkt dat dit nodig is. Deze vereiste wordt gedefinieerd door het noodherstelplan van uw organisatie en u moet rekening houden met de gevolgen, zoals beschreven in de sectie Overwegingen hieronder.

Als er sprake is van een regionale storing of noodgeval, kan het Azure Storage-team besluiten om een geo-failover uit te voeren naar de secundaire regio. Voor deze typen failovers is er geen actie van de klant vereist. Failback naar de primaire regio wordt ook beheerd door het Azure-opslagteam in deze gevallen.

In sommige gevallen is objectreplicatie voor blok-blobs een voldoende replicatieoplossing voor uw workload. Met deze replicatiefunctie kunt u afzonderlijke blok-blobs uit het primaire opslagaccount kopiëren naar een opslagaccount in uw secundaire regio. Voordelen van deze aanpak zijn een gedetailleerde controle over welke gegevens worden gerepliceerd. U kunt een replicatiebeleid definiëren voor gedetailleerdere controle over de typen blok-blobs die worden gerepliceerd. Voorbeelden van beleidsdefinities zijn, maar zijn niet beperkt tot:

• Alleen blok-blobs die na het maken van het beleid worden toegevoegd, worden gerepliceerd
• Alleen blok-blobs die na een bepaalde datum en tijd zijn toegevoegd, worden gerepliceerd
• Alleen blok-blobs die overeenkomen met een bepaald voorvoegsel worden gerepliceerd.

Voor dit scenario wordt naar Queue Storage verwezen als een alternatieve berichtoptie voor Azure Service Bus. Als u echter wachtrijopslag gebruikt voor uw berichtenoplossing, zijn de bovenstaande richtlijnen ten opzichte van geo-replicatie hier van toepassing, omdat wachtrijopslag zich in opslagaccounts bevindt. Het is echter belangrijk om te begrijpen dat berichten niet worden gerepliceerd naar de secundaire regio en dat hun status niet kan worden gebruikt vanuit de regio.

Azure Service Bus

Gebruik de Premium-laag voor uw naamruimten om te profiteren van de hoogste tolerantie die wordt aangeboden voor Azure Service Bus. De Premium-laag maakt gebruik van beschikbaarheidszones, waardoor uw naamruimten bestand zijn tegen storingen in datacenters. Als er sprake is van een wijdverspreide ramp die van invloed is op meerdere datacenters, kan de functie geo-noodherstel die deel uitmaakt van de Premium-laag u helpen bij het herstellen. De functie Voor herstel na noodgevallen zorgt ervoor dat de volledige configuratie van een naamruimte (wachtrijen, onderwerpen, abonnementen en filters) continu wordt gerepliceerd van een primaire naamruimte naar een secundaire naamruimte wanneer deze is gekoppeld. Hiermee kunt u op elk gewenst moment een eenmalige failover van de primaire naar de secundaire initiëren. Tijdens de failoververplaatsing wordt de gekozen aliasnaam voor de naamruimte opnieuw naar de secundaire naamruimte verplaatst en wordt de koppeling verbroken. De failover is bijna onmiddellijk nadat deze is gestart.

Azure Cognitive Search

In Cognitive Search wordt de beschikbaarheid bereikt via meerdere replica's, terwijl bcdr (bedrijfscontinuïteit en herstel na noodgevallen) wordt bereikt via meerdere zoekservices.

In Cognitive Search zijn replica's kopieën van uw index. Als u meerdere replica's hebt, kan Azure Cognitive Search computer opnieuw opstarten en onderhoud uitvoeren op de ene replica, terwijl de uitvoering van query's op andere replica's wordt voortgezet. Zie Replica's en partities toevoegen of verminderen voor meer informatie over het toevoegen van replica's.

U kunt Beschikbaarheidszones gebruiken met Azure Cognitive Search door twee of meer replica's toe te voegen aan uw zoekservice. Elke replica wordt in een andere beschikbaarheidszone binnen de regio geplaatst.

Raadpleeg voor BCDR-overwegingen de documentatie over meerdere services in afzonderlijke geografische regio's .

Azure Cache voor Redis

Hoewel alle lagen van Azure Cache voor Redis Standard-replicatie bieden voor hoge beschikbaarheid, wordt de Premium- of Enterprise-laag aanbevolen om een hoger niveau van tolerantie en herstelmogelijkheden te bieden. Bekijk de functies en opties voor hoge beschikbaarheid en herstel na noodgevallen voor een volledige lijst met tolerantie- en herstelfuncties en -opties voor deze lagen. Uw bedrijfsvereisten bepalen welke laag het meest geschikt is voor uw infrastructuur.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Overzicht van de betrouwbaarheidspijler voor meer informatie. Houd rekening met deze punten bij het ontwerpen voor hoge beschikbaarheid in verschillende regio's.

Azure Front Door

Azure Front Door voert automatisch een failover uit als de primaire regio niet beschikbaar is. Wanneer front Door een failover uitvoert, is er een periode (meestal ongeveer 20-60 seconden) wanneer clients de toepassing niet kunnen bereiken. Hoe lang dit duurt, is afhankelijk van de volgende factoren:

• Frequentie van statustests. Hoe vaker de statustests worden verzonden, hoe sneller Front Door downtime kan detecteren of de oorsprong in orde komt.
• Configuratie van voorbeeldgrootte. Deze configuratie bepaalt hoeveel voorbeelden vereist zijn voor de statustest om te detecteren dat de primaire oorsprong onbereikbaar is geworden. Als deze waarde te laag is, kunt u fout-positieven krijgen van onregelmatige problemen.

Front Door is een mogelijk punt van mislukken in het systeem. Als de service mislukt, hebben clients tijdens de downtime geen toegang tot uw toepassing. Controleer de service level agreement (SLA) voor Front Door en bepaal of het gebruik van alleen Front Door voldoet aan uw zakelijke vereisten voor hoge beschikbaarheid. Als dat niet het geval is, overweeg dan een andere oplossing voor het beheer van verkeer toe te voegen als failback. Als de Front Door-service uitvalt, wijzigt u de adresbronrecords (CNAME-records) in DNS zó, dat deze verwijzen naar de andere verkeerbeheerservice. Deze stap moet handmatig worden uitgevoerd en uw toepassing pas weer beschikbaar als de DNS-wijzigingen zijn doorgegeven.

De Azure Front Door Standard- en Premium-laag combineren de mogelijkheden van Azure Front Door (klassiek), Azure CDN Standard van Microsoft (klassiek) en Azure WAF in één platform. Het gebruik van Azure Front Door Standard of Premium vermindert de storingspunten en maakt verbeterde controle, bewaking en beveiliging mogelijk. Zie Overzicht van de Azure Front Door-laag voor meer informatie.

SQL Database

De beoogde herstelpuntdoelstelling (RPO) en de geschatte beoogde hersteltijd (RTO) voor SQL Database worden beschreven in Overzicht van bedrijfscontinuïteit met Azure SQL Database.

Houd er rekening mee dat actieve geo-replicatie de kosten van elke gerepliceerde database effectief verdubbelt. Sandbox-, test- en ontwikkelingsdatabases worden doorgaans niet aanbevolen voor replicatie.

Azure Cosmos DB

RPO en RTO (Recovery Time Objective) voor Azure Cosmos DB kunnen worden geconfigureerd via de gebruikte consistentieniveaus, die een afweging bieden tussen beschikbaarheid, duurzaamheid van gegevens en doorvoer. Azure Cosmos DB biedt minimaal RTO van 0 voor een ontspannen consistentieniveau met meerdere masters of een RPO van 0 voor een sterke consistentie met één master. Zie Consistentieniveaus en duurzaamheid van gegevens in Azure Cosmos DB voor meer informatie over azure Cosmos DB-consistentieniveaus.

Storage

RA-GRS-opslag biedt duurzame opslag, maar het is belangrijk om rekening te houden met de volgende factoren bij het uitvoeren van een failover:

• Verwacht gegevensverlies: gegevensreplicatie naar de secundaire regio wordt asynchroon uitgevoerd. Als een geo-failover wordt uitgevoerd, moet daarom worden verwacht dat er gegevensverlies optreedt als wijzigingen in het primaire account niet volledig zijn gesynchroniseerd met het secundaire account. U kunt de eigenschap Laatste synchronisatietijd van het secundaire opslagaccount controleren om te zien wanneer de gegevens uit de primaire regio voor het laatst naar de secundaire regio zijn geschreven.

• Plan uw beoogde hersteltijd (RTO) dienovereenkomstig: Failover naar de secundaire regio duurt doorgaans ongeveer één uur, dus uw DR-plan moet rekening houden met deze informatie bij het berekenen van uw RTO-parameters.

• Plan uw failback zorgvuldig: het is belangrijk om te weten dat wanneer een opslagaccount een failover uitvoert, de gegevens in het oorspronkelijke primaire account verloren gaan. Het uitvoeren van een failback naar de primaire regio zonder zorgvuldige planning is riskant. Nadat de failover is voltooid, wordt de nieuwe primaire, in de failoverregio, geconfigureerd voor lokaal redundante opslag (LRS). U moet deze handmatig opnieuw configureren als geografisch gerepliceerde opslag om replicatie naar de primaire regio te initiëren en vervolgens voldoende tijd te geven om de accounts te laten synchroniseren.

• Tijdelijke fouten, zoals een netwerkstoring, activeren geen opslagfailover. Ontwerp uw toepassing zo, dat deze tolerant is bij tijdelijke fouten. Risicobeperkingsopties zijn onder andere:

  • Lezen van de secundaire regio.
  • Tijdelijk overschakelen naar een ander opslagaccount voor nieuwe schrijfbewerkingen (bijvoorbeeld om berichten in de wachtrij te plaatsen).
  • Gegevens van de secundaire regio kopiëren naar een ander opslagaccount.
  • Verminderde functionaliteit bieden totdat het systeem is hersteld (failback is uitgevoerd).

Zie voor meer informatie Wat te doen in het geval van een Azure Storage-storing.

Raadpleeg de vereisten en opmerkingen voor documentatie over objectreplicatie voor overwegingen bij het gebruik van objectreplicatie voor blok-blobs.

Azure Service Bus

Het is belangrijk om te weten dat de functie geo-noodherstel die is opgenomen in de premium Azure Service Bus-laag, directe continuïteit van bewerkingen met dezelfde configuratie mogelijk maakt. De berichten in wachtrijen of onderwerpabonnementen of wachtrijen met dode letters worden echter niet gerepliceerd. Daarom is een risicobeperkingsstrategie vereist om een soepele failover naar de secundaire regio te garanderen. Raadpleeg de belangrijke punten voor overwegingen en overwegingen voor herstel na noodgevallen voor een gedetailleerde beschrijving van andere overwegingen en risicobeperkingsstrategieën.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

Beperk inkomend verkeer Configureer de toepassing om alleen verkeer van Front Door te accepteren. Dit zorgt ervoor dat al het verkeer via de WAF gaat voordat de app wordt bereikt. Zie Hoe kan ik de toegang tot mijn back-end vergrendelen voor alleen Azure Front Door voor meer informatie?

Cross-Origin Resource Sharing (CORS) Als u een website en web-API als afzonderlijke apps maakt, kan de website geen AJAX-aanroepen aan de clientzijde naar de API maken, tenzij u CORS inschakelt.

App Services heeft ingebouwde ondersteuning voor CORS. U hoeft geen enkele toepassingscode te schrijven. Zie Consume an API app from JavaScript using CORS (Een JavaScript-API-app gebruiken met CORS). Voeg de website toe aan de lijst met toegestane oorsprongen voor de API.

SQL Database-versleuteling : gebruik Transparent Data Encryption als u data-at-rest in de database wilt versleutelen. Deze functie voert realtime versleuteling en ontsleuteling van een volledige database uit (inclusief back-ups en transactielogboekbestanden) en vereist geen wijzigingen in de toepassing. Versleuteling zorgt voor enige vertraging. Daarom doet u er verstandig aan om de gegevens die moeten worden beveiligd, in een afzonderlijke database op te nemen en alleen voor deze database versleuteling in te schakelen.

Identiteit Wanneer u identiteiten definieert voor de onderdelen in deze architectuur, gebruikt u waar mogelijk door het systeem beheerde identiteiten om uw behoeften te beperken voor het beheren van referenties en de risico's die inherent zijn aan het beheren van referenties. Als het niet mogelijk is om door het systeem beheerde identiteiten te gebruiken, moet u ervoor zorgen dat elke door de gebruiker beheerde identiteit in slechts één regio bestaat en nooit wordt gedeeld over regiogrenzen.

Servicefirewalls Bij het configureren van de servicefirewalls voor de onderdelen, moet u ervoor zorgen dat alleen de lokale services toegang hebben tot de services en dat de services alleen uitgaande verbindingen toestaan, die expliciet vereist zijn voor replicatie en toepassingsfunctionaliteit. Overweeg om Azure Private Link te gebruiken voor verdere verbeterde controle en segmentatie. Zie Basislijn voor maximaal beschikbare zone-redundante webtoepassing voor meer informatie over het beveiligen van webtoepassingen.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

Caching : Gebruik caching om de belasting te verminderen van servers die inhoud verwerken die niet vaak wordt gewijzigd. Elke rendercyclus van een pagina kan van invloed zijn op de kosten omdat deze rekenkracht, geheugen en bandbreedte verbruikt. Deze kosten kunnen aanzienlijk worden verlaagd door caching te gebruiken, met name voor statische inhoudsservices, zoals JavaScript-apps met één pagina en mediastreaming-inhoud.

Als uw app statische inhoud heeft, gebruikt u CDN om de belasting op de front-endservers te verminderen. Gebruik Azure Cache voor Redis voor gegevens die niet vaak veranderen.

Staatloze apps die zijn geconfigureerd voor automatisch schalen, zijn rendabeler dan stateful apps. Voor een ASP.NET toepassing die gebruikmaakt van sessiestatus, slaat u deze op in het geheugen met Azure Cache voor Redis. Zie ASP.NET Session State Provider voor Azure Cache voor Redis voor meer informatie. Een andere optie is om Azure Cosmos DB te gebruiken als een back-endstatusarchief via een sessiestatusprovider. Zie Azure Cosmos DB gebruiken als een ASP.NET sessiestatus en cacheprovider.

Functions Overweeg om een functie-app in een toegewezen App Service-plan te plaatsen, zodat achtergrondtaken niet worden uitgevoerd op dezelfde exemplaren die HTTP-aanvragen verwerken. Als achtergrondtaken af en toe worden uitgevoerd, kunt u overwegen een verbruiksabonnement te gebruiken, dat wordt gefactureerd op basis van het aantal uitvoeringen en resources dat wordt gebruikt, in plaats van per uur.

Zie de kostensectie in het Microsoft Azure Well-Architected Framework voor meer informatie.

Gebruik de prijscalculator om de kosten te schatten. Deze aanbevelingen in deze sectie kunnen u helpen om de kosten te verlagen.

Azure Front Door

Azure Front Door-facturering heeft drie prijscategorieën: uitgaande gegevensoverdrachten, binnenkomende gegevensoverdrachten en routeringsregels. Zie prijzen voor Azure Front Door voor meer informatie. De prijsgrafiek omvat niet de kosten voor toegang tot gegevens van de oorspronkelijke services en overdracht naar Front Door. Deze kosten worden gefactureerd op basis van kosten voor gegevensoverdracht, zoals beschreven in prijsinformatie voor bandbreedte.

Azure Cosmos DB

Er zijn twee factoren die de prijzen van Azure Cosmos DB bepalen:

• De ingerichte doorvoer of aanvraageenheden per seconde (RU/s).

  Er zijn twee typen doorvoer die kunnen worden ingericht in Azure Cosmos DB, standaard en automatisch schalen. Standaarddoorvoer wijst de resources toe die nodig zijn om de RU/s te garanderen die u opgeeft. Voor automatische schaalaanpassing richt u de maximale doorvoer in en schaalt Azure Cosmos DB direct omhoog of omlaag, afhankelijk van de belasting, met minimaal 10% van de maximale doorvoer voor automatische schaalaanpassing. Standaarddoorvoer wordt gefactureerd voor de ingerichte doorvoer per uur. Doorvoer automatisch schalen wordt gefactureerd voor de maximale verbruikte doorvoer per uur.

• Verbruikte opslag. U wordt een vast tarief gefactureerd voor de totale hoeveelheid opslagruimte (GB's) die wordt verbruikt voor gegevens en de indexen voor een bepaald uur.

Raadpleeg de kostensectie in Microsoft Azure Well-Architected Framework voor meer informatie.

Prestatie-efficiëntie

Een groot voordeel van Azure App Service is de mogelijkheid om uw toepassing te schalen op basis van de belasting. Hier volgen enkele overwegingen om rekening mee te houden bij het plannen van het schalen van uw toepassing.

App Service-app

Als uw oplossing verschillende App Service-apps bevat, kunt u overwegen om deze te implementeren in afzonderlijke App Service-abonnementen. Dit stelt u in staat de apps afzonderlijk te schalen, omdat ze worden uitgevoerd op afzonderlijke exemplaren.

SQL Database

Verhoog de schaalbaarheid van een SQL-database door sharding toe te passen. Sharding houdt in dat u de database horizontaal partitioneert. Via sharding kunt u de database horizontaal uitschalen met behulp van hulpprogramma's voor elastische databases. Mogelijke voordelen van sharding zijn:

• Een betere transactiedoorvoer.
• Query's kunnen sneller worden uitgevoerd op een subset van gegevens.

Azure Front Door

Front Door kan SSL-offload uitvoeren en vermindert ook het totale aantal TCP-verbindingen met de back-endweb-app. Dit verbetert de schaalbaarheid omdat de web-app een kleiner volume SSL-handshakes en TCP-verbindingen beheert. Deze prestatieverbeteringen zijn ook van toepassing als u de aanvragen doorstuurt naar de web-app als HTTPS, vanwege het hoge niveau van het hergebruik van de verbinding.

Azure Search

Met Azure Search elimineert u de overhead voor het uitvoeren van complexe gegevenszoekopdrachten vanuit de primaire gegevensopslag en beschikt u over de schaalbaarheid die u nodig hebt om ook grotere workloads te verwerken. Zie Scale resource levels for query and indexing workloads in Azure Search (Resourceniveaus schalen voor query- en indexeringsworkloads in Azure Search).

Operationele uitmuntendheid

Operationele uitmuntendheid verwijst naar de operationele processen die een toepassing implementeren en blijven werken in productie en is een uitbreiding van de richtlijnen voor de betrouwbaarheid van het goed ontworpen framework. Deze richtlijnen bieden een gedetailleerd overzicht van het ontwerpen van tolerantie in uw toepassingsframework om ervoor te zorgen dat uw workloads beschikbaar zijn en kunnen worden hersteld na fouten op elke schaal. Een belangrijk tenet van deze benadering is om uw toepassingsinfrastructuur zo te ontwerpen dat deze maximaal beschikbaar is, optimaal in meerdere geografische regio's, zoals dit ontwerp illustreert.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

• Arvind Boggaram Pandurangaiah Setty | Senior Consultant

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

• Uitgebreide informatie over Azure Front Door - verkeersrouteringsmethoden

• Statustests maken die de algehele status van de toepassing rapporteren op basis van eindpuntbewakingspatronen

• Azure SQL-groepen voor automatische failover inschakelen

• Bedrijfscontinuïteit en herstel na noodgevallen garanderen met behulp van gekoppelde Azure-regio's

Verwante resources

• Een toepassing met meerdere regio's met meerdere regio's is een vergelijkbaar scenario. Er wordt een N-tier-toepassing weergegeven die wordt uitgevoerd in meerdere Azure-regio's

• Ontwerprichtlijnen voor Azure-toepassingen