Sdílet prostřednictvím

Osvědčené postupy architektury pro Azure API Management

Azure API Management je platforma pro správu a brána pro rozhraní API ve všech prostředích, včetně hybridního a multicloudového prostředí. Jako řešení PaaS (platforma jako služba) pomáhá služba API Management podporovat životní cyklus rozhraní API vaší úlohy.

Tento článek předpokládá, že jste jako architekt zkontrolovali rozhodovací strom integračních služeb a jako integrační službu pro vaši úlohu zvolili api Management. Pokyny v tomto článku poskytují architektonická doporučení, která odpovídají principům pilířů Well-Architected Framework.

Rozsah technologií

Tato kontrola se zaměřuje na vzájemně související rozhodnutí pro následující prostředek Azure.

  • Azure API Management

Oborem této příručky je služba API Management, především komponenta brány (rovina dat), která proxy serveruje požadavky rozhraní API z klientských aplikací na back-endová rozhraní API hostovaná na různých platformách nebo na různých místech. Architektura úlohy by měla zohledňovat řídicí rovinu služby API Management a související komponenty, jako jsou klientské aplikace, které přistupují k bráně, a back-endová rozhraní API, která zpracovávají směrované požadavky. Integruje také podpůrné služby Azure, včetně sítí, monitorování, správy identit a dalších funkcí.

Tato příručka se nevztahuje na Azure API Center. Řeší pouze témata na úrovni rozhraní API, protože se týkají služby API Management, místo aby poskytovala dobře navrženou perspektivu při návrhu rozhraní API.

Note

Ne všechna doporučení platí pro všechny úrovně služeb služby API Management. Řada doporučení v této příručce se zaměřuje na úrovně Standard v2, Classic Premium a Premium v2 služby API Management, což jsou doporučené produkční úrovně pro většinu podnikových úloh.

Reliability

Účelem pilíře spolehlivosti je zajistit nepřetržitou funkčnost budováním dostatečné odolnosti a schopnosti rychle se zotavit ze selhání.

principy návrhu spolehlivosti poskytují základní strategii návrhu použitou pro jednotlivé komponenty, systémové toky a systém jako celek.

Kontrolní seznam návrhu úloh

Zahajte strategii návrhu na základě kontrolního seznamu pro kontrolu návrhů z hlediska spolehlivosti. Určete její význam pro vaše obchodní požadavky a mějte na paměti úrovně a funkce služby API Management a její závislosti. Rozšiřte strategii tak, aby podle potřeby zahrnovala více přístupů.

  • Vyhodnocení možností brány pro spolehlivost a redundanci: Určete úroveň a funkce služby API Management, které jsou potřeba ke splnění požadavků na spolehlivost úloh pro každé prostředí.

    Vyhodnoťte funkce redundance brány, včetně zón dostupnosti, více jednotek brány, více oblastí a pracovních prostorů. Všechny tyto funkce jsou podporovány na úrovni Premium. Úroveň Premium v2 v současné době podporuje všechny tyto funkce s výjimkou několika oblastí. Úroveň Developer, která nezahrnuje smlouvu o úrovni služeb (SLA), není vhodná pro produkční úlohy. Vezměte v úvahu kompromisy při zavádění funkcí, jako je externí ukládání do mezipaměti, které můžou představovat potenciální body selhání a kritických bodů výkonu.

  • Kontrola možností pozorovatelnosti: Zvažte možnosti pozorovatelnosti služby, včetně protokolů a metrik služby Azure Monitor, Application Insights, integrovaných analýz a integrované diagnostiky. Pomocí těchto možností můžete monitorovat signály spolehlivosti vaší úlohy.

    Zvažte například použití upozornění služby Azure Monitor , která vás upozorní na potenciální problémy s bránou služby API Management nebo jejími závislostmi.

  • Kontrola strategií škálování: Definujte kritéria pro horizontální navýšení kapacity brány přidáním jednotek pro zachování spolehlivosti služeb. Zvažte, jestli se má škálovat na základě požadavků, výjimek nebo obojího. Vyhodnoťte dopad škálování komponenty brány na jiné součásti úlohy. Má například vliv na adresní prostor sítě a možnosti škálování back-endů.

  • Izolace kritických úloh: Určete, jestli je pro splnění požadavků úloh potřeba izolace výpočetních prostředků, jako je suverenita dat nebo optimalizace výkonu, ve vašich rozhraních API. Používejte vyhrazené brány pro kritická rozhraní API a sdílené brány pro méně důležitá rozhraní API.

    Zvolte přístup izolace, jako je použití vyhrazené brány pracovního prostoru nebo samostatné instance služby API Management. V případě několika instancí udržujte prostředí synchronizovaná jako součást vašich postupů bezpečného nasazení.

  • Sladění cíle na úrovni služby (SLO): Při nastavování cílů úrovně služeb vaší úlohy zvažujte rozsah SLA brány. Služba poskytuje vlastní smlouvu SLA, ale musíte také zohlednit očekávanou spolehlivost jiných komponent úloh, jako jsou back-endy rozhraní API.

  • Řešení chyb back-endu: Naplánujte očekávané i neočekávané chyby back-endu. Otestujte prostředí klienta v těchto scénářích. Vyhodnoťte zásady brány, abyste zlepšili odolnost a vylepšili prostředí klienta. Zaměřte se na kvóty, omezení rychlosti, zásady opakování, jističe back-endu, vyrovnávání zatížení a zpracování výjimek, jak je uvedeno ve specifikacích rozhraní API.

  • Definování strategií testování: K vyjádření skutečných produkčních úloh použijte testovací řešení, jako je například Zátěžové testování Azure z vaší sítě. Nespoléhejte na publikovanou propustnost ani jiné odhady, které se nemusí vztahovat na vaši úlohu.

  • Plánování zotavení po havárii (DR): Projděte si možnosti zálohování a obnovení infrastruktury brány a rozhraní API. Integrované možnosti zálohování a obnovení můžou být užitečné v některých scénářích. Je ale také možné zvážit možnosti spravované zákazníkem, jako jsou nástroje APIOps a řešení infrastruktury jako kódu (IaC). Vyvíjejte strategie pro údržbu dalších systémových dat, včetně uživatelských předplatných.

