Bewerken

Delen via


Betrouwbaar web-app-patroon voor .NET - De implementatie plannen

Azure App Service
Azure Front Door
Azure Cache for Redis
.NET

In dit artikel leest u hoe u het patroon Reliable Web App toepast. Het patroon Reliable Web App is een set principes en implementatietechnieken waarmee wordt gedefinieerd hoe u web-apps (opnieuw platformen) moet wijzigen bij het migreren naar de cloud. Het richt zich op de minimale code-updates die u moet uitvoeren om succesvol te zijn in de cloud.

Om de toepassing van deze richtlijnen te vergemakkelijken, is er een referentie-implementatie van het Reliable Web App-patroon dat u kunt implementeren.

Diagram met de architectuur van de referentie-implementatie.Architectuur van de referentie-implementatie. Download een Visio-bestand van deze architectuur.

In de volgende richtlijnen wordt de referentie-implementatie als voorbeeld gebruikt. Voer de volgende stappen uit om een implementatie van het patroon Reliable Web App te plannen:

Bedrijfsdoelen definiëren

De eerste stap bij de overgang naar cloud-computing is het formuleren van uw bedrijfsdoelstellingen. Het patroon Reliable Web App benadrukt het belang van het instellen van zowel onmiddellijke als toekomstige doelstellingen voor uw webtoepassing. Deze doelstellingen zijn van invloed op uw keuze van cloudservices en de architectuur van uw webtoepassing in de cloud.

Voorbeeld: Het fictieve bedrijf Relecloud verkoopt tickets via de on-premises webtoepassing. Relecloud heeft een positieve verkoopprognose en verwacht een toegenomen vraag op hun web-app voor ticketing. Om aan deze vraag te voldoen, hebben ze de doelstellingen voor de webtoepassing gedefinieerd:

  • Wijzigingen in code met lage kosten en hoge waarden toepassen
  • Bereik een serviceniveaudoelstelling (SLO) van 99,9%
  • DevOps-procedures gebruiken
  • Voor kosten geoptimaliseerde omgevingen maken
  • Betrouwbaarheid en beveiliging verbeteren

De on-premises infrastructuur van Relecloud was geen rendabele oplossing om deze doelen te bereiken. Daarom hebben ze besloten dat het migreren van hun webtoepassing naar Azure de meest rendabele manier was om hun onmiddellijke en toekomstige doelstellingen te bereiken.

De juiste beheerde services kiezen

Wanneer u een web-app naar de cloud verplaatst, moet u Azure-services selecteren die voldoen aan uw zakelijke vereisten en overeenkomen met de huidige functies van de on-premises web-app. De uitlijning helpt bij het minimaliseren van de herplatformingsinspanning. Gebruik bijvoorbeeld services waarmee u dezelfde database-engine kunt behouden en bestaande middleware en frameworks kunt ondersteunen. De volgende secties bevatten richtlijnen voor het selecteren van de juiste Azure-services voor uw web-app.

Voorbeeld: Voordat de overstap naar de cloud werd uitgevoerd, was de web-app voor ticketing van Relecloud een on-premises, monolithische, ASP.NET-app. Het werd uitgevoerd op twee virtuele machines en had een Microsoft SQL Server-database. De web-app heeft last van veelvoorkomende uitdagingen bij schaalbaarheid en functie-implementatie. Dit uitgangspunt, hun bedrijfsdoelen en SLO hebben hun servicekeuzen aangereden.

Toepassingsplatform

Kies het beste platform voor het hosten van toepassingen voor uw web-app. Azure heeft veel verschillende rekenopties om te voldoen aan een reeks vereisten voor web-apps. Zie de beslissingsstructuur van Azure Compute voor hulp bij het beperken van opties.

Voorbeeld: Relecloud koos Azure-app Service als het toepassingsplatform om de volgende redenen:

  • Sla (High Service Level Agreement): Het heeft een hoge SLA die voldoet aan de SLO van de productieomgeving van 99,9%.

  • Verminderde beheeroverhead: het is een volledig beheerde oplossing die schaalaanpassing, statuscontroles en taakverdeling afhandelt.

  • .NET-ondersteuning: het ondersteunt de versie van .NET waarin de toepassing is geschreven.

  • Containerisatiemogelijkheid: De web-app kan worden geconvergeerd in de cloud zonder containeriseren, maar het toepassingsplatform biedt ook ondersteuning voor containerisatie zonder azure-services te wijzigen

  • Automatisch schalen: de web-app kan automatisch omhoog, omlaag, in en uit schalen op basis van gebruikersverkeer en instellingen.

