Delen via

Azure Well-Architected Framework perspectief op Azure-app Service (Web Apps)

  • Artikel

Azure-app Service is een PaaS-rekenoplossing (Platform as a Service) die u kunt gebruiken om uw workload op het Azure-platform te hosten. Het is een volledig beheerde service die de onderliggende berekening abstraheert en de verantwoordelijkheid voor het bouwen, implementeren en schalen naar het platform offload. Een app-service draait altijd in een App Service-plan. Het serviceplan dat u kiest, bepaalt de regio waarin de workload wordt uitgevoerd, de rekenconfiguraties en het besturingssysteem. Er zijn meerdere factureringsmodellen beschikbaar voor App Service.

In dit artikel wordt ervan uitgegaan dat u als architect de structuur van de berekeningsbeslissing hebt gecontroleerd en App Service hebt gekozen als rekenproces voor uw workload. De richtlijnen in dit artikel bevatten architectuuraanbevelingen die zijn toegewezen aan de principes van de pijlers van het Azure Well-Architected Framework.

Belangrijk

Deze handleiding gebruiken

Elke sectie bevat een ontwerpcontrolelijst die architectuurgebieden presenteert, samen met ontwerpstrategieën die zijn gelokaliseerd in het technologiebereik.

Ook zijn inbegrepen aanbevelingen voor de technologiemogelijkheden die kunnen helpen bij het materialiseren van deze strategieën. De aanbevelingen vertegenwoordigen geen volledige lijst met alle configuraties die beschikbaar zijn voor de functie Web Apps van Azure-app Service en hun afhankelijkheden. In plaats daarvan worden de belangrijkste aanbevelingen vermeld die zijn toegewezen aan de ontwerpperspectieven. Gebruik de aanbevelingen om uw proof-of-concept te bouwen of uw bestaande omgevingen te optimaliseren.

Basisarchitectuur die de belangrijkste aanbevelingen demonstreert: App Service-basislijnarchitectuur.

Technologiebereik

Deze beoordeling is gericht op de onderling gerelateerde beslissingen voor de volgende Azure-resources:

  • App Service-plannen
  • Web Apps

Andere Azure-aanbiedingen zijn gekoppeld aan App Service, zoals Azure Functions, Azure Logic Apps en App Service Environment. Deze aanbiedingen vallen buiten het bereik van dit artikel. Er wordt af en toe naar App Service Environment verwezen om functies of opties van de belangrijkste App Service-aanbiedingen te verduidelijken.

Betrouwbaarheid

Het doel van de pijler Betrouwbaarheid is om doorlopende functionaliteit te bieden door voldoende tolerantie en de mogelijkheid om snel te herstellen na storingen.

De principes voor betrouwbaarheidsontwerp bieden een ontwerpstrategie op hoog niveau die wordt toegepast op afzonderlijke onderdelen, systeemstromen en het systeem als geheel.

Controlelijst voor ontwerp

