Betrouwbaar web-app-patroon voor .NET

Dit artikel bevat richtlijnen voor het implementeren van het patroon Reliable Web App. In dit patroon wordt beschreven hoe u web-apps voor cloudmigratie wijzigt (opnieuw platformen). Het biedt prescriptieve architectuur, code en configuratierichtlijnen die zijn afgestemd op de principes van de Azure Well-Architected Framework-.

Waarom het patroon Reliable Web App voor .NET?

Het patroon Reliable Web App is een set principes en implementatietechnieken waarmee wordt gedefinieerd hoe u web-apps opnieuw moet platformen wanneer u ze naar de cloud migreert. Het richt zich op de minimale code-updates die u moet uitvoeren om succesvol te zijn in de cloud. In de volgende richtlijnen wordt een referentie-implementatie als voorbeeld gebruikt. De richtlijnen volgen het herplatformtraject van het fictieve bedrijf Relecloud om uw reis bedrijfscontext te bieden. Voordat het patroon Reliable Web App voor .NET werd geïmplementeerd, had Relecloud een monolithische on-premises ticketing-web-app die gebruikmaakt van het ASP.NET framework.

Het patroon Reliable Web App implementeren

Dit artikel bevat richtlijnen voor architectuur, code en configuratie voor het implementeren van het reliable web-app-patroon. Gebruik de volgende koppelingen om naar de specifieke richtlijnen te gaan die u nodig hebt:

• Zakelijke context. stem deze richtlijnen af op uw bedrijfscontext en leer hoe u onmiddellijke en langetermijndoelen definieert die bepalend zijn voor het opnieuw platformeren van beslissingen.
• richtlijnen voor architectuur. Meer informatie over het selecteren van de juiste cloudservices en het ontwerpen van een architectuur die voldoet aan uw bedrijfsvereisten.
• coderichtlijnen. Implementeer drie ontwerppatronen om de betrouwbaarheid en prestatie-efficiëntie van uw web-app in de cloud te verbeteren: de patronen voor opnieuw proberen, circuitonderbreker en Cache-Aside.
• configuratierichtlijnen. verificatie en autorisatie configureren, beheerde identiteiten, gerechtende omgevingen, infrastructuur als code en bewaking.

Zakelijke context

De eerste stap bij het opnieuw platformen van een web-app is het definiëren van uw bedrijfsdoelstellingen. U moet onmiddellijke doelen instellen, zoals serviceniveaudoelstellingen (SLO) en kostenoptimalisatiedoelen, en ook toekomstige doelen voor uw webtoepassing. Deze doelstellingen zijn van invloed op uw keuze van cloudservices en de architectuur van uw webtoepassing in de cloud. Definieer een doel-SLO voor uw web-app, zoals 99,9% uptime. Bereken de samengestelde SLA voor alle services die van invloed zijn op de beschikbaarheid van uw web-app.

Relecloud heeft bijvoorbeeld 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 SLO van 99,9%.
• DevOps-procedures gebruiken.
• Voor kosten geoptimaliseerde omgevingen maken.
• Verbeter de betrouwbaarheid en beveiliging.

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

Uitleg bij architectuur

Het patroon Reliable Web App heeft enkele essentiële architecturale elementen. U hebt DNS nodig voor het beheren van eindpuntomzetting, een webtoepassingsfirewall om schadelijk HTTP-verkeer te blokkeren en een load balancer om binnenkomende gebruikersaanvragen te routeren en te beveiligen. Het toepassingsplatform fungeert als host voor uw web-app-code en roept alle back-endservices aan via privé-eindpunten in een virtueel netwerk. Een hulpprogramma voor bewaking van toepassingsprestaties legt metrische gegevens en logboeken vast, zodat u inzicht krijgt in uw web-app.

Figuur 1. Essentiële architecturale elementen van het patroon Reliable Web App.

De architectuur ontwerpen

Ontwerp uw infrastructuur ter ondersteuning van uw metrische herstelgegevens, zoals uw beoogde hersteltijd (RTO) en RPO (Recovery Point Objective). De RTO beïnvloedt de beschikbaarheid en moet ondersteuning bieden voor uw SLO. Bepaal een RPO en configureer gegevensredundantie om te voldoen aan de RPO.

