Použití brány před několika nasazeními nebo instancemi Azure OpenAI

Architektury úloh, které zahrnují službu Azure OpenAI, můžou být stejně jednoduché jako jedna nebo více klientských aplikací, které přímo využívají jedno nasazení modelu Azure OpenAI, ale ne všechny úlohy se dají navrhnout s takovou jednoduchostí. Složitější scénáře zahrnují topologie s více klienty, několik nasazení Azure OpenAI nebo více instancí Azure OpenAI. V takových situacích může být zavedení brány před Azure OpenAI přínosné pro návrh úlohy.

Několik instancí Azure OpenAI nebo nasazení modelů řeší konkrétní požadavky v architektuře úloh. Dají se klasifikovat ve čtyřech klíčových topologiích.

• Několik nasazení modelů v jedné instanci Azure OpenAI
• Několik instancí Azure OpenAI v jedné oblasti a jednom předplatném
• Několik instancí Azure OpenAI v jedné oblasti napříč několika předplatnými
• Několik instancí Azure OpenAI napříč několika oblastmi

Tyto topologie samy o sobě nevyžadují použití brány. Volba brány závisí na tom, jestli úloha využívá její zahrnutí do architektury. Tento článek popisuje výzvy, které řeší každá ze čtyř topologií, a výhody a náklady zahrnutí brány do každé topologie.

Několik nasazení modelů v jedné instanci Azure OpenAI

Podrobnosti topologie pro více nasazení modelů

• Nasazení modelu Azure OpenAI: více
• Instance Azure OpenAI: jedna
• Předplatná: jedno
• Oblasti: jedna

Případy použití topologie pro více nasazení modelu

Topologie, která zahrnuje jednu instanci Azure OpenAI, ale obsahuje více než jeden souběžně nasazený model, podporuje následující případy použití:

• Zpřístupňujte různé možnosti modelu, například gpt-35-turbo, gpt-4a vlastní jemně vyladěné modely.

• Zveřejnění různých verzí modelu, jako 0613je například , 1106a vlastních jemně vyladěných modelů pro podporu vývoje úloh nebo nasazení s modrou zelenou barvou.

• Zveřejnění různých kvót přiřazených (30 000 tokenů za minutu ( TPM), 60 000 TPM) pro podporu omezování spotřeby napříč více klienty

Zavedení brány pro více nasazení modelů

Zavedení brány do této topologie je primárně určené k abstrakci klientů od vlastního výběru konkrétní instance modelu mezi dostupnými nasazeními v instanci. Brána umožňuje řízení na straně serveru směrovat požadavek klienta na konkrétní model, aniž by bylo nutné znovu nasadit klientský kód nebo změnit konfiguraci klienta.

Brána je zvlášť užitečná, když neřídíte kód klienta. Je také výhodné, když nasazení konfigurace klienta je složitější nebo rizikové než nasazení změn v konfiguraci směrování brány. Můžete změnit model, na který klient ukazuje, na základě strategie modrého zeleného zavedení vašich verzí modelu, jako je zavedení nového jemně vyladěného modelu nebo přechod z verze X na X+1 stejného modelu.

Bránu je možné použít také jako jediný vstupní bod rozhraní API, který bráně umožňuje identifikovat klienta. Pak může určit, které nasazení modelu se použije k zobrazení výzvy, na základě identity daného klienta nebo jiných informací v požadavku HTTP. Například u víceklientského řešení můžou být tenanti omezeni na konkrétní propustnost a implementace architektury je nasazení modelu na tenanta s konkrétními kvótami. V tomto případě bude směrování na model tenanta zodpovědností brány na základě informací v požadavku HTTP.

Použití brány v této topologii umožňuje sledování využití na základě klienta. Pokud klienti nepoužívají odlišné instanční objekty Microsoft Entra, nebudou protokoly přístupu pro Azure OpenAI moct rozlišit více klientů. Když máte bránu před nasazením, můžete svou úlohu využít ke sledování využití jednotlivých klientů napříč různými dostupnými nasazeními modelu za účelem podpory vratek nebo modelů showback.

Tipy pro topologii nasazení více modelů

• I když je brána v pozici pro úplnou změnu používaného modelu, například gpt-35-turbo na gpt-4, bude tato změna pravděpodobně považována za zásadní změnu klienta. Nenechte nové funkční funkce brány rozptylovat od toho, aby pro tuto úlohu vždy prováděly postupy bezpečného nasazení.

• Tato topologie je obvykle dostatečně jednoduchá k implementaci prostřednictvím zásad služby Azure API Management místo vlastního řešení kódu.

