Delen via

Beste praktijken voor architectuur voor Azure API Management

Azure API Management is een beheerplatform en gateway voor API's in alle omgevingen, waaronder hybride en multicloud. Als PaaS-oplossing (Platform as a Service) helpt API Management de API-levenscyclus van uw workload te ondersteunen.

In dit artikel wordt ervan uitgegaan dat u als architect de beslissingsstructuur voor integratieservices hebt bekeken en API Management hebt gekozen als de integratieservice voor uw workload. De richtlijnen in dit artikel bevatten aanbevelingen voor architectuur die overeenkomen met de principes van de Well-Architected Framework-pijlers.

Belangrijk

Deze handleiding gebruiken

Elke sectie heeft een ontwerpcontrolelijst die architectuurgebieden van belang presenteert, samen met ontwerpstrategieën die zijn gelokaliseerd in het technologiebereik.

Ook zijn inbegrepen aanbevelingen voor de technologiemogelijkheden die kunnen helpen bij het materialiseren van deze strategieën. De aanbevelingen vertegenwoordigen geen volledige lijst met alle configuraties die beschikbaar zijn voor API Management of de back-end-API-servers van uw workload. In plaats daarvan worden de belangrijkste aanbevelingen opgesomd die aansluiten op de ontwerpperspectieven. Gebruik de aanbevelingen om uw proof-of-concept te bouwen of om uw bestaande omgevingen te optimaliseren.

Basisarchitectuur die de belangrijkste aanbevelingen demonstreert: architectuur voor API Management-landingszones.

Technologische omvang

Deze beoordeling is gericht op de onderling gerelateerde beslissingen voor de volgende Azure-resource:

  • Azure API Management

Het bereik van deze handleiding is de API Management-service, voornamelijk het gatewayonderdeel (gegevensvlak), dat API-aanvragen van clienttoepassingen doorstuurt naar back-end-API's die worden gehost op verschillende platforms of over de locaties heen. De architectuur van de workload moet rekening houden met het API Management-besturingsvlak en gerelateerde onderdelen, zoals clienttoepassingen die toegang hebben tot de gateway en de back-end-API's die gerouteerde aanvragen verwerken. Het integreert ook ondersteunende Azure-services, waaronder netwerken, bewaking, identiteitsbeheer en andere mogelijkheden.

Deze handleiding heeft geen betrekking op Azure API Center. Het behandelt onderwerpen op API-niveau, omdat ze betrekking hebben op API Management in plaats van een goed ontworpen perspectief te bieden op api-ontwerpoverwegingen.

Opmerking

Niet alle aanbevelingen zijn van toepassing op alle servicelagen van API-beheer. Veel aanbevelingen in deze gids richten zich op de Standard v2- en klassieke Premium-niveaus van API-beheer, die worden aanbevolen als productieniveaus voor de meeste bedrijfsbelastingen.

Belangrijk

De Premium v2-laag met enterprise-mogelijkheden is in preview. Als u wilt bepalen of uw ontwerp moet vertrouwen op functies voor vroege toegang of algemeen beschikbare mogelijkheden, evalueert u de tijdlijnen voor ontwerp en implementatie met betrekking tot de beschikbare informatie over de release- en migratiepaden van Premium v2.

Betrouwbaarheid

Het doel van de pijler Betrouwbaarheid is om doorlopende functionaliteit te bieden door voldoende tolerantie te ontwikkelen en de mogelijkheid om snel te herstellen van storingen.

principes voor betrouwbaarheidsontwerp een ontwerpstrategie op hoog niveau bieden die wordt toegepast op afzonderlijke onderdelen, systeemstromen en het systeem als geheel.

Controlelijst voor ontwerpen

Begin met uw ontwerpstrategie op basis van de ontwerpbeoordelingschecklist voor betrouwbaarheid. Bepaal de relevantie voor uw zakelijke behoeften, rekening houdend met de niveaus en functies van API-management en de afhankelijkheden ervan. Breid de strategie uit om zo nodig meer benaderingen op te nemen.

  • Evalueer gatewaymogelijkheden voor betrouwbaarheid en redundantie: Bepaal de API Management-laag en -functies die nodig zijn om te voldoen aan de betrouwbaarheidsvereisten van de workload voor elke omgeving.

    Evalueer de functies voor gatewayredundantie, waaronder beschikbaarheidszones, meerdere gateway-eenheden, meerdere regio's en werkruimten. Deze functies worden allemaal ondersteund in de Premium-laag. De developer-laag, die geen SLA (Service Level Agreement) bevat, is niet geschikt voor productieworkloads. Houd rekening met de afwegingen van het gebruik van functies zoals externe caching die potentiële storings- en prestatieknelpunten kunnen veroorzaken.

  • Bekijk de mogelijkheden voor waarneembaarheid: Overweeg de waarneembaarheidsmogelijkheden van de service, waaronder Azure Monitor-logboeken en metrische gegevens, Application Insights, ingebouwde analyses en ingebouwde diagnostische gegevens. Gebruik deze mogelijkheden om de betrouwbaarheidssignalen van uw workload te bewaken.

    U kunt bijvoorbeeld Azure Monitor-waarschuwingen gebruiken om u op de hoogte te stellen van mogelijke problemen met de API Management-gateway of de bijbehorende afhankelijkheden.

  • Schaalstrategieën beoordelen: Definieer criteria voor het uitschalen van de gateway door eenheden toe te voegen om de betrouwbaarheid van de service te behouden. Overweeg of u wilt schalen op basis van aanvragen, uitzonderingen of beide. Evalueer de impact van het schalen van het gatewayonderdeel op andere onderdelen van de workload. Bijvoorbeeld het effect ervan op de netwerkadresruimte en de schaalmogelijkheden van de back-ends.

  • Kritieke workloads isoleren: Bepaal of rekenisolatie nodig is om te voldoen aan workloadvereisten, zoals gegevenssoevereineiteit of prestatieoptimalisatie, in uw API's. Gebruik toegewezen gateways voor kritieke API's en gedeelde gateways voor minder kritieke API's.

    Kies een isolatiebenadering, zoals het gebruik van een toegewezen werkruimtegateway of een afzonderlijk API Management-exemplaar. Voor meerdere instanties, houd de omgevingen gesynchroniseerd als onderdeel van uw veilige implementatiepraktijken.

  • Slo-uitlijning (Service Level Objective): Houd rekening met het SLA-bereik van de gateway wanneer u de SLO's van uw workload instelt. De service biedt een eigen SLA, maar u moet ook rekening houden met de verwachte betrouwbaarheid van andere workloadonderdelen, zoals de API-back-ends.

  • Back-endfouten oplossen: Plan zowel verwachte als onverwachte back-endfouten. Test clientervaringen in deze scenario's. Evalueer gatewaybeleid om de veerkracht te vergroten en de klantervaring te optimaliseren. Richt u op quota, frequentielimieten, beleid voor opnieuw proberen, back-end circuitonderbrekers, taakverdeling en afhandeling van uitzonderingen, zoals beschreven in uw API-specificaties.

  • Teststrategieën definiëren: Gebruik een testoplossing zoals Azure Load Testing vanuit uw netwerk om de werkelijke productieworkloads weer te geven. Vertrouw niet op gepubliceerde doorvoersnelheden of andere schattingen die mogelijk niet van toepassing zijn op uw werklast.

  • Plan voor herstel na noodgevallen (DR): Bekijk de opties voor het maken van back-ups en het herstellen van de gatewayinfrastructuur en API's. Ingebouwde mogelijkheden voor back-up en herstel kunnen nuttig zijn in sommige scenario's. Maar door de klant beheerde opties, zoals APIOps-hulpprogramma's en oplossingen voor infrastructuur als code (IaC), kunnen ook worden overwogen. Ontwikkel strategieën voor het onderhouden van andere systeemgegevens, waaronder gebruikersabonnementen.