Doporučení pro konfiguraci

Tato doporučení pro spolehlivost se vztahují buď na samotnou službu, nebo na provoz, který prochází přes rozhraní API a jejich zásady. Designátory (Služba) nebo (API) označují, jestli doporučení cílí na službu nebo rozhraní API.

Recommendation Benefit
(Služba) Povolte zónovou redundanci (k dispozici na úrovních Premium a Premium v2) a nasaďte aspoň dvě jednotky.

Za normálních provozních podmínek jsou všechny jednotky škálování ve všech konfigurovaných zónách aktivní a obsluhují provoz brány.

V jakémkoli scénáři typu aktivní-aktivní naplánujte rozšíření kapacity ve zbývajících aktivních zónách, aby zvládly provoz, který jednotky původně zpracovávaly v nefunkční zóně.		 Odolnost je zajištěna během výpadku datacentra v rámci oblasti. Během úplné ztráty datacentra pokračuje provoz rozhraní API přes zbývající jednotky nasazené v jiných zónách.
(Služba) Povolte automatické horizontální navýšení kapacity na základě požadavků na provoz.

Při nasazení ve více regionech nemají sekundární regiony automatické možnosti měřítkového navýšení nebo snížení kapacity. Je potřeba implementovat vlastní funkci nebo aplikaci logiky, která se aktivuje v reakci na upozornění na metriky služby Azure Monitor, abyste mohli spravovat úpravy jednotek na základě poptávky.		 Je zaručeno, že dostatek prostředků splňuje poptávku od klientů rozhraní API, což brání selháním kvůli nedostatečné kapacitě.
(Služba) Topologie s více oblastmi slouží k podpoře odolnosti proti úplnému regionálnímu selhání.

Tento přístup vyžaduje, abyste se koordinovali s dalšími komponentami ve vaší pracovní zátěži a porozuměli jejich plánovaným charakteristikám převzetí při selhání. V jakémkoli scénáři typu aktivní-aktivní naplánujte podporu rozšíření kapacity ve zbývajících aktivních regionech pro zpracování provozu, který původně zpracovávala nyní neaktivní oblast.

Zajistěte, aby topologie ve více oblastech odpovídala všem požadavkům na dodržování předpisů pro přenášená data nebo data v rezidenci mezipaměti.		 Robustní odolnost je poskytována během úplného regionálního výpadku, což pomáhá zajistit nepřerušovaný provoz rozhraní API prostřednictvím jednotek nasazených v jiných oblastech.
(Služba) Izolujte nesouvisející rozhraní API pomocí pracovních prostorů nebo dalších instancí služby API Management. Dopad selhání způsobených chybnou konfigurací nebo výpadky se minimalizuje oddělením rozhraní API napříč různými výpočetními instancemi.
(API) Důkladně otestujte výrazy a logiku zásad a spárujte je s odolnými technikami zpracování chyb v zásadách služby API Management. Prostředí klienta je vylepšené tím, že brání novým zdrojům selhání v bráně a poskytuje řádné snížení výkonu nebo bezpečné zpracování přechodných chyb.
(Služba a rozhraní API) Shromážděte metriky spolehlivosti.

Mezi typické metriky spolehlivosti rozhraní API patří:

- Omezení rychlosti a porušení kvót.
– Míra chyb na základě stavových kódů HTTP.
– Odchylky frekvence požadavků od základní úrovně.
– Kontroly stavu, včetně stavu závislostí.		 Jsou identifikovány odchylky od očekávaného chování a předchozích směrných plánů. Tato data se dají použít ke sledování původních příčin, jako jsou změna chování uživatele, interference z rutinních operací, neočekávaný dopad na nové funkce nebo neplánované chyby v úloze.
(Služba a rozhraní API) Jako součást plánu obnovy po havárii můžete využívat vestavěné funkce zálohování a obnovení v API Management. Doplňte tyto funkce pomocí artefaktů IaC a procesů APIOps pro robustní řešení, které dokáže zvládnout různé scénáře, včetně koordinace obnovení se závislostmi a back-endy. Provozní kontinuita je zajištěna povolením obnovení brány rozhraní API a obnovením definovaných rozhraní API po úplné ztrátě systému.

Zabezpečení

Účelem pilíře zabezpečení je poskytnout záruky důvěrnosti, integrity a dostupnosti úloh.

Principy návrhu zabezpečení poskytují strategii návrhu vysoké úrovně pro dosažení těchto cílů použitím přístupů k technickému návrhu služby API Management.

Note

Kontrolní seznam a doporučení v této části se zaměřují na zabezpečení prostředku brány služby API Management. Zabezpečení samotných rozhraní API se řeší jen krátce. Další informace najdete v tématu Zmírnění zabezpečení rozhraní API OWASP 10 ve službě API Management.

Kontrolní seznam návrhu úloh