• Pokud chcete podporovat nativní využití sad SDK s publikovanými specifikacemi rozhraní API Azure OpenAI, udržujte kompatibilitu rozhraní API s rozhraním API Azure OpenAI. Tato situace je větší obavou, když váš tým nevytváření kódu všech vašich klientů úloh. Při rozhodování o návrhu rozhraní HTTP API pro bránu zvažte výhody zachování kompatibility rozhraní HTTP API Azure OpenAI.

• I když tato topologie technicky podporuje předávací přihlašovací údaje klienta (přístupové tokeny nebo klíč rozhraní API) pro instanci Azure OpenAI, důrazně zvažte implementaci ukončení přihlašovacích údajů a opětovného publikování. Tímto způsobem je klient autorizovaný v bráně a pak je brána autorizovaná prostřednictvím Azure RBAC pro instanci Azure OpenAI.

• Pokud je brána navržená tak, aby používala předávací přihlašovací údaje, ujistěte se, že klienti nemůžou bránu obejít ani žádná omezení modelu založená na klientovi.

• Nasaďte bránu ve stejné oblasti jako instance Azure OpenAI.

• Nasaďte bránu do vyhrazené skupiny prostředků v předplatném, které je oddělené od instance Azure OpenAI. Izolování předplatného z back-endů může pomoct řídit přístup APIOps prostřednictvím oddělení zájmu.

• Nasaďte bránu do virtuální sítě, která obsahuje podsíť pro privátní koncový bod Azure Private Link instance Azure OpenAI. U této podsítě použijte pravidla skupiny zabezpečení sítě (NSG), která umožní přístup brány pouze k danému privátnímu koncovému bodu. Všechny ostatní přístupy k instancím Azure OpenAI by měly být zakázány.

Důvody, proč se vyhnout bráně pro více nasazení modelů

Pokud je řízení konfigurace vašich klientů stejně snadné nebo jednodušší než řízení směrování na úrovni brány, přidaná spolehlivost, zabezpečení, náklady, údržba a dopad na výkon brány nemusí být za přidanou architekturu.

Některé scénáře úloh můžou také těžit z migrace z přístupu k nasazení více modelů na více přístupů k nasazení instance Azure OpenAI. Představte si například více instancí Azure OpenAI, pokud máte více klientů, kteří by pro přístup k modelu měli používat různé RBAC nebo přístupové klíče. Použití více nasazení v jedné instanci Azure OpenAI a zpracování segmentace logické identity na úrovni brány je možné, ale může být nadměrné, pokud je k dispozici fyzický přístup k segmentaci RBAC pomocí různých instancí Azure OpenAI.

Několik instancí Azure OpenAI v jedné oblasti a jednom předplatném

Podrobnosti topologie pro více instancí v jedné oblasti a jednom předplatném

• Nasazení modelu Azure OpenAI: jedno nebo více
• Instance Azure OpenAI: více
• Předplatná: jedno
• Oblasti: jedna

Případy použití topologie pro více instancí v jedné oblasti a jednom předplatném

Topologie, která zahrnuje více instancí Azure OpenAI v jedné oblasti a jedno předplatné podporuje následující případy použití:

• Umožňuje hranice segmentace zabezpečení, jako je klíč nebo RBAC na klienta.

• Umožňuje snadný model zpětného účtování pro různé klienty.

• Umožňuje strategii převzetí služeb při selhání pro dostupnost Azure OpenAI, jako je výpadek platformy, který má vliv na konkrétní instanci, chybnou konfiguraci sítě nebo náhodně odstraněné nasazení.

• Umožňuje strategii převzetí služeb při selhání pro dostupnost kvóty Azure OpenAI, jako je párování instance založené na PTU a instance založené na spotřebě pro přelití.

Zavedení brány pro více instancí v jedné oblasti a předplatném

Model nemusí být přístupný pro klienta z několika důvodů. Mezi tyto důvody patří přerušení služby Azure OpenAI, požadavky na omezování Azure OpenAI nebo problémy související s operacemi úloh, jako je chybná konfigurace sítě nebo neúmyslné odstranění nasazení modelu. Pokud chcete tyto výzvy vyřešit, měli byste implementovat logiku opakování a přerušení okruhu.

Tuto logiku je možné implementovat v klientech nebo na straně serveru v bráně. Implementace logiky v bráně abstrahuje logiku od klientů, což vede k žádnému opakovanému kódu a jedinému místu k otestování logiky. Bez ohledu na to, jestli vlastníte kód klienta nebo ne, může tento posun zvýšit spolehlivost úlohy.

Použití brány s několika instancemi Azure OpenAI v jedné oblasti a předplatném umožňuje považovat všechny back-endy za nasazení aktivní-aktivní, a ne jen je používat v převzetí služeb při selhání typu aktivní-pasivní. Stejný model založený na PTU můžete nasadit napříč několika instancemi Azure OpenAI a pomocí brány mezi nimi vyrovnávat zatížení.