Identiteitsbeheer

Kies de beste oplossing voor identiteitsbeheer voor uw web-app. Zie Oplossingen voor identiteitsbeheer en verificatiemethoden vergelijken voor meer informatie.

Voorbeeld: Relecloud heeft Microsoft Entra-id gekozen om de volgende redenen:

  • Verificatie en autorisatie: de toepassing moet medewerkers van het callcenter verifiëren en autoriseren.

  • Schaalbaar: deze schaalt om grotere scenario's te ondersteunen.

  • Beheer van gebruikersidentiteiten: callcentermedewerkers kunnen hun bestaande bedrijfsidentiteiten gebruiken.

  • Autorisatieprotocolondersteuning: Het ondersteunt OAuth 2.0 voor beheerde identiteiten.

Database

Kies de beste database voor uw web-app. Zie de beslissingsstructuur van het Azure-gegevensarchief voor hulp bij het beperken van de opties.

Voorbeeld: De web-app heeft on-premises SQL Server gebruikt en Relecloud wilde het bestaande databaseschema, opgeslagen procedures en functies gebruiken. Er zijn verschillende SQL-producten beschikbaar in Azure, maar Relecloud koos Azure SQL Database om de volgende redenen:

  • Betrouwbaarheid: de laag algemeen gebruik biedt een hoge SLA en redundantie voor meerdere regio's. Het kan een hoge gebruikersbelasting ondersteunen.

  • Beperkte beheeroverhead: Het biedt een beheerd SQL-database-exemplaar.

  • Migratieondersteuning: het biedt ondersteuning voor databasemigratie vanaf on-premises SQL Server.

  • Consistentie met on-premises configuraties: het ondersteunt de bestaande opgeslagen procedures, functies en weergaven.

  • Tolerantie: het ondersteunt back-ups en herstel naar een bepaald tijdstip.

  • Expertise en minimale herwerkbewerking: SQL Database maakt gebruik van interne expertise en vereist minimale werkzaamheden.

Bewaking van toepassingsprestaties

Kies voor een bewaking van toepassingsprestaties voor uw web-app. Application Insights is de azure-systeemeigen APM-oplossing (Application Performance Management). Het is een functie van de bewakingsoplossing van Azure, Azure Monitor.

Voorbeeld: Relecloud heeft ervoor gekozen om Application Insights te gebruiken om de volgende redenen:

  • Integratie met Azure Monitor: Het biedt de beste integratie met Azure Monitor.

  • Anomaliedetectie: Hiermee worden prestatieafwijkingen automatisch gedetecteerd.

  • Probleemoplossing: Hiermee kunt u problemen vaststellen in de actieve app.

  • Bewaking: Het verzamelt informatie over hoe gebruikers de app gebruiken en stelt u in staat om eenvoudig aangepaste gebeurtenissen bij te houden.

  • Zichtbaarheidsverschil: de on-premises oplossing heeft geen oplossing voor bewaking van toepassingsprestaties. Application Insights biedt eenvoudige integratie met het toepassingsplatform en code.

Cache

Kies of u cache wilt toevoegen aan uw web-app-architectuur. Azure Cache voor Redis is de primaire cacheoplossing van Azure. Het is een beheerd gegevensarchief in het geheugen op basis van de Redis-software.

Voorbeeld: De belasting van de web-app van Relecloud is sterk vertekend voor het bekijken van concerten en locatiedetails. Er zijn Azure Cache voor Redis toegevoegd om de volgende redenen:

  • Minder beheeroverhead: het is een volledig beheerde service.

  • Snelheid en volume: het heeft leesbewerkingen met hoge gegevensdoorvoer en lage latentie voor veelgebruikte, trage veranderende gegevens.

  • Diverse ondersteuningsmogelijkheden: het is een uniforme cachelocatie voor alle exemplaren van de web-app die moet worden gebruikt.

  • Externe gegevensopslag: de on-premises toepassingsservers hebben vm-lokale caching uitgevoerd. Met deze installatie zijn niet zeer frequente gegevens overgeslagen en kunnen gegevens niet ongeldig worden.

  • Niet-plaksessies: De sessiestatus externaliseren ondersteunt niet-plakgebonden sessies.