• Kies de betrouwbaarheid van de infrastructuur. Bepaal hoeveel beschikbaarheidszones en regio's u nodig hebt om te voldoen aan uw beschikbaarheidsvereisten. Voeg beschikbaarheidszones en regio's toe totdat de samengestelde SLA voldoet aan uw SLO. Het patroon Reliable Web App ondersteunt meerdere regio's voor een actief-actief- of actief-passieve configuratie. De referentie-implementatie maakt bijvoorbeeld gebruik van een actief-passieve configuratie om te voldoen aan een SLO van 99,9%.

  Voor een web-app met meerdere regio's configureert u uw load balancer om verkeer naar de tweede regio te routeren ter ondersteuning van een actief-actief- of actief-passieve configuratie, afhankelijk van de behoeften van uw bedrijf. Voor de twee regio's zijn dezelfde services vereist, behalve één regio heeft een virtueel hubnetwerk waarmee de regio's worden verbonden. Gebruik een hub-and-spoke-netwerktopologie om resources, zoals een netwerkfirewall, te centraliseren en te delen. Als u virtuele machines hebt, voegt u een bastionhost toe aan het virtuele hubnetwerk om deze te beheren met verbeterde beveiliging. (Zie afbeelding 2.)

  

  Figuur 2. Het patroon Reliable Web App met een tweede regio en een hub-and-spoke-topologie.

• Kies een netwerktopologie. Kies de juiste netwerktopologie voor uw web- en netwerkvereisten. Als u van plan bent om meerdere virtuele netwerken te gebruiken, gebruikt u een hub-and-spoke-netwerktopologie. Het biedt voordelen van kosten, beheer en beveiliging en hybride connectiviteitsopties voor on-premises en virtuele netwerken.

De juiste Azure-services kiezen

Wanneer u een web-app naar de cloud verplaatst, moet u Azure-services kiezen die voldoen aan uw bedrijfsvereisten en die overeenkomen met de huidige functies van de on-premises web-app. Deze 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.

Voordat de app naar de cloud werd verplaatst, was de web-app voor ticketing van Relecloud bijvoorbeeld een on-premises monolithische ASP.NET-app. Deze is uitgevoerd op twee virtuele machines en heeft een SQL Server-database gebruikt. De web-app heeft last van veelvoorkomende problemen met schaalbaarheid en functie-implementatie. Dit uitgangspunt, hun bedrijfsdoelen en SLO hebben hun servicekeuzen aangereden.

• Toepassingsplatform: gebruik Azure-app Service als uw toepassingsplatform. Relecloud koos 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%.
  • Minder 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 in- en uitschalen op basis van gebruikersverkeer en configuratie-instellingen. Het platform biedt ook ondersteuning voor omhoog of omlaag schalen om aan verschillende hostingvereisten te voldoen.

• Identiteitsbeheer: Gebruik Microsoft Entra-id als uw oplossing voor identiteits- en toegangsbeheer. Relecloud koos om de volgende redenen voor Microsoft Entra-id:

  • Verificatie en autorisatie. De toepassing moet medewerkers van het callcenter verifiëren en autoriseren.
  • Schaalbare. Microsoft Entra ID wordt geschaald om grotere scenario's te ondersteunen.
  • Gebruikersidentiteitsbeheer. Callcentermedewerkers kunnen hun bestaande bedrijfsidentiteiten gebruiken.
  • Ondersteuning voor autorisatieprotocol. Microsoft Entra ID ondersteunt OAuth 2.0 voor beheerde identiteiten.

• Database: Gebruik een service waarmee u dezelfde database-engine kunt behouden. Gebruik de beslissingsstructuur voor gegevensarchief om uw selectie te begeleiden. De web-app van Relecloud heeft on-premises SQL Server gebruikt. Ze wilden 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.
  • Minder beheeroverhead. SQL Database biedt een beheerd SQL Database-exemplaar.
  • Migratieondersteuning. Het biedt ondersteuning voor databasemigratie vanuit on-premises SQL Server.
  • Consistentie met on-premises configuraties. Het ondersteunt de bestaande opgeslagen procedures, functies en weergaven.
  • Herstellingsvermogen. Het ondersteunt back-ups en herstel naar een bepaald tijdstip.
  • Expertise en minimale rework. Met SQL Database kan Relecloud profiteren van bestaande expertise en is minimale hoeveelheid werk vereist.

• Bewaking van toepassingsprestaties: Gebruik Application Insights- om telemetriegegevens voor uw toepassing te analyseren. Relecloud heeft ervoor gekozen Om de volgende redenen Application Insights te gebruiken:

  • Integratie met Azure Monitor. Het biedt de beste integratie met Azure Monitor.
  • Anomaliedetectie. Er worden automatisch prestatieafwijkingen gedetecteerd.
  • Probleemoplossing. Het helpt u bij het diagnosticeren van problemen in de actieve app.
  • Monitoring. 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 het bewaken van de prestaties van toepassingen. Application Insights biedt eenvoudige integratie met het toepassingsplatform en code.

• Cache: Kiezen of u een cache wilt toevoegen aan de architectuur van uw web-app. Azure Cache voor Redis is de primaire Azure Cache-oplossing. Het is een beheerd gegevensarchief in het geheugen dat is gebaseerd op Redis-software. De belasting van de web-app van Relecloud is sterk vertekend voor het bekijken van concerten en locatiedetails. Relecloud heeft Om de volgende redenen Azure Cache voor Redis toegevoegd:

  • Minder beheeroverhead. Het is een volledig beheerde service.
  • Snelheid en volume. Het bevat leesbewerkingen met een hoge gegevensdoorvoer en lage latentie voor veelgebruikte, langzaam 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. Het externaliseren van de sessiestatus ondersteunt niet-plakgebonden sessies.