Jednou z možností, které tým úloh má při zřizování Azure OpenAI, se rozhoduje, jestli je model fakturace a propustnosti založený na PTU nebo na základě spotřeby. Strategie optimalizace nákladů, která zabrání plýtvání nevyužitým PTU, je mírně pod zřízením instance PTU a zároveň nasadit instanci založenou na spotřebě. Cílem této topologie je, aby klienti nejprve spotřebovali všechny dostupné PTU a pak "propadli" do nasazení založeného na spotřebě pro nadlimitní využití. Tato forma plánovaného převzetí služeb při selhání má stejný důvod, jak je uvedeno v úvodním odstavci této části: zachování této složitosti mimo klientský kód.

Když je brána zapojená, je v jedinečné pozici k zachycení podrobností o všech klientech nasazení modelu, se kterými pracují klienti. I když každá instance Azure OpenAI dokáže zachytit vlastní telemetrii, umožňuje týmu úloh publikovat telemetrická data a chybové odpovědi napříč všemi spotřebovanými modely do jednoho úložiště, což usnadňuje jednotné řídicí panely a upozorňování.

Tipy pro více instancí v jedné oblasti a topologii předplatného

• Při podpoře scénářů převzetí služeb při selhání v bráně se ujistěte, že brána používá Retry-After informace dostupné v odpovědi HTTP z Azure OpenAI. Tyto autoritativní informace slouží k řízení implementace jističe. Nepřesávejte nepřetržitě koncový bod, který vrací 429 Too Many Requestshodnotu . Místo toho přerušte okruh pro danou instanci modelu.

• Pokus o predikci událostí omezování před tím, než k nim dojde, sledováním spotřeby modelu prostřednictvím předchozích požadavků je možné v bráně, ale je zasycený hraničními případy. Ve většiněpřípadůch

• Při kruhovém dotazování nebo převzetí služeb při selhání do jiného koncového bodu, včetně přelití PTU do spotřeby, vždy se ujistěte, že tyto koncové body používají stejný model ve stejné verzi. Například nepředávejte služby při selhání z gpt-4 gpt-35-turbo verze X do verze X+1 nebo vyrovnávání zatížení mezi nimi. Tato změna verze může způsobit neočekávané chování klientů.

• Vyrovnávání zatížení a logika převzetí služeb při selhání se dají implementovat v rámci zásad služby Azure API Management. Možná budete moct poskytnout sofistikovanější přístup pomocí řešení brány založeného na kódu, ale pro tento případ použití je dostatečná služba API Management.

• Nasaďte bránu ve stejné oblasti jako instance Azure OpenAI.

• Nasaďte bránu do vyhrazené skupiny prostředků v předplatném, které je oddělené od instancí Azure OpenAI. Když je brána izolovaná od back-endů, může pomoct řídit přístup APIOps prostřednictvím oddělení zájmu.

• Společné přidělení všech privátních koncových bodů privátního propojení instance Azure OpenAI do jedné podsítě ve virtuální síti brány. Pomocí pravidel NSG na tuto podsíť povolte přístup brány jenom k těmto privátním koncovým bodům. Všechny ostatní přístupy k instancím Azure OpenAI by měly být zakázány.

• Pokud chcete zjednodušit logiku v kódu směrování brány, použijte stejný název nasazení modelu, abyste minimalizovali rozdíl mezi trasami HTTP. Název gpt4-v1 modelu se například dá použít u všech instancí s vyrovnáváním zatížení nebo přeléváním, ať už se jedná o spotřebu nebo ptU.

Důvody, proč se vyhnout bráně pro více instancí v jedné oblasti a předplatném

Samotná brána nezlepší schopnost vratky modelů proti různým klientům pro tuto konkrétní topologii. V této topologii je možné klientům udělit přístup k vlastním vyhrazeným instancím Azure OpenAI, které by podporovaly schopnost týmu úloh provádět vrácení peněz nebo showback. Tento model podporuje jedinečnou identitu a hraniční sítě, takže brána by se nemusela zavádět speciálně pro segmentaci.

Pokud máte v oblasti, kde kód řídíte, několik klientů a klienti jsou snadno aktualizovatelné, logika, kterou byste museli integrovat do brány, by mohla být přidána přímo do kódu. Zvažte použití přístupu brány pro převzetí služeb při selhání nebo vyrovnávání zatížení, a to především v případě, že nevlastníte klientský kód nebo složitost je příliš velká, aby klienti mohli zpracovat.

Několik instancí Azure OpenAI v jedné oblasti napříč několika předplatnými

Podrobnosti topologie pro více instancí Azure OpenAI v jedné oblasti napříč několika předplatnými

