Ontwerpen voor tolerantie

Voltooid
De workload moet blijven werken met volledige of verminderde functionaliteit.

U moet verwachten dat onderdelen defecten, platformstoringen, prestatieverminderingen en andere fouten optreden. Bouw tolerantie in het systeem zodat het fouttolerant is en probleemloos kan afnemen.

Voorbeeldscenario

Contoso Air is een commerciële luchtvaartmaatschappij met een interne ontwikkelingsafdeling. De belangrijkste LOB-toepassing is een boekingsoplossing waarmee klanten vluchten rechtstreeks kunnen boeken met Contoso Air. De app is ingebouwd in Azure en maakt gebruik van Azure-app Service, Cosmos DB, Azure Functions, Azure Logic Apps en Azure Service Bus.

Foutrisico's bepalen

Identificeer mogelijke storingspunten in het systeem, met name voor de kritieke onderdelen, en bepaal het effect op gebruikers- en systeemstromen.

Analyseer de foutcase, de straalstraal en de intensiteit van de fout voor elk potentieel storingspunt. Foutgevallen en hun intensiteit kunnen variëren van relatief lage impactscenario's, zoals het tijdelijke verlies van een back-endproces tot uitval op volledige schaal als gevolg van rampen. Door deze analyse uit te voeren, kunt u het ontwerp van mogelijkheden voor foutafhandeling op onderdeelniveau bepalen.

De uitdaging van Contoso

  • De LOB-toepassing biedt veel belangrijke functies, variërend van marketing tot en met commerce. De gebruikersstroom voor het aanschaffen van tickets is geïdentificeerd als de meest kritieke stroom. Het workloadteam heeft vastgesteld dat er meer betrouwbaarheidsmaatregelen moeten worden geïmplementeerd om ervoor te zorgen dat de stroom is geoptimaliseerd voor tolerantie.
  • Het team heeft tijd gebudgetteerd voor verbeteringen, zoals het loskoppelen van onderdelen en het opnieuw ontwerpen van stromen, maar wil ervoor zorgen dat ze die tijd gebruiken om zich te richten op de hoogste waardeverbeteringen.

De aanpak en resultaten toepassen

  • Het team identificeert de externe betalingsgateway als een mogelijk storingspunt. De gateway is maximaal beschikbaar, maar er is een potentieel voor gebruikers die af en toe tijdelijke fouten ondervinden als gevolg van netwerkproblemen of bursts met extreem hoge aanvragen. De gateway kan sommige aanvragen weigeren wanneer deze overbelast is door meerdere gelijktijdige aanvragen die worden verzonden.
  • Het team bepaalt dat gebruikers aanvragen opnieuw moeten indienen wanneer de gateway hun initiële aanvragen weigert, wat een negatieve gebruikerservaring veroorzaakt.

Zelfbehoudmechanismen implementeren

Bouw mogelijkheden voor zelfbehoud door ontwerppatronen correct te gebruiken en het ontwerp te modulariseren om fouten te isoleren.

Door mogelijkheden voor zelfbehoud in het systeem te bouwen, kunt u voorkomen dat een probleem van invloed is op downstreamonderdelen. Het systeem kan tijdelijke en permanente fouten, prestatieknelpunten en andere problemen die van invloed kunnen zijn op de betrouwbaarheid beperken. U kunt ook de straal minimaliseren.

De uitdaging van Contoso

  • Het team wil het risico op tijdelijke fouten minimaliseren, waardoor aanvragen van gebruikers worden geweigerd door de betalingsgateway. Vanwege de tijdelijke aard van sommige foutvoorwaarden is er een hoge kans dat dezelfde aanvraag slaagt als deze opnieuw wordt verzonden.

De aanpak en resultaten toepassen

  • Het team ontwikkelt aangepaste logica in de stroom om de transactie na een korte vertraging opnieuw uit te voeren wanneer er een fout wordt gedetecteerd die opnieuw kan worden geprobeerd.
  • Het oplossingsontwerp wordt aangepast om het patroon Opnieuw proberen op te nemen, waardoor de wachttijd tussen nieuwe pogingen enigszins wordt verhoogd totdat de aanvraag is verwerkt of het maximum aantal mislukte pogingen is bereikt.
  • Het team besluit ook de functionaliteit voor gebruikersinteractie en betalingsverwerking van de back-end van deze stroom los te koppelen met behulp van een gebeurtenisgestuurde benadering met Azure Service Bus. Wanneer er onherstelbare fouten optreden tijdens het verwerken van het bericht (na het maximum aantal nieuwe pogingen), wordt de verwerking van die aanvraag door de back-endprocessor afbroken, waardoor het bericht in de wachtrij blijft staan, zodat het op een later tijdstip opnieuw kan worden verwerkt.

Uitgebreide redundantie en tolerantie bouwen

Bouw redundantie in lagen en tolerantie op verschillende toepassingslagen.

Doel voor redundantie in fysieke hulpprogramma's en onmiddellijke gegevensreplicatie. Richt u ook op redundantie in de functionele laag die betrekking heeft op services, bewerkingen en personeel. Redundantie helpt bij het minimaliseren van single points of failure. Als er bijvoorbeeld sprake is van een storing die van invloed is op een of meer onderdelen, een beschikbaarheidszone of een hele regionale, redundante implementatie (actief-actief of actief-passief) kunt u voldoen aan uptimedoelen.

Door tussenpersonen toe te voegen voorkomt u directe afhankelijkheid tussen onderdelen en verbetert u de buffering. Beide voordelen verbeteren de tolerantie van het systeem.

De uitdaging van Contoso

  • Het implementeren van nieuwe pogingen en het loskoppelen van de aanroepen van de betalingsgateway vanuit de gebruikersinterface met behulp van Service Bus heeft de betrouwbaarheid van deze stroom aanzienlijk verhoogd, maar de zakelijke belanghebbenden maken zich nog steeds zorgen over gegevensverlies die kunnen optreden als gevolg van een catastrofale fout in de primaire regio.

De aanpak en resultaten toepassen

  • Het team besluit om een upgrade uit te voeren naar de Service Bus Premium-laag. Hierdoor kunnen ze profiteren van de Beschikbaarheidszones ondersteuningsfunctionaliteit van die laag. Met deze functionaliteit worden meerdere kopieën van de gegevens opgeslagen in drie fysiek gescheiden faciliteiten (beschikbaarheidszones) en heeft de service voldoende capaciteitsreserves om direct om te gaan met het volledige, catastrofale verlies van een datacenter.
  • Daarnaast configureert het team Azure Service Bus Geo-Disaster Recovery om continu gegevens te repliceren naar een secundaire regio die wordt gebruikt in het onwaarschijnlijke geval van een volledige fout van de primaire regio.

Kennis testen

1.

Welke mogelijkheden moet u in uw workload ontwerpen om ervoor te zorgen dat deze bestand is tegen storingen?

2.

Wat is een voorbeeld van het toevoegen van redundantie in uw workload?

3.

Het workloadteam moet weten hoe een DDoS-aanval van invloed kan zijn op de workload. Wat moet het team doen voordat het wordt getest?