• Load balancer: webtoepassingen die gebruikmaken van PaaS-oplossingen, moeten Gebruikmaken van Azure Front Door, Azure Application Gateway of beide, afhankelijk van de architectuur en vereisten van de web-app. Gebruik de beslissingsstructuur van de load balancer om de juiste load balancer te kiezen. Relecloud had een load balancer van laag 7 nodig waarmee verkeer naar meerdere regio's kan worden gerouteerd. Het bedrijf 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 is systeemeigen geïntegreerd 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-punt van aanwezigheid te bereiken en de snelste route naar de web-app te vinden.
  • Aangepaste domeinen. Het ondersteunt aangepaste domeinnamen met flexibele domeinvalidatie.
  • Statustests. Voor de toepassing is intelligente statustestcontrole vereist. Azure Front Door gebruikt reacties van de test om de beste oorsprong te bepalen voor het routeren van clientaanvragen.
  • Bewakingsondersteuning. Het biedt ondersteuning voor ingebouwde rapporten met een alles-in-één dashboard voor zowel Azure Front Door als beveiligingspatronen. U kunt waarschuwingen configureren die worden geïntegreerd met Azure Monitor. Met Azure Front Door 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 om een netwerk voor contentlevering te gebruiken. Het netwerk voor contentlevering biedt siteversnelling.

• Web Application Firewall: Gebruik Azure Web Application Firewall om gecentraliseerde beveiliging te bieden tegen veelvoorkomende aanvallen en beveiligingsproblemen op internet. Relecloud maakt gebruik van 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 instellingen bewaken en configureren om beveiligingsproblemen met betrekking tot botnets te verhelpen.
  • 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. 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 dat app opnieuw hoeft te worden geïmplementeerd.
  • Ondersteuning voor Git-pijplijnen. 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.
  • Ondersteuning voor 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. De on-premises web-app van Relecloud heeft geheimen opgeslagen in codeconfiguratiebestanden, maar een betere beveiligingspraktijk is het opslaan van geheimen op een locatie die ondersteuning biedt voor RBAC en controlebesturingselementen. 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:

  • Codering. Het ondersteunt versleuteling-at-rest en in transit.
  • Ondersteuning voor beheerde identiteiten. De toepassingsservices kunnen beheerde identiteiten gebruiken om toegang te krijgen tot het geheime archief.
  • Bewaking en logboekregistratie. Key Vault vereenvoudigt controletoegang en genereert waarschuwingen wanneer opgeslagen geheimen worden gewijzigd.
  • Integratie. Key Vault biedt systeemeigen integratie met het Azure-configuratiearchief (App Configuration) en het webhostingplatform (App Service).

• Storage-oplossing: Zie Opties voor Azure-opslag om de juiste opslagoplossing te kiezen op basis van uw vereisten. De on-premises web-app van Relecloud had 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 :

  • Verbeterde toegang tot beveiliging. De web-app kan eindpunten elimineren voor toegang tot opslag die beschikbaar is voor het openbare internet met anonieme toegang.
  • Codering. Blob Storage versleutelt data-at-rest en in transit.
  • Herstellingsvermogen. Blob Storage 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: Gebruik Azure Private Link voor toegang tot PaaS-oplossingen (Platform as a Service) via een privé-eindpunt in uw virtuele netwerk. Verkeer tussen uw virtuele netwerk en de service loopt over het Backbone-netwerk van Microsoft. Relecloud koos Private Link om de volgende redenen:

  • Verbeterde beveiligingscommunicatie. Private Link biedt de toepassing privé toegang 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 door de web-app wordt gebruikt. Beide platforms spiegelen bestaande on-premises configuraties, dus minimale wijziging is vereist.

• Netwerkbeveiliging. Gebruik Azure Firewall- om inkomend en uitgaand verkeer op netwerkniveau te beheren. Gebruik Azure Bastion- om verbinding te maken met virtuele machines met verbeterde beveiliging, zonder RDP-/SSH-poorten weer te geven. Relecloud heeft een hub-and-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 verbeterde beveiligingsimplementaties vanaf een jumphost in het DevOps-subnet.

Richtlijnen voor code

Als u een web-app naar de cloud wilt verplaatsen, moet u de code van uw web-app bijwerken met het patroon Opnieuw proberen, circuitonderbrekerpatroon en Cache-Aside patroon.

Figuur 3. Rollen van de ontwerppatronen.

Elk ontwerppatroon biedt voordelen voor workloadontwerp die zijn afgestemd op een of meer pijlers van het Well-Architected Framework. Hier volgt een overzicht van de patronen die u moet implementeren:

1. Patroon voor opnieuw proberen. Met het patroon Opnieuw proberen worden tijdelijke fouten verwerkt door bewerkingen opnieuw uit te voeren die af en toe mislukken. Implementeer dit patroon voor alle uitgaande aanroepen naar andere Azure-services.

2. Circuitonderbrekerpatroon. Het circuitonderbrekerpatroon voorkomt dat een toepassing bewerkingen opnieuw probeert uit te voeren die niet tijdelijk zijn. Implementeer dit patroon in alle uitgaande aanroepen naar andere Azure-services.

3. Cache-Aside patroon. Het Cache-Aside patroon laadt gegevens op aanvraag in een cache vanuit een gegevensarchief. Implementeer dit patroon voor aanvragen naar de database.

Het patroon Opnieuw proberen implementeren

Voeg het patroon Opnieuw proberen toe aan uw toepassingscode om tijdelijke serviceonderbrekingen aan te pakken. Deze onderbrekingen worden tijdelijke fouten genoemd. Tijdelijke fouten lossen zichzelf meestal binnen enkele seconden op. Met het patroon Opnieuw proberen kunt u mislukte aanvragen opnieuw verzenden. Hiermee kunt u ook de vertraging tussen nieuwe pogingen en het aantal pogingen configureren dat moet worden uitgevoerd voordat een fout wordt opgegeven.

• Ingebouwde mechanismen voor opnieuw proberen gebruiken. Gebruik het ingebouwde mechanisme voor opnieuw proberen dat de meeste Azure-services bieden om uw implementatie te versnellen. De referentie-implementatie maakt bijvoorbeeld gebruik van verbindingstolerantie in Entity Framework Core om het patroon Opnieuw proberen toe te passen in aanvragen op SQL Database:

  services.AddDbContextPool<ConcertDataContext>(options => options.UseSqlServer(sqlDatabaseConnectionString,
      sqlServerOptionsAction: sqlOptions =>
      {
          sqlOptions.EnableRetryOnFailure(
          maxRetryCount: 5,
          maxRetryDelay: TimeSpan.FromSeconds(3),
          errorNumbersToAdd: null);
      }));
  

• Gebruik programmeerbibliotheken voor opnieuw proberen. Voor HTTP-communicatie integreert u een standaardtolerantiebibliotheek zoals Polly- of Microsoft.Extensions.Http.Resilience. Deze bibliotheken bieden uitgebreide mechanismen voor opnieuw proberen die essentieel zijn voor het beheren van communicatie met externe webservices. De referentie-implementatie maakt bijvoorbeeld gebruik van Polly om het patroon Opnieuw proberen af te dwingen telkens wanneer de code een object maakt dat het IConcertSearchService-object aanroept:

  private void AddConcertSearchService(IServiceCollection services)
  {
      var baseUri = Configuration["App:RelecloudApi:BaseUri"];
      if (string.IsNullOrWhiteSpace(baseUri))
      {
          services.AddScoped<IConcertSearchService, MockConcertSearchService>();
      }
      else
      {
          services.AddHttpClient<IConcertSearchService, RelecloudApiConcertSearchService>(httpClient =>
          {
              httpClient.BaseAddress = new Uri(baseUri);
              httpClient.DefaultRequestHeaders.Add(HeaderNames.Accept, "application/json");
              httpClient.DefaultRequestHeaders.Add(HeaderNames.UserAgent, "Relecloud.Web");
          })
          .AddPolicyHandler(GetRetryPolicy())
          .AddPolicyHandler(GetCircuitBreakerPolicy());
      }
  }
  
  private static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy()
  {
      var delay = Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromMilliseconds(500), retryCount: 3);
      return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .WaitAndRetryAsync(delay);
  }
  

Het circuitonderbrekerpatroon implementeren

Gebruik het circuitonderbrekerpatroon om serviceonderbrekingen af te handelen die geen tijdelijke fouten zijn. Het circuitonderbrekerpatroon voorkomt dat een toepassing continu toegang probeert te krijgen tot een service die niet reageert. De toepassing wordt vrijgegeven en helpt cpu-cycli te voorkomen, zodat de toepassing de prestatie-integriteit voor eindgebruikers behoudt.

De referentie-implementatie past bijvoorbeeld het circuitonderbrekerpatroon toe op alle aanvragen voor de API. Er wordt gebruikgemaakt van de HandleTransientHttpError logica om HTTP-aanvragen te detecteren die veilig opnieuw kunnen worden geprobeerd, maar beperkt het aantal cumulatieve fouten gedurende een opgegeven periode:

private static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy()
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));
}

Het cache-aside-patroon implementeren