• Nasazení modelu Azure OpenAI: jedno nebo více
• Instance Azure OpenAI: více
• Předplatná: více
• Oblasti: jedna

Případy použití topologie pro více instancí Azure OpenAI v jedné oblasti napříč několika předplatnými

Topologie, která zahrnuje více instancí Azure OpenAI v jedné oblasti napříč několika předplatnými, podporuje následující případy použití:

• Zahrnuje všechny případy použití uvedené pro více instancí Azure OpenAI v jedné oblasti a jedno předplatné.

• Umožňuje získat více kvót založených na spotřebě, protože hranice předplatného je dostupným faktorem modelu spotřeby. Tuto dodatečnou kvótu můžete použít k podpoře vysoké souběžné spotřeby.

Zavedení brány pro více instancí v jedné oblasti a několika předplatných

Pro tuto topologii platí stejné důvody, které jsou popsané v části Zavedení brány pro více instancí v jedné oblasti a předplatném .

Kromě těchto důvodů přidání brány do této topologie podporuje také centralizovaný tým poskytující model Azure OpenAI jako služby pro svou organizaci. Vzhledem k tomu, že kvóta založená na spotřebě je vázána na předplatné, centralizovaný tým poskytující služby Azure OpenAI, které používají model založený na spotřebě, musí nasadit instance Azure OpenAI napříč několika předplatnými, aby získal požadovanou kvótu. Logika brány stále zůstává z velké části stejná.

Tipy pro více instancí v jedné oblasti a více topologií předplatných

• V ideálním případě by se předplatná měla zálohovat se stejným tenantem Microsoft Entra, aby podporovala konzistenci v Azure RBAC a Azure Policy.

• Nasaďte bránu ve stejné oblasti jako instance Azure OpenAI.

• Nasaďte bránu do vyhrazeného předplatného, které je oddělené od instancí Azure OpenAI. To pomáhá vynutit konzistenci při řešení instancí Azure OpenAI a poskytuje logické segmentace povinností mezi nasazeními Azure OpenAI a jejich směrováním.

• Při směrování požadavků z brány napříč předplatnými se ujistěte, že jsou dostupné privátní koncové body. Tranzitní směrování prostřednictvím centra můžete použít k privátním koncovým bodům pro back-endy v příslušných paprskech. Možná budete moct zveřejnit privátní koncové body pro služby Azure OpenAI přímo v předplatném brány pomocí připojení Private Link napříč předplatnými. Pokud vaše architektura a organizace tento přístup podporují, preferují se připojení Private Link mezi předplatnými.

Důvody, proč se vyhnout bráně pro více instancí v jedné oblasti a několika předplatných

Všechny důvody, proč se vyhnout bráně pro více instancí v jedné oblasti a předplatném, platí pro tuto topologii.

Několik instancí Azure OpenAI napříč několika oblastmi

Podrobnosti topologie pro více instancí Azure OpenAI napříč několika oblastmi

• Nasazení modelu Azure OpenAI: více
• Instance Azure OpenAI: více
• Předplatná: jedno nebo více
• Oblasti: více

Případy použití topologie pro více instancí Azure OpenAI napříč několika oblastmi

Topologie, která zahrnuje několik instancí Azure OpenAI rozložených do dvou nebo více oblastí Azure, podporuje následující případy použití:

• Zahrnuje všechny případy použití uvedené pro více instancí Azure OpenAI v jedné oblasti napříč několika předplatnými.

• Umožňuje strategii převzetí služeb při selhání pro dostupnost služeb, jako je použití párů mezi oblastmi.

• Umožňuje návrh rezidence dat a dodržování předpisů.

• Umožňuje dostupnost smíšeného modelu. V některých oblastech jsou pro modely k dispozici různé modely a různé kvóty.

I když technicky ne různé oblasti Azure, tato topologie se dá použít také v případě, že máte model AI vystavený v místní situaci, například v místním prostředí nebo v jiném cloudu.

Zavedení brány pro více instancí ve více oblastech

Pro důležité obchodní architektury, které musí přežít úplný regionální výpadek, globální jednotná brána pomáhá eliminovat logiku převzetí služeb při selhání z kódu klienta. Tato implementace vyžaduje, aby brána zůstala nedotčená oblastním výpadkem.

Zatížení napříč oblastmi není typické, ale dá se použít strategicky ke kombinování dostupných kvót v nasazeních založených na spotřebě napříč oblastmi. Tento scénář nevyžaduje, aby brána zůstala nedotčená oblastním výpadkem, ale doporučujeme ji pro maximální spolehlivost úloh.

Použití služby Azure API Management (nasazení v jedné oblasti)