Zahajte strategii návrhu na základě kontrolního seznamu pro kontrolu návrhu pro zabezpečení a identifikujte ohrožení zabezpečení a kontrolní mechanismy, které zlepšují stav zabezpečení.

  • Vytvoření standardních hodnot zabezpečení: Zkontrolujte standardní hodnoty zabezpečení pro SLUŽBU API Management a začlente příslušné míry do směrného plánu.

  • Ochrana kanálu nasazení: Identifikujte jednotlivce a role řízení přístupu na základě rolí, které jsou potřeba ke správě platformy služeb, kanálů kontinuální integrace a průběžného nasazování (CI/CD) a jednotlivých rozhraní API. Zajistěte, aby ke správě služby a jeho rozhraní API měli přístup jenom autorizovaní jednotlivci.

  • Vyhodnocení citlivosti dat: Pokud citlivá data procházejí žádostmi rozhraní API a odpověďmi v bráně služby API Management, zajistěte jejich ochranu v průběhu celého životního cyklu. Účet pro různé požadavky na ochranu dat v různých oblastech Vyhodnoťte funkce služeb, jako je několik oblastí , abyste izolovali konkrétní data. Ověřte také, jestli strategie ukládání do mezipaměti odpovídá těmto požadavkům na izolaci.

  • Vývoj strategií segmentace ve sdílených branách: Pokud vaše instance SLUŽBY API Management hostuje rozhraní API pro více týmů úloh, použijte pracovní prostory k oddělení rolí, sítí a případně bran. Tento přístup zajišťuje, že každý tým má odpovídající přístup a kontrolu nad rozhraními API, která spravují, a zároveň omezuje přístup k rozhraním API jiných týmů.

  • Zvažte řízení sítě: Identifikujte požadavky a možnosti izolace nebo filtrování příchozího a odchozího provozu brány pomocí virtuálních sítí. Určete, jestli je možné přístup k bráně omezit prostřednictvím služby Azure Private Link nebo jestli je nutný veřejný přístup k bráně. Vyhodnoťte, jestli má architektura zahrnovat bránu firewall webových aplikací, jako je Azure Web Application Firewall ve službě Azure Application Gateway nebo Azure Front Door, aby se dosáhlo požadované izolace sítě a filtrování síťového provozu.

  • Zvažte možnosti ověřování a autorizace rozhraní API: Vyhodnoťte použití zprostředkovatelů identity, jako je Microsoft Entra ID, které zahrnuje integrované skupiny, nebo Externí ID Microsoft Entra k blokování požadavků brány a povolení autorizace OAuth pro back-endová rozhraní API.

  • Šifrování síťového provozu: Identifikujte nejbezpečnější verze protokolu TLS (Transport Layer Security) a šifry , které můžou vaše úlohy podporovat. Nepožadujte nezabezpečené verze protokolu TLS. Protokol TLS 1.3 použijte v případech, kdy klienti podporují.

  • Modelování hrozeb ve službě API Management a snížení jeho plochy: Určete, jestli se můžou zakázat, omezit nebo odebrat konkrétní komponenty služby API Management, jako je rozhraní API pro přímou správu nebo veřejný přístup k portálu pro vývojáře.

  • Identifikace tajných kódů, které úlohy vyžadují: Operace brány může vyžadovat certifikáty, klíče rozhraní API nebo jiné tajné hodnoty. Projděte si požadavky a možnosti služby Azure Key Vault pro ukládání tajných kódů a certifikátů. Nebo si projděte integrované funkce služby API Management, jako jsou pojmenované hodnoty a spravované certifikáty.

Doporučení pro konfiguraci

Tato doporučení zabezpečení se můžou vztahovat buď na samotnou službu, nebo na provoz, který prochází přes rozhraní API a jejich zásady. Designátory (Služba) nebo (API) označují, jestli doporučení cílí na službu nebo rozhraní API.

Recommendation Benefit
(Služba) Zakažte zastaralé rozhraní API pro přímou správu. Jako řídicí rovinu použijte Azure Resource Manager. Plocha služby se snižuje odebráním přístupového bodu řídicí roviny.
(Služba) Omezte vystavení brány výhradně na základě toho, odkud se připojují legitimní klienti.

– Injektáž virtuální sítě bez veřejné IP adresy použijte, když všichni klienti můžou směrovat provoz přes virtuální síť. Pomocí skupiny zabezpečení sítě (NSG) dále omezte provoz jenom na očekávané IP adresy původu klienta.

– Integrace virtuální sítě se službou Application Gateway nebo Azure Front Door použijte, pokud nějaký provoz musí pocházet z internetu. Nakonfigurujte skupinu zabezpečení sítě tak, aby přijímala provoz pouze z jediného vstupního bodu.		 Důvěrnost síťového provozu je chráněná omezením ohrožení rozsahů zdrojových IP adres, u které se očekává, že budou obsahovat legitimní klienty. Tato omezení blokují přístup ze zdrojů, které by neměly inicializovat legitimní komunikaci klientů. Omezení vystavení legitimním zdrojům provozu zvyšuje důvěrnost, integritu a dostupnost služby.
(Služba) Pokud se nepoužívá, zakažte vývojářský portál . Pokud se portál používá, zakažte prostředí registrace, zakažte anonymní přístup a omezte přístup jenom na důvěryhodná síťová umístění. Plocha služby a šance na nesprávnou konfiguraci nebo zanedbání se sníží.
(Služba) Explicitně nastavte nejužší podporované verze protokolu TLS, protokoly a šifry pro vaše klienty a back-endy. Verze a podporované šifry jsou omezené pouze na možnosti, které klienti a back-endy podporují. Tento přístup pomáhá zajistit, aby byly upřednostňovány co nejkvalitnější připojení z hlediska důvěrnosti.
(Služba) Ukládejte vlastní certifikáty ve službě Key Vault. Funkce správy certifikátů je poskytována pomocí služby Key Vault, která podporuje pravidelnou rotaci a audituje přístup k certifikátům.
(Služba) Back-endy by měly přijímat pouze provoz z bran rozhraní API a všechny ostatní přenosy by měly blokovat. Škodlivému provozu se zabrání v obejití zabezpečení a dalších problémů s křížovým snižováním zátěže do brány.
(Služba) V případě instancí služby API Management, které hostují rozhraní API pro více týmů nebo segmentovaných úloh, vytvořte robustní strategii izolace řízení přístupu. K dosažení této strategie použijte pracovní prostory nebo implementujte přísný proces APIOps .