Aanbevelingen

Deze aanbevelingen voor betrouwbaarheid kunnen van toepassing zijn op de service zelf of op het verkeer dat via API's en hun beleid stroomt. De indicatoren (Service) of (API) geven aan of een aanbeveling gericht is op de service of de API.

Aanbeveling Voordeel
(Service) Schakel zoneredundantie in in de Premium-laag en zorg ervoor dat er minimaal drie eenheden zijn geïmplementeerd.

In deze configuratie zijn onder normale bedrijfsomstandigheden alle schaaleenheden in alle geconfigureerde zones actief en bedienen ze gatewayverkeer.

Plan in elk actief-actief scenario om het uitschalen in de resterende actieve zones te ondersteunen, zodat ze het verkeer kunnen verwerken dat oorspronkelijk in de defecte zone werd verwerkt.		 Tolerantie wordt gegarandeerd tijdens een storing in een datacenter binnen een regio. Tijdens een volledig datacentrumverlies blijft API-verkeer stromen door de resterende eenheden die in andere zones zijn geïmplementeerd.
(Service) Automatisch uitschalen inschakelen op basis van verkeersvraag.

In implementaties met meerdere regio's hebben secundaire regio's geen mogelijkheden voor automatisch uitschalen of inschalen. U moet een aangepaste functie of logische app implementeren die wordt geactiveerd als reactie op metrische waarschuwingen van Azure Monitor voor het beheren van eenheidsaanpassingen op basis van aanvraag.		 Er zijn gegarandeerd voldoende resources die voldoen aan de vraag van API-clients, waardoor fouten vanwege onvoldoende capaciteit worden voorkomen.
(Service) Gebruik een topologie met meerdere regio's om tolerantie te ondersteunen tegen een volledige regionale storing.

Voor deze aanpak moet u samenwerken met andere onderdelen in uw workload en de kenmerken van de geplande failover begrijpen. Plan in elk actief-actief scenario uit te schalen in resterende actieve regio's om verkeer te verwerken dat oorspronkelijk is verwerkt in de inactieve regio.

Zorg ervoor dat uw multiregionale topologie aansluit op de nalevingsvereisten voor gegevens tijdens overdracht en gegevens in cache-opslag.		 Robuuste tolerantie wordt geboden tijdens een volledige regionale storing, waardoor ononderbroken API-verkeer wordt gegarandeerd via eenheden die in andere regio's zijn geïmplementeerd.
(Service) Isoleer niet-gerelateerde API's met werkruimten of extra API Management-instanties. De impact van fouten die worden veroorzaakt door onjuiste configuratie of storingen, wordt geminimaliseerd door API's te scheiden over verschillende rekeninstanties.
(API) Test beleidsexpressies en logica grondig en koppel deze met flexibele technieken voor foutafhandeling in API Management-beleid. De clientervaring wordt verbeterd door nieuwe bronnen van fouten op de gateway te voorkomen en respijtieve degradatie of veilige tijdelijke foutafhandeling te bieden.
(Service & API) Verzamel metrische gegevens over betrouwbaarheid.

Typische metrische gegevens over betrouwbaarheid van API's zijn:

- Verwerkingslimieten en quotumoverschrijdingen.
- Foutpercentage op basis van HTTP-statuscodes.
- Afwijkingen van aanvraagsnelheid van basislijn.
- Gezondheidscontroles, inclusief afhankelijkheidsgezondheid.		 Afwijkingen van verwacht gedrag en eerdere basislijnen worden geïdentificeerd. Deze gegevens kunnen worden gebruikt om hoofdoorzaken te traceren, zoals gewijzigd gebruikersgedrag, interferentie van routinebewerkingen, onverwachte gevolgen van nieuwe functies of ongeplande fouten in de workload.
(Service & API) Gebruik ingebouwde mogelijkheden voor back-up en herstel die zijn ingebouwd in API Management als onderdeel van uw DR-playbook. Vul deze functies aan met uw IaC-artefacten en APIOps-processen voor een robuuste oplossing die verschillende scenario's kan verwerken, waaronder herstelcoördinatie met afhankelijkheden en back-ends. Bedrijfscontinuïteit wordt gegarandeerd door herstel van de API-gateway en herstel van gedefinieerde API's na een volledig systeemverlies toe te staan.

Veiligheid

Het doel van de pijler Beveiliging is het bieden van vertrouwelijkheid, integriteit en beschikbaarheid garanties voor de workload.