V této topologii se azure API Management používá speciálně pro technologii brány. Tady se služba API Management nasadí do jedné oblasti. Z této instance brány provádíte vyrovnávání zatížení aktivní-aktivní napříč oblastmi. Zásady ve vaší bráně odkazují na všechny instance Azure OpenAI. Brána vyžaduje síťovou čáru dohledu na každý back-end napříč oblastmi, a to buď prostřednictvím partnerského vztahu virtuálních sítí mezi oblastmi, nebo privátních koncových bodů. Volání z této brány do instance Azure OpenAI v jiné oblasti účtují vyšší latenci sítě a poplatky za výchozí přenos dat.

Vaše brána musí dodržovat omezování a signály dostupnosti z instancí Azure OpenAI a odebírat chybné back-endy z fondu, dokud se neochytí chyba nebo omezení instance Azure OpenAI. Brána by měla opakovat aktuální požadavek na jinou back-endovou instanci ve fondu při selhání, než se vrátí k chybě brány. Kontrola stavu brány by měla signalizovat, že není v pořádku, pokud nejsou k dispozici žádné instance Azure OpenAI back-endu.

Vzhledem k tomu, že tato topologie představuje jediný bod selhání (brána), je nástroj této konkrétní architektury poměrně omezený. Tento model se hodí pro fakturaci založenou na spotřebě v Azure OpenAI, když predikuje přidělení PTU, může být příliš náročné.

Varianta aktivní-pasivní

Tento model lze také použít k zajištění přístupu typu aktivní-pasivní, který konkrétně řeší regionální selhání pouze Azure OpenAI. V tomto režimu provoz obvykle proudí z brány do instance Azure OpenAI ve stejné oblasti jako služba API Management. Tato instance Azure OpenAI zpracuje veškerý očekávaný tok provozu bez výskytu regionálních selhání. V závislosti na preferovaném modelu fakturace může být založená na PTU nebo spotřebě. V případě regionálního selhání pouze Azure OpenAI může brána přesměrovat provoz do jiné oblasti s Azure OpenAI, která je už nasazená v režimu spotřeby.

Použití služby Azure API Management (nasazení ve více oblastech)

Aby se zlepšila spolehlivost předchozí architektury založené na službě Azure API Management, služba API Management podporuje nasazení instance do několika oblastí Azure. Tato možnost nasazení poskytuje jednu řídicí rovinu prostřednictvím jedné instance služby API Management, ale poskytuje replikované brány v oblastech podle vašeho výběru. V této topologii nasadíte komponenty brány do každé oblasti obsahující instance Azure OpenAI, které poskytují architekturu brány aktivní-aktivní.

Zásady, jako je směrování a logika zpracování požadavků, se replikují do každé jednotlivé brány. Veškerá logika zásad musí mít v zásadách podmíněnou logiku, abyste zajistili, že voláte instance Azure OpenAI ve stejné oblasti jako aktuální brána. Další informace najdete v tématu Směrování volání rozhraní API do regionálních back-endových služeb. Komponenta brány pak vyžaduje síťovou čáru jen pro instance Azure OpenAI ve své vlastní oblasti, obvykle prostřednictvím privátních koncových bodů.

Služba API Management nabízí kompletní globální plně kvalifikovaný název domény (FQDN) směrování na základě nejnižší latence. Tuto integrovanou funkci založenou na výkonu můžete použít pro nasazení brány typu aktivní-aktivní. Tato integrovaná funkce pomáhá řešit výkon a zpracovávat výpadek místní brány. Integrovaný globální směrovač také podporuje testování zotavení po havárii, protože oblasti je možné simulovat prostřednictvím zakázání jednotlivých bran. Ujistěte se, že klienti respektují dobu provozu (TTL) v plně kvalifikovaném názvu domény a mají odpovídající logiku opakování pro zpracování nedávného převzetí služeb při selhání DNS.

Pokud potřebujete do této architektury zavést firewall webových aplikací, můžete stále použít integrované řešení směrování plně kvalifikovaného názvu domény jako back-endový zdroj globálního směrovače, který implementuje firewall webových aplikací. Globální směrovač by delegoval odpovědnost za převzetí služeb při selhání do služby API Management. Případně můžete jako členy back-endového fondu použít plně kvalifikované názvy domén místní brány. V této druhé architektuře použijte integrovaný /status-0123456789abcdef koncový bod pro každou místní bránu nebo jiný vlastní koncový bod rozhraní API stavu pro podporu regionálního převzetí služeb při selhání. Pokud si nejste jistí, začněte s přístupem jednoho back-endového back-endu back-endu.