Voeg het cache-aside-patroon toe aan uw web-app om het gegevensbeheer in het geheugen te verbeteren. Het patroon wijst de toepassing de verantwoordelijkheid toe voor het verwerken van gegevensaanvragen en zorgt voor consistentie tussen de cache en permanente opslag, zoals een database. Het verkort de reactietijden, verbetert de doorvoer en vermindert de behoefte aan meer schaalaanpassing. Het vermindert ook de belasting van het primaire gegevensarchief, wat de betrouwbaarheid en kostenoptimalisatie verbetert. Volg deze aanbevelingen om het cache-aside-patroon te implementeren:

• Configureer de toepassing voor het gebruik van een cache. Productie-apps moeten gebruikmaken van een gedistribueerde Redis-cache. Deze cache verbetert de prestaties door databasequery's te verminderen. Het maakt ook niet-plakkerige sessies mogelijk, zodat de load balancer verkeer gelijkmatig kan verdelen. De referentie-implementatie maakt gebruik van een gedistribueerde Redis-cache. De AddAzureCacheForRedis methode configureert de toepassing voor het gebruik van Azure Cache voor Redis:

  private void AddAzureCacheForRedis(IServiceCollection services)
  {
      if (!string.IsNullOrWhiteSpace(Configuration["App:RedisCache:ConnectionString"]))
      {
          services.AddStackExchangeRedisCache(options =>
          {
              options.Configuration = Configuration["App:RedisCache:ConnectionString"];
          });
      }
      else
      {
          services.AddDistributedMemoryCache();
      }
  }
  

• Gegevens die veel nodig zijn in de cache opslaan. Pas het Cache-Aside patroon toe op gegevens met hoge behoeften om de effectiviteit ervan te verbeteren. Gebruik Azure Monitor om de CPU, het geheugen en de opslag van de database bij te houden. Met deze metrische gegevens kunt u bepalen of u een kleinere database-SKU kunt gebruiken nadat u het Cache-Aside patroon hebt toegepast. De referentie-implementatie slaat bijvoorbeeld gegevens met een hoge behoefte in de cache op die ondersteuning bieden voor de pagina Geplande concerten. De methode GetUpcomingConcertsAsync haalt gegevens op uit de SQL Database in de Redis-cache en vult de cache met de meest recente concertgegevens:

  public async Task<ICollection<Concert>> GetUpcomingConcertsAsync(int count)
  {
      IList<Concert>? concerts;
      var concertsJson = await this.cache.GetStringAsync(CacheKeys.UpcomingConcerts);
      if (concertsJson != null)
      {
          // There is cached data. Deserialize the JSON data.
          concerts = JsonSerializer.Deserialize<IList<Concert>>(concertsJson);
      }
      else
      {
          // There's nothing in the cache. Retrieve data 
          // from the repository and cache it for one hour.
          concerts = await this.database.Concerts.AsNoTracking()
              .Where(c => c.StartTime > DateTimeOffset.UtcNow && c.IsVisible)
              .OrderBy(c => c.StartTime)
              .Take(count)
              .ToListAsync();
          concertsJson = JsonSerializer.Serialize(concerts);
          var cacheOptions = new DistributedCacheEntryOptions {
              AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1)
          };
          await this.cache.SetStringAsync(CacheKeys.UpcomingConcerts, concertsJson, cacheOptions);
      }
      return concerts ?? new List<Concert>();
  }
  

• Houd cachegegevens actueel. Plan regelmatige cache-updates om te synchroniseren met de meest recente databasewijzigingen. Gebruik de gegevensvolatiliteit en de gebruiker moet de optimale vernieuwingsfrequentie bepalen. Deze procedure zorgt ervoor dat de toepassing gebruikmaakt van het Cache-Aside patroon om zowel snelle toegang als huidige informatie te bieden. De referentie-implementatie slaat bijvoorbeeld slechts één uur gegevens in de cache op en gebruikt de CreateConcertAsync methode om de cachesleutel te wissen wanneer de gegevens worden gewijzigd:

  public async Task<CreateResult> CreateConcertAsync(Concert newConcert)
  {
      database.Add(newConcert);
      await this.database.SaveChangesAsync();
      this.cache.Remove(CacheKeys.UpcomingConcerts);
      return CreateResult.SuccessResult(newConcert.Id);
  }
  

• Zorg voor gegevensconsistentie. Implementeer mechanismen voor het bijwerken van de cache direct na een schrijfbewerking van de database. Gebruik gebeurtenisgestuurde updates of toegewezen gegevensbeheerklassen om cachecoherentie te garanderen. Het consistent synchroniseren van de cache met databasewijzigingen is centraal in het cache-aside-patroon. De referentie-implementatie maakt gebruik van de UpdateConcertAsync methode om de gegevens in de cache consistent te houden:

  public async Task<UpdateResult> UpdateConcertAsync(Concert existingConcert), 
  {
     database.Update(existingConcert);
     await database.SaveChangesAsync();
     this.cache.Remove(CacheKeys.UpcomingConcerts);
     return UpdateResult.SuccessResult();
  }
  

Configuratierichtlijnen

