Schaalbare cloudtoepassingen en sitebetrouwbaarheidstechniek (SRE)

Azure Front Door

Azure API Management

Azure Kubernetes Service (AKS)

Azure Application Gateway

Het succes van uw cloudoplossing is afhankelijk van de betrouwbaarheid. Betrouwbaarheid is de kans dat het systeem werkt zoals verwacht, onder opgegeven omstandigheden, binnen een opgegeven tijd. Site Reliability Engineering (SRE) is een set principes en procedures voor het maken van schaalbare en zeer betrouwbare softwaresystemen. SRE is een standaardbenadering voor het ontwerpen van digitale services ter ondersteuning van betrouwbaarheidsdoelen in uw workload.

In dit artikel wordt beschreven hoe u SRE-principes toepast op een schaalbaar API-platform. Deze architectuur definieert serviceniveauindicatoren (SLO's) en serviceniveaudoelstellingen (SLO's), modellen voor schaal- en prestatieverwachtingen en stelt bewakingsprocedures vast. Deze technieken zorgen voor meetbare en haalbare betrouwbaarheid.

Zie Een SRE-strategie ontwikkelen voor meer informatie.

Architectuur

Een Visio-bestand van deze architectuur downloaden.

Gegevensstroom

De volgende gegevensstroom komt overeen met het vorige diagram:

Clienttoepassingen zoals web-apps, mobiele apps en servicetoepassingen verzenden aanvragen naar het geïntegreerde eindpunt https://api.contoso.com.
Azure Front Door ontvangt alle binnenkomende aanvragen en biedt SSL-beëindiging (Secure Sockets Layer) en Azure Web Application Firewall-beveiliging.
Azure Front Door routeert aanvragen naar Azure API Management, dat beleid toepast voor toegangsbeheer, snelheidsbeperking, caching en aanvraagtransformatie.
API Management stuurt aanvragen door naar Application Gateway for Containers, waarmee het verkeer wordt verdeeld over het AKS-cluster.
De juiste microservice in AKS verwerkt de aanvraag. Microservices omvatten product-, profiel-, orders- en betalings- en inhoudsservices. Elke microservice verzendt telemetrie die bijdraagt aan SLI-berekeningen voor beschikbaarheid, latentie en doorvoer.
Microservices hebben zo nodig toegang tot back-endgegevensarchieven:
- Azure Cosmos DB voor wereldwijd gedistribueerde gegevens met lage latentie
- Azure SQL voor relationele gegevens
- Azure Storage en Azure Data Lake Storage voor ongestructureerde inhoud en bestanden
Microsoft Entra ID verifieert en autoriseert gebruikers en service-principals in de aanvraagstroom.
Azure Monitor en Application Insights verzamelen telemetrie onafhankelijk van elke laag:
- Metrische gegevens van Azure Front Door-aanvragen
- Uitvoering van API Management-beleid
- Loaddistributie met Application Gateway voor containers
- Metrische gegevens op AKS-podniveau
- Reactietijden voor gegevensopslag
SRE-teams gebruiken verzameling per laag om samengestelde SLO's te berekenen, degradatiebronnen te identificeren en SLO-naleving bij te houden.
Het antwoord gaat terug door hetzelfde pad naar de clienttoepassing.

Deze architectuur vertegenwoordigt een schaalbaar API-platform. De oplossing bevat meerdere microservices die gebruikmaken van verschillende databases en opslagservices.

In het voorbeeldscenario worden gebruiksscenario's voor marketplace en e-commerce op hoog niveau behandeld:

Bladeren door producten
Registratie en aanmelding
Inhoud weergeven, zoals nieuwsartikelen
Order- en abonnementsbeheer

Clienttoepassingen zoals web-apps, mobiele apps en servicetoepassingen gebruiken de API-platformservices via een geïntegreerd toegangspad. https://api.contoso.com

Onderdelen