Tato architektura funguje nejlépe, pokud můžete považovat oblasti za plně dostupné nebo plně nedostupné. To znamená, že pokud není dostupná brána služby API Management nebo instance Azure OpenAI, chcete, aby se klientský provoz už nepřesměroval do brány služby API Management v této oblasti. Pokud není provedeno jiné zřizování, pokud regionální brána stále přijímá provoz, zatímco Azure OpenAI není k dispozici, musí se chyba rozšířit do klienta. Pokud se chcete vyhnout chybě klienta, podívejte se na vylepšený přístup v bráně Active-Active a variantě Azure OpenAI typu active-pasivní.

Pokud u určité oblasti dochází k výpadku brány služby API Management nebo je označená jako poškozená, zbývající dostupné oblasti musí absorbovat 100 % provozu z těchto ostatních oblastí. To znamená, že potřebujete zřizovat instance Azure OpenAI založené na PTU, abyste mohli zpracovat nový nárůst provozu nebo použít přístup typu aktivní-pasivní pro převzetí služeb při selhání. K plánování kapacity použijte kalkulačku kapacity Azure OpenAI.

Ujistěte se, že skupina prostředků, která obsahuje Azure API Management, je stejné umístění jako samotná instance služby API Management, aby se snížil poloměr výbuchu souvisejícího oblastního výpadku, který ovlivňuje vaši schopnost přistupovat k poskytovateli prostředků pro vaše brány.

Brána active-active plus varianta Active-passive Azure OpenAI

Předchozí část se zabývá dostupností brány tím, že poskytuje topologii brány aktivní-aktivní. Tato topologie kombinuje bránu aktivní-aktivní s nákladově efektivní topologií Azure OpenAI typu aktivní-pasivní. Přidání logiky aktivní-pasivní do brány pro převzetí služeb při selhání do nasazení Azure OpenAI založeného na spotřebě z nasazení založeného na PTU může výrazně zvýšit spolehlivost úlohy. Tento model stále umožňuje klientům používat integrované řešení směrování plně kvalifikovaného názvu domény api pro směrování na základě výkonu.

Použití vlastní kódované brány

Pokud jsou pravidla směrování pro jednotlivé brány příliš složitá, aby váš tým zvážil rozumný přístup jako zásady služby API Management, musíte nasadit a spravovat vlastní řešení. Tato architektura musí být nasazení brány ve více oblastech s jednou vysoce dostupnou jednotkou škálování na každou oblast. Tato nasazení je potřeba předvést pomocí služby Azure Front Door (Anycast) nebo Azure Traffic Manageru (DNS), obvykle pomocí směrování na základě latence a odpovídajících kontrol stavu dostupnosti brány.

Azure Front Door použijte, pokud potřebujete bránu firewall webových aplikací a veřejný přístup k internetu. Traffic Manager použijte, pokud nepotřebujete bránu firewall webových aplikací a hodnota TTL DNS je dostatečná. Při frontingu instancí brány pomocí služby Azure Front Door (nebo jakéhokoli reverzního proxy serveru) se ujistěte, že bránu nejde obejít. Zpřístupnění instancí brány pouze prostřednictvím privátního koncového bodu při použití služby Azure Front Door a přidání ověření X_AZURE_FDID hlavičky HTTP v implementaci brány.

Prostředky pro jednotlivé oblasti, které se používají ve vlastní bráně, umístěte do skupin prostředků pro jednotlivé oblasti. Tím se sníží poloměr výbuchu souvisejícího regionálního výpadku, který ovlivňuje vaši schopnost získat přístup k poskytovateli prostředků pro prostředky brány v této oblasti.

Můžete také zvážit předvádět implementaci logiky brány pomocí služby API Management, a to pro další výhody služby API Management, jako je TLS, ověřování, kontrola stavu nebo vyrovnávání zatížení s kruhovým dotazováním. Tím se změní běžné obavy rozhraní API z vlastního kódu ve vaší bráně a umožní vaší bráně konkrétně řešit instanci Azure OpenAI a směrování nasazení modelu.

V případě dodržování předpisů pro rezidenci dat se ujistěte, že každá geopolitické hranice má své vlastní izolované nasazení této architektury a že klienti můžou dosáhnout pouze svého autorizovaného koncového bodu.

Důvody, proč se vyhnout bráně pro více instancí ve více oblastech

Pokud se vyžaduje rezidence dat a dodržování předpisů, neimplementujte jednotnou bránu napříč geopolitickými oblastmi. Tím dojde k porušení požadavků na rezidenci dat. Používejte jednotlivě adresovatelné brány pro každou oblast a postupujte podle pokynů v jedné z předchozích částí.

Pokud se u klientů neočekává převzetí služeb při selhání mezi oblastmi a máte možnost poskytnout klientům konkrétní bránu, použijte místo toho více bran, jednu pro každou oblast a postupujte podle pokynů v jedné z předchozích částí. Nevážete dostupnost jiných oblastí s oblastí obsahující bránu jako jediný bod selhání.