Start uw ontwerpstrategie op basis van de controlelijst voor ontwerpbeoordeling voor betrouwbaarheid. Bepaal de relevantie ervan voor uw bedrijfsvereisten en houd daarbij rekening met de lagen en functies van App Service en de bijbehorende afhankelijkheden. Breid de strategie uit om zo nodig meer benaderingen op te nemen.

  • Prioriteit geven aan gebruikersstromen: niet alle stromen zijn even kritiek. Wijs prioriteiten toe aan elke stroom om uw ontwerpbeslissingen te begeleiden. Het ontwerp van gebruikersstromen kan van invloed zijn op de servicelagen en het aantal exemplaren dat u kiest voor een App Service-plan en -configuratie.

    Uw toepassing kan bijvoorbeeld front-end- en back-endlagen bevatten die communiceren via een berichtenbroker. U kunt ervoor kiezen om de lagen in meerdere web-apps te segmenteren om onafhankelijk schalen, levenscyclusbeheer en onderhoud mogelijk te maken. Het plaatsen van een grote toepassing in één plan kan leiden tot geheugen- of CPU-problemen en kan de betrouwbaarheid beïnvloeden.

    Mogelijk hebt u meer exemplaren aan de front-end nodig voor optimale prestaties aan de gebruikersinterfacezijde. De back-end vereist mogelijk echter niet hetzelfde aantal exemplaren.

  • Potentiële fouten anticiperen: risicobeperkingsstrategieën plannen voor mogelijke fouten. In de volgende tabel ziet u voorbeelden van analyse van foutmodus.

    Mislukking Oplossing
    Fout in onderliggende of abstracte App Service-onderdelen Onderdelenredundantie hebben in exemplaren en afhankelijkheden. Controleer de status van exemplaren, netwerkprestaties en opslagprestaties.
    Fout bij externe afhankelijkheden Gebruik ontwerppatronen zoals het patroon Opnieuw proberen en het patroon Circuitonderbreker. Controleer de externe afhankelijkheden en stel de juiste time-outs in.
    Fout vanwege verkeer dat wordt gerouteerd naar beschadigde exemplaren Controleer de status van het exemplaar. Overweeg de reactiesnelheid en vermijd het verzenden van aanvragen naar beschadigde exemplaren.

    Zie Analyse van foutmodus voor Azure-toepassingen voor meer informatie.

  • Buildredundantie: Bouwredundantie in de toepassing en ondersteunende infrastructuur. Verspreid instanties over beschikbaarheidszones om fouttolerantie te verbeteren. Verkeer wordt doorgestuurd naar andere zones als één zone uitvalt. Implementeer uw toepassing in meerdere regio's om ervoor te zorgen dat uw app beschikbaar blijft, zelfs als een hele regio een storing ondervindt.

    Bouw vergelijkbare redundantieniveaus in afhankelijke services. Toepassingsexemplaren binden bijvoorbeeld aan blobopslag. Overweeg om het gekoppelde opslagaccount te configureren met zone-redundante opslag (ZRS) als een toepassing gebruikmaakt van een zone-redundante implementatie.

    Redundantie hebben in netwerkonderdelen. Gebruik bijvoorbeeld zone-redundante IP-adressen en load balancers.

  • Een betrouwbare schaalstrategie hebben: onverwachte belasting van een toepassing kan deze onbetrouwbaar maken. Overweeg de juiste schaalbenadering op basis van uw workloadkenmerken. Soms kunt u omhoog schalen om de belasting te verwerken. Als de belasting echter blijft toenemen, schaalt u uit naar nieuwe exemplaren. Geef de voorkeur aan automatisch schalen ten opzichte van handmatige benaderingen. Onderhoud altijd een buffer van extra capaciteit tijdens schaalbewerkingen om prestatievermindering te voorkomen.

    De App Service-planlaag die u kiest, is van invloed op het schalen in termen van het aantal exemplaren en de rekeneenheden.

    Zorg voor de juiste initialisatie van apps, zodat nieuwe exemplaren snel worden opgewarmd en aanvragen kunnen ontvangen.

    Streven naar staatloze toepassingen waar mogelijk. Het betrouwbaar schalen van de status met nieuwe exemplaren kan de complexiteit verhogen. Overweeg een extern gegevensarchief dat u onafhankelijk kunt schalen als u de toepassingsstatus wilt opslaan. Het opslaan van de sessiestatus in het geheugen kan leiden tot verlies van sessiestatus wanneer er een probleem is met de toepassing of App Service. Het beperkt ook de mogelijkheid om de belasting over andere exemplaren te spreiden.

    Test regelmatig uw regels voor automatisch schalen. Simuleer laadscenario's om te controleren of uw app naar verwachting wordt geschaald. U moet schaalgebeurtenissen vastleggen, zodat u problemen kunt oplossen die zich kunnen voordoen en uw schaalstrategie in de loop van de tijd kunt optimaliseren.

    App Service heeft een beperking voor het aantal exemplaren binnen een plan, wat van invloed kan zijn op de betrouwbaarheid van schalen. Eén strategie is het gebruik van identieke implementatiestempels, elk actief App Service-planexemplaren met een eigen eindpunt. Het is essentieel dat u alle stempels met een externe load balancer frontt om verkeer over deze postzegels te verdelen. Gebruik Azure-toepassing Gateway voor implementaties met één zone en Azure Front Door voor implementaties in meerdere regio's. Deze benadering is ideaal voor bedrijfskritieke toepassingen waarbij betrouwbaarheid cruciaal is. Zie Bedrijfskritieke basislijn met App Service voor meer informatie.

    Een App Service-plan distribueert verkeer over exemplaren en bewaakt hun status. Houd er rekening mee dat de externe load balancer mogelijk niet onmiddellijk detecteert als één exemplaar mislukt.

  • Uw herstelbaarheid plannen: Redundantie is cruciaal voor bedrijfscontinuïteit. Voer een failover uit naar een ander exemplaar als één exemplaar onbereikbaar is. Verken automatische herstelmogelijkheden in App Service, zoals het automatisch herstellen van exemplaren.

    Implementeer ontwerppatronen voor het afhandelen van respijtieve degradatie voor zowel tijdelijke fouten, zoals problemen met de netwerkverbinding en grootschalige gebeurtenissen zoals regionale storingen. Houd rekening met de volgende ontwerppatronen:

    • Het schotpatroon segmenteert uw toepassing in geïsoleerde groepen om te voorkomen dat een storing van invloed is op het hele systeem.

    • De wachtrijen voor load leveling op basis van wachtrijen werken met items die als buffer fungeren om pieken in het verkeer te vereffenen.

    • Het patroon Opnieuw proberen verwerkt tijdelijke fouten vanwege netwerkstoringen, verbroken databaseverbindingen of bezet-services.

    • Het circuitonderbrekerpatroon voorkomt dat een toepassing herhaaldelijk probeert een bewerking uit te voeren die waarschijnlijk mislukt.

    U kunt WebJobs gebruiken om achtergrondtaken uit te voeren in uw web-app. Als u deze taken betrouwbaar wilt uitvoeren, moet u ervoor zorgen dat de app die als host fungeert voor uw taak continu wordt uitgevoerd volgens een planning of op basis van gebeurtenisgestuurde triggers.

    Zie Betrouwbaarheidspatronen voor meer informatie.

  • Voer betrouwbaarheidstests uit: voer belastingstests uit om de betrouwbaarheid en prestaties van uw toepassing onder belasting te evalueren. Testplannen moeten scenario's bevatten waarmee uw geautomatiseerde herstelbewerkingen worden gevalideerd.

    Gebruik foutinjectie om opzettelijk fouten te introduceren en uw zelfherstel- en zelfbehoudmechanismen te valideren. Verken de foutbibliotheek van Azure Chaos Studio.

    App Service legt resourcelimieten op voor gehoste apps. Het App Service-plan bepaalt deze limieten. Zorg ervoor dat uw tests bevestigen dat de app binnen deze resourcelimieten wordt uitgevoerd. Zie Azure-abonnement en servicelimieten, quota en beperkingen voor meer informatie.

  • Gebruik statustests om niet-reagerende werknemers te identificeren: App Service heeft ingebouwde mogelijkheden die periodiek een specifiek pad van uw webtoepassing pingen. Niet-reagerende exemplaren worden verwijderd uit de load balancer en vervangen door een nieuw exemplaar.

Aanbevelingen
Aanbeveling Voordeel
(App Service-plan) Kies de Premium-laag van een App Service-plan voor productieworkloads.

Stel het maximum- en minimumaantal werknemers in op basis van uw capaciteitsplanning. Zie het overzicht van het App Service-plan voor meer informatie.		 Een Premium App Service-plan biedt geavanceerde schaalfuncties en zorgt voor redundantie als er fouten optreden.
(App Service-plan) Schakel zoneredundantie in.

Overweeg om meer dan drie exemplaren in te richten om fouttolerantie te verbeteren.