Aplikace Teams musí mít přístup pouze k rozhraním API, která vlastní. Neměli by mít přístup k jiným rozhraním API, která by mohla být hostována ve stejné instanci.		 Laterální pohyb útočníků z jedné ohrožené sady rozhraní API do jiných nesouvisejících rozhraní API se sníží.
(API) Ukládejte tajné kódy ve službě Key Vault a zpřístupněte je zásadám prostřednictvím pojmenovaných hodnot. Nepoužívejte službu Key Vault k ukládání nezabezpečených objektů. Pro tyto hodnoty použijte přímo vlastnosti pojmenované hodnoty. Doporučuje se rotace tajných kódů prostřednictvím jedné platformy správy ve službě Key Vault, podobně jako u přístupu používaného pro certifikáty. Tento proces zajišťuje, aby služba API Management byla odpovídajícím způsobem aktualizována. Pojmenované hodnoty také zajišťují konzistentní zkušenost při konfiguraci zásad jak pro tajné, tak i neutajené informace. Veškerý přístup k tajným kódům je také auditován ve službě Key Vault, aby poskytoval historii přístupu. Ukládání tajných kódů ve službě Key Vault minimalizuje závislost na službě Key Vault a nemění službu Key Vault na službu konfigurace aplikace.
(API) Použijte různé spravované identity přiřazené uživatelem pro různá rozhraní API pomocí zásad identity spravované ověřováním . Každé rozhraní API má povolenou nezávislou identitu, která podporuje cíle segmentace prostřednictvím přístupu s nejnižšími oprávněními pro každé rozhraní API. Poskytuje také lepší auditovatelnost v back-endových systémech.
(API) Pokud je to možné, vyžadovat, aby se klienti ověřili pomocí toků OAuth 2.0 místo použití předsdílených klíčů, včetně klíčů předplatného nebo klientských certifikátů. Je vylepšena identifikace klientů pro účely auditování, obměna klíčů je eliminována a zatížení klientů za účelem ochrany tajných kódů se snižuje v porovnání s používáním předsdílených klíčů.
(API) Potlačte HTTP hlavičky v odpovědích API pomocí zásady set-header, která může odhalit detaily implementace. Náklady na útočníky se zvyšují tím, že zadrží informace o implementaci.
(API) Nepoužívejte trasování rozhraní API v produkčním prostředí. V trasování požadavků se zabrání odhalení citlivých dat.
(API) Použijte Defender pro rozhraní API. K dispozici jsou přehledy zabezpečení rozhraní API, doporučení a detekce hrozeb.
(API) Chránit back-endové prostředky delegováním kontrol klíčového zabezpečení v zásadách API, jako jsou validate-jwt, ip-filter, validate-headers, validate-content. Objem nelegitimatního provozu, který dosahuje back-endových služeb, se sníží provedením kontrol zabezpečení na bráně. Tento přístup pro snižování zátěže pomáhá chránit integritu a dostupnost těchto prostředků.
(API) Aplikujte postupy životního cyklu vývoje zabezpečení (SDL) na změny zásad rozhraní API stejným způsobem, jakým aplikujete navrhované změny kódu aplikace ve vaší úloze. Zásady se spouštějí s vysokým stupněm oprávnění pro přístup k provozu rozhraní API. Je zabráněno obcházení back-endových ochran pro důvěrnost, integritu a dostupnost pomocí brány rozhraní API, která byla kompromitována.
(Služba a rozhraní API) Používejte spravované identity pro závislosti služeb a rozhraní API. Připojení ke službě Key Vault, Azure Event Hubs a dalším závislostem, jako jsou certifikáty a pojmenované hodnoty, se navazují, aniž by se museli spoléhat na předem sdílené tajné kódy.
Pokud je to možné, připojte se ke závislostem, jako je Key Vault, Event Hubs a back-endy, prostřednictvím soukromých síťových připojení. Důvěrnost provozu je chráněna tím, že neukračuje provoz mimo privátní síť.
(Služba & API) Klientský provoz, který cílí na rozhraní API vystavená na internetu, by měl nejprve projít Web Application Firewall, než dosáhne API Management. Veřejné koncové body také můžete chránit pomocí služby Azure DDoS Protection. Objem nelegitimatního provozu, který dosahuje brány a back-endových služeb, se snižuje provedením kontrol zabezpečení pomocí firewallu webových aplikací. Snížení tohoto provozu pomáhá chránit integritu a dostupnost těchto prostředků.
(Služba a rozhraní API) Vyhodnoťte a povolte všechny kontroly dodržování právních předpisů azure Policy , které jsou pro vaši úlohu relevantní. Instance API Managementu odpovídá požadovanému stavu a zůstává sladěna, jak se zátěž vyvíjí, díky zavedeným zásadám zabezpečení.

Optimalizace nákladů

Optimalizace nákladů se zaměřuje na odhalování vzorců výdajů, upřednostnění investic do klíčových oblastí a optimalizaci jiných oblastí pro splnění rozpočtu organizace a zároveň obchodních požadavků.

Principy návrhu optimalizace nákladů poskytují strategii návrhu vysoké úrovně pro dosažení těchto cílů a dosažení kompromisů v technickém návrhu souvisejícím se službou API Management a jeho prostředím.

Kontrolní seznam návrhu úloh