Azure Front Door is een moderne netwerkservice voor het leveren van cloudinhoud die gebruikmaakt van het wereldwijde edge-netwerk van Microsoft om schaalbare webtoepassingen te maken. In deze architectuur fungeert het als één toegangspunt voor alle clientaanvragen. Het biedt SSL-beëindiging en past Azure Web Application Firewall-regels toe voordat verkeer naar API Management wordt gerouteerd. Zie overzicht van routeringsarchitectuur voor meer informatie.
API Management is een beheerde API-gatewayservice die een hybride, multicloudbeheerplatform biedt voor API's in alle omgevingen. In deze architectuur fungeert deze als de API-gateway. Het dwingt beleidsregels voor toegangsbeheer af, past snelheidsbeperking toe, slaat antwoorden in de cache op met behulp van Azure Managed Redis als een externe cache en transformeert aanvragen voordat deze worden doorgestuurd naar de back-endservices. API Management biedt ondersteuning voor automatisch schalen in Standard- en Premium-lagen.
AKS is een beheerde containerindelingsservice die een Kubernetes-platform biedt voor het uitvoeren van containertoepassingen. In deze architectuur worden alle microservices gehost, waaronder product-, profiel-, orders- en betalings- en inhoudsservices. Azure beheert het besturingsvlak en u beheert de agentknooppunten.
Application Gateway for Containers is een load balancer voor toepassingen die dynamisch verkeersbeheer biedt voor workloads die worden uitgevoerd in een Kubernetes-cluster. In deze architectuur biedt het laag-7-taakverdeling voor verkeer dat het AKS-cluster binnenkomt. Het verdeelt aanvragen van API Management over de microservice-pods.
Azure Cosmos DB is een beheerde NoSQL- en relationele databaseservice met wereldwijde distributie en automatische schaalbaarheid. In deze architectuur worden productcatalogus- en profielgegevens opgeslagen waarvoor wereldwijd gedistribueerde toegang met lage latentie is vereist. Automatisch schalen van de doorvoer past de capaciteit aan op basis van de vraag.
Azure SQL is een serie beheerde relationele databaseservices die gebruikmaken van de SQL Server-database-engine in Azure. In deze architectuur worden relationele gegevens opgeslagen voor orders, abonnementen en transactionele records.
Azure Storage is een cloudopslagservice die object-, bestands-, schijf-, wachtrij- en tabelopslag bevat. Azure Data Lake Storage is een zeer schaalbare Data Lake-service voor high-performance analyseworkloads. In deze architectuur slaan deze services ongestructureerde inhoud op, zoals mediaassets, documenten en bestanden.
Microsoft Entra ID is een cloudservice voor identiteits- en toegangsbeheer die gebruikers verifieert en autoriseert voor toegang tot resources. In deze architectuur biedt het gecentraliseerd identiteits- en toegangsbeheer voor gebruikers en service-principals in alle services.
Azure Monitor is een waarneembaarheidsservice voor het verzamelen, analyseren en reageren op bewakingsgegevens uit uw cloud- en on-premises omgevingen. Application Insights is een uitbreiding van Azure Monitor die APM-functies (Application Performance Monitoring) biedt. In deze architectuur verzamelen deze services telemetrie over alle lagen. Ze berekenen SLO's, volgen SLO-naleving en bieden dashboards voor proactieve waarschuwingen. Azure Monitor ondersteunt OpenTelemetry en kan worden geïntegreerd met Azure Managed Grafana voor gedistribueerde tracering en visualisatie.
Azure Chaos Studio is een beheerde chaos-engineeringservice waarmee u uw cloudtoepassing en servicetolerantie kunt meten, begrijpen en verbeteren. In deze architectuur injecteert het fouten en valideert het de tolerantie van het systeem tijdens het testen van tolerantie en herstel.

Alternatieven

Voor het rekenvlak, neem het volgende in overweging:

Azure Container Apps voor microservices en gebeurtenisgestuurde workloads. Het biedt ondersteuning voor serverloze containers en automatisch schalen op basis van KEDA zonder dat Kubernetes-clusterbeheer is vereist. Deze keuze vervangt zowel AKS als Application Gateway voor Containers, omdat Container Apps ingebouwde inkomende toegang biedt.
Web App for Containers voor teams die bekend zijn met App Service die alleen HTTP/HTTPS-inkomend verkeer nodig hebben. Deze keuze vervangt AKS en Application Gateway for Containers door een volledig beheerd platform, maar biedt minder gedetailleerd schaalbeheer.
Azure Functions voor serverloze API-services, waar u afzonderlijke API-eindpunten als onafhankelijke functies kunt implementeren. Deze keuze vervangt het microservicemodel door functies per eindpunt en past bij gebeurtenisgestuurde OF API's met weinig verkeer.

Houd voor de gegevenslaag rekening met Microsoft Fabric met Azure Cosmos DB-spiegeling wanneer u analyse van operationele gegevens nodig hebt. Fabric voegt een rapportage- en analyse-laag toe naast de bestaande transactionele opslag zonder request-eenheden te gebruiken.

Details van het scenario

In dit voorbeeldscenario ziet u hoe u SRE-procedures toepast op een schaalbaar API-platform dat marketplace- en e-commercegebruiksscenario's verwerkt. Het artikel richt zich op het definiëren van SLI's en SLO's, het modelleren van schaal- en prestatieverwachtingen, en hoe die resultaten gebruikt kunnen worden voor bewaking en waarschuwingen.

Potentiële gebruikscases

De concepten in dit artikel zijn van toepassing op:

Op API gebaseerde cloudservices.
Openbare webtoepassingen.
IoT-workloads (Internet of Things) of op gebeurtenissen gebaseerde workloads.
E-commerceplatforms met product browsen, registratie en orderbeheer.
Toepassingen voor contentlevering voor nieuwsartikelen en media.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die u kunt gebruiken om de kwaliteit van een workload te verbeteren. Zie Well-Architected Framework voor meer informatie.

Reliability

Betrouwbaarheid helpt ervoor te zorgen dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Ontwerp controlelijst voor betrouwbaarheid voor meer informatie.

Uw bedrijfscontext bepaalt uw betrouwbaarheidsvereisten. Met SRE-procedures kunt u het juiste niveau van betrouwbaarheid bereiken. U meet betrouwbaarheid via SLO's, die doelen instellen die in de loop van de tijd als percentages worden uitgedrukt. SLI's zijn de metrics die u meet om SLO's te bepalen, op basis van de klantervaring. Zie SLI-metrische gegevens definiëren om SLO's te berekenen voor meer informatie.

Deze architectuur bevat verschillende betrouwbaarheidspatronen:

Zoneredundantie: Azure Front Door, Application Gateway for Containers en AKS ondersteunen implementatie van beschikbaarheidszones voor hoge beschikbaarheid binnen een regio.
Automatisch schalen: Azure Front Door wordt automatisch geschaald op basis van het verkeersvolume. Application Gateway for Containers past de capaciteitseenheden automatisch aan. AKS maakt gebruik van de automatische schaalaanpassing van clusters voor knooppunten en horizontale automatische schaalaanpassing voor pods. API Management biedt ondersteuning voor automatisch schalen in Standard- en Premium-lagen. De doorvoer voor automatische schaalaanpassing van Azure Cosmos DB wordt aangepast op basis van verbruik van aanvraageenheden. Deze mogelijkheden helpen het systeem bij het afhandelen van belastingvariaties zonder handmatige tussenkomst.
Gezondheidscontrole: Gebruik Azure Monitor en Application Insights om SLI's en SLO's bij te houden en proactief betrouwbaarheidsproblemen te identificeren.
Tolerantie- en hersteltests: Gebruik Chaos Studio om fouttolerantie- en herstelprocedures te valideren.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Ontwerpcontrolelijst voor beveiliging voor meer informatie.

Deze architectuur behandelt beveiliging via meerdere lagen:

Identiteits- en toegangsbeheer: Microsoft Entra ID biedt gecentraliseerd identiteitsbeheer voor gebruikers en service-principals.
Netwerkbeveiliging: Azure Web Application Firewall, geïntegreerd met Azure Front Door, biedt bescherming tegen veelvoorkomende webexplots, waaronder Open Worldwide Application Security Project (OWASP) Top 10-beveiligingsproblemen . API Management dwingt toegangsbeheer op netwerkniveau af, zoals filteren van IP-adressen en frequentiebeperking.
API-gatewaybeveiliging: API Management dwingt verificatie en autorisatie op toepassingsniveau af via OAuth 2.0-tokenvalidatie en certificaatverificatie. Met dit beleid wordt de identiteit van de aanroeper op API-aanvraagniveau gevalideerd, gescheiden van de beveiliging op netwerkniveau die Web Application Firewall en IP-adresfiltering bieden.
Gegevensbescherming: Beheerde identiteiten gebruiken voor service-naar-service-verificatie. Versleuteling in rust activeren voor alle gegevensopslag.

Kostenoptimalisatie

Kostenoptimalisatie richt zich op manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie controlelijst ontwerpbeoordeling voor kostenoptimalisatievoor meer informatie.

Vanuit het perspectief van SRE heeft kostenoptimalisatie rechtstreeks betrekking op de manier waarop u de bewakingsinfrastructuur inricht, drempelwaarden voor automatisch schalen definieert en foutbudget toewijst. Overprovisioning verslechtert de kostenefficiëntie. Onderberekening verslechtert de betrouwbaarheid.

Belangrijke SRE-gerelateerde kostenfactoren in deze architectuur zijn onder andere:

Bewaking en waarneembaarheid: Voor Azure Monitor, Application Insights en Azure Managed Grafana worden kosten in rekening gebracht op basis van het gegevensopnamevolume, het bewaarbeleid en het aantal waarschuwingsregels. Stel steekproefpercentages en bewaarperioden af om de observatiediepte af te wegen tegen de kosten.
Overhead voor automatisch schalen: Rekenresources zoals AKS-knooppuntgroepen en API Management-schaaleenheden vertegenwoordigen de grootste kostenvariabele. Stel minimumdrempels voor automatische schaalaanpassing zorgvuldig in. Het instellen van grenzen die te hoog zijn, verspilt resources, terwijl te lage grenzen het risico op SLO-schendingen tijdens verkeerspieken vergroten. Gebruik bewakingsgegevens om drempelwaarden te kalibreren.
Foutenbudgetinvestering: Wanneer fouten binnen uw foutenbudget blijven, investeer in functionaliteiten. Wanneer fouten uw budget verbruiken, investeert u in betrouwbaarheid. Deze praktijk voorkomt onnodige uitgaven voor betrouwbaarheidsverbeteringen wanneer het systeem al voldoet aan de SLO's.

Andere kostenfactoren zijn onder andere:

API Management: De kosten variëren per laag. De Standard- en Premium-lagen bieden ondersteuning voor automatisch schalen, maar met hogere basiskosten in vergelijking met de lagen Developer en Basic, die geen ondersteuning bieden voor automatisch schalen.
Gegevensservices: Azure Cosmos DB-kosten zijn afhankelijk van ingerichte doorvoer en opslag. Gebruik doorvoer voor automatische schaalaanpassing om te optimaliseren voor fluctuerende workloads.
Networking: Voor Azure Front Door en Application Gateway voor containers worden kosten in rekening gebracht op basis van verkeersvolume en actieve functies.

Kosten optimaliseren:

Gebruik Azure Advisor-aanbevelingen voor gereserveerde instanties en Azure-spaarplannen.
Rightsize AKS-knooppuntgroepen op basis van het werkelijke gebruik.
Stel drempelwaarden voor automatisch schalen in om de prestaties en kosten te verdelen.
Gebruik automatische schaalaanpassing van Azure Cosmos DB om overprovisioning te voorkomen.

Gebruik de Azure-prijscalculator om de kosten voor deze architectuur te schatten.

Operationele uitmuntendheid

Operational Excellence behandelt de operationele processen die een toepassing implementeren en deze in productie houden. Voor meer informatie, zie Controlelijst voor ontwerpevaluatie voor Operational Excellence.