De veiligheidsontwerpprincipes bieden een ontwerpstrategie op hoog niveau om die doelen te bereiken door benaderingen toe te passen op het technische ontwerp ter bescherming van de API-beheergateway.

Opmerking

De controlelijst en aanbevelingen in deze sectie richten zich op het beveiligen van de API Management-gatewayresource. Het beveiligen van de API's zelf wordt slechts kort aangepakt. Zie De top 10 van de OWASP-API-beveiliging beperken in API Management voor meer informatie.

Controlelijst voor ontwerpen

Start uw ontwerpstrategie op basis van de ontwerpbeoordelingschecklist voor beveiliging en identificeer kwetsbaarheden en maatregelen om de beveiligingspositie te verbeteren. Breid de strategie uit om zo nodig meer benaderingen op te nemen.

  • Stel een beveiligingsbasislijn in: Controleer de beveiligingsbasislijn voor API Management en neem toepasselijke metingen op in uw basislijn.

  • Beveilig de implementatiepijplijn: Identificeer de personen en op rollen gebaseerd toegangsbeheerrollen die nodig zijn voor het beheren van het serviceplatform, CI/CD-pijplijnen (continue integratie en continue implementatie) en de afzonderlijke API's. Zorg ervoor dat alleen bevoegde personen toegang hebben om de dienst en diens API's te beheren.

  • Gegevensgevoeligheid evalueren: Als gevoelige gegevens stromen via API-aanvragen en -antwoorden in de API Management-gateway, moet u de beveiliging gedurende de gehele levenscyclus garanderen. Houd rekening met verschillende vereisten voor gegevensbescherming in verscheidene regio's. Evalueer servicefuncties zoals meerdere regio's om specifieke gegevens te isoleren. Controleer ook of uw cachingstrategie voldoet aan deze isolatievereisten.

  • Segmentatiestrategieën ontwikkelen voor gedeelde gateways: Als uw API Management-exemplaar API's host voor meerdere workloadteams, gebruikt u werkruimten om rollen, netwerken en mogelijk gateways te scheiden. Deze aanpak zorgt ervoor dat elk team de juiste toegang en controle heeft over de API's die ze beheren terwijl de toegang tot de API's van andere teams wordt beperkt.

  • Overweeg netwerkbesturingselementen: Vereisten en opties identificeren voor het isoleren of filteren van inkomend en uitgaand gatewayverkeer met behulp van virtuele netwerken. Bepaal of de toegang tot de gateway kan worden beperkt via Azure Private Link of als openbare toegang tot de gateway nodig is. Bepaal of de architectuur een webtoepassingsfirewall moet bevatten, zoals Azure Web Application Firewall in Azure Application Gateway of Azure Front Door, om de vereiste netwerkisolatie te bereiken en netwerkverkeer te filteren.

  • Overweeg mogelijkheden voor API-verificatie en -autorisatie: Evalueer het gebruik van id-providers, zoals Microsoft Entra-id, die ingebouwde groepen bevat of externe Microsoft Entra-id om gatewayaanvragen te screenen en OAuth-autorisatie in te schakelen voor back-end-API's.

  • Netwerkverkeer versleutelen: Identificeer de veiligste TLS-protocolversies ( Transport Layer Security) en coderingen die uw workloads kunnen ondersteunen. U hebt geen onveilige TLS-versies nodig. Gebruik TLS 1.3 wanneer dit door uw cliënten wordt ondersteund.

  • Voer bedreigingsmodellering uit op API Management en verminder het oppervlak ervan: Bepaal of specifieke API Management-onderdelen, zoals de directe beheer-API of openbare toegang tot de ontwikkelaarsportal, kunnen worden uitgeschakeld, beperkt of verwijderd.

  • Geheimen identificeren waarvoor workloads nodig zijn: Voor de gatewaybewerking zijn mogelijk certificaten, API-sleutels of andere geheime waarden vereist. Bekijk de vereisten en mogelijkheden van Azure Key Vault om geheimen en certificaten op te slaan. Of bekijk de ingebouwde API Management-mogelijkheden, zoals benoemde waarden en beheerde certificaten.

Aanbevelingen

Deze beveiligingsaanvelingen kunnen van toepassing zijn op de service zelf of op het verkeer dat via API's en hun beleid stroomt. De aanduidingen (Service) of (API) geven aan of een aanbeveling gericht is op de service of de API.

Aanbeveling Voordeel
(Service) Schakel de API voor direct beheer uit, die is afgeschaft. Gebruik Azure Resource Manager als besturingsvlak. Het oppervlak van de service wordt verminderd door een toegangspunt voor het besturingsvlak te verwijderen.
(Service) Beperk de blootstelling van de gateway uitsluitend op basis van waar legitieme clients verbinding maken.

- Gebruik virtuele netwerkinjectie zonder een openbaar IP-adres wanneer alle clients verkeer kunnen routeren via een virtueel netwerk. Gebruik een netwerkbeveiligingsgroep (NSG) om het verkeer verder te beperken tot alleen de verwachte IP-adressen van de clientoorsprong.

- Gebruik integratie van virtuele netwerken met Application Gateway of Azure Front Door als er verkeer afkomstig moet zijn van internet. Configureer de NSG zodanig dat alleen verkeer van het ene toegangspunt wordt geaccepteerd.		 Vertrouwelijkheid van netwerkverkeer wordt beschermd door blootstelling aan de bron-IP-adresbereiken te beperken die naar verwachting legitieme clients bevatten. Deze beperkingen blokkeren de toegang van bronnen die geen legitieme clientcommunicatie mogen initiëren. Het beperken van blootstelling aan legitieme verkeersbronnen verbetert de vertrouwelijkheid, integriteit en beschikbaarheid van de service.
(Service) Schakel de ontwikkelaarsportal uit als deze niet in gebruik is. Als de portal wordt gebruikt, schakelt u de registratie-ervaring uit, schakelt u anonieme toegang uit en beperkt u de toegang tot alleen vertrouwde netwerklocaties. Het oppervlak van de service en de kans op onjuiste configuratie of verwaarlozing worden verminderd.
(Service) Stel expliciet de smalste ondersteunde TLS-versies, -protocollen en -coderingen in voor uw clients en uw back-ends. Versies en ondersteunde coderingen worden beperkt tot alleen de opties die clients en back-ends ondersteunen. Deze aanpak zorgt ervoor dat verbindingen prioriteit geven aan de hoogst mogelijke verbindingen voor vertrouwelijkheid.
(Service) Sla aangepaste certificaten op in Key Vault. De functionaliteit voor certificaatbeheer wordt geleverd met Key Vault, dat routinerotatie ondersteunt en de toegang tot certificaten controleert.
(Service) Back-ends mogen alleen verkeer van de API-gateways accepteren en alle andere verkeer blokkeren. Kwaadwillig verkeer wordt tegengehouden zodat de beveiliging en andere overkoepelende maatregelen door de gateway worden afgehandeld.
(Service) Voor API Management-exemplaren die API's hosten voor meerdere teams of gesegmenteerde workloads, moet u een robuuste strategie voor isolatie van toegangsbeheer ontwerpen. Gebruik werkruimten of implementeer een strikt APIOps-proces om deze strategie te bereiken.