Zahajte svou strategii návrhu na základě kontrolního seznamu přezkumu návrhu pro optimalizaci nákladů pro investice. Dolaďte návrh tak, aby úloha odpovídala rozpočtu přidělenému pro danou úlohu. Váš návrh by měl využívat správné možnosti Azure, monitorovat investice a hledat příležitosti k optimalizaci v průběhu času.

  • Zvažte model nákladů služby API Management: Využijte cenovou kalkulačku Azure s výhodami a kritérii účtu vaší organizace pro smlouvu SLA a škálovatelnost, abyste mohli vyvíjet přesné odhady nákladů na používání úrovně služby API Management. Určete, jestli je model pro vrácení poplatků nezbytný, a zjistěte, jak ho vypočítat na základě metrik, značek a tokenů.

    Model nákladů na služby má vliv hlavně na úroveň služby, počet jednotek a počet bran. Vyhodnoťte dodatečné náklady spojené s udržováním rezervní jednotky nebo implementací konfigurace DR aktivní-pasivní.

    Pokud implementujete pracovní prostory, vyhodnoťte náklady na použití samostatných a sdílených bran pracovních prostorů, abyste vyřešili jedinečné požadavky na tok rozhraní API různých týmů rozhraní API nebo zúčastněných stran.

  • Odhad nákladů na škálování: Vytvořte kritéria škálování, abyste zachovali vysoké využití prostředků brány. Vyhodnoťte základní náklady v předprodukčním prostředí a proveďte testování k modelování nákladů na škálování podle očekávaného zatížení provozu.

    Navrhněte strategii zmírnění rizik, abyste zabránili zneužití bran, což může způsobit nákladné škálování nad rámec předpokládaného využití.

  • Vyhodnocení konfigurací a zásad služby: Funkce, jako je omezení rychlosti a souběžnost limitu , se dají použít jako techniky optimalizace nákladů ke správě zatížení požadavků.

  • Optimalizace umístění logiky: Vyhodnoťte, jestli jsou back-endové servery nákladově efektivnější pro logiku zpracování nebo jestli by brána měla zpracovávat využití prostředků. Brána je silnou komponentou pro implementaci průřezových požadavků, ale v určitých scénářích může provádět příliš mnoho funkcí. Identifikujte úlohy zpracování požadavků náročné na prostředky, které brána provádí, a určete, jestli přesun této logiky na back-endové servery může snížit náklady.

Doporučení pro konfiguraci

Tato doporučení optimalizace nákladů se vztahují buď na samotnou službu, nebo na provoz, který prochází přes rozhraní API a jejich zásady. Designátory (Služba) nebo (API) označují, jestli doporučení cílí na službu nebo rozhraní API.

Recommendation Benefit
(Služba) Použijte nejlevnější úroveň , která podporuje požadavky vašich úloh. Pokud například vaše úloha nebude těžit z přidané funkce způsobem, který by odůvodňuje návratnost investic (ROI), zvolte místo úrovně Premium úroveň Standard. Vyhnout se nákupu nevyužitých nebo nedostatečně využívaných funkcí.
(Služba) Používejte neprodukční úrovně nebo přechodnou infrastrukturu v nižších prostředích, jako jsou vývojová prostředí, nasazení testování konceptu a aktivity modelování počátečních nákladů. Náklady na prostředky se ukládají pro prostředí, která mohou zůstat užitečná, aniž by bylo nutné plně replikovat přesnou konfiguraci nebo požadavky na dostupnost, které mají produkční prostředí.
(Služba) Škálování při poklesu poptávky Nakonfigurujte pravidla automatického škálování nebo jiné automatizované procesy tak, aby se snížily jednotky, když kapacita brány klesne pod definované prahové hodnoty. Nepotřebné náklady se snižují přizpůsobením kapacity poptávce.
(Služba) Spočítejte případné výhody federovaného modelu pro správu rozhraní API pomocí pracovních prostorů pro obsluhu rozhraní API a zároveň zajištění izolace týmu. Plocha pro nasazení a správu je omezená. Cílem tohoto přístupu je dosáhnout úspor z rozsahu prostřednictvím optimalizace času a zdrojů.
(Služba) Pokud už pracovní prostory nepoužíváte, vyřazujete z provozu pracovní prostory . Vyhnete se útratě za nevyužité prostředky.
(Služba) Integrovanou mezipaměť použijte, pokud se data uložená v mezipaměti vaší úlohy vejdou do omezení předdefinované mezipaměti ve vaší vrstvě. Náklady spojené s nákupem a údržbou externí mezipaměti kompatibilní s Redis se vyhnete.
(Služba) Zablokujte škodlivý provoz před tím, než se dostanete k bráně pomocí síťových ovládacích prvků, ochrany před útoky DDoS a bran firewall webových aplikací. Za konkrétní úrovně služby API Management se účtují poplatky na základě počtu operací požadavků HTTP, které brána zpracovává. V důsledku toho může nežádoucí provoz, jako jsou požadavky generované robotem, zvýšit náklady.

Vyhodnoťte náklady na mechanismus blokování a odhadované náklady na snížení počtu operací HTTP a vyhodnoťte, jestli má tento přístup návratnosti prostředků.		 Poplatky vzniklé z důvodu nadměrného škodlivého nebo obtěžujícího provozu HTTP proti bráně se sníží.
(API) Optimalizujte výrazy zásad a zpracování a kód, abyste se vyhnuli nadměrnému využití výpočetních prostředků, jako jsou procesor, sítě nebo paměť. Nepotřebné nasazení dalších jednotek pro zajištění kapacity pro neoptimalizované implementace zásad a kódu se vyhne.
(API) Vyhodnoťte náklady na umístění logiky mezi bránou, back-endem nebo veřejným vstupním bodem, jako je Azure Front Door. Stejné zpracování může často probíhat v kterékoli z těchto vrstev, z nichž každá má své vlastní kompromisy. Některé vrstvy ale můžou přinést úsporu nákladů kvůli nevyužité kapacitě dostupné na této úrovni. Například logika ukládání do mezipaměti původně implementovaná v back-endu může být nákladově efektivnější implementovaná na úrovni brány pomocí integrované mezipaměti. Tento přístup snižuje režijní náklady na síť a výpočetní prostředky na back-endové služby. Zatížení vysoce nákladových prostředků je minimalizované umístěním funkcí do nákladově nejefektivnější vrstvy. Tento přístup přesouvá úlohy do vrstev, které mají volnou kapacitu nebo možnosti výpočetních prostředků s nižšími náklady.