De volgende secties bevatten richtlijnen voor het implementeren van de configuratie-updates. Elke sectie wordt uitgelijnd met een of meer pijlers van het Well-Architected Framework.

Gebruikersverificatie en -autorisatie configureren

Wanneer u webtoepassingen naar Azure migreert, configureert u gebruikersverificatie en autorisatiemechanismen. Volg deze aanbevelingen:

• Gebruik een identiteitsplatform. Gebruik het Microsoft Identity Platform om verificatie van web-apps in te stellen. Dit platform ondersteunt toepassingen die gebruikmaken van één Microsoft Entra-directory, meerdere Microsoft Entra-mappen van verschillende organisaties en Microsoft-identiteiten of sociale accounts.

• Maak een toepassingsregistratie. Microsoft Entra ID vereist een toepassingsregistratie in de primaire tenant. De toepassingsregistratie helpt ervoor te zorgen dat gebruikers die toegang krijgen tot de web-app identiteiten hebben in de primaire tenant.

• Platformfuncties gebruiken. Minimaliseer de noodzaak van aangepaste verificatiecode met behulp van platformmogelijkheden om gebruikers te verifiëren en toegang te krijgen tot gegevens. App Service- biedt bijvoorbeeld ingebouwde verificatieondersteuning, zodat u gebruikers kunt aanmelden en gegevens kunt openen terwijl u minimale of geen code in uw web-app schrijft.

• Autorisatie in de toepassing afdwingen. Gebruik RBAC om minimale bevoegdheden toe te wijzen aan toepassingsrollen. Specifieke rollen definiëren voor verschillende gebruikersacties om overlapping te voorkomen en duidelijkheid te garanderen. Wijs gebruikers toe aan de juiste rollen en zorg ervoor dat ze alleen toegang hebben tot de benodigde resources en acties.

• Geef de voorkeur aan tijdelijke toegang tot opslag. Gebruik tijdelijke machtigingen om te beschermen tegen onbevoegde toegang en schendingen. U kunt bijvoorbeeld SAS- (Shared Access Signatures) gebruiken om de toegang tot een bepaalde periode te beperken. Gebruik SAS voor gebruikersdelegering om de beveiliging te maximaliseren wanneer u tijdelijke toegang verleent. Het is de enige SAS die gebruikmaakt van Microsoft Entra ID-referenties en waarvoor geen permanente opslagaccountsleutel is vereist.

• Autorisatie afdwingen in Azure. Gebruik Azure RBAC om minimale bevoegdheden toe te wijzen aan gebruikersidentiteiten. Azure RBAC definieert de Azure-resources waartoe identiteiten toegang hebben, wat ze kunnen doen met deze resources en de gebieden waartoe ze toegang hebben.

• Vermijd permanente verhoogde machtigingen. Gebruik Microsoft Entra Privileged Identity Management om Just-In-Time-toegang te verlenen voor bevoorrechte bewerkingen. Ontwikkelaars hebben bijvoorbeeld vaak toegang op beheerdersniveau nodig om databases te maken/verwijderen, tabelschema's te wijzigen en gebruikersmachtigingen te wijzigen. Wanneer u Just-In-Time-toegang gebruikt, ontvangen gebruikersidentiteiten tijdelijke machtigingen om bevoorrechte taken uit te voeren.

Beheerde identiteiten gebruiken

Gebruik beheerde identiteiten voor alle Azure-services die deze ondersteunen. Met een beheerde identiteit kunnen Azure-resources (workloadidentiteiten) worden geverifieerd bij en communiceren met andere Azure-services zonder dat u referenties hoeft te beheren. Ter vereenvoudiging van de migratie kunt u on-premises verificatieoplossingen blijven gebruiken voor hybride en verouderde systemen, maar u moet ze zo snel mogelijk overschakelen naar beheerde identiteiten. Volg deze aanbevelingen om beheerde identiteiten te implementeren:

• Kies het juiste type beheerde identiteit. Geef de voorkeur aan door de gebruiker toegewezen beheerde identiteiten wanneer u twee of meer Azure-resources hebt die dezelfde set machtigingen nodig hebben. Deze aanpak is efficiënter dan het maken van door het systeem toegewezen beheerde identiteiten voor elk van deze resources en het toewijzen van dezelfde machtigingen aan al deze resources. Gebruik anders door het systeem toegewezen beheerde identiteiten.

• Minimale bevoegdheden configureren. Gebruik Azure RBAC- om alleen machtigingen te verlenen die essentieel zijn voor bewerkingen, zoals CRUD-acties in databases of toegang tot geheimen. Machtigingen voor workloadidentiteit zijn permanent, zodat u geen Just-In-Time- of Korte-termijnmachtigingen kunt opgeven voor workloadidentiteiten. Als Azure RBAC geen specifiek scenario omvat, moet u Azure RBAC aanvullen met toegangsbeleid op Azure-serviceniveau.