Teams mag alleen toegang hebben tot de API's die ze bezitten. Ze mogen geen toegang hebben tot andere API's die mogelijk in hetzelfde exemplaar worden gehost.		 De laterale beweging van aanvallers van een gecompromitteerde set API's naar andere niet-gerelateerde API's wordt verminderd.
(API) Sla geheimen op in Key Vault en stel ze beschikbaar voor beleid via benoemde waarden. Gebruik Key Vault niet om niet-geheime gegevens op te slaan. Gebruik benoemde waarde-eigenschappen rechtstreeks voor deze waarden. Het rouleren van geheimen wordt aangemoedigd via een enkele beheerinterface in Key Vault, vergelijkbaar met de aanpak die voor certificaten wordt gebruikt. Dit proces zorgt ervoor dat API Management dienovereenkomstig wordt bijgewerkt. Benoemde waarden zorgen ook voor een consistente ervaring voor beleidsconfiguratie voor zowel geheimen als niet-secrets. Alle geheime toegang wordt ook gecontroleerd in Key Vault om een toegangsverloop te bieden. Als u alleen geheimen opslaat in Key Vault, wordt de afhankelijkheid van Key Vault geminimaliseerd en wordt Key Vault niet omgezet in een toepassingsconfiguratieservice.
(API) Gebruik verschillende door de gebruiker toegewezen beheerde identiteiten voor verschillende API's met behulp van het beleid voor door verificatie beheerde identiteiten . Elke API is ingeschakeld voor een onafhankelijke identiteit, die segmentatiedoelen ondersteunt via toegang tot minimale bevoegdheden voor elke API. Het biedt ook betere controlebaarheid in de back-endsystemen.
(API) Indien mogelijk moeten clients worden geverifieerd met OAuth 2.0-stromen in plaats van alleen vooraf gedeelde sleutels te gebruiken, inclusief abonnementssleutels of clientcertificaten. Clientidentificatie voor controledoeleinden wordt verbeterd, sleutelrotatie wordt geëlimineerd en de last voor clients om geheimen te beveiligen wordt verminderd vergeleken met het gebruik van vooraf gedeelde sleutels.
(API) Onderdrukt HTTP-headers van API-antwoorden met behulp van het set-headerbeleid waarmee implementatiedetails kunnen worden weergegeven. De kosten voor aanvallers worden verhoogd door implementatiegegevens achter te houden.
(API) Gebruik geen API-tracering in productie. Het voorkomen van het blootstellen van gevoelige gegevens in aanvraagtraceringen.
(API) Defender voor API's gebruiken. API-beveiligingsinzichten, aanbevelingen en detectie van bedreigingen worden geboden.
(API) Beveilig back-endbronnen door sleutelbeveiligingscontroles in API-beleid te delegeren, zoals validate-jwt, ip-filter, validate-headers, validate-content. Het aantal niet-legitieerde verkeer dat back-endservices bereikt, wordt verminderd door beveiligingscontroles bij de gateway uit te voeren. Deze offloading-benadering helpt de integriteit en beschikbaarheid van deze resources te beschermen.
(API) Pas SDL-procedures (Security Development Lifecycle) toe op wijzigingen in API-beleid op dezelfde manier als u voorgestelde wijzigingen toepast op toepassingscode in uw workload. Beleidsmaatregelen worden uitgevoerd met een hoogst bevoorrechte inzage in het API-verkeer. Het omzeilen van back-endbeveiligingen voor vertrouwelijkheid, integriteit en beschikbaarheid door een aangetaste API-gateway wordt voorkomen.
(Service & API) Gebruik beheerde identiteiten voor service- en API-afhankelijkheden. Verbindingen met Key Vault, Azure Event Hubs en andere afhankelijkheden, zoals certificaten en benoemde waarden, worden tot stand gebracht zonder afhankelijk te zijn van vooraf gedeelde geheimen.
(Service & API) Maak verbinding met afhankelijkheden, zoals Key Vault, Event Hubs en back-ends via privénetwerkverbindingen, indien mogelijk. Vertrouwelijkheid van verkeer wordt beschermd door het verkeer niet buiten het privénetwerk weer te geven.
(Service & API) Clientverkeer dat is gericht op api's die beschikbaar zijn op internet, moeten eerst via een webtoepassingsfirewall, zoals Web Application Firewall, worden doorgegeven voordat API Management wordt bereikt. Beveilig ook openbare eindpunten met behulp van Azure DDoS Protection. Het aantal niet-legitieerde verkeer dat de gateway en back-endservices bereikt, wordt verminderd door beveiligingscontroles uit te voeren met een webtoepassingsfirewall. Het verminderen van dit verkeer helpt de integriteit en beschikbaarheid van die middelen te beschermen.
(Service & API) Evalueer en schakel alle controles voor naleving van Azure Policy-regelgeving in die relevant zijn voor uw workload. Het API Management-exemplaar is afgestemd op de gewenste houding en blijft uitgelijnd naarmate de workload zich ontwikkelt door beveiligingsbeleidsregels te implementeren.

Kostenoptimalisatie