Efektivita provozu

Operační dokonalost se primárně zaměřuje na vývojové postupy, pozorovatelnost a správu verzí.

Principy návrhu efektivity provozu poskytují strategii návrhu vysoké úrovně pro dosažení těchto cílů pro provozní požadavky úlohy.

Kontrolní seznam návrhu úloh

Zahajte strategii návrhu založenou na kontrolním seznamu kontroly návrhu pro efektivitu provozu pro definování procesů pozorovatelnosti, testování a nasazení souvisejících se službou API Management.

  • Projděte si klíčové znalosti a dovednosti potřebné k provozování služby: Oblasti zahrnují životní cyklus rozhraní API, procesy DevOps, sítě a připojení, monitorování a pozorovatelnost a vývoj softwaru. Tento přístup zahrnuje konfiguraci zásad, testování částí a vytváření kanálů CI/CD.

  • Zvažte potřeby dokumentace: Potvrďte dokumentaci procesů pro konfiguraci na úrovni služeb a rozhraní API, operace životního cyklu a různé vzory přístupu pro týmy rozhraní API.

  • Vyhodnoťte standardní nástroje pro podporu operací služeb. K publikování rozhraní API a správě konfigurací rozhraní API můžete například použít metody APIOps , jako je GitOps a CI/CD. Nástroje IaC slouží ke změnám konfigurace na úrovni služeb. Navrhujte opakovaně použitelné artefakty, které můžou bezproblémově přecházet z vývojových prostředí do produkčního prostředí. Zvažte integraci linteru, jako je Spectral, buď samostatně spravovaný, nebo integrovaný do služby Azure, jako je Azure API Center, do kanálů schválení rozhraní API.

  • Určení klíčových provozních metrik a protokolů: Zkontrolujte metriky pro produkční prostředí. Mezi tyto metriky patří kapacita brány, využití procesoru, využití paměti a počet požadavků. Projděte si protokoly a nástroje pozorovatelnosti, jako je Azure Monitor a Application Insights. Určete strategie a nástroje potřebné k efektivní správě velkých objemů observačních dat v produkčních prostředích. Určete dotazy, které poskytují užitečné přehledy pro operátora brány i zúčastněné strany, které monitorují konkrétní hostovaná rozhraní API.

  • Naplánujte pravidelné testování produkčních úloh pomocí zátěžového testování.

  • Identifikujte provozní úlohy nad rámec procesů CI/CD nebo IaC , které vyžadují automatizaci. Plánování automatizace v oblastech, jako je správa zdrojů zásad služby API Management, zásady Azure a konkrétní konfigurace portálu pro vývojáře

Doporučení pro konfiguraci

Tato doporučení efektivity provozu se můžou vztahovat buď na samotnou službu, nebo na provoz, který prochází přes rozhraní API a jejich zásady. Designátory (Služba) nebo (API) označují, jestli doporučení cílí na službu nebo rozhraní API.

Recommendation Benefit
(Služba) Nakonfigurujte protokoly prostředků diagnostiky Azure pro API Management. Protokoly generované platformou jsou k dispozici pro dotazování na rutinní operace, potřeby na vyžádání nebo naléhavé scénáře, jako jsou audity zabezpečení.
(Služba) Azure Event Grid můžete použít k automatizaci na základě smysluplných událostí, které vaše instance SLUŽBY API Management vyvolává, například APICreated. Úlohy automatizace nebo oznámení se dají sestavit podle klíčových událostí životního cyklu, ke kterým dochází v instanci služby API Management.
(Služba) Nepoužívejte samostatně hostovanou bránu, pokud ve vašem scénáři funguje jednotka brány hostované Microsoftem. Úlohy automatizace nebo oznámení se dají sestavit podle klíčových událostí životního cyklu, ke kterým dochází v instanci služby API Management.
(Služba) Použijte všechny předdefinované zásady Azure Policy , které vám pomůžou řídit instanci a omezit ji tak, aby odpovídala požadavkům na úlohy, včetně požadavků na zabezpečení. Pomocí zásad odepření můžete například zabránit zpřístupnění rozhraní API přes protokol HTTP nebo k zabránění povolení rozhraní REST API pro přímou správu. Pokud zásady auditu nejsou k dispozici, použijte zásady auditu nebo vytvořte vlastní zásady zamítnutí, pokud je pro vaši úlohu důležité. Vaše instance služby API Management odpovídá návrhu a zůstává v souladu s vývojem úloh.
(Služba) Seznamte se s funkcí Diagnostika a řešení problémů na webu Azure Portal.