Load balancer

Kies de beste load balancer voor uw web-app. Azure heeft verschillende load balancers. Zie de beste load balancer voor uw app kiezen voor hulp bij het beperken van de opties.

Voorbeeld: Relecloud heeft een load balancer van laag 7 nodig waarmee verkeer naar meerdere regio's kan worden gerouteerd. Relecloud heeft een web-app met meerdere regio's nodig om te voldoen aan de SLO van 99,9%. Relecloud koos Om de volgende redenen voor Azure Front Door :

  • Globale taakverdeling: het is een load balancer van laag 7 die verkeer kan routeren over meerdere regio's.

  • Web Application Firewall: Het integreert systeemeigen met Azure Web Application Firewall.

  • Flexibiliteit voor routering: hiermee kan het toepassingsteam inkomend verkeer configureren om toekomstige wijzigingen in de toepassing te ondersteunen.

  • Verkeersversnelling: Er wordt gebruikgemaakt van anycast om het dichtstbijzijnde Azure-aanwezigheidspunt te bereiken en de snelste route naar de web-app te vinden.

  • Aangepaste domeinen: het ondersteunt aangepaste domeinnamen met flexibele domeinvalidatie.

  • Statustests: De toepassing heeft intelligente statustestbewaking nodig. Azure Front Door gebruikt reacties van de test om de beste oorsprong te bepalen voor het routeren van clientaanvragen.

  • Ondersteuning voor bewaking: het ondersteunt ingebouwde rapporten met een alles-in-één dashboard voor zowel Front Door als beveiligingspatronen. U kunt waarschuwingen configureren die worden geïntegreerd met Azure Monitor. Hiermee kan de toepassing elke aanvraag en mislukte statustests registreren.

  • DDoS-beveiliging: het heeft ingebouwde DDoS-beveiliging op laag 3-4.

  • Netwerk voor contentlevering: Het positioneert Relecloud voor het gebruik van een netwerk voor contentlevering. Het netwerk voor contentlevering biedt siteversnelling.

Web Application Firewall

Kies een webtoepassingsfirewall om uw web-app te beschermen tegen webaanvallen. Azure Web Application Firewall is de Web Application Firewall (WAF) van Azure en biedt gecentraliseerde beveiliging tegen veelvoorkomende webexplots en beveiligingsproblemen.

Voorbeeld: Relecloud nodig om de web-app te beschermen tegen webaanvallen. Ze gebruikten Azure Web Application Firewall om de volgende redenen:

  • Wereldwijde beveiliging: Het biedt verbeterde wereldwijde web-app-beveiliging zonder dat dit ten koste gaat van de prestaties.

  • Botnet-beveiliging: het team kan beveiligingsproblemen van botnets bewaken en configureren.

  • Pariteit met on-premises: de on-premises oplossing werd uitgevoerd achter een webtoepassingsfirewall die wordt beheerd door IT.

  • Gebruiksgemak: Web Application Firewall kan worden geïntegreerd met Azure Front Door.

Configuratieopslag

Kies of u app-configuratieopslag wilt toevoegen aan uw web-app. Azure-app Configuration is een service voor het centraal beheren van toepassingsinstellingen en functievlagmen. Bekijk aanbevolen procedures voor App Configuration om te bepalen of deze service geschikt is voor uw app.

Voorbeeld: Relecloud wilde de configuratie op basis van bestanden vervangen door een centraal configuratiearchief dat kan worden geïntegreerd met het toepassingsplatform en de code. Om de volgende redenen hebben ze App Configuration toegevoegd aan de architectuur:

  • Flexibiliteit: het ondersteunt functievlagmen. Met functievlagmen kunnen gebruikers zich afmelden voor vroege preview-functies in een productieomgeving zonder de app opnieuw te implementeren.

  • Ondersteunt Git-pijplijn: de bron van waarheid voor configuratiegegevens moet een Git-opslagplaats zijn. De pijplijn die nodig is om de gegevens in het centrale configuratiearchief bij te werken.

  • Ondersteunt beheerde identiteiten: het ondersteunt beheerde identiteiten om de verbinding met het configuratiearchief te vereenvoudigen en te beveiligen.