Neimplementujte jednotnou bránu, pokud váš model a verze nejsou dostupné ve všech oblastech vystavených bránou. Klienti je potřeba směrovat na stejný model a stejnou verzi modelu. U bran s vyrovnáváním zatížení a převzetím služeb při selhání ve více oblastech je potřeba vybrat společnou verzi modelu a modelu, která je dostupná ve všech zahrnutých oblastech. Další informace najdete v tématu Dostupnost modelu. Pokud nemůžete standardizovat model a verzi modelu, je výhoda brány omezená.

Obecná doporučení

Bez ohledu na to, jakou topologii vaše úlohy potřebuje, existuje několik doporučení, která byste při sestavování řešení brány měli zvážit.

Stavové interakce

Pokud klienti používají stavové funkce Azure OpenAI, jako je rozhraní API asistentů, musíte bránu nakonfigurovat tak, aby během této interakce připnula klienta na konkrétní back-end. Toho lze dosáhnout uložením dat instance do souboru cookie. V těchto scénářích zvažte vrácení odpovědi rozhraní API Azure OpenAI, jako je 429 připnutý klient, místo abyste je přesměrovali na jinou instanci Azure OpenAI. Tím umožníte klientovi explicitně zpracovat náhlou nedostupnost a skrýt ji a směrovat ji do instance modelu, která nemá žádnou historii.

Kontroly stavu brány

Existují dvě perspektivy kontroly stavu, které je potřeba vzít v úvahu bez ohledu na topologii.

Pokud je vaše brána postavená na kruhovém dotazování nebo výhradně provádí převzetí služeb při selhání dostupnosti, chcete využít instanci Azure OpenAI (nebo model) ze stavu dostupnosti. Azure OpenAI neposkytuje žádný druh koncového bodu kontroly stavu, aby předem věděl, jestli je k dispozici pro zpracování požadavků. Můžete odesílat syntetické přechody, ale to spotřebovává kapacitu modelu. Pokud nemáte jiný spolehlivý zdroj signálu pro instanci Azure OpenAI a dostupnost modelu, brána by pravděpodobně měla předpokládat, že instance Azure OpenAI je vzhůru a pak zpracovává 429500503 stavové kódy HTTP jako signál pro přerušení okruhu pro budoucí požadavky na instanci nebo model nějakou dobu. V případě situací omezování vždy respektujte data v Retry-After hlavičce nalezená v odpovědích rozhraní API Azure OpenAI pro 429 kódy odpovědí v logice způsobující chyby okruhu. Pokud používáte Azure API Management, vyhodnoťte použití integrované funkce jističe .

Vaši klienti nebo provozní tým úloh můžou chtít mít ve vaší bráně kontrolu stavu pro vlastní účely směrování nebo introspekce. Pokud používáte službu API Management, nemusí být výchozí /status-0123456789abcdef dostatečně podrobná, protože většinou řeší instanci brány služby API Management, ne vaše back-endy. Zvažte přidání vyhrazeného rozhraní API pro kontrolu stavu, které může klientům nebo systémům pozorovatelnosti vracet smysluplná data o dostupnosti brány nebo konkrétních trasách v bráně.

Postupy bezpečného nasazení

Implementace brány můžete použít k orchestraci blue-green nasazení aktualizovaných modelů. Modely Azure OpenAI se aktualizují o nové verze modelů a nové modely a můžete mít nové jemně vyladěné modely.

Po otestování účinků změny v předprodukčním prostředí vyhodnoťte, jestli mají být produkční klienti "oříznuti" na novou verzi modelu, nebo místo toho přesun provozu. Model brány popsaný výše umožňuje back-endu mít oba modely souběžně nasazené. Souběžné nasazování modelů dává bráně sílu přesměrovat provoz na základě postupu bezpečného nasazení týmu úloh při postupném zavedení.

I když nepoužíváte nasazení s modrou zelenou barvou, je potřeba definovat a dostatečně automatizovat přístup APIOps vaší úlohy s rychlostí změny back-endové instance a nasazení modelu.

Stačí dostatek implementace.

Mnoho scénářů zavedených v tomto článku pomáhá zvýšit potenciální cíl na úrovni služby (SLO) vaší úlohy snížením složitosti klienta a implementací spolehlivých technik samoobslužné zachování. Ostatní vylepšují zabezpečení úlohy přesunutím řízení přístupu do konkrétních modelů mimo Azure OpenAI. Ujistěte se, že zavedení brány nekončí funkčním čítačem těchto cílů. Seznamte se s riziky přidání nového jediného bodu selhání prostřednictvím chyb služeb nebo problémů s konfigurací způsobených člověkem v bráně, komplexní logiky směrování nebo rizikům vystavení více modelů neautorizovaným klientům, než je zamýšleno.