K řešení potíží s připojením k síti použijte okno Stav sítě na portálu.		 Pracovníci technického inženýrství pro spolehlivost lokality můžou identifikovat a řešit potíže s výkonem brány, dostupností služeb a připojením k síti ve všech prostředích.
(API) Služba Event Hubs slouží ke zpracování protokolů nebo datových proudů událostí z volání rozhraní API, které vyžadují reakce téměř v reálném čase nebo operace s krátkým časovým rámcem. K dispozici je téměř dostupnost položek protokolu v reálném čase. Zpoždění příjmu dat protokolu, ke kterému dochází při protokolování do služby Azure Monitor v rozhraních API, se vyhne.
(API) Podpora využití trasování rozhraní API ve vývoji, která vývojářům pomáhá pochopit implementaci politiky. Produktivita vývojářů je optimalizovaná tím, že poskytuje přehled o implementaci zásad v rámci rozhraní API. Bez této schopnosti musí vývojáři zavést hacky v implementaci zásad, aby získali přehled.
(API) Vždy definujte back-endy pomocí funkce back-endů služby API Management. Odkazujte na tyto backendy podle ID v politice pomocí set-backend-service. Back-endy s vyvážením zátěže by se měly definovat jako fond back-endů. Změny připojení na back-end se vztahují na všechna rozhraní API, která používají back-end, aniž by bylo nutné aktualizovat kódy jednotlivých zásad. Riziko chybných konfigurací nebo přehlédnutí změn zásad rozhraní API je sníženo a scénáře, kde více API sdílí stejný backend, jsou řešeny pomocí této vrstvy abstrakce konfigurace.
(API) Navrhněte přístup správy verzí vašich rozhraní API tak, aby odpovídal funkcím správy verzí a revizí služby API Management. Zohledněte tento přístup při operacích nasazení rozhraní API. Strategie správy verzí rozhraní API podporovaná službou API Management se používá k využití integrovaných funkcí místo vytváření vlastních řešení.
(Služba a rozhraní API) Definujte konzistentní a udržitelný provozní proces pro přidávání, úpravy a odstraňování rozhraní API. Určete, jestli chcete toto prostředí spravovat ručně prostřednictvím portálu, nebo ho implementovat prostřednictvím procesu APIOps. Místo přístupu založeného na portálu raději použijte přístup založený na IaC.

Reprezentace služby API Management v rozhraní API Resource Manageru se skládá z mnoha podřízených prostředků, takže je důležité přijmout vícevrstvý přístup pro správu této kolekce prostředků založenou na IaC.		 Specifikace rozhraní API a jejich implementace brány jsou integrované do procesů řízení změn úloh. Tento přístup brání zpracování změn back-endových rozhraní API odlišně od toho, jak jsou vystaveny klientům rozhraní API prostřednictvím brány.

Efektivita výkonu

Výkonnostní efektivita se týká zachování uživatelského zážitku i při rostoucím zatížení řízením kapacity. Strategie zahrnuje škálování prostředků, identifikaci a optimalizaci potenciálních kritických bodů a optimalizaci výkonu ve špičce.

Návrhové principy efektivity výkonu poskytují strategii návrhu na vysoké úrovni pro dosažení cílů kapacity s ohledem na očekávané využití.

Kontrolní seznam návrhu úloh

Zahajte strategii návrhu na základě kontrolního seznamu pro kontrolu efektivity výkonu. Definujte směrný plán založený na klíčových ukazatelích výkonu služby API Management.

  • Definování cílů výkonu: Mezi klíčové metriky pro vyhodnocení výkonu brány služby API Management patří metriky kapacity, jako jsou procento využití procesoru a paměti pro infrastrukturu brány, dobu trvání požadavků a propustnost požadavků. V nasazeních ve více oblastech definujte cíle výkonu pro každou oblast. Zákazník musí definovat odpovídající prahové hodnoty škálování na základě vzorů provozu, úloh rozhraní API a časů škálování.

  • Shromažďování dat o výkonu: Projděte si možnosti integrovaných analýz, metrik Azure Monitoru, protokolů Služby Azure Monitor, Application Insights a Event Hubs za účelem shromažďování a analýzy výkonu na různých úrovních členitosti.

  • Přečtěte si, jak identifikovat problémy s výkonem za provozu: Mezi indikátory problémů s výkonem za provozu patří dostupnost služby Azure, chyby odezvy HTTP a chyby vyvolané v části Diagnostika a řešení problémů na portálu. Při řešení potíží s výkonem a dostupností využijte Application Insights, dotazy Kusto a doporučení z diagnostiky služby API Management na webu Azure Portal.

  • Výkon testu: Otestujte výkon za produkčních podmínek pomocí zátěžového testování.

  • Vyhodnoťte sousední služby, které by mohly zlepšit výkon: Zásady ukládání do mezipaměti nebo externí mezipaměť můžou zlepšit výkon konkrétních operací rozhraní API. Azure Front Door a také Azure Application Gateway jsou běžné volby pro odlehčení zpracování TLS.

  • Projděte si zdokumentované limity a omezení:SLUŽBA API Management má omezení a omezení. Projděte si zdokumentovaná omezení a porovnejte je s požadavky vaší úlohy, abyste zjistili, jestli potřebujete navrhnout řešení, které těmto omezením zabrání.

Doporučení pro konfiguraci

Tato doporučení týkající se efektivity výkonu se můžou vztahovat buď na samotnou službu, nebo na provoz, který prochází přes rozhraní API a jejich zásady. Designátory (Služba) nebo (API) označují, jestli doporučení cílí na službu nebo rozhraní API.

Recommendation Benefit
(Služba) Dynamicky se škáluje tak, aby odpovídala poptávce. Nakonfigurujte pravidla automatického škálování nebo jiné automatizované procesy tak, aby upravovaly jednotky brány tak, aby odpovídaly cílové kapacitě využití. Elasticita se dosahuje na základě souběžného využití, což brání vyčerpání prostředků aktuálně nasazených jednotek nebo nadměrného přidělení kapacity.
(API) Minimalizujte nákladné úlohy zpracování, jako je generování velkých velikostí datové části ve vyrovnávací paměti, pomocí zásad ověření obsahu u velkých subjektů požadavků nebo udržováním velkého počtu aktivních webSocketů. Zatížení jednotek pro škálování je snížené, což jim umožňuje zpracovávat více požadavků souběžně, než je třeba škálovat na více instancí.
(Služba a rozhraní API) Shromážděte metriky výkonu.