• Beveiliging bieden voor resterende geheimen. Sla eventuele resterende geheimen op in Azure Key Vault. Laad geheimen uit Key Vault bij het opstarten van de toepassing in plaats van tijdens elke HTTP-aanvraag. Toegang met hoge frequentie binnen HTTP-aanvragen kan de transactielimieten van Key Vault overschrijden. Sla toepassingsconfiguraties op in Azure-app Configuratie.

De referentie-implementatie maakt gebruik van het argument Authentication in de verbindingsreeks van de SQL-database, zodat App Service verbinding kan maken met de SQL-database met behulp van een beheerde identiteit: Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default. Er wordt gebruikgemaakt van DefaultAzureCredential om de web-API verbinding te laten maken met Key Vault met behulp van een beheerde identiteit:

    builder.Configuration.AddAzureAppConfiguration(options =>
    {
         options
            .Connect(new Uri(builder.Configuration["Api:AppConfig:Uri"]), new DefaultAzureCredential())
            .ConfigureKeyVault(kv =>
            {
                // Some of the values coming from App Configuration
                // are stored in Key Vault. Use the managed identity
                // of this host for the authentication.
                kv.SetCredential(new DefaultAzureCredential());
            });
    });

Omgevingen rechten verlenen

Gebruik prestatielagen (SKU's) van Azure-services die voldoen aan de behoeften van elke omgeving zonder deze te overschrijden. Volg deze aanbevelingen om uw omgevingen te beveiligen:

• Kosten schatten. Gebruik de Azure-prijscalculator om de kosten van elke omgeving te schatten.

• Productieomgevingen optimaliseren met kosten. Productieomgevingen hebben SKU's nodig die voldoen aan de SLA(Service Level Agreements), functies en schaal die nodig zijn voor productie. Bewaak continu het resourcegebruik en pas SKU's aan om te voldoen aan de werkelijke prestatiebehoeften.

• preproductieomgevingen optimaliseren.preproductieomgevingen goedkopere resources moeten gebruiken en profiteren van kortingen zoals Prijzen voor Azure Dev/Test. In deze omgevingen moet u services uitschakelen die niet nodig zijn. Zorg er tegelijkertijd voor dat preproductieomgevingen voldoende vergelijkbaar zijn met productieomgevingen omgevingen om risico's te voorkomen. Het handhaven van dit evenwicht zorgt ervoor dat testen effectief blijft zonder onnodige kosten te maken.

• Gebruik infrastructuur als code (IaC) om SKU's te definiëren. Implementeer IaC om dynamisch de juiste SKU's te selecteren en te implementeren op basis van de omgeving. Deze aanpak verbetert de consistentie en vereenvoudigt het beheer.

De referentie-implementatie maakt bijvoorbeeld gebruik van Bicep-parameters om duurdere lagen (SKU's) te implementeren in de productieomgeving:

    var redisCacheSkuName = isProd ? 'Standard' : 'Basic'
    var redisCacheFamilyName = isProd ? 'C' : 'C'
    var redisCacheCapacity = isProd ? 1 : 0

Automatisch schalen implementeren

Automatisch schalen helpt ervoor te zorgen dat een web-app flexibel, responsief blijft en dynamische workloads efficiënt kan verwerken. Volg deze aanbevelingen om automatisch schalen te implementeren:

• Uitschalen automatiseren. Gebruik automatische schaalaanpassing van Azure om horizontaal schalen in productieomgevingen te automatiseren. Configureer regels voor automatisch schalen om uit te schalen op basis van belangrijke prestatiegegevens, zodat uw toepassing verschillende belastingen kan verwerken.

• Schaaltriggers verfijnen. Gebruik CPU-gebruik als de eerste schaaltrigger als u niet bekend bent met de schaalvereisten van uw toepassing. Verfijn uw schaaltriggers met andere metrische gegevens, zoals RAM, netwerkdoorvoer en schijf-I/O. Het doel is om het gedrag van uw webtoepassing te vinden voor betere prestaties.

• Geef een uitschaalbuffer op. Stel de drempelwaarden voor schaalaanpassing in om te activeren voordat de maximale capaciteit wordt bereikt. Configureer bijvoorbeeld schalen voor 85% CPU-gebruik in plaats van te wachten totdat het 100% bereikt. Deze proactieve aanpak helpt de prestaties te behouden en potentiële knelpunten te voorkomen.

Resource-implementatie automatiseren

Automatisering gebruiken om Azure-resources en -code in alle omgevingen te implementeren en bij te werken. Volg deze aanbevelingen:

• Gebruik infrastructuur als code. Implementeer infrastructuur als code met behulp van CI/CD-pijplijnen (continuous integration and continuous delivery). Azure biedt vooraf gemaakte Bicep-, ARM-sjablonen (JSON) en Terraform-sjablonen voor elke Azure-resource.

• Gebruik een pijplijn voor continue integratie/continue implementatie (CI/CD). Gebruik een CI/CD-pijplijn om code van broncodebeheer te implementeren in uw verschillende omgevingen, zoals testen, faseren en productie. Gebruik Azure Pipelines als u met Azure DevOps werkt. Gebruik GitHub Actions voor GitHub-projecten.

• Moduletests integreren. Prioriteit geven aan de uitvoering en het doorgeven van alle eenheidstests in uw pijplijn voordat u een implementatie naar App Services uitvoert. Neem codekwaliteit en dekkingshulpprogramma's zoals SonarQube op om uitgebreide testdekking te bereiken.

• Gesimuleerde frameworks gebruiken. Voor het testen van externe eindpunten gebruikt u mocking-frameworks. Met deze frameworks kunt u gesimuleerde eindpunten maken. Ze elimineren de noodzaak om echte externe eindpunten te configureren en uniforme testomstandigheden in omgevingen te garanderen.

• Beveiligingsscans uitvoeren. Gebruik SAST (Static Application Security Testing) om beveiligingsfouten en coderingsfouten in uw broncode te vinden. Voer bovendien softwaresamenstellingsanalyse (SCA) uit om bibliotheken en onderdelen van derden te onderzoeken op beveiligingsrisico's. Hulpprogramma's voor deze analyses zijn eenvoudig te integreren in zowel GitHub als Azure DevOps.

Bewaking implementeren

Implementeer toepassings- en platformbewaking om de operationele uitmuntendheid en prestatie-efficiëntie van uw web-app te verbeteren. Volg deze aanbevelingen om bewaking te implementeren:

• Toepassingstelemetrie verzamelen. Gebruik automatische instrumentatie in Azure Application Insights om de toepassing te verzamelen telemetrie, zoals aanvraagdoorvoer, gemiddelde duur van de aanvraag, fouten en afhankelijkheidsbewaking. U hoeft geen codewijzigingen aan te brengen om deze telemetrie te kunnen gebruiken.

  De referentie-implementatie maakt gebruik van AddApplicationInsightsTelemetry uit het NuGet-pakket Microsoft.ApplicationInsights.AspNetCore om telemetrieverzamelingin te schakelen:

  public void ConfigureServices(IServiceCollection services)
  {
     ...
     services.AddApplicationInsightsTelemetry(Configuration["App:Api:ApplicationInsights:ConnectionString"]);
     ...
  }
  

• Aangepaste metrische toepassingsgegevens maken. Gebruik instrumentatie op basis van code voor aangepaste toepassingstelemetrie. Voeg de Application Insights-SDK toe aan uw code en gebruik de Application Insights-API.

  De referentie-implementatie verzamelt telemetrie over gebeurtenissen met betrekking tot de winkelwagenactiviteit. this.telemetryClient.TrackEvent telt de tickets die aan de winkelwagen zijn toegevoegd. Hiermee wordt de gebeurtenisnaam (AddToCart) geleverd en wordt een woordenlijst opgegeven met de concertId en count:

  this.telemetryClient.TrackEvent("AddToCart", new Dictionary<string, string> {
      { "ConcertId", concertId.ToString() },
      { "Count", count.ToString() }
  });
  

• Bewaak het platform. Schakel diagnostische gegevens in voor alle ondersteunde services. Verzend diagnostische gegevens naar dezelfde bestemming als de toepassingslogboeken voor correlatie. Azure-services maken automatisch platformlogboeken, maar slaan ze alleen op wanneer u diagnostische gegevens inschakelt. Schakel diagnostische instellingen in voor elke service die diagnostische gegevens ondersteunt.

De referentie-implementatie implementeren

De referentie-implementatie begeleidt ontwikkelaars bij een gesimuleerde migratie van een on-premises ASP.NET toepassing naar Azure, waarbij wijzigingen worden gemarkeerd die nodig zijn tijdens de initiële acceptatiefase. In dit voorbeeld wordt een toepassing voor concertticketing gebruikt voor het fictieve bedrijf Relecloud, dat tickets verkoopt via de on-premises webtoepassing. Relecloud stelt de volgende doelen voor de webtoepassing in:

• Goedkope, hoogwaardige codewijzigingen implementeren.
• Een SLO bereiken van 99,9%.
• DevOps-procedures gebruiken.
• Voor kosten geoptimaliseerde omgevingen maken.
• Verbeter de betrouwbaarheid en beveiliging.

Relecloud heeft vastgesteld dat hun on-premises infrastructuur geen rendabele oplossing was voor het voldoen aan deze doelstellingen. Ze hebben besloten dat het migreren van hun webtoepassing naar Azure de meest rendabele manier was om hun onmiddellijke en toekomstige doelstellingen te bereiken. De volgende architectuur vertegenwoordigt de eindstatus van de reliable web app-patroon-implementatie van Relecloud.

afbeelding 4. Architectuur van de referentie-implementatie. Download een Visio-bestand van deze architectuur.