Suverenita dat

Různé přístupy aktivní-aktivní a aktivní-pasivní je potřeba vyhodnotit z hlediska dodržování předpisů pro rezidenci dat pro vaši úlohu. Mnoho z těchto vzorů by bylo možné použít pro architekturu vaší úlohy, pokud příslušné oblasti zůstanou v geopolitické hranici. Pokud chcete tento scénář podporovat, musíte zacházet s geopolitickými hranicemi jako s izolovanými razítky a používat zpracování aktivní-aktivní nebo aktivní-pasivní výhradně v rámci tohoto razítka.

Zejména je potřeba pečlivě prověřovat dodržování předpisů v oblasti suverenity dat. Ve scénářích suverenity dat nemůžete obsluhovat klienty s jinou geografickou oblastí a zůstat v souladu s předpisy. Všechny architektury brány, které zahrnují rezidenci dat, musí vynutit, aby klienti používali pouze koncové body v geopolitické oblasti. Klienti musí být zablokovaní v používání jiných koncových bodů brány a samotná brána neporušuje vztah důvěryhodnosti klienta tím, že provede křížově geopolitický požadavek. Nejspolehlivějším způsobem implementace této segmentace je vytvořit architekturu na plně nezávislé a vysoce dostupné bráně na geopolitickou oblast.

Autorizace Azure OpenAI

Brána se musí ověřit pomocí všech instancí Azure OpenAI, se kterými spolupracuje. Pokud jste bránu nenavrhli k předávacímu ověřování, měla by brána pro své přihlašovací údaje používat spravovanou identitu. Každá instance Azure OpenAI proto musí nakonfigurovat nejméně privilegované řízení přístupu na základě role pro spravované identity bran. V případě architektur aktivní-aktivní a převzetí služeb při selhání se ujistěte, že identita brány má ekvivalentní oprávnění pro všechny příslušné instance Azure OpenAI.

Azure Policy

Konzistence mezi nasazeními modelů a instancemi Azure OpenAI je důležitá v situacích aktivní-aktivní nebo aktivní-pasivní. Azure Policy vám pomůže vynutit konzistenci mezi různými instancemi Azure OpenAI nebo nasazeními modelů. Pokud předdefinované zásady pro Azure OpenAI nestačí k zajištění konzistence mezi nimi, zvažte vytvoření nebo použití vlastních zásad vytvořených komunitou.

Redundance brány

I když není specifická pro více back-endů, měla by být implementace brány každé oblasti vždy sestavena s redundancí a měla by být vysoce dostupná v rámci jednotky škálování. Zvolte oblasti se zónami dostupnosti a ujistěte se, že je vaše brána rozložená mezi ně. Nasaďte několik instancí brány, aby se kritický bod selhání omezil na úplný regionální výpadek, a ne na chybu jedné výpočetní instance ve vaší bráně. Pro službu API Management nasaďte dvě nebo více jednotek napříč dvěma nebo více zónami. U vlastních implementací kódu nasaďte aspoň tři instance s distribucí nejlepšího úsilí napříč zónami dostupnosti.

Implementace brány

Azure nenabízí řešení na klíč ani referenční architekturu pro vytvoření takové brány. Jak je uvedeno v úvodním článku, váš tým úloh musí sestavit a provozovat tuto bránu. Následuje několik příkladů ukázkových implementací podporovaných komunitou, které pokrývají některé z výše uvedených případů použití. Při vytváření vlastního testování konceptu zvažte odkazování na tyto ukázky GitHubu.

Implementace	Příklad
Azure API Management	Inteligentní vyrovnávání zatížení pro Azure OpenAI pomocí služby Azure API Management – Toto úložiště GitHubu obsahuje ukázkový kód zásad a pokyny pro nasazení do vašeho předplatného. Škálování Azure OpenAI pomocí služby Azure API Management – Toto úložiště GitHubu obsahuje ukázkový kód zásad a pokyny pro přelití PTU a spotřeby. V úložišti nástrojů brány GenAI jsou také některé zásady služby API Management podporované komunitou.
Vlastní kód	Inteligentní vyrovnávání zatížení pro Azure OpenAI s využitím Azure Container Apps Toto úložiště GitHubu obsahuje ukázkový kód a pokyny pro sestavení kontejneru a nasazení do vašeho předplatného.

Další kroky

Implementace brány pro vaši úlohu poskytuje výhody nad rámec taktické výhody více back-endového směrování popsané v tomto článku. Seznamte se s dalšími klíčovými problémy , které může brána vyřešit.

Související prostředky

• Služba Azure OpenAI
• Brána rozhraní API ve službě Azure API Management