Mezi běžné metriky výkonu rozhraní API patří:

– Doba trvání zpracování požadavku pro samotnou bránu a celkovou operaci.
– Metriky využití prostředků bránové jednotky
– Měření propustnosti, jako jsou požadavky za sekundu nebo megabity za sekundu.
- Poměr přístupů do mezipaměti.		 Skutečný výkon se měří podle cílů úlohy.
(Služba a rozhraní API) Definujte procento vzorkování pro Application Insights , které poskytuje dostatečnou viditelnost, aniž by to mělo vliv na výkon. Požadavky na data pozorovatelnosti jsou splněné, aniž by to ovlivnilo celkový výkon.
(Služba a rozhraní API) Vyhodnoťte dopad umístění logiky mezi bránou, back-endem nebo veřejným vstupním bodem, jako je Azure Front Door. Stejné úlohy zpracování mohou často nastat v kterékoli z těchto vrstev s kompromisy a omezeními výkonu při optimalizaci příležitostí pro každou z nich. Pokud úloha, jako je například zásada správy rozhraní API, zavádí příliš velkou latenci, zvažte, jestli se tato úloha může spouštět na jiném místě optimalizovaně. Úlohy, které přidávají latenci do rozhraní API spouštěných na výpočetních prostředcích optimalizovaných tak, aby splňovaly požadavky na úlohy.

Zásady Azure

Azure poskytuje rozsáhlou sadu předdefinovaných zásad souvisejících se službou API Management a jejími závislostmi. Některé z předchozích doporučení je možné auditovat prostřednictvím služby Azure Policy. Můžete například zkontrolovat, jestli:

  • Brána je nakonfigurovaná pro redundanci zón.
  • Pro bránu služby API Management platí správné síťové ovládací prvky, jako je nasazení ve virtuální síti.
  • Koncové body konfigurace služby nejsou veřejně přístupné.
  • Rozhraní REST API pro přímou správu je deaktivované.

Komplexní zásady správného řízení najdete v předdefinovaných definicích služby Azure Policy a dalších zásadách , které by mohly ovlivnit zabezpečení brány služby API Management.

Doporučení azure Advisoru

Azure Advisor je individuální cloudový konzultant, který vám pomůže postupovat podle osvědčených postupů pro optimalizaci nasazení Azure.

Další informace najdete v tématu Azure Advisor.

Tradeoffs

Pokud použijete přístupy v kontrolních seznamech pilířů, budete možná muset zvolit kompromisní řešení. Tady je několik příkladů výhod a nevýhod.

Vysoká dostupnost prostřednictvím redundance a izolace

  • Vysoká dostupnost. Redundance ovlivňuje náklady. Například zřízení alespoň tří jednotek, aby nedocházelo k výpadkům zón, nemusí být pro vaši úlohu finančně proveditelné. Náklady se dále zvyšují díky architektuře s více oblastmi, která vyžaduje alespoň šest jednotek nebo tři jednotky na oblast. Nastavení ve více oblastech také přidává provozní náklady na bezpečnou koordinaci nasazení, spolehlivé škálování a koordinační mechanismy pro převzetí služeb při selhání s backendovými systémy.

  • Isolation. Izolace úloh napříč pracovními prostory nebo instancemi služby API Management zvyšuje provozní složitost, protože zahrnuje správu víceklientských systémů s izolací výpočetních prostředků.

Škálování podle poptávky

  • Když automaticky škálujete kapacitu tak, aby splňovala poptávku od dobře chovaných klientů, jsou tyto náklady už do vašich nákladových modelů zaváděné. Tato schopnost škálování však také umožňuje službě přizpůsobit se tak, aby zvládla provoz z nežádoucího a škodlivého provozu.

  • Zmírnění nežádoucího provozu způsobuje náklady. Přidání služeb, jako je firewall webových aplikací a ochrana před útoky DDoS, zvyšuje výdaje. Škálování služby za účelem zvládnutí provozu zvyšuje náklady z důvodu přidaných jednotek. Nastavení horních limitů škálování může omezit výdaje, ale může vést k problémům se spolehlivostí legitimních uživatelů, pokud vaše rozhraní API zahltí škodlivý provoz.

Federovaný a distribuovaný přístup

Základním rozhodnutím ve službě API Management je, jestli chcete společně přidělit různorodé úlohy v rámci jedné instance služby API Management nebo izolovat úlohy napříč několika instancemi v plně autonomní topologii.

Pracovní prostory služby API Management umožňují efektivní provoz jako multiklientské kolokační platformy pro více týmů rozhraní API. Vrstvené cenové modely jsou navržené tak, aby umožňovaly sdílení nákladů na služby napříč všemi tenanty, kteří používají brány. Stejně jako jakákoli platforma pro kolokaci, výpadky nebo chybné konfigurace můžou mít za následek rozsáhlé účinky na nesouvisející úlohy, které sdílejí stejnou infrastrukturu.

Plně distribuovaný model, kde každý tým úloh spravuje vlastní instance, zavádí duplicitní náklady a redundanci v rutinních operacích. Poskytuje však základní zmírnění poloměru výbuchu pro incidenty související se spolehlivostí, zabezpečením a výkonem.

Příklad architektury

Základní architektura, která demonstruje klíčová doporučení: Architektura cílové zóny služby API Management

Další kroky

API Management se často kombinuje s následujícími službami. Pokud vaše úloha tyto služby zahrnuje, nezapomeňte si projít jejich příručky ke službám nebo dokumentaci k produktům.

Následující články ukazují některá doporučení probíraná v tomto článku.

  • Last updated on