Algemene webtoepassing

App Service
Key Vault
Monitor
SQL Database
Web Apps

Deze referentiearchitectuur toont bewezen procedures voor een webtoepassing die gebruikmaakt van Azure App Service en Azure SQL Database.

Referentiearchitectuur voor een eenvoudige webtoepassing in Azure

Een Visio-bestand van deze architectuur downloaden.

Referentie-implementatie

Deze architectuur bevat een Azure App Service-plan en een lege toepassing, Azure SQL Database, Azure Key Vault voor het opslaan van de database-connection string en Azure Monitor voor logboekregistratie, bewaking en waarschuwingen.

Gebruik de volgende opdracht om een resourcegroep voor de implementatie te maken. Klik op de knop Uitproberen om een ingesloten shell te gebruiken.

az group create --name basic-web-app --location eastus

Voer de volgende opdracht uit om de webtoepassing en ondersteunende infrastructuur te implementeren. Voer een gebruikersnaam en wachtwoord in wanneer u hier om wordt gevraagd. Deze waarden worden gebruikt voor toegang tot het Azure SQL Database exemplaar.

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

Zie de ARM-sjablonen die worden gebruikt om deze oplossing te implementeren voor gedetailleerde informatie en aanvullende implementatieopties.

Architectuur

De architectuur bestaat uit de volgende onderdelen.