Kostenoptimalisatie richt zich op het detecteren van uitgavenpatronen, het prioriteren van investeringen in kritieke gebieden en het optimaliseren van andere gebieden. Dit alles om te voldoen aan het budget van de organisatie terwijl aan de bedrijfsvereisten wordt voldaan.

De ontwerpprincipes voor kostenoptimalisatie bieden een ontwerpstrategie op hoog niveau voor het bereiken van deze doelen en het waar nodig maken van compromissen in het technische ontwerp met betrekking tot API Management en de bijbehorende omgeving.

Controlelijst voor ontwerpen

  • Houd rekening met het kostenmodel van API Management: Gebruik de Azure-prijscalculator met de accountvoordelen en -criteria van uw organisatie voor SLA en schaalbaarheid om nauwkeurige kostenramingen te ontwikkelen voor het gebruik van een API Management-servicelaag. Bepaal of een verrekenmodel nodig is en hoe dit berekend kan worden op basis van metrische gegevens, tags en tokens.

    Het kostenmodel voor de dienst wordt voornamelijk beïnvloed door het serviceniveau, het aantal eenheden en het aantal gateways. Evalueer de extra kosten die zijn gekoppeld aan het onderhouden van een reserveeenheid of het implementeren van een actief-passieve DR-configuratie.

    Als u werkruimten implementeert, evalueert u de kosten voor het gebruik van afzonderlijke versus gedeelde werkruimtegateways om te voldoen aan de afzonderlijke API-stroomvereisten van verschillende API-teams of belanghebbenden.

  • Geschatte schaalkosten: Ontwikkel schaalcriteria om een hoog gebruik van de gatewaybronnen te behouden. Evalueer de basiskosten in een pre-productieomgeving en voer tests uit om de kosten van opschaling te modelleren op basis van de verwachte werkverkeersbelasting.

    Ontwerp een risicobeperkingsstrategie om misbruik van uw gateways te voorkomen, wat kan leiden tot dure schaling buiten predicatiegebruik.

  • Serviceconfiguraties en -beleid evalueren: Mogelijkheden zoals frequentielimiet en gelijktijdigheid van limieten kunnen worden gebruikt als technieken voor kostenoptimalisatie voor het beheren van aanvraagbelastingen.

  • Logische plaatsing optimaliseren: Beoordeel of back-endservers rendabeler zijn voor verwerkingslogica of dat de gateway het resourcegebruik moet verwerken. De gateway is een krachtig onderdeel voor het implementeren van overkoepelende aspecten, maar het kan te veel functies uitvoeren in bepaalde scenario's. Identificeer resource-intensieve aanvraagverwerkingstaken die de gateway uitvoert en bepaal of het verplaatsen van die logica naar back-endservers kosten kan verlagen.

Aanbevelingen

Deze aanbevelingen voor kostenoptimalisatie kunnen van toepassing zijn op de service zelf of op het verkeer dat via API's en hun beleid stroomt. De aanduidingen (Service) of (API) geven aan of een aanbeveling gericht is op de service of de API.

Aanbeveling Voordeel
(Service) Gebruik de goedkoopste laag die ondersteuning biedt voor de vereisten van uw workload. Kies bijvoorbeeld een Standard-laag in plaats van een Premium-laag als uw workload niet profiteert van de toegevoegde functionaliteit op een manier die het rendement op investering (ROI) rechtvaardigt. Het kopen van ongebruikte of te weinig gebruikte mogelijkheden wordt vermeden.
(Service) Gebruik niet-productielagen of tijdelijke infrastructuur in lagere omgevingen, zoals ontwikkelomgevingen, proof-of-concept-implementaties en initiële kostenmodelleringsactiviteiten. Kosten voor middelen worden bespaard voor omgevingen die nuttig kunnen blijven zonder exact te hoeven voldoen aan de configuratie- en uptimevereisten van de productie.
(Service) Inschalen wanneer de vraag afneemt. Configure autoscale-regels of andere geautomatiseerde processen om eenheden te verminderen wanneer de gatewaycapaciteit onder de gedefinieerde drempelwaarden zakt. Onnodige kosten worden verlaagd door de capaciteit af te stemmen op de vraag.
(Service) Bereken eventuele kostenvoordelen van een federatief model voor API Management met behulp van werkruimten om API's te bedienen en tegelijkertijd teamisolatie te bieden. Het implementatie- en beheeroppervlak wordt verminderd. Deze aanpak streeft naar schaalvoordelen bij het aankopen van tijd en middelen.
(Service) Werkruimten buiten gebruik stellen wanneer ze niet meer worden gebruikt. Uitgaven voor ongebruikte resources worden vermeden.
(Service) Gebruik de ingebouwde cache als de gegevens in de cache van uw workload binnen de beperkingen van de ingebouwde cache in uw laag passen. Kosten voor het aanschaffen en onderhouden van een externe Redis-compatibele cache worden vermeden.
(Service) U kunt schadelijk verkeer blokkeren voordat deze de gateway bereikt met behulp van netwerkbesturingselementen, DDoS-beveiliging en firewalls voor webtoepassingen. Voor specifieke lagen van API Management worden kosten in rekening gebracht op basis van het aantal HTTP-aanvraagbewerkingen dat door de gateway wordt verwerkt. Hierdoor kan ongewenst verkeer, zoals door de bot gegenereerde aanvragen, de kosten verhogen.

Evalueer de kosten van het blokkerende mechanisme ten opzichte van de geschatte kosten van het verminderen van HTTP-bewerkingen om te evalueren of deze benadering een ROI heeft.		 De kosten als gevolg van overmatige schadelijke of hinderlijke HTTP-bewerkingen tegen de gateway worden verminderd.
(API) Optimaliseer de beleidsexpressies en -verwerking en code om overmatig rekenresourcegebruik te voorkomen, zoals processor, netwerken of geheugen. Onnodige implementatie van meer eenheden om capaciteit te bieden voor niet-geoptimaliseerde beleidsimplementaties en code wordt vermeden.
(API) Evalueer de kosten van logische plaatsing tussen uw gateway, uw back-end of uw openbare ingangspunt, zoals Azure Front Door. Dezelfde verwerking kan vaak plaatsvinden op een van deze lagen, elk met zijn eigen compromissen. Sommige lagen kunnen echter kostenbesparingen opleveren vanwege ongebruikte capaciteit die op dat niveau beschikbaar is. Cachelogica die oorspronkelijk in de back-end is geïmplementeerd, kan bijvoorbeeld rendabeler worden geïmplementeerd op gatewayniveau met behulp van de ingebouwde cache. Deze aanpak vermindert extra netwerk- en rekenoverhead voor back-endservices. De belasting van resources met hoge kosten wordt geminimaliseerd door mogelijkheden in de meest rendabele laag te plaatsen. Deze benadering verschuift workloads naar lagen met reservecapaciteit of lagere kosten voor computeropties.