Geheimenbeheerder

Gebruik Azure Key Vault als u geheimen hebt om te beheren in Azure. U kunt Key Vault opnemen in .NET-apps met behulp van het ConfigurationBuilder-object.

Voorbeeld: De on-premises web-app van Relecloud heeft geheimen opgeslagen in codeconfiguratiebestanden, maar het is een betere beveiligingspraktijk om geheimen te externaliseren. Hoewel beheerde identiteiten de voorkeursoplossing zijn voor het maken van verbinding met Azure-resources, had Relecloud toepassingsgeheimen die ze nodig hadden om te beheren. Relecloud heeft Key Vault gebruikt om de volgende redenen:

  • Versleuteling: het ondersteunt versleuteling at rest en in transit.

  • Beheerde identiteiten: de toepassingsservices kunnen beheerde identiteiten gebruiken voor toegang tot het geheime archief.

  • Bewaking en logboekregistratie: het vereenvoudigt de toegang tot audit en genereert waarschuwingen wanneer opgeslagen geheimen worden gewijzigd.

  • Integratie: Het biedt systeemeigen integratie met het Azure-configuratiearchief (App Configuration) en het webhostingplatform (App Service).

Opslagoplossing

Kies de beste opslagoplossing voor uw web-app. Zie Uw opslagopties controleren voor meer informatie.

Voorbeeld: On-premises had de web-app schijfopslag gekoppeld aan elke webserver, maar het team wilde een oplossing voor externe gegevensopslag gebruiken. Relecloud koos om de volgende redenen voor Azure Blob Storage :

  • Beveiligde toegang: de web-app kan eindpunten elimineren voor toegang tot opslag die beschikbaar is voor het openbare internet met anonieme toegang.

  • Versleuteling: hiermee worden data-at-rest en in transit versleuteld.

  • Tolerantie: Het ondersteunt zone-redundante opslag (ZRS). Zone-redundante opslag repliceert gegevens synchroon over drie Azure-beschikbaarheidszones in de primaire regio. Elke beschikbaarheidszone bevindt zich op een afzonderlijke fysieke locatie met onafhankelijke voeding, koeling en netwerken. Deze configuratie moet ervoor zorgen dat de ticketinstallatiekopieën bestand zijn tegen verlies.

Eindpuntbeveiliging

Kies ervoor om alleen privétoegang tot Azure-services in te schakelen. Azure Private Link biedt toegang tot platform-as-a-service-oplossingen via een privé-eindpunt in uw virtuele netwerk. Verkeer tussen uw virtuele netwerk en de service loopt over het Backbone-netwerk van Microsoft.

Voorbeeld: Relecloud heeft Private Link gebruikt om de volgende redenen:

  • Verbeterde beveiligingscommunicatie: Hiermee kan de toepassing privé toegang krijgen tot services op het Azure-platform en vermindert de netwerkvoetafdruk van gegevensarchieven om bescherming te bieden tegen gegevenslekken.

  • Minimale inspanning: de privé-eindpunten ondersteunen het web-app-platform en het databaseplatform dat de web-app gebruikt. Beide platforms spiegelen bestaande on-premises configuraties voor minimale wijzigingen.

Netwerkbeveiliging

Kies of u netwerkbeveiligingsservices wilt toevoegen aan uw virtuele netwerken. Azure Firewall is stateful, netwerkfirewall die netwerkverkeer inspecteert. Met Azure Bastion kunt u veilig verbinding maken met virtuele machines zonder RDP-/SSH-poorten weer te geven.

Voorbeeld: Relecloud heeft een hub- en spoke-netwerktopologie aangenomen en wilde gedeelde netwerkbeveiligingsservices in de hub plaatsen. Azure Firewall verbetert de beveiliging door al het uitgaande verkeer van de spokes te inspecteren om de netwerkbeveiliging te verbeteren. Relecloud heeft Azure Bastion nodig voor beveiligde implementaties vanaf een jumphost in het DevOps-subnet.