App Service:een App Service-abonnement biedt de beheerde virtuele machines (VM's) die als host voor uw app worden gebruikt. Alle apps die zijn gekoppeld aan een plan, worden uitgevoerd op dezelfde VM-instanties.

App Service app:Azure App Service is een volledig beheerd platform voor het maken en implementeren van cloudtoepassingen.

Implementatiesleuven:met een implementatiesleuf kunt u een implementatie faseer en deze vervolgens wisselen met de productie-implementatie. Op deze manier voorkomt u rechtstreekse implementatie op de productiesite. Zie de sectie Beheerbaarheid voor specifieke aanbevelingen.

IP-adres:de App Service app heeft een openbaar IP-adres en een domeinnaam. De domeinnaam is een subdomein van azurewebsites.net, zoals contoso.azurewebsites.net.

Azure DNS:Azure DNS is een hostingservice voor DNS-domeinen die naamresolutie biedt met behulp 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. Maak DNS-records die de aangepaste domeinnaam toewijzen aan het IP-adres, om een aangepaste domeinnaam te gebruiken (zoals contoso.com). Zie Configure a custom domain name in Azure App Service (Een aangepaste domeinnaam configureren in Azure App Service) voor meer informatie.

Azure SQL Database: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. Afhankelijk van uw toepassingsvereisten kunt u ook Azure Database for MySQL ofAzure Database for PostgreSQL. Dit zijn volledig beheerde databaseservices op basis van de opensource MySQL Server- en Postgres-database-engines.

Aanbevelingen

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

App Service-plan

Gebruik de lagen Gratis en Gedeeld (preview) voor testdoeleinden, omdat de gedeelde resources niet kunnen worden uitschalen. De twee lagen bieden verschillende opties binnen uw budget. Voer uw productieworkload uit in de lagen Basic,Standarden Premium, omdat de app wordt uitgevoerd op toegewezen instanties van virtuele machines en resources heeft toegewezen die kunnen worden uitschalen. App Service-abonnementen worden per seconde gefactureerd.

Zie Hoeveel kost mijn App Service abonnement? voor meer informatie.

Gebruik de lagen Standard of Premium omdat deze ondersteuning bieden voor uitschalen, automatisch schalen en Secure Sockets Layer (SSL). Elke laag ondersteunt verschillende instantiegrootten die verschillen op basis van het aantal kernen en het geheugen. U kunt de laag of instantiegrootte wijzigen nadat u een plan hebt gemaakt. Zie Prijzen voor App Service voor meer informatie over App Service-plannen.

De instanties in het App Service-plan worden bij u in rekening gebracht, zelfs als de app is beëindigd. Verwijder de plannen die u niet gebruikt (bijvoorbeeld testimplementaties).

SQL Database

Een logische servergroep maakt beheertaken eenvoudig. Elke database in de groep wordt geïmplementeerd met een specifieke servicelaag. Binnen elke groep kunnen de databases geen resources delen. Er zijn geen rekenkosten voor de server, maar u moet de laag voor elke database opgeven. Daarom zijn de prestaties mogelijk beter vanwege de toegewezen resources, maar kunnen de kosten hoger zijn.

Gebruik de V12-versie van SQL Database. SQL Database biedt ondersteuning voor de servicelagen Basic, Standard en Premium, met meerdere prestatieniveaus binnen elke laag die worden gemeten in DTU’s (Database Transaction Units). Plan de capaciteiten, en kies een laag en prestatieniveau die voldoen aan uw vereisten.

Region

Richt het App Service-plan en de SQL-database in dezelfde regio in om de netwerklatentie te verminderen. In het algemeen kiest u de regio die het meest in de buurt van uw gebruikers is.

Aan de resourcegroep is ook een regio gekoppeld. Dit is waar de metagegevens voor de implementatie zijn opgeslagen. Plaats de resourcegroep en de bijbehorende resources in dezelfde regio. Dit kan de beschikbaarheid verbeteren tijdens de implementatie.

Gebruik de prijscalculator om de kosten te schatten.

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

Schaalbaarheidsoverwegingen

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.

De App Service-app schalen

Er zijn twee manieren om een App Service-app te schalen:

  • Omhoog schalen. Dit gaat over het wijzigen van de instantiegrootte. De instantiegrootte bepaalt het geheugen, het aantal kerngeheugens en de opslag op elke VM-instantie. U kunt handmatig omhoog schalen door de instantiegrootte of planlaag te wijzigen.

  • Uitschalen. Dit gaat over het toevoegen van instanties om een toenemende belasting te verwerken. Elke prijslaag heeft een maximum aantal instanties.

U kunt handmatig uitschalen door het aantal exemplaren te wijzigen of automatisch schalen te gebruiken, zodat Azure automatisch exemplaren toevoegt of verwijdert op basis van een planning en/of metrische prestatiegegevens. Elke schaalbewerking vindt snel plaats, meestal binnen enkele seconden.

Als u automatisch schalen wilt inschakelen, maakt u een profiel voor automatisch schalen waarin u het minimum en maximum aantal instanties bepaalt. Profielen kunnen worden gepland. U kunt bijvoorbeeld afzonderlijke profielen maken voor weekdagen en weekenddagen. Een profiel bevat optioneel regels voor het toevoegen of verwijderen van instanties. (Bijvoorbeeld: voeg twee instanties toe als het CPU-gebruik gedurende vijf minuten hoger is dan 70%.)

Aanbevelingen voor het schalen van een web-app:

  • Voorkom zo veel mogelijk omhoog en omlaag schalen, omdat dit kan leiden tot het opnieuw opstarten van de toepassing. Selecteer in plaats hiervan een laag en grootte die voldoen aan de prestatievereisten bij een bepaalde belasting, en schaal de instanties vervolgens uit om wijzigingen in de hoeveelheid verkeer te verwerken.
  • Schakel automatisch schalen in. Als uw toepassing een voorspelbare, reguliere workload heeft, maakt u profielen om het aantal instanties van tevoren te plannen. Als de workload niet voorspelbaar is, gebruikt u automatisch schalen op basis van regels om te reageren op wijzigingen in de belasting wanneer deze plaatsvinden. U kunt beide benaderingen combineren.
  • CPU-gebruik is gewoonlijk een goede meetwaarde voor regels voor automatisch schalen. Het is wel raadzaam om de belasting voor de toepassing te testen, mogelijke knelpunten te identificeren, en de regels voor automatisch schalen te baseren op deze gegevens.
  • Regels voor automatisch schalen bevatten een afkoelperiode. Dit is het interval dat moet worden gewacht nadat een schaalactie is voltooid voordat een nieuwe schaalactie wordt uitgevoerd. Dankzij de afkoelperiode kan het systeem stabiliseren voordat er opnieuw wordt geschaald. Stel een kortere afkoelperiode in voor het toevoegen van exemplaren en een langere afkoelperiode voor het verwijderen van exemplaren. Stel bijvoorbeeld 5 minuten in voor het toevoegen van een instantie, maar 60 minuten voor het verwijderen van een instantie. Het is beter om nieuwe exemplaren snel toe te voegen onder zware belasting om het extra verkeer af te handelen en vervolgens geleidelijk terug te schalen.

SQL-database schalen

Als u een hogere servicelaag of een hoger prestatieniveau nodig hebt voor SQL Database, kunt u afzonderlijke databases omhoog schalen zonder downtime van de toepassing. Zie Resources voor één database schalen inAzure SQL Database.

Beschikbaarheidsoverwegingen

Op het moment van schrijven is de SLA (Service Level Agreement) voor App Service 99,95%. De SLA voor SQL Database is 99,99% voor de lagen Basic, Standard en Premium. De App Service-SLA geldt voor zowel één als meerdere instanties.

Back-ups

In het geval van gegevensverlies biedt SQL Database herstel naar een bepaald tijdstip en geo-herstel. Deze functies zijn beschikbaar in alle lagen en zijn automatisch ingeschakeld. U hoeft geen back-ups te plannen of te beheren.

Zie Cloud business continuity and database disaster recovery with SQL Database (Bedrijfscontinuïteit in de cloud en herstel van databases na noodgevallen met SQL Database) voor meer informatie.

App Service biedt een functie voor back-up en herstel voor uw toepassingsbestanden. Let er echter op dat de back-upbestanden app-instellingen in tekst zonder tekst bevatten, en dat deze geheimen kunnen bevatten, zoals verbindingsreeksen. Vermijd het gebruik van App Service-back-upfunctie om een back-up te maken van uw SQL-databases, omdat deze de database exporteert naar een SQL BACPAC-bestand en DTUs verbruikt. Gebruik in plaats hiervan herstel naar een bepaald tijdstip van SQL Database, een functie die hierboven wordt beschreven.

Beheerbaarheidsoverwegingen

Maak afzonderlijke resourcegroepen voor productie-, ontwikkelings- en testomgevingen. Hiermee kunt u eenvoudiger implementaties beheren, testimplementaties verwijderen en toegangsrechten verlenen.

Wanneer u resources toewijst aan resourcegroepen, moet u het volgende overwegen:

  • Levenscyclus. In het algemeen kunt u resources met dezelfde levenscyclus het beste in dezelfde resourcegroep onderbrengen.
  • Toegang. U kunt op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken om toegangsbeleid toe te passen op de resources in een groep.
  • Facturering. U kunt de samengevoegde kosten voor de resourcegroep bekijken.

Zie Overzicht van Azure Resource Manager voor meer informatie.

DevOps overwegingen

In deze architectuur gebruikt u een Azure Resource Manager voor het inrichten van de Azure-resources en hun afhankelijkheden. Aangezien dit één webtoepassing is, worden alle resources geïsoleerd in dezelfde basisworkload, waardoor het eenvoudiger is om de specifieke resources van de workload aan een team te koppelen, zodat het team alle aspecten van deze resources onafhankelijk kan beheren. Door deze isolatie kan het DevOps-team continue integratie en continue levering (CI/CD) uitvoeren. U kunt ook verschillende ARM-sjablonen gebruiken en deze integreren met Azure DevOps Services om binnen enkele minuten verschillende omgevingen in terichten, bijvoorbeeld om productie-achtige scenario's te repliceren of omgevingen voor belastingstests alleen wanneer dat nodig is, wat kosten bespaart.

U kunt meerdere exemplaren van de webtoepassing inrichten, zodat deze niet afhankelijk is van één exemplaar, waardoor één storingspunt kan worden veroorzaakt. Daarnaast verbeteren meerdere exemplaren de tolerantie en schaalbaarheid.

Implementatie

Implementatie bestaat uit twee stappen:

  1. Inrichten van de Azure-resources. We raden u aan om Azure Resource Manager gebruiken voor deze stap. Met sjablonen kunt u implementaties eenvoudiger automatiseren via PowerShell of de Azure CLI.
  2. Implementeren van de toepassing (code, binaire bestanden en inhoudsbestanden). U hebt verschillende opties, waaronder implementeren vanuit een lokale Git-opslagplaats, via Visual Studio, of continue implementatie vanuit broncodebeheer in de cloud. Zie Deploy your app to Azure App Service (Uw app implementeren in Azure App Service).

Een App Service-app heeft altijd één implementatiesite met de naam production, die de live-productiesite vertegenwoordigt. We raden u aan om een staging-site te maken voor het implementeren van updates. De voordelen van het gebruik van een staging-site zijn:

  • U kunt controleren of de implementatie is geslaagd voordat u deze naar productie wisselt.
  • Door te implementeren op een staging-site kunt u controleren of alle instanties juist werken voordat ze in productie komen. Veel toepassingen hebben een aanzienlijke opwarm- en koude starttijd.

We raden u ook aan om een derde site te maken waarop u de laatst bekende juiste implementatie hebt staan. Nadat u de fasering en de productie hebt gewisseld, verplaatst u de vorige productie-implementatie (die nu gefaseerd wordt uitgevoerd) naar de site voor de laatste bekende juiste implementatie. Op deze manier kunt u, als u later een probleem ontdekt, snel terugkeren naar de laatst bekende juiste versie.

Swapping-slots voor productie- en faseringsimplementaties

Als u terugkeert naar een vorige versie, moet u ervoor zorgen dat eventuele wijzigingen in het databaseschema compatibel zijn met eerdere versies.

Gebruik geen testsites in de productie-implementatie, omdat alle apps in hetzelfde App Service-plan dezelfde VM-instanties delen. Belastingstests kunnen bijvoorbeeld de live productiesite verslechteren. Maak in plaats hiervan afzonderlijke App Service-plannen voor productie en testen. Door testimplementaties in een afzonderlijk plan te plaatsen, kunt u ze isoleren van de productieversie.

Configuratie

Sla configuratie-instellingen op als app-instellingen. Definieer de app-instellingen in Resource Manager sjablonen of met behulp van PowerShell. Tijdens het uitvoeren zijn app-instellingen beschikbaar voor de toepassing als omgevingsvariabelen.

Schakel wachtwoorden, toegangstoetsen of verbindingsreeksen nooit in broncodebeheer in. Geef deze in plaats hiervan door als parameters voor een implementatiescript waarin deze waarden worden opgeslagen als app-instellingen.

Wanneer u een implementatiesite wisselt, worden de app-instellingen standaard ook gewisseld. Als u andere productie- en faseringsinstellingen nodig hebt, kunt u app-instellingen maken die zich aan een site houden en niet worden gewisseld.

Diagnose en controle

Schakel Diagnostische logboekregistratie in, inclusief toepassingslogboeken en webserverlogboeken. Logboekregistratie configureren voor het gebruik van Azure Log Analytics. Zie Monitoring and diagnostics guidance (Hulp bij controle en logboekregistratie) voor meer gedetailleerde hulp bij logboekregistratie.

Gebruik een service zoals New Relic of Application Insights om de prestaties en het gedrag van toepassingen tijdens belasting te controleren. Houd rekening met de limieten voor gegevenssnelheid in Application Insights.

Voer belastingstests uit met behulp van een hulpprogramma zoals Azure DevOpsof Visual Studio Team Foundation Server. Zie Performance Analysis Primer (Inleiding tot prestatieanalyse) voor een algemeen overzicht van prestatieanalyse in cloudtoepassingen.

Tips voor het oplossen van problemen met uw toepassing:

  • Gebruik de blade Problemen oplossen in Azure Portal om oplossingen te vinden voor bekende problemen.
  • Schakel logboekstreaming in om logboekgegevens bijna in realtime weer te geven.
  • Het Kudu-dashboard heeft verschillende hulpprogramma’s voor het controleren en opsporen van fouten in de toepassing. Zie Azure Websites online tools you should know about (Onlinehulpprogramma’s voor Azure Websites die u zou moeten kennen) (blogpost) voor meer informatie. U kunt het Kudu-dashboard bereiken via Azure Portal. Open de blade voor uw app en klik op Extra. Klik vervolgens op Kudu.
  • Als u Visual Studio gebruikt, raadpleegt u het artikel Troubleshoot a web app in Azure App Service using Visual Studio (Problemen met een web-app in Azure App Service oplossen met behulp van Visual Studio) voor tips over het opsporen van fouten en het oplossen van problemen.

Zie de sectie DevOps in Azure Well-Architected Framework voor meer informatie.

Beveiligingsoverwegingen

In deze sectie vindt u beveiligingsoverwegingen die specifiek zijn bedoeld voor de Azure-services die worden beschreven in dit artikel. Het is geen volledige lijst met aanbevolen procedures voor beveiliging. Zie Secure an app in Azure App Service (Een app beveiligen in Azure App Service) voor een aantal aanvullende beveiligingsoverwegingen.

SQL Database Auditing

Dankzij controles kunt u zorgen voor naleving van wet- en regelgeving, en krijgt u inzicht in de discrepanties en onregelmatigheden die kunnen wijzen op problemen voor het bedrijf of vermoedelijke schendingen van de beveiliging. Zie Get started with SQL database auditing (Aan de slag met SQL Database Auditing).

Implementatiesites

Elke implementatiesite heeft een openbaar IP-adres. Beveilig niet-productiesites met behulp van Azure Active Directory-aanmelding zodat alleen leden van het ontwikkelingsteam en DevOps-team deze eindpunten kunnen bereiken.

Logboekregistratie

Leg nooit wachtwoorden van gebruikers of andere informatie die kan worden gebruikt voor identiteitsfraude, vast in logboeken. Wis deze details uit de gegevens voordat u ze opslaat.

SSL

Een App Service-app bevat een SSL-eindpunt op een subdomein van azurewebsites.net zonder extra kosten. Het SSL-eindpunt bevat een jokertekencertificaat voor het domein *.azurewebsites.net. Als u een aangepaste domeinnaam gebruikt, moet u een certificaat opgeven dat overeenkomt met het aangepaste domein. De eenvoudigste methode hiervoor is om rechtstreeks in Azure Portal een certificaat aan te schaffen. U kunt certificaten ook importeren uit andere certificeringsinstanties. Zie Buy and Configure an SSL Certificate for your Azure App Service (Een SSL-certificaat kopen en configureren voor Azure App Service) voor meer informatie.

Het is een aanbevolen procedure om met de app HTTPS af te dwingen door HTTP-aanvragen om te leiden. U kunt dit in de toepassing implementeren of een herschrijvingsregel voor URL gebruiken zoals wordt beschreven in Enable HTTPS for an app in Azure App Service (HTTPS inschakelen voor een app in Azure App Service).

Verificatie

We raden u aan om te verifiëren via een IDP (id-provider), zoals Azure AD, Facebook, Google of Twitter. Gebruik OAuth 2 of OIDC (OpenID Connect) voor de verificatiestroom. Azure AD biedt functionaliteit voor het beheren van gebruikers en groepen, het maken van toepassingsrollen, het integreren van uw on-premises identiteiten en het gebruiken van back-Microsoft 365 en Skype voor Bedrijven.

Beheer geen gebruikersaanmelding en -referenties via de toepassing, omdat dit kwetsbaar maakt voor potentiële aanvallen. U moet minimaal een e-mailbevestiging, wachtwoordherstel en meervoudige verificatie hebben, wachtwoordsterkte valideren en wachtwoordhashes veilig opslaan. De grote id-providers verwerken al deze zaken voor u en zijn voortdurend bezig met het bewaken en verbeteren van hun beveiligingsprocedures.

Overweeg om App Service-verificatie te gebruiken voor het implementeren van de OAuth/OIDC-verificatiestroom. Een aantal voordelen van App Service-verificatie:

  • Eenvoudig te configureren.
  • Geen code vereist voor eenvoudige verificatiescenario's.
  • Ondersteunt gedelegeerde autorisatie met OAuth-toegangstokens voor het gebruik van resources namens de gebruiker.
  • Biedt een ingebouwde tokencache.

Een aantal beperkingen van App Service-verificatie:

  • Beperkte aanpassingsopties.
  • Gedelegeerde autorisatie is beperkt tot één back-endresource per aanmeldingssessie.
  • Als u meer dan één IDP gebruikt, is er geen ingebouwd mechanisme voor detectie van het thuisdomein.
  • In scenario’s met meerdere tenants, moet voor de toepassing de logica worden geïmplementeerd om de uitgever van het token te valideren.