Operationele uitmuntendheid

Operational Excellence richt zich voornamelijk op procedures voor ontwikkelprocedures, waarneembaarheid en releasebeheer.

De ontwerpprincipes voor Operational Excellence bieden een ontwerpstrategie op hoog niveau voor het bereiken van deze doelstellingen voor de operationele vereisten van de workload.

Begin uw ontwerpstrategie op basis van de ontwerpbeoordelingschecklist voor Operationele Uitmuntendheid voor het definiëren van processen voor observeerbaarheid, testen en implementatie met betrekking tot API-beheer.

Controlelijst voor ontwerpen

  • Bekijk belangrijke kennis en vaardigheden die nodig zijn om de service te bedienen: Gebieden zijn onder andere api-levenscyclus, DevOps-processen, netwerken en connectiviteit, bewaking en waarneembaarheid en softwareontwikkeling. Deze benadering omvat beleidsconfiguratie, eenheidstests en het maken van CI/CD-pijplijnen.

  • Houd rekening met documentatiebehoeften: Organisaties moeten zich inzetten voor het documenteren van processen voor configuratie op service- en API-niveau, levenscyclusoperaties en de verschillende toegangspatronen voor API-teams.

  • Evalueer standaardhulpprogramma's ter ondersteuning van servicebewerkingen. Gebruik bijvoorbeeld APIOps-methoden , zoals GitOps en CI/CD, om API's te publiceren en API-configuraties te beheren. Gebruik hulpprogramma's voor IaC voor configuratiewijzigingen op serviceniveau. Ontwerp herbruikbare artefacten die naadloos kunnen worden overgestapt van ontwikkelomgevingen naar productie. Overweeg een linter zoals Spectral te integreren in API-goedkeuringspijplijnen, waarbij je deze zelf beheert of integreert als onderdeel van een Azure-service zoals Azure API Center.

  • Belangrijke operationele metrische gegevens en logboeken bepalen: Bekijk de metrische gegevens voor productie. Deze metrische gegevens omvatten gatewaycapaciteit, CPU-gebruik, geheugengebruik en het aantal aanvragen. Bekijk logboeken en hulpprogramma's voor waarneembaarheid, zoals Azure Monitor en Application Insights. Bepaal welke strategieën en hulpprogramma's nodig zijn om grote hoeveelheden observationele gegevens effectief te beheren in productieomgevingen. Bepaal query's die bruikbare inzichten bieden voor zowel de gatewayoperator als belanghebbenden die specifieke gehoste API's bewaken.

  • Plan regelmatig testen van productieworkloads met behulp van belastingstests.

  • Operationele taken identificeren buiten CI/CD- of IaC-processen waarvoor automatisering is vereist. Plan automatisering op gebieden zoals API Management-beleidsbronbeheer, Azure-beleid en specifieke configuraties van de ontwikkelaarsportal.

Aanbevelingen

Deze aanbevelingen voor operationele uitmuntendheid kunnen van toepassing zijn op de service zelf of op het verkeer dat via API's en hun beleid stroomt. De aanduidingen (Service) of (API's) geven aan of een aanbeveling gericht is op de service of de API's.

Aanbeveling Voordeel
(Service) Azure Diagnostics-resourcelogboeken configureren voor API Management. Door het platform gegenereerde logboeken zijn beschikbaar om query's uit te voeren op routinebewerkingen, behoeften op aanvraag of urgente scenario's, zoals beveiligingscontroles.
(Service) Gebruik Azure Event Grid voor automatisering op basis van zinvolle gebeurtenissen die uw API Management-exemplaar genereert, zoals APICreated. Automatiserings- of meldingstaken kunnen worden gebouwd rond belangrijke levenscyclus-gebeurtenissen die plaatsvinden in het API Management-exemplaar.
(Service) Vermijd het gebruik van een zelf-hostende gateway als een door Microsoft gehoste gateway-eenheid in uw scenario werkt. Automatiserings- of meldingstaken kunnen worden gebouwd rond belangrijke levenscyclus-gebeurtenissen die plaatsvinden in het API Management-exemplaar.
(Service) Pas alle ingebouwde Azure Policy-beleidsregels toe waarmee u uw exemplaar kunt beheren en beperken zodat deze overeenkomt met de workloadvereisten, inclusief beveiligingsvereisten. Gebruik bijvoorbeeld weiger beleidsregels om te voorkomen dat API's via HTTP worden blootgesteld of om te voorkomen dat de directe beheers-REST-API wordt ingeschakeld. Gebruik controlebeleid als beleid voor weigeren niet beschikbaar is of maak aangepast beleid voor weigeren als dit belangrijk is voor uw workload. Het API Management-exemplaar is afgestemd op het ontwerp en blijft uitgelijnd naarmate de workload zich ontwikkelt.
(Service) Raak vertrouwd met de mogelijkheid problemen vaststellen en oplossen in Azure Portal.