De juiste architectuur kiezen

Nadat u hebt gedefinieerd wat er beschikbaar is voor uw web-app en de beste cloudservices hebt geselecteerd, moet u de beste architectuur voor uw web-app bepalen. Uw architectuur moet uw bedrijfsvereisten, technische vereisten en SLO ondersteunen.

Architectuurredundantie kiezen

De bedrijfsdoelen bepalen het niveau van infrastructuur en gegevensredundantie die uw web-app nodig heeft. De SLO van de web-app biedt een goede basislijn voor het begrijpen van uw redundantievereisten. Bereken de samengestelde SLA alle afhankelijkheden op het kritieke pad van de beschikbaarheid. Afhankelijkheden moeten Azure-services en niet-Microsoft-oplossingen omvatten.

Wijs een beschikbaarheidsraming toe voor elke afhankelijkheid. Service level agreements (SLA's) bieden een goed uitgangspunt, maar SLA's houden geen rekening met code, implementatiestrategieën en beslissingen over architectuurconnectiviteit.

Voorbeeld: Relecloud heeft de services geïdentificeerd op het kritieke pad naar beschikbaarheid. Ze hebben Azure SLA's gebruikt voor schattingen van beschikbaarheid. Op basis van de samengestelde SLA-berekening had Relecloud een architectuur met meerdere regio's nodig om te voldoen aan de SLO van 99,9%.

Een netwerktopologie kiezen

Kies de juiste netwerktopologie voor uw web- en netwerkvereisten. Een sternetwerktopologie is standaardconfiguratie in Azure. Het biedt voordelen voor kosten, beheer en beveiliging. Het biedt ook ondersteuning voor hybride connectiviteitsopties voor on-premises netwerken.

Voorbeeld: Relecloud heeft een hub- en spoke-netwerktopologie gekozen om de beveiliging van hun implementatie met meerdere regio's te verbeteren tegen lagere kosten- en beheeroverhead.

Gegevensredundantie kiezen

Zorg ervoor dat gegevens betrouwbaar zijn door deze te distribueren over de regio's en beschikbaarheidszones van Azure; hoe groter hun geografische scheiding, hoe hoger de betrouwbaarheid.

  • Stel een RPO (Recovery Point Objective) in. RPO definieert het maximaal toelaatbare gegevensverlies tijdens een storing, waarbij wordt uitgelegd hoe vaak gegevens replicatie nodig hebben. Een RPO van één uur betekent bijvoorbeeld dat er maximaal een uur aan recente gegevensverlies kan worden geaccepteerd.

  • Gegevensreplicatie implementeren. Gegevensreplicatie uitlijnen met uw architectuur en RPO. Azure biedt doorgaans ondersteuning voor synchrone replicatie binnen beschikbaarheidszones. Gebruik meerdere zones om de betrouwbaarheid eenvoudig te verbeteren. Voor web-apps met meerdere regio's in een actief-passieve installatie repliceert u gegevens naar de passieve regio volgens de RPO van de web-app, zodat de replicatiefrequentie de RPO overschrijdt. Actief-actieve configuraties vereisen bijna realtime gegevenssynchronisatie tussen regio's, waardoor codeaanpassingen mogelijk noodzakelijk zijn.

  • Maak een failoverplan. Ontwikkel een plan voor failover (herstel na noodgevallen) met een overzicht van de reactiestrategieën op storingen, afhankelijk van downtime of functionaliteitsverlies. Geef de beoogde hersteltijd (RTO) op voor maximaal acceptabele downtime. Zorg ervoor dat het failoverproces sneller is dan RTO. Beslis over geautomatiseerde of handmatige failovermechanismen voor consistentie en controle en detail over de terugkeer naar het normale bewerkingsproces. Test het failoverplan om de effectiviteit te garanderen.

Volgende stap

In dit artikel hebt u gezien hoe u een implementatie van het patroon Reliable Web App plant. De volgende stap is het toepassen van de implementatietechnieken van het patroon Reliable Web App.