Controleer de regionale ondersteuning voor zoneredundantie omdat niet alle regio's deze functie bieden.		 Uw toepassing kan bestand zijn tegen storingen in één zone wanneer meerdere exemplaren verspreid zijn over zones. Verkeer wordt automatisch verplaatst naar gezonde exemplaren in andere zones en onderhoudt de betrouwbaarheid van toepassingen als één zone niet beschikbaar is.
(App Service) Overweeg de functie ARR-affiniteit (Application Request Routing) uit te schakelen. Met ARR-affiniteit worden plaksessies gemaakt waarmee gebruikers worden omgeleid naar het knooppunt dat hun vorige aanvragen heeft verwerkt. Binnenkomende aanvragen worden gelijkmatig verdeeld over alle beschikbare knooppunten wanneer u ARR-affiniteit uitschakelt. Gelijkmatig gedistribueerde aanvragen voorkomen dat verkeer een willekeurig knooppunt overweldigt. Aanvragen kunnen naadloos worden omgeleid naar andere knooppunten die in orde zijn als een knooppunt niet beschikbaar is.

Vermijd sessieaffiniteit om ervoor te zorgen dat uw App Service-exemplaar staatloos blijft. Een stateless App Service vermindert de complexiteit en zorgt voor consistent gedrag tussen knooppunten.

Verwijder plaksessies zodat App Service exemplaren kan toevoegen of verwijderen om horizontaal te schalen.
(App Service) Definieer automatische herstelregels op basis van het aantal aanvragen, trage aanvragen, geheugenlimieten en andere indicatoren die deel uitmaken van uw prestatiebasislijn. Overweeg deze configuratie als onderdeel van uw schaalstrategie. Met automatische herstelregels kunt u uw toepassing automatisch herstellen na onverwachte problemen. De geconfigureerde regels activeren herstelacties wanneer drempelwaarden worden overschreden.

Automatische genezing maakt automatisch proactief onderhoud mogelijk.
(App Service) Schakel de statuscontrolefunctie in en geef een pad op dat reageert op de statuscontroleaanvragen. Statuscontroles kunnen problemen vroegtijdig detecteren. Vervolgens kan het systeem automatisch corrigerende acties ondernemen wanneer een statuscontroleaanvraag mislukt.

De load balancer routeert verkeer weg van beschadigde exemplaren, waardoor gebruikers worden doorgestuurd naar knooppunten die in orde zijn.

Beveiliging

Het doel van de beveiligingspijler is het bieden van vertrouwelijkheid, integriteit en beschikbaarheidsgaranties voor de workload.

De principes voor beveiligingsontwerp bieden een ontwerpstrategie op hoog niveau voor het bereiken van deze doelen door benaderingen toe te passen op het technische ontwerp rond hosting op App Service.

Controlelijst voor ontwerp