Gebruik de Netwerkstatus-blad in het portaal om netwerkconnectiviteit te verhelpen.		 Personen van sitebetrouwbaarheidstechniek kunnen gatewayprestaties, servicebeschikbaarheid en netwerkverbindingsproblemen in alle omgevingen identificeren en oplossen.
(API) Gebruik Event Hubs om logboek- of gebeurtenisstromen van API-aanroepen te verwerken waarvoor bijna realtime reacties of korte tijdvensterbewerkingen zijn vereist. Er is bijna realtime beschikbaarheid van logboekvermeldingen beschikbaar. De opnamevertraging van logboekgegevens die optreedt bij het loggen naar Azure Monitor binnen API's, wordt vermeden.
(API) Ondersteuning voor het gebruik van API-tracering in ontwikkeling om ontwikkelaars inzicht te geven in hun beleidsimplementatie. De productiviteit van ontwikkelaars wordt geoptimaliseerd door inzicht te bieden in de implementatie van beleid binnen een API. Zonder deze mogelijkheid moeten ontwikkelaars hacks in beleidsuitvoering introduceren om inzicht te krijgen.
(API) Definieer altijd back-ends met behulp van de back-endfunctie van API Management. Verwijs naar deze back-ends in uw beleid op basis van ID met behulp van set-backend-service. Achterkanten met gelijkmatig verdeelde belasting moeten worden gedefinieerd als een backend pool. Wijzigingen in de back-endverbinding zijn van toepassing op alle API's die gebruikmaken van de back-end zonder dat er updates nodig zijn voor afzonderlijke beleidscode. Het risico op onjuiste configuraties of het negeren van wijzigingen in API-beleid wordt verminderd en scenario's waarin meerdere API's dezelfde back-end delen, zijn geschikt via deze configuratieabstractie.
(API) Ontwerp de benadering voor versiebeheer van uw API's, zodat deze overeenkomt met de versie- en revisiemogelijkheden van API Management. Verwerk deze aanpak in uw API-implementatieprocessen. Een API-versiebeheerstrategie die standaard door API Management wordt ondersteund, wordt gebruikt om te profiteren van ingebouwde mogelijkheden in plaats van aangepaste oplossingen te bouwen.
(Service & API) Definieer een consistent en duurzaam operationeel proces voor het toevoegen, wijzigen en verwijderen van API's. Bepaal of u deze ervaring handmatig wilt beheren via de portal of deze wilt implementeren via een APIOps-proces. Gebruik liever een op IaC gebaseerde benadering in plaats van een portalbenadering.

De weergave van API Management in de Resource Manager-API bestaat uit veel onderliggende resources, dus het is belangrijk om een gelaagde benadering te gebruiken voor op IaC gebaseerd beheer van deze resourceverzameling.		 API-specificaties en hun gatewayimplementaties worden geïntegreerd in de wijzigingsbeheerprocessen van de workload. Deze aanpak voorkomt dat wijzigingen in back-end-API's anders worden verwerkt dan de manier waarop ze via de gateway worden blootgesteld aan API-clients.

Prestatie-efficiëntie

Prestatie-efficiëntie gaat over het waarborgen van de gebruikerservaring, zelfs wanneer er een toename in de belasting is door capaciteitsbeheer. De strategie omvat het schalen van resources, het identificeren en optimaliseren van potentiële knelpunten en het optimaliseren van piekprestaties.

De ontwerpprincipes voor Prestatie-efficiëntie een ontwerpstrategie op hoog niveau bieden voor het bereiken van deze capaciteitsdoelen ten opzichte van het verwachte gebruik.

Start uw ontwerpstrategie op basis van de checklist voor ontwerpbeoordeling voor prestatie-efficiëntie om een basislijn te definiëren op basis van belangrijke prestatie-indicatoren voor API-beheer.

Controlelijst voor ontwerpen

  • Prestatiedoelen definiëren: Belangrijke metrische gegevens voor het evalueren van de prestaties van de API Management-gateway zijn metrische capaciteitsgegevens, zoals CPU- en geheugengebruikspercentages voor gatewayinfrastructuur, aanvraagduur en aanvraagdoorvoer. Definieer in implementaties met meerdere regio's prestatiedoelen voor elke regio. De klant moet de juiste schaaldrempels definiëren op basis van verkeerspatronen, API-workloads en schaaltijden.

  • Prestatiegegevens verzamelen: Bekijk de mogelijkheden van ingebouwde analyses, metrische gegevens van Azure Monitor, Azure Monitor-logboeken, Application Insights en Event Hubs om prestaties op verschillende granulariteitsniveaus te verzamelen en te analyseren.

  • Bekijk hoe u problemen met liveprestaties kunt identificeren: Indicatoren voor problemen met liveprestaties zijn onder andere beschikbaarheid van Azure-services, HTTP-responsfouten en fouten die zijn opgetreden in de sectie Problemen vaststellen en oplossen in de portal. Los prestatie- en beschikbaarheidsproblemen op met behulp van Application Insights, Kusto-query's en aanbevelingen van API Management Diagnostics in Azure Portal.

  • Testprestaties: Test de prestaties onder productieomstandigheden met behulp van belastingstests.

  • Evalueer aangrenzende services die de prestaties kunnen verbeteren: Cachebeleid of een externe cache kan de prestaties van specifieke API-bewerkingen verbeteren. Azure Front Door en Application Gateway zijn veelvoorkomende keuzes voor TLS-offloading.

  • Bekijk de gedocumenteerde limieten en beperkingen:API Management heeft limieten en beperkingen. Bekijk de gedocumenteerde beperkingen en vergelijk deze met de vereisten van uw workload om te zien of u een oplossing moet ontwerpen die deze beperkingen vermijdt.

Aanbevelingen

Deze aanbevelingen voor prestatie-efficiëntie kunnen van toepassing zijn op de service zelf of op het verkeer dat via API's en hun beleid stroomt. De markeringen (Service) ofwel (API) geven aan of een aanbeveling gericht is op de service of de APIs.

Aanbeveling Voordeel
(Service) Dynamisch schalen om aan de vraag te voldoen. Configure automatische schalingsregels of andere geautomatiseerde processen om de gateway-eenheden aan te passen aan een beoogde gebruikscapaciteit. Elasticiteit wordt bereikt op basis van gelijktijdig gebruik, waardoor resourceuitputting van momenteel geïmplementeerde eenheden of overtoewijzing van capaciteit wordt voorkomen.
(API) Minimaliseer dure verwerkingstaken, zoals het genereren van grote gebufferde payloadgroottes, door gebruik te maken van de inhoudsvalidatiebeleid op grote aanvraaglichamen of door een hoog aantal actieve WebSockets te behouden. De belasting van schaaleenheden wordt verminderd, waardoor ze meer aanvragen gelijktijdig kunnen verwerken voordat ze moeten uitschalen.
(Service & API) Prestatiegegevens verzamelen.

