Ontwerpen voor zelfherstel

De toepassing zo ontwerpen dat zelfherstel mogelijk is wanneer er fouten optreden

In een gedistribueerd systeem kunnen fouten optreden. De hardware kan defect raken. Het netwerk kan tijdelijke storingen ondervinden. In zeldzame gevallen kan een hele service of regio met een onderbreking te maken krijgen, maar ook hier moet rekening mee worden gehouden.

Ontwerp een toepassing daarom zo dat zelfherstel mogelijk is wanneer er fouten optreden. Hiervoor is een drieledige methode vereist:

• Detecteren van fouten.
• Probleemloos reageren op fouten.
• Fouten in een logboek vastleggen en bijhouden voor operationele inzichten.

Hoe u reageert op een bepaald type fout kan afhankelijk zijn van de beschikbaarheidsvereisten van de toepassing. Als u bijvoorbeeld een zeer hoge beschikbaarheid nodig hebt, kan tijdens een regionale onderbreking automatisch een failover worden uitgevoerd naar een secundaire regio. Dit brengt echter hogere kosten met zich mee dan een implementatie in één regio.

Focus u bovendien niet te veel op grote gebeurtenissen, zoals regionale onderbrekingen, omdat deze over het algemeen niet veel voorkomen. Richt u minstens zoveel op het verwerken van lokale fouten van kortere duur, zoals fouten in de netwerkconnectiviteit of mislukte databaseverbindingen.

Aanbevelingen

Mislukte bewerkingen opnieuw proberen. Tijdelijke storingen kunnen optreden vanwege een kortstondige uitval van de netwerkconnectiviteit, een verbroken databaseverbinding, of een time-out als een service bezet is. Bouw pogingslogica in de toepassing in om tijdelijke fouten te verwerken. Bij veel Azure-services worden met de client SDK automatische nieuwe pogingen geïmplementeerd. Zie Transient fault handling (Afhandeling van tijdelijke fouten) en retry pattern (Patroon voor opnieuw proberen) voor meer informatie.

Beveilig niet goed werkende externe services (Circuitonderbreker). Het is een goed idee om een nieuwe poging uit te voeren na een tijdelijke fout, maar als de fout zich blijft voordoen, kan het voorkomen dat er te veel aanroepen worden gedaan bij een niet goed werkende service. Dit kan leiden tot opstapelende fouten omdat er steeds meer aanvragen worden gedaan. Gebruik het patroon Circuit breaker om snel te mislukken (zonder de externe aanroep te doen) wanneer een bewerking waarschijnlijk zal mislukken.

Isoleer kritieke resources (Bulkhead). Fouten in één subsysteem kunnen zich soms opstapelen. Dit kan zich voordoen als aan storing sommige resources, zoals threads of sockets, niet tijdig vrij komen, wat tot bronuitputting leidt. U kunt dit voorkomen door een systeem te partitioneren in geïsoleerde groepen, zodat een storing in één partitie niet het hele systeem laat uitvallen.

Voer load leveling uit. Er kunnen plotselinge pieken optreden in het verkeer in toepassingen. Back-endservices kunnen hierdoor overbelast raken. U kunt dit voorkomen door het patroon Load Leveling op basis van wachtrijen te gebruiken om werkitems in de wachtrij te houden om asynchroon te worden uitgevoerd. De wachtrij fungeert als een buffer die de pieken in de werkbelasting afvlakt.

Fail over . Als een instantie niet kan worden bereikt, kunt u een failover uitvoeren naar een andere instantie. Voor staatloze items, zoals een webserver, plaatst u meerdere instanties achter een load balancer of Traffic Manager. Gebruik replica’s en failover voor items die een status hebben, zoals een database. Afhankelijk van de gegevensopslag en hoe deze wordt gerepliceerd, kan het voorkomen dat de toepassing uiteindelijk te maken krijgt met inconsistenties.

Compenseer mislukte transacties. Over het algemeen wordt het aangeraden om gedistribueerde transacties te voorkomen, omdat hiervoor coördinatie tussen verschillende services en resources is vereist. Gebruik in plaats hiervan een bewerking die bestaat uit kleinere afzonderlijke transacties. Als de bewerking halverwege mislukt, gebruikt u Compensatietransacties om alle reeds voltooide stappen ongedaan te maken.

Controlepunt bij langlopende transacties. Controlepunten kunnen flexibiliteit bieden als een langdurige bewerking mislukt. Wanneer de bewerking opnieuw wordt gestart (bijvoorbeeld wanneer deze wordt voortgezet op een andere VM), kan deze worden hervat vanaf het laatste controlepunt.

Degraderen zonder al te veel tijd. Soms is er geen tijdelijke oplossing voor een probleem. U kunt dan echter wel een verminderde functionaliteit bieden die nog steeds nuttig is. Neem als voorbeeld een toepassing met een boekencatalogus. Als de toepassing de miniatuurafbeelding voor het omslag niet kan ophalen, dan kan er tijdelijk een vervangende afbeelding worden getoond. Volledige subsystemen zijn mogelijk niet-kritiek voor de toepassing. Het weergeven van productaanbevelingen is op een e-commercesite bijvoorbeeld minder kritiek dan het verwerken van bestellingen.

Beperk klanten. Soms zorgt een klein aantal gebruikers voor een overmatige werkbelasting. Dit kan de beschikbaarheid van de toepassing verminderen voor andere gebruikers. Beperk deze klanten in dit geval gedurende een bepaalde tijdsperiode. Zie beperkingspatroon.

Blokkeer ongeldige actoren. Als u een klant beperkt, betekent dit niet dat deze zich heeft misdragen. Het betekent alleen dat de klant zijn/haar servicequotum heeft overschreden. Maar als een klant consequent dit quotum overschrijdt of ander ongewenst gedrag vertoont, kunt u ervoor kiezen de klant te blokkeren. Definieer een buiten-bandproces waarmee de gebruiker kan aanvragen om de blokkering op te heffen.

Gebruik Selectie van leider. Gebruik Selectie van leider om een coördinator te selecteren, wanneer u een taak hebt die moet worden gecoördineerd. Op deze manier is de coördinator geen SPOF (Single Point of Failure). Als de coördinator niet slaagt, wordt er een nieuwe geselecteerd. Overweeg om een gebruiksklare oplossing te gebruiken, zoals Zookeeper, in plaats van een heel nieuw algoritme voor het selecteren van een leider te implementeren.

Test met foutinjectie. Het komt maar al te vaak voor dat de successen goed zijn getest, maar de fouten niet. Een systeem kan al lange tijd in productie zijn voordat als oefening een fout wordt uitgevoerd. Gebruik foutinjectie om de flexibiliteit van het systeem tijdens storingen te testen door echte storingen te activeren of door ze te simuleren.

Profiteer van chaos-engineering. Chaos-engineering breidt het begrip foutinjectie uit, door willekeurig fouten of abnormale omstandigheden te genereren in productie-exemplaren.

Zie Betrouwbare toepassingen ontwerpen voor Azure voor een gestructureerde benadering voor het zelfherstel van uw toepassingen.