Start uw ontwerpstrategie op basis van de controlelijst voor ontwerpbeoordeling voor Beveiliging en identificeer beveiligingsproblemen en besturingselementen om het beveiligingspostuur te verbeteren. Breid de strategie uit om zo nodig meer benaderingen op te nemen.

  • Bekijk de beveiligingsbasislijnen: Als u de beveiligingspostuur van uw toepassing wilt verbeteren die wordt gehost in een App Service-plan, controleert u de beveiligingsbasislijn voor App Service.

  • Gebruik de nieuwste runtime en bibliotheken: test de builds van uw toepassing grondig voordat u updates uitvoert om problemen vroegtijdig te ondervangen en een soepele overgang naar de nieuwe versie te garanderen. App Service ondersteunt het ondersteuningsbeleid voor taalruntime voor het bijwerken van bestaande stacks en het buiten gebruik stellen van end-of-support-stacks.

  • Segmentatie maken via isolatiegrenzen die inbreuk moeten bevatten: identiteitssegmentatie toepassen. Implementeer bijvoorbeeld op rollen gebaseerd toegangsbeheer (RBAC) om specifieke machtigingen toe te wijzen op basis van rollen. Volg het principe van minimale bevoegdheid om toegangsrechten te beperken tot alleen wat nodig is. Maak ook segmentatie op netwerkniveau. Injecteer App Service-apps in een virtueel Azure-netwerk voor isolatie en definieer netwerkbeveiligingsgroepen (NSG's) om verkeer te filteren.

    App Service-plannen bieden de App Service Environment-laag die een hoge mate van isolatie biedt. Met App Service Environment krijgt u toegewezen rekenkracht en netwerken.

  • Toegangsbeheer toepassen op identiteiten: beperk zowel binnenkomende toegang tot de web-app als externe toegang van de web-app naar andere resources. Met deze configuratie worden toegangsbeheer toegepast op identiteiten en wordt de algehele beveiligingspostuur van de workload gehandhaafd.

    Gebruik Microsoft Entra ID voor alle verificatie- en autorisatiebehoeften. Gebruik ingebouwde rollen, zoals inzender voor webplannen, inzender voor websites en een algemene inzender, lezer en eigenaar.

  • Netwerkverkeer naar en van de toepassing beheren: maak toepassingseindpunten niet beschikbaar op het openbare internet. Voeg in plaats daarvan een privé-eindpunt toe aan de web-app die in een toegewezen subnet wordt geplaatst. Front your application with a reverse proxy that communicates with that private endpoint. Overweeg hiervoor Application Gateway of Azure Front Door te gebruiken.

    Implementeer een WAF (Web Application Firewall) om te beschermen tegen veelvoorkomende beveiligingsproblemen. Zowel Application Gateway als Azure Front Door hebben geïntegreerde WAF-mogelijkheden.

    Configureer de omgekeerde proxyregels en netwerkinstellingen op de juiste manier om het gewenste beveiligings- en beheerniveau te bereiken. Voeg bijvoorbeeld NSG-regels toe aan het subnet van het privé-eindpunt om alleen verkeer van de omgekeerde proxy te accepteren.

    Uitgaand verkeer van de toepassing naar andere PaaS-services moet via privé-eindpunten zijn. Overweeg om een firewallonderdeel te plaatsen om uitgaand verkeer naar het openbare internet te beperken. Beide benaderingen voorkomen exfiltratie van gegevens.

    Zie App Service-netwerkfuncties voor een uitgebreide weergave.

  • Gegevens versleutelen: gegevens tijdens overdracht beveiligen met end-to-end Tls (Transport Layer Security). Gebruik uw door de klant beheerde sleutels voor volledige versleuteling van data-at-rest. Zie Versleuteling-at-rest met behulp van door de klant beheerde sleutels voor meer informatie.

    Gebruik geen verouderde protocollen zoals TLS 1.0 en 1.1. App Service schakelt standaard 1.2 in. Zie Het overzicht van App Service TLS voor meer informatie.

    Alle exemplaren van uw App Service hebben een standaarddomeinnaam. Gebruik een aangepast domein en beveilig dat domein met certificaten.

  • Verminder het kwetsbaarheid voor aanvallen: verwijder standaardconfiguraties die u niet nodig hebt. Schakel bijvoorbeeld externe foutopsporing, lokale verificatie voor SCM-sites (Source Control Manager) en basisverificatie uit. Schakel onbeveiligde protocollen zoals HTTP en File Transfer Protocol (FTP) uit. Dwing configuraties af via Azure-beleid. Zie Azure-beleid voor meer informatie.

    Implementeer beperkende CORS-beleidsregels (Cross-Origin Resource Sharing): Gebruik beperkende CORS-beleidsregels in uw web-app om alleen aanvragen van de toegestane domeinen, headers en andere criteria te accepteren. CORS-beleid afdwingen met ingebouwde Azure-beleidsdefinities.

  • Toepassingsgeheimen beveiligen: u moet gevoelige informatie verwerken, zoals API-sleutels of verificatietokens. In plaats van deze geheimen rechtstreeks te coderen in uw toepassingscode of configuratiebestanden, kunt u Azure Key Vault-verwijzingen gebruiken in app-instellingen. Wanneer de toepassing wordt gestart, haalt App Service automatisch de geheime waarden op uit Key Vault met behulp van de beheerde identiteit van de app.

  • Schakel resourcelogboeken in voor uw toepassing: schakel resourcelogboeken voor uw toepassing in om uitgebreide activiteitentrails te maken die waardevolle gegevens bieden tijdens onderzoeken die volgen op beveiligingsincidenten.

    Overweeg logboekregistratie als onderdeel van uw threat modeling-proces wanneer u bedreigingen evalueert.

Aanbevelingen
Aanbeveling Voordeel
(App Service) Beheerde identiteiten toewijzen aan de web-app. Als u isolatiegrenzen wilt behouden, moet u identiteiten niet delen of hergebruiken tussen toepassingen.

Zorg ervoor dat u veilig verbinding maakt met uw containerregister als u containers gebruikt voor uw implementatie.		 De toepassing haalt geheimen op uit Key Vault om uitgaande communicatie van de toepassing te verifiëren. Azure beheert de identiteit en vereist niet dat u geheimen inricht of roteert.

U hebt verschillende identiteiten voor granulariteit van controle. Afzonderlijke identiteiten maken het intrekken eenvoudig als een identiteit wordt aangetast.
(App Service) Aangepaste domeinen configureren voor toepassingen.

Schakel HTTP uit en accepteer alleen HTTPS-aanvragen.		 Aangepaste domeinen maken beveiligde communicatie mogelijk via HTTPS met behulp van TLS-protocol (Transport Layer Security), wat de beveiliging van gevoelige gegevens garandeert en gebruikersvertrouwen bouwt.
(App Service) controleer of ingebouwde App Service-verificatie het juiste mechanisme is om gebruikers te verifiëren die toegang hebben tot uw toepassing. Ingebouwde App Service-verificatie kan worden geïntegreerd met Microsoft Entra ID. Deze functie verwerkt tokenvalidatie en gebruikersidentiteitsbeheer voor meerdere aanmeldingsproviders en ondersteunt OpenID-Verbinding maken. Met deze functie hebt u geen autorisatie op gedetailleerd niveau en hebt u geen mechanisme om verificatie te testen. Wanneer u deze functie gebruikt, hoeft u geen verificatiebibliotheken te gebruiken in toepassingscode, wat de complexiteit vermindert. De gebruiker wordt al geverifieerd wanneer een aanvraag de toepassing bereikt.
(App Service) Configureer de toepassing voor integratie van virtuele netwerken.

Gebruik privé-eindpunten voor App Service-apps. Alle openbare verkeer blokkeren.

Routeer de containerinstallatiekopie via de integratie van het virtuele netwerk . Al het uitgaande verkeer van de toepassing passeert via het virtuele netwerk.		 Profiteer van de beveiligingsvoordelen van het gebruik van een virtueel Azure-netwerk. De toepassing heeft bijvoorbeeld veilig toegang tot resources binnen het netwerk.

Voeg een privé-eindpunt toe om uw toepassing te beveiligen. Privé-eindpunten beperken directe blootstelling aan het openbare netwerk en bieden gecontroleerde toegang via de omgekeerde proxy.
(App Service) Beveiliging implementeren:
- Schakel basisverificatie uit die gebruikmaakt van een gebruikersnaam en wachtwoord ten gunste van verificatie op basis van Microsoft Entra ID.
- Schakel externe foutopsporing uit zodat binnenkomende poorten niet worden geopend.
- Schakel CORS-beleid in om binnenkomende aanvragen aan te scherpen.
- Protocollen uitschakelen, zoals FTP.		 We raden basisverificatie niet aan als een veilige implementatiemethode. Microsoft Entra ID maakt gebruik van verificatie op basis van OAuth 2.0-tokens. Dit biedt talloze voordelen en verbeteringen die betrekking hebben op de beperkingen die zijn gekoppeld aan basisverificatie.

Beleid beperkt de toegang tot toepassingsbronnen, staat alleen aanvragen van specifieke domeinen toe en beveiligt aanvragen tussen regio's.
(App Service) Gebruik altijd Key Vault-verwijzingen als app-instellingen.
Geheimen worden gescheiden gehouden van de configuratie van uw app. App-instellingen worden in rust versleuteld. App Service beheert ook geheime rotaties.
(App Service-plan) Schakel Microsoft Defender voor Cloud in voor App Service. Realtime-beveiliging krijgen voor resources die worden uitgevoerd in een App Service-plan. Bescherm bedreigingen en verbeter uw algehele beveiligingspostuur.
(App Service-plan) Schakel diagnostische logboekregistratie in en voeg instrumentatie toe aan uw app. De logboeken worden verzonden naar Azure Storage-accounts, Azure Event Hubs en Log Analytics. Zie Ondersteunde logboektypen voor meer informatie over typen auditlogboeken. Logboekregistratie legt toegangspatronen vast. Het registreert relevante gebeurtenissen die waardevolle inzichten bieden in de manier waarop gebruikers met een toepassing of platform communiceren. Deze informatie is van cruciaal belang voor verantwoordelijkheid, naleving en beveiligingsdoeleinden.

Kostenoptimalisatie

Kostenoptimalisatie is gericht op het detecteren van uitgavenpatronen, het prioriteren van investeringen in kritieke gebieden en het optimaliseren van anderen om te voldoen aan het budget van de organisatie terwijl aan de bedrijfsvereisten wordt voldaan.

De ontwerpprincipes voor kostenoptimalisatie bieden een ontwerpstrategie op hoog niveau voor het bereiken van deze doelen en het waar nodig maken van compromissen in het technische ontwerp met betrekking tot uw web-apps en de omgeving waarin ze worden uitgevoerd.

Controlelijst voor ontwerp

Start uw ontwerpstrategie op basis van de controlelijst voor ontwerpbeoordeling voor kostenoptimalisatie voor investeringen en verfijn het ontwerp, zodat de workload is afgestemd op het budget dat voor de workload is toegewezen. Uw ontwerp moet gebruikmaken van de juiste Azure-mogelijkheden, investeringen bewaken en mogelijkheden vinden om in de loop van de tijd te optimaliseren.

  • Maak een schatting van de initiële kosten: als onderdeel van uw oefening voor kostenmodellering gebruikt u de Azure-prijscalculator om de geschatte kosten te evalueren die zijn gekoppeld aan verschillende lagen op basis van het aantal exemplaren dat u wilt uitvoeren. Elke App Service-laag biedt verschillende rekenopties.

    Bewaak continu het kostenmodel om uitgaven bij te houden.

  • Evalueer de opties met korting: hogere lagen omvatten toegewezen rekeninstanties. U kunt een reserveringskorting toepassen als uw workload een voorspelbaar en consistent gebruikspatroon heeft. Zorg ervoor dat u gebruiksgegevens analyseert om het type reservering te bepalen dat bij uw workload past. Zie Kosten besparen met gereserveerde instanties van App Service voor meer informatie.

  • Inzicht in gebruiksmeters: Azure brengt een uurtarief in rekening, naar rato van de tweede, op basis van de prijscategorie van uw App Service-plan. Kosten zijn van toepassing op elke uitgeschaalde instantie in uw abonnement, op basis van de tijd waarop u het VM-exemplaar toewijst. Let op onderbezette rekenresources die uw kosten kunnen verhogen als gevolg van overbezetting als gevolg van suboptimale SKU-selectie of slecht geconfigureerde inschaalconfiguratie.

    Extra App Service-functies, zoals registratie van aangepaste domeinen en aangepaste certificaten, kunnen kosten toevoegen. Andere resources, zoals virtuele netwerken om uw oplossing of sleutelkluizen te isoleren om workloadgeheimen te beveiligen, die kunnen worden geïntegreerd met uw App Service-resources, kunnen ook kosten toevoegen. Zie het App Services-factureringsmodel voor meer informatie.

  • Houd rekening met de afwegingen tussen dichtheid en isolatie: u kunt App Service-plannen gebruiken om meerdere toepassingen op dezelfde berekening te hosten, waardoor kosten worden bespaard met gedeelde omgevingen. Zie Compromissen voor meer informatie.

  • Evalueer het effect van uw schaalstrategie op kosten: u moet de schaal aanpassen, testen en configureren voor uitschalen en inschalen wanneer u automatisch schalen implementeert. Stel nauwkeurige maximum- en minimumlimieten in voor automatisch schalen.

    Initialiseer de toepassing proactief voor betrouwbare schaalaanpassing. Wacht bijvoorbeeld niet totdat het CPU-gebruik 95% bereikt. In plaats daarvan activeert u schalen met ongeveer 65%, zodat er voldoende tijd is om nieuwe exemplaren toe te wijzen en te initialiseren tijdens het schaalproces. Deze strategie kan echter leiden tot ongebruikte capaciteit.

    We raden u aan mechanismen voor omhoog schalen en uitschalen te combineren en te verdelen. Een app kan bijvoorbeeld enige tijd omhoog schalen en zo nodig uitschalen. Verken hoge lagen die grote capaciteit en efficiënt resourcegebruik bieden. Op basis van gebruikspatronen zijn hogere Premium-lagen vaak rendabeler omdat ze beter geschikt zijn.

  • Omgevingskosten optimaliseren: Overweeg de Basic- of Gratis laag om preproductieomgevingen uit te voeren. Deze lagen zijn lage prestaties en lage kosten. Als u de basic- of gratis laag gebruikt, gebruikt u governance om de laag af te dwingen, het aantal exemplaren en CPU's te beperken, het schalen te beperken en logboekretentie te beperken.

  • Ontwerppatronen implementeren: Deze strategie vermindert het aantal aanvragen dat uw workload genereert. Overweeg patronen zoals het back-endpatroon voor front-ends en het patroon Gatewayaggregatie te gebruiken, waardoor het aantal aanvragen kan worden geminimaliseerd en de kosten kunnen worden verlaagd.

  • Regelmatig gegevensgerelateerde kosten controleren: uitgebreide gegevensretentieperioden of dure opslaglagen kunnen leiden tot hoge opslagkosten. Meer uitgaven kunnen zich verzamelen vanwege zowel bandbreedtegebruik als langdurige retentie van logboekgegevens.

    Overweeg om caching te implementeren om de kosten voor gegevensoverdracht te minimaliseren. Begin met lokale cacheopslag in het geheugen en verken vervolgens gedistribueerde cacheopties om het aantal aanvragen voor de back-enddatabase te verminderen. Houd rekening met de bandbreedteverkeerskosten die zijn gekoppeld aan communicatie tussen regio's als uw database zich in een andere regio bevindt.

  • Implementatiekosten optimaliseren: profiteer van implementatiesites om de kosten te optimaliseren. De site wordt uitgevoerd in dezelfde rekenomgeving als het productie-exemplaar. Gebruik ze strategisch voor scenario's zoals blauwgroene implementaties die schakelen tussen sites. Deze aanpak minimaliseert downtime en zorgt voor soepele overgangen.

    Gebruik implementatiesites met voorzichtigheid. U kunt problemen introduceren, zoals uitzonderingen of geheugenlekken, die zowel de bestaande exemplaren als nieuwe exemplaren kunnen beïnvloeden. Zorg ervoor dat u wijzigingen grondig test. Zie Operational Excellence voor operationele richtlijnen.

Aanbevelingen
Aanbeveling Voordeel
(App Service-plan) Kies gratis of Basic-lagen voor lagere omgevingen. We raden deze lagen aan voor experimenteel gebruik. Verwijder de lagen wanneer u ze niet meer nodig hebt. De gratis en Basic-lagen zijn budgetvriendelijk vergeleken met hogere lagen. Ze bieden een rendabele oplossing voor niet-productieomgevingen die niet de volledige functies en prestaties van Premium-abonnementen nodig hebben.
(App Service-plan) Profiteer van kortingen en verken voorkeursprijzen voor:
- Lagere omgevingen met ontwikkel-/testplannen.
- Azure-reserveringen en Azure-besparingsplannen voor toegewezen rekenkracht die u inricht in de Premium V3-laag en App Service Environment.

Gebruik gereserveerde instanties voor stabiele workloads met voorspelbare gebruikspatronen.		 Dev/test-plannen bieden lagere tarieven voor Azure-services, waardoor ze rendabel zijn voor niet-productieomgevingen.

Gebruik gereserveerde instanties om vooraf te betalen voor rekenresources en aanzienlijke kortingen te krijgen.
(App Service) Bewaak de kosten die App Service-resources met zich meebrengen. Voer het hulpprogramma voor kostenanalyse uit in Azure Portal.

Maak budgetten en waarschuwingen om belanghebbenden op de hoogte te stellen.		 U kunt kostenpieken, inefficiënties of onverwachte uitgaven vroegtijdig identificeren. Deze proactieve aanpak helpt u bij het bieden van budgettaire controles om te voorkomen dat de overbesteding wordt overschreden.
(App Service-plan) Inschalen wanneer de vraag afneemt. Als u wilt inschalen, definieert u schaalregels om het aantal exemplaren in Azure Monitor te verminderen. Voorkom verspilling en verminder onnodige uitgaven.

Operationele topprestaties

Operational Excellence richt zich voornamelijk op procedures voor ontwikkelprocedures, waarneembaarheid en releasebeheer.

De ontwerpprincipes van Operational Excellence bieden een ontwerpstrategie op hoog niveau voor het bereiken van deze doelstellingen voor de operationele vereisten van de workload.

Controlelijst voor ontwerp

Start uw ontwerpstrategie op basis van de controlelijst voor ontwerpbeoordeling voor Operational Excellence voor het definiëren van processen voor waarneembaarheid, testen en implementatie met betrekking tot Web Apps.

  • Releases beheren: Implementatiesites gebruiken om releases effectief te beheren. U kunt uw toepassing implementeren in een site, tests uitvoeren en de functionaliteit ervan valideren. Na verificatie kunt u de app naadloos naar productie verplaatsen. Voor dit proces worden geen extra kosten in rekening gebracht omdat de site wordt uitgevoerd in dezelfde virtuele-machineomgeving (VM) als het productie-exemplaar.

  • Voer geautomatiseerde tests uit: voordat u een release van uw web-app promoveerde, test u de prestaties, functionaliteit en integratie met andere onderdelen grondig. Gebruik Azure Load Testing, dat is geïntegreerd met Apache JMeter, een populair hulpprogramma voor prestatietests. Verken geautomatiseerde hulpprogramma's voor andere soorten testen, zoals Phantom voor functionele tests.

  • Onveranderbare eenheden implementeren: Implementeer het patroon Implementatiestempels om App Service te compartimenteren in een onveranderbare stempel. App Service ondersteunt het gebruik van containers, die inherent onveranderbaar zijn. Overweeg aangepaste containers voor uw App Service-web-app.

    Elke stempel vertegenwoordigt een zelfstandige eenheid die u snel kunt uitschalen of inschalen. Eenheden die op deze stempel zijn gebaseerd, zijn tijdelijk en staatloos. Staatloos ontwerp vereenvoudigt bewerkingen en onderhoud. Deze benadering is ideaal voor bedrijfskritieke toepassingen. Zie Voor een voorbeeld een bedrijfskritieke basislijn met App Service.

    Gebruik een IaC-technologie (Infrastructure as Code), zoals Bicep, om eenheden met herhaalbaarheid en consistentie uit te stempelen.

  • Productieomgevingen veilig houden: Maak afzonderlijke App Service-plannen om productie- en preproductieomgevingen uit te voeren. Breng geen wijzigingen rechtstreeks aan in de productieomgeving om stabiliteit en betrouwbaarheid te garanderen. Afzonderlijke exemplaren bieden flexibiliteit bij het ontwikkelen en testen voordat u wijzigingen in productie promoveert.

    Gebruik lage omgevingen om nieuwe functies en configuraties op een geïsoleerde manier te verkennen. Ontwikkel- en testomgevingen kortstondig houden.

  • Certificaten beheren: Voor aangepaste domeinen moet u TLS-certificaten beheren.

    Zorg ervoor dat er processen zijn om certificaten aan te schaffen, te vernieuwen en te valideren. Offload deze processen indien mogelijk naar App Service. Als u uw eigen certificaat gebruikt, moet u de verlenging ervan beheren. Kies een benadering die het beste aansluit bij uw beveiligingsvereisten.

Aanbeveling Voordeel
(App Service) Controleer de status van uw exemplaren en activeer statustests voor exemplaren.

Stel een specifiek pad in voor het afhandelen van statustestaanvragen.		 U kunt snel problemen detecteren en de benodigde acties ondernemen om de beschikbaarheid en prestaties te behouden.
(App Service) Schakel diagnostische logboeken in voor de toepassing en het exemplaar.

Regelmatige logboekregistratie kan de prestaties van het systeem vertragen, opslagkosten toevoegen en risico's veroorzaken als u onbeveiligde toegang tot logboeken hebt. Volg deze aanbevolen procedures:
- Het juiste informatieniveau vastleggen.
- Bewaarbeleid instellen.
- Houd een audittrail bij geautoriseerde toegang en niet-geautoriseerde pogingen.
- Logboeken behandelen als gegevens en besturingselementen voor gegevensbeveiliging toepassen.		 Diagnostische logboeken bieden waardevolle inzichten in het gedrag van uw app. Bewaak verkeerspatronen en identificeer afwijkingen.
(App Service) Profiteer van door App Service beheerde certificaten om certificeringsbeheer naar Azure te offloaden. App Service verwerkt automatisch processen zoals het aanschaffen van certificaten, certificaatverificatie, certificaatvernieuwing en het importeren van certificaten uit Key Vault. U kunt uw certificaat ook uploaden naar Key Vault en de App Service-resourceprovider machtigen om toegang tot het certificaat te krijgen.
(App Service-plan) Valideer app-wijzigingen in de staging-site voordat u deze wisselt met de productiesite. Vermijd downtime en fouten.

Ga snel terug naar de laatst bekende goede status als u een probleem na een wissel detecteert.

Prestatie-efficiëntie

Prestatie-efficiëntie gaat over het onderhouden van de gebruikerservaring, zelfs wanneer er een toename van de belasting is door capaciteit te beheren. De strategie omvat het schalen van resources, het identificeren en optimaliseren van potentiële knelpunten en het optimaliseren van piekprestaties.

De ontwerpprincipes prestatie-efficiëntie bieden een ontwerpstrategie op hoog niveau voor het bereiken van deze capaciteitsdoelen ten opzichte van het verwachte gebruik.

Controlelijst voor ontwerp

Start uw ontwerpstrategie op basis van de controlelijst voor ontwerpbeoordeling voor prestatie-efficiëntie voor het definiëren van een basislijn op basis van key performance indicators voor Web Apps.

  • Prestatie-indicatoren identificeren en bewaken: stel doelen in voor de sleutelindicatoren voor de toepassing, zoals het volume van binnenkomende aanvragen, de tijd die de toepassing nodig heeft om te reageren op aanvragen, aanvragen in behandeling en fouten in HTTP-antwoorden. Houd rekening met belangrijke indicatoren als onderdeel van de prestatiebasislijn voor de workload.

    Leg metrische gegevens van App Service vast die de basis vormen van prestatie-indicatoren. Verzamel logboeken om inzicht te krijgen in resourcegebruik en -activiteiten. Gebruik APM-hulpprogramma's (Application Performance Monitoring), zoals Application Insights, om prestatiegegevens van de toepassing te verzamelen en te analyseren. Zie De naslaginformatie over app Service-bewakingsgegevens voor meer informatie.

    Neem instrumentatie op codeniveau, transactietracering en prestatieprofilering op.

  • Capaciteit evalueren: simuleer verschillende gebruikersscenario's om de optimale capaciteit te bepalen die u nodig hebt om verwacht verkeer te verwerken. Gebruik Belastingstests om te begrijpen hoe uw toepassing zich gedraagt onder verschillende belastingniveaus.

  • Selecteer de juiste laag: Toegewezen rekenkracht gebruiken voor productieworkloads. Premium-lagen bieden grotere SKU's met meer geheugen- en CPU-capaciteit, meer exemplaren en meer functies, zoals zoneredundantie. Zie de prijscategorie Premium V3 voor meer informatie.

  • Optimaliseer uw schaalstrategie: gebruik, indien mogelijk, automatisch schalen in plaats van het aantal exemplaren handmatig aan te passen wanneer het laden van toepassingen verandert. Met automatisch schalen past App Service de servercapaciteit aan op basis van vooraf gedefinieerde regels of triggers. Zorg ervoor dat u voldoende prestatietests uitvoert en stel de juiste regels in voor de juiste triggers.

    Als u prioriteit geeft aan eenvoud tijdens de eerste installatie, gebruikt u een optie voor automatisch schalen waarvoor u geen regels hoeft te definiëren en hoeft u alleen limieten in te stellen.

    Zorg ervoor dat er voldoende resources beschikbaar zijn om optimale prestaties te garanderen. Wijs resources op de juiste manier toe om prestatiedoelen te behouden, zoals reactietijd of doorvoer. Overweeg indien nodig overbezetting van resources.

    Wanneer u regels voor automatisch schalen definieert, moet u rekening houden met de tijd die nodig is om uw toepassing te initialiseren. Houd rekening met deze overhead wanneer u alle schaalbeslissingen neemt.

  • Caching gebruiken: het ophalen van informatie uit een resource die niet regelmatig wordt gewijzigd en die duur is voor toegang, is van invloed op de prestaties. Complexe query's, waaronder joins en meerdere zoekacties, dragen bij aan runtime. Voer caching uit om de verwerkingstijd en latentie te minimaliseren. Cachequeryresultaten om herhaalde retouren naar de database of back-end te voorkomen en de verwerkingstijd voor volgende aanvragen te verminderen.

    Zie Caching voor meer informatie over het gebruik van lokale en gedistribueerde cache in de workload.

  • Bekijk de antipatronen voor prestaties: om ervoor te zorgen dat de webtoepassing wordt uitgevoerd en geschaald in overeenstemming met uw bedrijfsvereisten, vermijdt u de typische antipatronen. Hier volgen enkele antipatronen die door App Service worden gecorrigeerd.

    Antipatroon Beschrijving
    Front-end bezet Resource-intensieve taken kunnen de reactietijd voor aanvragen van gebruikers verlengen en zo hoge latentie veroorzaken.
    Verplaats processen die veel resources verbruiken naar een afzonderlijke back-end. Gebruik een berichtenbroker om resource-intensieve taken in de wachtrij te plaatsen die de back-end ophaalt tot asynchroon proces.
    Geen caching Dien aanvragen uit vanuit een tussenliggende cache vóór de back-enddatabase om de latentie te verminderen.
    Luidruchtige buurman Multitenant-systemen delen resources tussen tenants. De activiteit van één tenant kan een negatief effect hebben op het gebruik van het systeem van een andere tenant. App Service Environment biedt een volledig geïsoleerde en toegewezen omgeving voor het uitvoeren van App Service-apps.
Aanbevelingen
Aanbeveling Voordeel
Schakel de AlwaysOn-instelling in wanneer toepassingen één App Service-plan delen. App Service-apps worden automatisch verwijderd wanneer ze niet actief zijn om resources op te slaan. De volgende aanvraag activeert een koude start, wat time-outs voor aanvragen kan veroorzaken. De toepassing wordt nooit uitgeladen met AlwaysOn ingeschakeld.
Overweeg om HTTP/2 te gebruiken voor toepassingen om de efficiëntie van het protocol te verbeteren. Kies HTTP/2 via HTTP/1.1 omdat HTTP/2 verbindingen volledig multiplexes bevatten, verbindingen hergebruikt om overhead te verminderen en headers te comprimeren om de gegevensoverdracht te minimaliseren.

Compromissen

Mogelijk moet u een compromis tussen ontwerpen maken als u de benaderingen in de controlelijsten voor pijlers gebruikt. Hier volgen enkele voorbeelden van voordelen en nadelen.

Dichtheid en isolatie

  • Hogere dichtheid: plaats meerdere apps binnen hetzelfde App Service-plan om resources te minimaliseren. Alle apps delen resources, zoals CPU en geheugen, waardoor u geld kunt besparen en de operationele complexiteit kunt verminderen. Deze benadering optimaliseert ook het resourcegebruik. Apps kunnen niet-actieve resources van een andere app gebruiken als de belastingspatronen na verloop van tijd veranderen.

    Houd ook rekening met de nadelen. Pieken in gebruik of instabiliteit van een app kunnen bijvoorbeeld van invloed zijn op de prestaties van andere apps. Incidenten in de ene app kunnen ook worden doordrongen naar andere apps in de gedeelde omgeving, wat van invloed kan zijn op de beveiliging.

  • Hogere isolatie: Isolatie helpt interferentie te voorkomen. Deze strategie is van toepassing op beveiliging, prestaties en zelfs scheiding van ontwikkel-, test- en productieomgevingen.

    App Service Environment biedt betere controle over beveiliging en gegevensbeveiliging, omdat elke app eigen beveiligingsinstellingen kan hebben. Uw omgeving kan schendingen bevatten omdat isolatie de straal beperkt. Resourceconflicten worden geminimaliseerd vanuit het perspectief van prestaties. Isolatie maakt onafhankelijk schalen mogelijk op basis van specifieke vraag en individuele capaciteitsplanning.

    Als nadeel is deze aanpak duurder en vereist operationele rigor.

Betrouwbare schaalstrategie

Een goed gedefinieerde schaalstrategie zorgt ervoor dat uw toepassing verschillende belastingen kan verwerken zonder de prestaties in gevaar te brengen. Er zijn echter compromissen met de kosten. Het duurt even om schaalbewerkingen uit te voeren. Wanneer nieuwe resources worden toegewezen, moet de toepassing correct worden geïnitialiseerd voordat aanvragen effectief kunnen worden verwerkt. U kunt resources (prewarm-exemplaren) overprovisionen om een veiligheidsnet te bieden. Zonder die extra capaciteit kan er tijdens de initialisatiefase een vertraging optreden bij het verwerken van aanvragen, wat van invloed is op de gebruikerservaring. Automatische schaalaanpassingsbewerkingen kunnen vroeg genoeg activeren om de juiste resource-initialisatie in te schakelen op het moment dat klanten de resources gebruiken.

Een nadeel is dat overprovisioned resources meer kosten. Er worden kosten per seconde in rekening gebracht voor elk exemplaar, inclusief vooraf inwarmende exemplaren. Hogere lagen omvatten vooraf inwarmende exemplaren. Bepaal of mogelijkheden met duurdere lagen de investering waard zijn.

Bouwredundantie

Redundantie biedt tolerantie, maar brengt ook kosten met zich mee. Serviceniveaudoelstellingen (SLO's) voor uw workload bepalen acceptabele prestatiedrempels. Het wordt verspilling als redundantie de SLO-vereisten overschrijdt. Evalueer of overtollige redundantie slo's verbetert of onnodige complexiteit toevoegt.

Houd ook rekening met de nadelen. Redundantie met meerdere regio's biedt bijvoorbeeld hoge beschikbaarheid, maar voegt complexiteit en kosten toe als gevolg van gegevenssynchronisatie, failovermechanismen en communicatie tussen regio's. Bepaal of zoneredundantie aan uw SLO's kan voldoen.

Azure-beleid

Azure biedt een uitgebreide set ingebouwde beleidsregels met betrekking tot App Service en de bijbehorende afhankelijkheden. Een set Azure-beleidsregels kan enkele van de voorgaande aanbevelingen controleren. U kunt bijvoorbeeld controleren of:

  • De juiste netwerkcontroles zijn aanwezig. U kunt bijvoorbeeld netwerksegmentatie opnemen door App Service in Azure Virtual Network te plaatsen via een virtuele netwerkinjectie om meer controle te hebben over de netwerkconfiguratie. De toepassing heeft geen openbare eindpunten en maakt verbinding met Azure-services via privé-eindpunten.

  • Identiteitscontroles zijn aanwezig. De toepassing gebruikt bijvoorbeeld beheerde identiteiten om zichzelf te verifiëren bij andere resources. Ingebouwde App Service-verificatie (Easy Auth) verifieert binnenkomende aanvragen.

  • Functies zoals externe foutopsporing en basisverificatie zijn uitgeschakeld om het kwetsbaarheid voor aanvallen te verminderen.

Raadpleeg de ingebouwde Azure Policy-definities en andere beleidsregels die van invloed kunnen zijn op de beveiliging van de rekenlaag voor uitgebreide governance.

Aanbevelingen van Azure Advisor

Azure Advisor is een gepersonaliseerde cloudconsultant waarmee u de aanbevolen procedures kunt volgen om uw Azure-implementaties te optimaliseren. Hier volgen enkele aanbevelingen waarmee u de betrouwbaarheid, beveiliging, kosteneffectiviteit, prestaties en operationele uitmuntendheid van uw webtoepassingsexemplaren kunt verbeteren.

Volgende stappen

Bekijk de volgende artikelen als resources die de aanbevelingen laten zien die in dit artikel zijn gemarkeerd.