Algemene metrische gegevens over API-prestaties zijn:

- Verwerkingstijd aanvragen voor de gateway zelf en voor de volledige bewerking.
- Metrische gegevens over resourcegebruik van gateway-eenheden.
- Doorvoermetingen zoals aanvragen per seconde of megabits per seconde.
- Cache-hitverhouding.		 De werkelijke prestaties worden gemeten op basis van de doelen van de workload.
(Service & API) Definieer een steekproefpercentage voor Application Insights dat voldoende zichtbaarheid biedt zonder dat dit van invloed is op de prestaties. Aan de behoeften van waarneembaarheidsgegevens wordt voldaan zonder dat dit van invloed is op de algehele prestaties.
(Service & API) Evalueer de invloed van de prestaties van logische plaatsing tussen uw gateway, uw back-end of uw openbare toegangspunt, zoals Azure Front Door. Dezelfde verwerkingstaken kunnen vaak plaatsvinden op elk van deze lagen, met prestatienadelen en beperkingen in optimalisatiemogelijkheden voor elk van deze lagen. Als een taak, zoals een API Management API-beleid, te veel latentie introduceert, kunt u overwegen of die taak ergens anders op een meer geoptimaliseerde manier kan worden uitgevoerd. Taken die latentie aan API's toevoegen, worden uitgevoerd op berekeningen die zijn geoptimaliseerd om te voldoen aan de workloadvereisten.

Azure-beleid

Azure biedt een uitgebreide set ingebouwde beleidsregels met betrekking tot API Management en de bijbehorende afhankelijkheden. Enkele van de voorgaande aanbevelingen kunnen worden gecontroleerd via Azure Policy. U kunt bijvoorbeeld controleren of:

  • De gateway is geconfigureerd voor zoneredundantie.
  • Er zijn passende netwerkcontroles ingesteld voor de API Management-gateway, zoals implementatie in een virtueel netwerk.
  • De serviceconfiguratie-eindpunten zijn niet openbaar toegankelijk.
  • De directe Management REST API is uitgeschakeld.

Voor omvattend beheer, bekijk en evalueer de ingebouwde definities van Azure Policy en andere beleidsregels die van invloed kunnen zijn op de beveiliging van de API Management gateway.

Aanbevelingen voor Azure Advisor

Azure Advisor is een gepersonaliseerde cloudconsultant waarmee u de aanbevolen procedures kunt volgen om uw Azure-implementaties te optimaliseren.

Zie Azure Advisor voor meer informatie.

Advisor kan ook andere aanbevelingen in uw productiesysteem naar voren brengen, zoals:

  • Failure to require long JWT key sizes in the validate-jwt policy.
  • You used a legacy Resource Manager API version to deploy the resource.
  • API-sleuteltokens liggen dicht bij de vervaldatum.
  • Failure in a certificate rotation operation.

Tradeoffs

Mogelijk moet u een compromis tussen ontwerpen maken als u de benaderingen in de controlelijsten voor pijlers gebruikt. Hier volgen enkele voorbeelden van voordelen en nadelen.

High availability through redundancy and isolation

  • Hoge beschikbaarheid. Het toevoegen van redundantie aan een architectuur is van invloed op de kosten. Bijvoorbeeld, het inzetten van ten minste drie eenheden om stroomuitval in zones te voorkomen, is mogelijk financieel niet haalbaar voor uw werklast. De kosten nemen verder toe met een architectuur met meerdere regio's, waarvoor ten minste zes eenheden of drie eenheden per regio nodig zijn. Een installatie met meerdere regio's voegt ook operationele kosten toe voor het coördineren van veilige implementaties, betrouwbare schaalaanpassing en failover-coördinatie met back-ends.

  • Isolatie. Het isoleren van workloads in werkruimten of API Management-exemplaren voegt operationele complexiteit toe, omdat het de beheersing van een multitenant-systeem dat rekenisolatie heeft, omvat.

Schaal naar gelang de vraag

  • Wanneer u automatisch uitschaalt om de vraag van klanten met een goed gedrag aan te passen, worden deze kosten al meegenomen in uw kostenmodellen. Met deze schaalfunctie kan de service echter ook schalen om verkeer van hinderlijk en schadelijk karakter af te handelen.

  • Mitigating undesired traffic incurs costs. Het toevoegen van services zoals een webtoepassingsfirewall en DDoS-beveiliging verhoogt de kosten. Het schalen van uw service om verkeer af te handelen, verhoogt de kosten vanwege extra eenheden. Het instellen van hogere schaallimieten kan de uitgaven beperken, maar kan leiden tot betrouwbaarheidsproblemen voor legitieme gebruikers als schadelijk of schadelijk verkeer uw API overweldigt.

Gefedereerde versus gedistribueerde benadering

Een fundamentele beslissing in API Management is of u afzonderlijke workloads binnen één API Management-exemplaar wilt plaatsen of workloads wilt isoleren over meerdere exemplaren in een volledig autonome topologie.

API Management-werkruimten maken efficiënte bewerking mogelijk als een multitenant-colocatieplatform voor meerdere API-teams. De gelaagde prijsmodellen zijn ontworpen om servicekosten te kunnen delen in alle tenants die gebruikmaken van de gateways. Net als elk colocatieplatform kunnen storingen of onjuiste configuraties echter leiden tot wijdverspreide gevolgen voor niet-gerelateerde workloads die dezelfde infrastructuur delen.

Een volledig gedistribueerd model, waarbij elk workloadteam zijn eigen exemplaren beheert, introduceert duplicatieve kosten en redundantie in routinebewerkingen. Het biedt echter inherente straalbeperking voor betrouwbaarheid, beveiliging en prestatiegerelateerde incidenten.

Volgende stappen

API Management wordt vaak gecombineerd met de volgende services. Zorg ervoor dat u de servicehandleidingen of productdocumentatie bekijkt wanneer uw werklast de volgende services bevat.

De volgende artikelen tonen enkele van de aanbevelingen die in dit artikel zijn besproken.