Maak een holistisch proces voor prestatiebeheer om de prestaties gedurende de levenscyclus van de service te beheren.

Prestatiedoelstellingen: Definieer aspiratie-SLO's op basis van bedrijfsvereisten.
Prestatiemodellering: Identificeer bedrijfskritieke werkstromen en model verwachte prestaties.
Instrumentation: Gebruik Azure Monitor en Application Insights voor analyse van APM, telemetrie en metrische gegevens. Azure Monitor ondersteunt OpenTelemetry en kan worden geïntegreerd met Azure Managed Grafana voor gedistribueerde tracering en visualisatie.
Prestatietests: Voer belasting- en stresstests uit met behulp van hulpprogramma's zoals K6, Karate en JMeter. Integreer geautomatiseerde tests in pijplijnen voor continue implementatie.
Continue bewaking: Stel waarschuwingen in op basis van SLI-drempelwaarden en volg SLO-naleving.
Implementatie op basis van ring: Gebruik progressieve implementatiestrategieën om de impact van wijzigingen te minimaliseren.

Houd prestatiedoelstellingen bij als gedetailleerde gebruikersverhalen in uw achterstand om ervoor te zorgen dat u naast functieactiviteiten prioriteit geeft aan governanceactiviteiten.

Prestatie-efficiëntie

Prestatie-efficiëntie verwijst naar de mogelijkheid van uw workload om efficiënt te voldoen aan de behoeften van de gebruiker. Zie controlelijst ontwerpbeoordeling voor prestatie-efficiëntievoor meer informatie.

Ontwerp toepassingen zodat de middelen automatisch worden geschaald om aan de belasting te voldoen. Dit ontwerp omvat reken-, opslag- en berichteninfrastructuur.

Pas schaalbaarheids- en prestatiemodelleringstechnieken toe om architectuur en ontwerp nauwkeurig af te stemmen:

Schaalbaarheidsvereisten identificeren.
Model van de verwachte belasting.
SLA's en SLO's definiëren voor gebruikersscenario's.

Schaalbaarheidsvereisten vastleggen

Stel deze metrische piekbelastingsgegevens voor:

Aantal consumenten: 1,5 miljoen
Actieve consumenten per uur (30%): 450.000
Lastverdeling
- Product bladeren: 75%
- Registratie en aanmelding: 10%
- Orders en abonnementen: 10%
- Inhoud weergeven: 5%

Vereisten voor API-schaal onder normale piekbelasting:

Productmicroservice: ongeveer 500 aanvragen per seconde (RPS)
Profielmicroservice: ongeveer 100 RPS
Bestellingen en betalingsmicroservice: ongeveer 100 RPS (verzoeken per seconde)
Inhoudsmicroservice: ongeveer 50 RPS

Tijdens speciale gebeurtenissen kunnen schaalvereisten 10 keer de normale piekbelasting bereiken.

SLI-metrische gegevens definiëren om SLO's te berekenen

Metrische SLI-gegevens geven aan in welke mate een service een bevredigende ervaring biedt, uitgedrukt als de verhouding van goede gebeurtenissen tot het totale aantal gebeurtenissen.

In de volgende tabel ziet u voorbeelden van SLI-metrische gegevens.

Metrisch	Omschrijving
Beschikbaarheid	Of de API de aanvraag heeft verwerkt
Latentie	Tijd voor het verwerken van de aanvraag en het antwoord van de API
Doorvoer	Aantal aanvragen dat is verwerkt
Slagingspercentage	Aantal aanvragen dat is verwerkt
Foutpercentage	Aantal fouten voor afgehandelde aanvragen
Nieuwheid	Aantal keren dat de gebruiker de meest recente gegevens heeft ontvangen

Voor elke SLI berekent u de verhouding van goede gebeurtenissen tot het totale aantal gebeurtenissen zoals waargenomen door de klant. In de volgende voorbeelden ziet u deze berekening voor verschillende gebruikersscenario's:

Latentie-SLI voor product browsen: Het aantal aanvragen is voltooid in <1000 ms gedeeld door het aantal aanvragen. Met deze SLI wordt bijgehouden of de productmicroservice binnen de acceptabele latentiedrempel reageert.
Freshness SLI voor zoeken: Het aantal zoekresultaten dat binnen drie seconden wordt geretourneerd , gedeeld door het aantal zoekopdrachten. Deze SLI meet hoe vaak de zoekervaring voldoet aan het nieuwheidsdoel na catalogusupdates.

Nadat u SLA's hebt gedefinieerd, bepaalt u welke telemetrie moet worden vastgelegd op elke laag van de architectuur, waaronder Azure Front Door, API Management, Application Gateway, AKS-pods en gegevensarchieven. Voor HTTP-services gebruikt u statuscodes om succes en fouten te classificeren. Azure Monitor en Application Insights bieden diagnostische en bewakingsondersteuning voor alle lagen.

Gebruik percentieldistributies om sommige SLI's te berekenen, en uitbijters uit te sluiten. Als de latentie van het 95e percentiel bijvoorbeeld binnen de drempelwaarde valt, voldoet het systeem aan de SLO.

Definieer SLO-meetperioden om activiteit vast te leggen en niet inactiviteit. Het venster kan variëren van vijf minuten tot 24 uur.

Inspirerende SLO's vaststellen voor de beoogde oplossing

Bekijk de volgende voorbeeld-ambitieuze SLO's:

Leesaanvragen worden binnen één seconde beantwoord voor 95% van de oproepen.
CREATE- en UPDATE-aanvragen reageren binnen drie seconden voor 95% aanroepen.
Alle aanvragen reageren binnen vijf seconden zonder fouten voor 99% van oproepen.
Alle aanvragen slagen zonder fouten voor 99,9% van aanroepen.
Tijdens piekuren leiden minder dan 1% aanvragen tot fouten.

SLO's aanpassen aan de vereisten van uw applicatie.

Eerste SLO's meten op basis van logboekgegevens

Stel dat u een week aan gegevens hebt:

Aanvragen: 123.456
Geslaagde aanvragen: 123.204
Latentie bij 90e percentiel: 497 ms
Latentie bij 95e percentiel: 870 ms
Latentie bij 99e percentiel: 1.024 ms

Initiële SLIs:

Beschikbaarheid = (123.204 / 123.456) = 99,8%.
Aanvragen worden binnen 500 ms verwerkt voor 90% van oproepen.
Aanvragen worden binnen 1000 ms verwerkt voor 98% van oproepen.

Vergelijk logboekgegevens met SLO-doelen om naleving te beoordelen.

Richtlijnen voor technische risicobeperking

Volg deze aanbevolen procedures:

Ontwerp voor schaal en prestaties.
- Leg schaalvereisten vast voor alle scenario's, inclusief pieken.
- Modelprestaties om beperkingen te identificeren.
Technische schulden beheren.
- Metrische prestatiegegevens traceren.
- Gebruik hulpprogramma's zoals K6, Karate en JMeter voor belastingstests.
- Integreer geautomatiseerde tests in continue implementatie.
Neem een productiementaliteit.
- Pas de automatische schaaldrempels aan op basis van gezondheidsstatistieken.
- Geef de voorkeur aan horizontaal schalen.
- Gebruik een ring-gebaseerde implementatie.
- Gebruik foutbudgetten om te bepalen wanneer u moet investeren in betrouwbaarheidsverbeteringen versus nieuwe functies. Een foutbudget is het verschil tussen 100% en uw SLO-doel. Met een SLO van 99,9% is er bijvoorbeeld een foutbudget van 0,1% beschikbaar. Als werkelijke fouten dit budget verbruiken, geeft u prioriteit aan betrouwbaarheidswerkzaamheden om de foutpercentages te verminderen. Als fouten binnen het budget blijven, investeert u in experimenten en functielevering.
- Gebruik Chaos Studio voor tolerantietests.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteur:

Subhajit Chatterjee | Hoofd Software Engineer

Andere bijdrager:

Dawid Obrocki | Senior Software Engineer

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Feedback

Is deze pagina nuttig?