Usare un gateway davanti a più distribuzioni di modelli o istanze

Le architetture dei carichi di lavoro che usano una piattaforma modello ospitata (ad esempio, Microsoft Foundry) possono essere semplici come una o più applicazioni client che chiamano direttamente un singolo endpoint del modello. Alcuni carichi di lavoro, tuttavia, richiedono più client, distribuzioni di più modelli o più istanze host del modello. In questi casi, un gateway può fungere da livello di routing programmabile davanti ai back-end del modello.

Più istanze o distribuzioni di modelli risolvono esigenze specifiche nell'architettura di un carico di lavoro. Possono essere classificati in quattro topologie chiave:

• Più distribuzioni di modelli in una singola istanza
• Istanze multiple in una singola area geografica e una singola sottoscrizione
• Più istanze in una singola area tra più sottoscrizioni
• Più istanze in più regioni

Queste topologie non richiedono automaticamente un gateway. La decisione dipende dal fatto che si tragga vantaggio dal controllo di routing centralizzato, dai controlli di affidabilità, dalla segmentazione della sicurezza, dall'osservabilità e dalla governance della quota a livello di gateway.

Più distribuzioni di modelli in una singola istanza

Dettagli della topologia per più distribuzioni di modelli

• Distribuzioni dei modelli: multiple
• Istanze: una
• Sottoscrizioni: una
• Regioni: una

Casi d'uso della topologia per più distribuzioni di modelli

Una topologia che include una singola istanza ma contiene più di un modello distribuito contemporaneamente supporta i casi d'uso seguenti:

• Esporre diverse funzionalità del modello (ad esempio, un modello per utilizzo generico, un modello con funzionalità più elevate e varianti personalizzate ottimizzate) dietro un unico host.

• Esporre versioni del modello diverse per supportare l'evoluzione del carico di lavoro, i test di regressione o le implementazioni blu-verde.

• Impostare quote di utilizzo o limiti di frequenza diversi per ogni distribuzione per regolare il consumo tra più client (ad esempio, assegnando limiti distinti di token al minuto (TPM) per ogni distribuzione, ove supportato).

Introdurre un gateway per più distribuzioni di modelli

L'introduzione di un gateway in questa topologia è destinata principalmente all'astrazione dei client dalla selezione automatica di un'istanza di modello specifica tra le distribuzioni disponibili nell'istanza. Un gateway consente al controllo lato server di indirizzare una richiesta client a un modello specifico senza dover ridistribuire il codice client o modificare la configurazione client.

Un gateway è particolarmente utile quando non si controlla il codice client. È utile anche quando la distribuzione della configurazione del client è più complessa o rischiosa rispetto alla modifica della configurazione di instradamento del gateway. È possibile modificare il modello a cui punta un client in base a una strategia di implementazione blu-verde delle versioni del modello, ad esempio l'implementazione di un nuovo modello ottimizzato o il passaggio dalla versione X alla X+1 dello stesso modello.

Il gateway può anche essere usato come singolo punto api di ingresso che consente al gateway di identificare il client. Può quindi determinare quale distribuzione del modello viene usata per gestire il prompt in base all'identità del client o ad altre informazioni nella richiesta HTTP. Ad esempio, in una soluzione multi-tenant, i tenant potrebbero essere limitati a un throughput specifico e l'implementazione dell'architettura è una distribuzione di un modello per tenant con quote specifiche. In questo caso, l’instradamento al modello del tenant è di competenza del gateway sulla base delle informazioni contenute nella richiesta HTTP.

L'uso di un gateway in questa topologia consente il rilevamento dell'utilizzo basato su client. A meno che i client non utilizzino entità servizio Microsoft Entra distinte, i log di accesso dell'host del modello non consentono di distinguere tra client diversi. L'inserimento di un gateway davanti alla distribuzione offre al carico di lavoro la possibilità di tenere traccia dell'utilizzo di ciascun client nelle varie distribuzioni di modelli disponibili, a supporto di modelli di chargeback o showback.

Suggerimenti per la topologia di più distribuzioni di modelli

• Anche se il gateway è in grado di modificare completamente il modello in uso, tale modifica potrebbe essere considerata una modifica che causa un'interruzione nel client. Non lasciare che le nuove funzionalità del gateway ti distolgano dall'adottare sempre pratiche di distribuzione sicura per il carico di lavoro.

• Questa topologia è in genere abbastanza semplice da implementare tramite criteri di Gestione API anziché una soluzione di codice personalizzata.

• Mantenere la compatibilità delle API quando è necessario supportare gli SDK. Se le applicazioni client si basano su API/SDK in stile OpenAI pubblicate, progettare l'API gateway in modo che i client possano continuare a usare tali SDK senza adattatori personalizzati.

• Sebbene questa topologia supporti tecnicamente le credenziali client in pass-through (token di accesso o chiave API) per l'istanza che ospita il modello, valuta attentamente l'implementazione della terminazione e del ristabilimento delle credenziali. In questa configurazione, il client è autorizzato dal gateway e, dopodiché, il gateway viene autorizzato tramite il controllo degli accessi in base al ruolo di Azure (RBAC) per tale istanza.

• Se il gateway è progettato per usare le credenziali pass-through, assicurati che i client non possano aggirare il gateway o eventuali restrizioni del modello basate sul client.

• Collocare il gateway nella stessa regione dell'host del modello e limitare, quando possibile, i percorsi di rete back-end in modo che gli endpoint del modello siano raggiungibili solo tramite il gateway. L'isolamento della sottoscrizione dai back-end consente di guidare un approccio APIOps attraverso la separazione dei problemi.

• Distribuisci il gateway in una rete virtuale che contiene una subnet per l'endpoint privato di collegamento privato di Azure dell'istanza. Applicare regole del gruppo di sicurezza di rete (NSG) a tale subnet per consentire solo l'accesso del gateway a tale endpoint privato. Impedire qualsiasi altro accesso al piano dati alle istanze che ospitano il modello.

Motivi per evitare un gateway per più distribuzioni di modelli

Se il controllo della configurazione dei client è altrettanto semplice o semplice rispetto al controllo del routing a livello di gateway, l'affidabilità, la sicurezza, i costi, la manutenzione e l'impatto sulle prestazioni del gateway potrebbero non giustificare il componente architetturale aggiunto.

Valutare anche se sono effettivamente necessarie distribuzioni separate in un host, rispetto a istanze host separate, per ottenere una segmentazione fisica più forte (identità, limite di rete, separazione della fatturazione) senza logica di routing complessa.

Carichi di lavoro basati su chat e interazioni con stato

Alcuni carichi di lavoro utilizzano interazioni basate su chat tramite le API Chat Completions e Assistants, che introducono un comportamento con stato attraverso più richieste. In questi casi, potrebbe essere necessario che un gateway mantenga l'affinità di sessione (talvolta definita stickiness) in modo che tutte le richieste che appartengono a una conversazione attiva vengano instradate alla stessa distribuzione back-end mentre la conversazione è in corso.

Capacità con provisioning ed elaborazione con priorità

La piattaforma potrebbe supportare le unità di throughput con provisioning, che rappresentano la capacità del modello riservata per garantire un throughput prevedibile. Alcuni carichi di lavoro possono combinare la capacità con provisioning con la capacità standard per assorbire i picchi. Le funzionalità di elaborazione della priorità possono ridurre la latenza delle richieste all'interno di una singola distribuzione. Tuttavia, non aumentano la quota complessiva e non devono essere considerati un sostituto di architetture multi-back-end o multi-istanza progettate per garantire elevata disponibilità, resilienza o isolamento multi-tenant.

Più istanze in un'unica area geografica e in un unico abbonamento

Per autenticare il gateway stesso, usare un'identità gestita. Quando il gateway è in esecuzione in Gestione API di Azure o in un altro servizio di Azure, assegnare al gateway un'identità gestita e assegnare a tale identità il ruolo Azure RBAC appropriato su ogni istanza a cui deve accedere. Questo approccio evita il passaggio di chiavi API client ai servizi back-end, abilita l'accesso con privilegi minimi e semplifica la gestione e la rotazione delle credenziali.

Il gateway deve rispettare il comportamento di throttling e le intestazioni Retry-After. API Management offre funzionalità integrate di circuit breaker che possono tenere automaticamente conto dei valori Retry-After restituiti per le risposte HTTP 429.

API Management fornisce anche un criterio llm-token-limit che consente di applicare quote di token al minuto per client o sottoscrizione a livello di gateway. Questi criteri integrati possono ridurre la necessità di una logica personalizzata di ripetizione dei tentativi, limitazione della frequenza e protezione nel codice del gateway e contribuire a evitare la limitazione della frequenza nel back-end.

Dettagli della topologia per più istanze in una singola area e in una singola sottoscrizione

• Distribuzioni di modelli: una o più distribuzioni di modelli
• Istanze: multiple
• Sottoscrizioni: una
• Regioni: una

Casi d'uso della topologia per più istanze in una singola area e una singola sottoscrizione

Una topologia che include più istanze in una singola area e una singola sottoscrizione supporta i casi d'uso seguenti:

• Abilita confini di segmentazione della sicurezza, come le chiavi o Azure RBAC per client

• Abilita un modello di chargeback semplice per client diversi

• Consente a una strategia di failover di mantenere la disponibilità durante eventi come un'interruzione della piattaforma che influisce su un'istanza specifica, una configurazione errata della rete o una distribuzione eliminata accidentalmente

• Abilita una strategia di failover per la disponibilità della quota, ad esempio abbinando un'istanza con provisioning predefinito e un'istanza standard per gestire il traffico in eccesso

Aggiungere un gateway per più istanze in un'unica area geografica e in un'unica sottoscrizione

Un modello potrebbe non essere accessibile a un client per diversi motivi. Questi motivi includono interruzioni, richieste di limitazione o problemi correlati a operazioni del carico di lavoro come la configurazione errata della rete o un'eliminazione accidentale di una distribuzione del modello. Per risolvere questi problemi, è necessario implementare la logica di ripetizione dei tentativi e di interruzione del circuito.

Questa logica può essere implementata nei client o sul lato server in un gateway. L'implementazione della logica in un gateway astrae la logica dai client, evitando il codice ripetuto e ottenendo un'unica posizione per testare la logica. Indipendentemente dal fatto che il codice client sia proprietario, questo passaggio può aumentare l'affidabilità del carico di lavoro.

L'utilizzo di un gateway con più istanze in una singola area geografica e sottoscrizione consente di trattare tutti i backend come distribuzioni in modalità attiva-attiva, anziché usarli solo per failover in modalità attiva-passiva. È possibile distribuire lo stesso modello con provisioning tra più istanze e usare il gateway per bilanciare il carico tra di essi.

Una delle opzioni a disposizione del team responsabile del carico di lavoro durante il provisioning è decidere se il modello di fatturazione e throughput sia di tipo provisioned o standard. Una strategia di ottimizzazione dei costi per evitare sprechi dovuti a capacità di provisioning inutilizzata consiste nel sottodimensionare leggermente l'istanza con provisioning e nel distribuire anche un'istanza standard accanto a essa. L'obiettivo di questa topologia è fare in modo che i client utilizzino prima di tutto il throughput preallocato disponibile e quindi "esplodano" nella distribuzione standard per gestire le eccedenze. Questa forma di failover pianificato è vantaggiosa per il motivo indicato nel paragrafo iniziale di questa sezione: mantenere questa complessità fuori dal codice client.

Quando un gateway è coinvolto, si trova in una posizione univoca per acquisire i dettagli su tutte le distribuzioni di modelli con cui interagiscono i client. Sebbene ogni istanza possa raccogliere la propria telemetria, raccoglierla all'interno del gateway consente al team responsabile del carico di lavoro di pubblicare la telemetria e le risposte agli errori relative a tutti i modelli utilizzati in un unico archivio. Questa configurazione semplifica l'invio di dashboard e avvisi unificati.

Suggerimenti per più istanze in una singola area e topologia di sottoscrizione singola

• Assicurarsi che il gateway utilizzi le informazioni Retry-After disponibili nelle risposte HTTP del servizio back-end quando si implementano scenari di failover sul gateway. Usare queste informazioni autorevoli per controllare l'implementazione dell'interruttore. Non raggiungere continuamente un endpoint che restituisce 429 Too Many Requests. Interrompere invece il circuito per l'istanza del modello.

• Prevedere gli eventi di throttling prima che si verifichino monitorando il consumo del modello sulla base delle richieste precedenti è possibile a livello di gateway, ma questo approccio presenta numerosi casi limite. Nella maggior parte dei casi, è preferibile non cercare di prevedere le situazioni di limitazione, ma utilizzare i codici di risposta HTTP per orientare le decisioni di instradamento successive.

• Quando si utilizza una strategia round-robin o si passa per failover a un endpoint diverso, incluso il passaggio da distribuzioni con capacità riservata a distribuzioni standard, assicurarsi sempre che tali endpoint utilizzino lo stesso modello nella stessa versione. Ad esempio, non eseguire il failover dalla versione X alla versione X+1 né effettuare il bilanciamento del carico tra le due versioni. Questa modifica della versione può causare un comportamento imprevisto nei client.

• È possibile implementare il bilanciamento del carico e la logica di failover nei criteri di Gestione API. È possibile implementare un approccio più sofisticato usando una soluzione gateway basata su codice, ma Gestione API è sufficiente per questo caso d'uso.

• Distribuisci il gateway nella stessa area geografica dell'istanza del modello.

• Distribuisci il gateway in un gruppo di risorse dedicato della sottoscrizione, separato dalle istanze del modello. L'isolamento del gateway dai back-end consente di guidare un approccio APIOps tramite la separazione delle problematiche.

• Raggruppare tutte le istanze collegamento privato endpoint privati in una singola subnet nella rete virtuale del gateway. Applicare le regole NSG a quella subnet per consentire solo al gateway di accedere a quegli endpoint privati. Qualsiasi altro accesso alle istanze tramite il piano dati deve essere negato.

• Per semplificare la logica nel codice di routing del gateway, usare lo stesso nome di distribuzione del modello per ridurre al minimo la differenza tra le route HTTP. Ad esempio, il nome del modello può essere usato in tutte le istanze con carico bilanciato o di spillover, indipendentemente dal fatto che siano standard o sottoposte a provisioning.

Motivi per evitare un gateway per più istanze in una singola area e in una singola sottoscrizione

Un gateway stesso non migliora la possibilità di eseguire il chargeback dei modelli su client diversi per questa topologia specifica. In questa topologia, è possibile concedere ai clienti l'accesso alle proprie istanze dedicate, consentendo al team responsabile dei carichi di lavoro di gestire il chargeback o lo showback. Questo modello supporta l'identità univoca e i perimetri di rete, pertanto non è necessario introdurre un gateway in modo specifico per la segmentazione.

Se nell'area sono presenti alcuni client e si controlla il codice e i client sono facili da aggiornare, la logica che si deve compilare nel gateway può essere aggiunta direttamente nel codice. Prendere in considerazione l'uso dell'approccio gateway per il failover o il bilanciamento del carico principalmente quando non si è proprietari del codice client o quando i client non possono gestire la complessità aggiunta.

Se si usa un gateway specificamente per risolvere i vincoli di capacità, valutare se le funzionalità di capacità basate sulla zona dati sono sufficienti per il carico di lavoro.

Più istanze in una singola area geografica in più sottoscrizioni

Quando si utilizzano più sottoscrizioni per ripartire la quota standard, un gateway può nascondere ai client i confini tra le sottoscrizioni instradando il traffico in base alla disponibilità o alla capacità. Tenere presente che le quote standard rimangono incluse nell'ambito della sottoscrizione, quindi la capacità non viene aggregata automaticamente a meno che non vengano usate sottoscrizioni separate.

Distribuzioni globali e di Data Zone

Con le distribuzioni globali, l'elaborazione delle richieste può verificarsi in qualsiasi area Azure in cui è disponibile la capacità, ma i dati inattivi rimangono all'interno dell'area della distribuzione. Le distribuzioni della zona dati limitano l'elaborazione a una zona geografica definita, ad esempio aree solo UE. Se il carico di lavoro richiede una rigorosa residenza dei dati senza elaborazione transfrontaliera, un singolo gateway globale che instrada il traffico tra aree non è appropriato. In questi casi, distribuire gateway separati per area o area geografica per garantire la conformità ai requisiti normativi.

Dettagli della topologia per più istanze in una singola area in più sottoscrizioni

• Distribuzioni di modelli: una o più distribuzioni di modelli
• Istanze: multiple
• Sottoscrizioni: multiple
• Regioni: una

Casi d'uso della topologia per più istanze in una singola area in più sottoscrizioni

Una topologia che include più istanze in una singola area in più sottoscrizioni supporta i casi d'uso seguenti:

• Uno dei casi d'uso elencati per più istanze in una singola area e in una singola sottoscrizione.

• Caso d'uso in cui si vuole ottenere una quota maggiore in una distribuzione standard ed è necessario vincolare l'uso di modelli a una singola area specifica.

  Note

  Se non è necessario vincolare l'uso di modelli a un'area specifica, usare le distribuzioni Global o Data Zone che usano l'infrastruttura globale Azure per instradare dinamicamente le richieste ai data center con la capacità disponibile.

Introdurre un gateway per più istanze in una singola area e sottoscrizioni multiple

Gli stessi motivi per l'introduzione di un gateway per più istanze in una singola area e sottoscrizione si applicano a questa topologia.

Oltre a questi motivi, l'aggiunta di un gateway in questa topologia supporta anche un team centralizzato che fornisce un modello di intelligenza artificiale come servizio per l'organizzazione. Poiché la quota in una distribuzione standard è associata alla sottoscrizione, un team centralizzato che fornisce servizi di intelligenza artificiale condivisi che usano la distribuzione standard deve distribuire istanze tra più sottoscrizioni per ottenere la quota necessaria. La logica del gateway rimane ancora la stessa.

Suggerimenti per più istanze in una singola area e in una topologia di più sottoscrizioni

• Idealmente, tutte le sottoscrizioni dovrebbero essere associate allo stesso tenant Microsoft Entra, per garantire coerenza in Azure RBAC e in Criteri di Azure.

• Distribuisci il gateway nella stessa area geografica dell'istanza che ospita il modello.

• Distribuire il gateway in una sottoscrizione dedicata, separata dalle istanze. Questa configurazione consente di applicare la coerenza nell'indirizzamento delle istanze e fornisce una segmentazione logica dei compiti tra le distribuzioni del modello e il relativo routing.

• Quando si instradano le richieste attraverso il gateway tra diverse sottoscrizioni, assicurarsi che gli endpoint privati siano raggiungibili. È possibile usare il routing transitivo tramite un hub verso gli endpoint privati per i backend nei rispettivi spoke. Potrebbe essere possibile esporre endpoint privati per il servizio AI direttamente nella sottoscrizione del gateway usando le connessioni collegamento privato tra sottoscrizioni. Le connessioni di collegamento privato tra sottoscrizioni sono preferibili se l'architettura e l'organizzazione supportano questo approccio.

Motivi per evitare un gateway per più istanze in una singola regione e per sottoscrizioni multiple

Tutti i motivi per evitare l'utilizzo di un gateway per gestire più istanze all'interno di una singola area e sottoscrizione si applicano a questa topologia.

Più istanze in più regioni

Dettagli della topologia per più istanze in più aree

• Distribuzioni dei modelli: multiple
• Istanze: multiple
• Sottoscrizioni: una o più sottoscrizioni
• Aree geografiche: multiple

Casi d'uso della topologia per più istanze in più aree

Una topologia che include più istanze distribuite tra due o più aree Azure supporta i casi d'uso seguenti:

• Supporta tutti i casi d'uso elencati per più istanze in una singola regione tra più sottoscrizioni.

• Abilita una strategia di failover per la disponibilità del servizio, ad esempio l'uso di coppie tra aree.

• Consente di progettare la residenza e la conformità dei dati.

• Abilita la disponibilità di modelli misti. Alcune aree hanno modelli diversi e quote diverse disponibili per i modelli.

Questa topologia è applicabile anche quando si dispone di un modello di intelligenza artificiale esposto in uno scenario cross-premise, ad esempio in locale o in un altro cloud. Tuttavia, questo scenario non usa aree di Azure diverse.

Introdurre un gateway per più istanze in più regioni

Per le architetture business critical che devono sopravvivere a un'interruzione completa a livello di area, un gateway unificato globale consente di eliminare la logica di failover dal codice client. Questa implementazione richiede che il gateway non sia influenzato da un'interruzione regionale.

Usa API Management (distribuzione in un'unica area geografica)

In questa topologia, Gestione API viene usata in modo specifico per la tecnologia del gateway. La gestione API viene distribuita in un'unica regione. Dall'istanza del gateway si utilizza il bilanciamento del carico attivo-attivo tra regioni. I criteri nel tuo gateway fanno riferimento a tutte le istanze che ospitano il modello. Il gateway richiede visibilità di linea di rete verso ciascun back-end nelle varie regioni, tramite peering di reti virtuali tra regioni o endpoint privati. Le chiamate da questo gateway verso un'istanza in un'altra regione comportano una maggiore latenza di rete e costi di traffico in uscita.

Il gateway deve tenere conto dei segnali di limitazione e disponibilità provenienti dalle istanze back-end e rimuovere dal pool i back-end che presentano errori finché non è possibile reinserire in sicurezza l'istanza con errori o soggetta a limitazione. Il gateway deve riprovare la richiesta corrente verso un'altra istanza di back-end nel pool quando si verifica un errore, prima di ripiegare sulla restituzione di un errore del gateway. Il controllo di integrità del gateway dovrebbe segnalare uno stato non integro quando non sono disponibili istanze di back-end.

Poiché questa topologia introduce un singolo punto di errore (il gateway), l'utilità di questa architettura specifica è limitata alla protezione da interruzioni dell'endpoint del modello a livello di area.

Variante attiva-passiva

Questo modello può essere usato anche per consentire un approccio attivo-passivo per gestire in modo specifico un guasto a livello regionale che interessa solo l'host del modello. In questa modalità il traffico passa normalmente dal gateway all'istanza nella stessa area del servizio Gestione API. Quell'istanza gestisce l'intero flusso di traffico previsto in assenza di un guasto regionale. Può essere con provisioning o standard, a seconda del modello di fatturazione preferito. Se un errore a livello di area influisce solo su tale servizio, il gateway può reindirizzare il traffico a un'altra area in cui il modello è già distribuito in una distribuzione standard.

Usare Gestione API (distribuzione in più aree)

Gestione API supporta la distribuzione di un'istanza instance in più aree Azure, che può migliorare l'affidabilità dell'architettura precedente basata su Gestione API. Questa opzione di distribuzione offre un singolo piano di controllo tramite una singola istanza di Gestione API, ma fornisce gateway replicati nelle aree desiderate. In questa topologia, si distribuiscono i componenti del gateway in ogni regione contenente istanze host del modello che forniscono un'architettura di gateway attivo-attivo.

I criteri, ad esempio il routing e la logica di gestione delle richieste, vengono replicati in ogni singolo gateway. La logica di tutti i criteri deve includere una logica condizionale nel criterio per garantire che le istanze vengano chiamate nella stessa area geografica del gateway corrente. Per ulteriori informazioni, consulta Instradamento delle chiamate API verso servizi back-end regionali. Il componente gateway richiede quindi visibilità di rete solo verso le istanze nella propria area geografica, in genere tramite endpoint privati.

Gestione API offre un routing globale con dominio completamente qualificato (FQDN) pronto all'uso basato sulla latenza più bassa. Usa questa funzionalità integrata basata sulle prestazioni per le distribuzioni di gateway attivo-attivo. Questa funzionalità predefinita consente di gestire le prestazioni e gestire un'interruzione del gateway a livello di area. Il router globale predefinito supporta anche i test di ripristino di emergenza perché è possibile simulare le aree fino alla disabilitazione dei singoli gateway. Assicurarsi che i client rispettino il TTL (Time to Live) associato all'FQDN e dispongano di una logica di ritentativo appropriata per gestire un recente failover DNS.

Se è necessario introdurre un web application firewall in questa architettura, è comunque possibile usare la soluzione di routing FQDN predefinita come origine back-end per il router globale che implementa un web application firewall. Il router globale delega la responsabilità del failover a API Management. In alternativa, è possibile usare gli FQDN regionali del gateway come membri del pool di back-end. In quest'ultima architettura, usare l'endpoint integrato /status-0123456789abcdef su ogni gateway regionale o un altro endpoint API di integrità personalizzato per supportare il failover regionale. Se non sei sicuro di quale approccio seguire, inizia con l'approccio con FQDN back-end a origine singola.

Questa architettura è più efficace quando si considerano le aree come completamente disponibili o completamente non disponibili. In altre parole, se il gateway di Gestione API o un'istanza back-end non è disponibile, non si vuole instradare il traffico client al gateway di Gestione API in tale area. Salvo diversa disposizione, se il gateway regionale continua ad accettare traffico mentre il back-end non è disponibile, l'errore deve essere propagato fino al client. Per evitare l'errore del client, vedi un approccio migliorato in gateway attivo-attivo più variante attivo-passivo.

Se una regione sta vivendo un'interruzione del gateway di API Management o viene contrassegnata come non funzionante, le regioni rimanenti disponibili devono assorbire il 100% del traffico dalle altre regioni. È quindi necessario sovradimensionare le istanze host del modello predisposte per gestire il nuovo picco di traffico oppure usare un approccio attivo-passivo per il failover. Usare il calcolatore della capacità a livello di servizio per la pianificazione della capacità.

Assicurarsi che il gruppo di risorse che contiene API Management si trovi nella stessa area geografica dell'istanza di API Management stessa, per ridurre la probabilità che la portata dell'impatto di un'interruzione regionale correlata comprometta l'accesso al provider di risorse dei gateway.

Gateway attivo-attivo e variante attivo-passivo

La sezione precedente descrive la disponibilità del gateway fornendo una topologia del gateway attivo-attivo. Questa topologia combina il gateway attivo-attivo con una topologia host in modalità attiva-passiva economica. L'aggiunta al gateway di una logica di tipo attivo-passivo per effettuare il failover da una distribuzione con provisioning già effettuato a una distribuzione standard può aumentare significativamente l'affidabilità del carico di lavoro. Questo modello consente comunque ai client di usare la soluzione di routing FQDN predefinita di Gestione API per il routing basato sulle prestazioni.

Usare un gateway sviluppato su misura

Se le regole di routing per ogni gateway sono troppo complesse perché il team possa considerarle ragionevolmente come criteri di API Management, è necessario implementare e gestire la propria soluzione. Questa architettura deve essere una distribuzione in più aree del gateway, con un'unità di scala a disponibilità elevata per area. È necessario far fronte a tali distribuzioni con Frontdoor di Azure o Gestione traffico di Azure, in genere usando il routing basato sulla latenza e i controlli di integrità appropriati per la disponibilità del gateway.

Usare Frontdoor di Azure se è necessario un web application firewall e l'accesso a Internet pubblico. Utilizzare Traffic Manager se non è necessario un firewall per applicazioni web e la durata (TTL DNS) è sufficiente. Quando si configura le istanze del gateway con Frontdoor di Azure (o qualsiasi proxy inverso), assicurarsi che il gateway non possa essere bypassato. Rendere disponibili le istanze del gateway solo tramite endpoint privato quando si usa Frontdoor di Azure e aggiungere la convalida dell'intestazione HTTP X_AZURE_FDID nell'implementazione del gateway.

Posizionare le risorse per area usate nel gateway personalizzato in gruppi di risorse per area. Così si riduce la probabilità che la portata di un'interruzione regionale correlata comprometta la possibilità di accedere al provider di risorse delle risorse gateway in quell'area geografica.

Puoi anche valutare di mettere API Management davanti all'implementazione della logica del gateway per ottenere anche gli altri vantaggi di API Management. Questi vantaggi includono TLS, autenticazione, controllo di integrità e bilanciamento del carico round-robin. Questa configurazione sposta i problemi comuni dell'API fuori dal codice personalizzato nel gateway e consente al gateway di indirizzare in modo specifico l'istanza del modello e il routing della distribuzione.

Per garantire la conformità ai requisiti di residenza dei dati, assicurarsi che ogni area geopolitica disponga di una distribuzione dedicata e isolata di questa architettura e che i client possano accedere solo al proprio endpoint autorizzato.

Motivi per evitare un gateway per più istanze in più aree

Non implementare un gateway unificato tra aree geopolitiche quando è necessaria la residenza e la conformità dei dati. In questo modo si violano i requisiti di residenza dei dati. Usare gateway indirizzabili singolarmente per area e seguire le indicazioni riportate in una delle sezioni precedenti.

Non implementare un gateway unificato esclusivamente per aumentare la quota. Usare Global Standard distribuzioni che usano l'infrastruttura globale di Azure per instradare dinamicamente le richieste ai data center con la migliore capacità per ogni richiesta.

Se non è previsto che i client eseguano il failover tra aree ed è possibile assegnare ogni client a un'area specifica, usare invece più gateway, uno per area e seguire le indicazioni riportate in una delle sezioni precedenti. Non vincolare la disponibilità di altre regioni alla regione che ospita il gateway, considerandola un singolo punto di guasto.

Non implementate un gateway unificato se il modello e la versione non sono disponibili in tutte le regioni supportate dal gateway. I client devono essere indirizzati allo stesso modello e alla stessa versione del modello. Per i gateway di failover e con bilanciamento del carico in più aree, è necessario selezionare un modello comune e una versione del modello disponibile in tutte le aree interessate. Per altre informazioni, vedere Disponibilità del modello. Se non è possibile standardizzare il modello e la versione del modello, il vantaggio del gateway è limitato.

Raccomandazioni generali

Indipendentemente dalla topologia necessaria per il carico di lavoro, sono disponibili alcune raccomandazioni trasversali da considerare quando si compila la soluzione gateway.

Interazioni a stato

Quando i client usano funzionalità con stato, ad esempio l'API Assistants, è necessario configurare il gateway per aggiungere un client a un back-end specifico durante tale interazione. È possibile eseguire questa configurazione archiviando i dati dell'istanza in un cookie. In questi scenari, valuta l'opportunità di restituire una risposta API come 429 a un client bloccato anziché reindirizzarlo a un'istanza back-end diversa. In questo modo il client può gestire in modo esplicito l'indisponibilità improvvisa anziché nasconderla e instradarla a un'istanza del modello senza cronologia.

Controlli di integrità del gateway

Esistono due prospettive di controllo dell'integrità da considerare, indipendentemente dalla topologia.

Se il gateway è basato sul round-robin o esegue rigorosamente il failover per la disponibilità del servizio, è necessario disporre di un modo per rimuovere un'istanza di back-end (o un modello) dallo stato di disponibilità. Molti servizi di intelligenza artificiale non forniscono un endpoint di controllo dell'integrità dedicato per determinare in modo preliminare se le istanze sono disponibili per gestire le richieste. È possibile inviare transazioni sintetiche tramite , ma in questo modo viene utilizzata la capacità del modello. A meno che non si disponga di un'altra origine di segnale affidabile per l'istanza e la disponibilità del modello, il gateway deve probabilmente presupporre che l'istanza back-end sia disponibile e gestire 429i codici di stato , 500e 503 HTTP come segnale di interruzione del circuito per le richieste future su tale istanza o modello per un periodo di tempo. In caso di throttling, attenersi sempre ai dati presenti nelle risposte API Retry-After per i codici di risposta 429 nella logica di circuit breaker. Se si usa Gestione API, valutare usando la funzionalità di interruttore predefinito .

I clienti oppure il team operativo responsabile dei carichi di lavoro potrebbero voler disporre di un controllo dello stato di salute esposto sul gateway per finalità di instradamento o ispezione. Se si usa Gestione API, l'impostazione predefinita /status-0123456789abcdef potrebbe non essere abbastanza dettagliata perché riguarda principalmente l'istanza del gateway di Gestione API, non i back-end. Considerare l'aggiunta di un'API dedicata al controllo dell'integrità che possa restituire dati significativi ai clienti o ai sistemi di osservabilità sulla disponibilità del gateway o di percorsi specifici nel gateway.

Procedure di distribuzione sicure

È possibile usare le implementazioni del gateway per orchestrare le distribuzioni blu-verde dei modelli aggiornati. I modelli ospitati vengono aggiornati con nuove versioni del modello e nuovi modelli e potrebbero essere disponibili nuovi modelli ottimizzati.

Dopo aver testato gli effetti di una modifica nella preproduzione, valutate se i client nell'ambiente di produzione debbano passare alla nuova versione del modello oppure reindirizzare il traffico. Il modello di gateway descritto in precedenza consente al back-end di distribuire entrambi i modelli contemporaneamente. La distribuzione simultanea dei modelli consente al gateway di reindirizzare il traffico in base alla strategia di distribuzione sicura del team responsabile del carico di lavoro, che prevede un rilascio graduale.

Anche se non si usano distribuzioni blu-verde, l'approccio APIOps del carico di lavoro deve essere definito e sufficientemente automatizzato in base alla frequenza di modifica delle distribuzioni di modelli e dell'istanza back-end.

Implementazione sufficiente

Molti degli scenari introdotti in questo articolo consentono di aumentare il potenziale obiettivo del livello di servizio (SLO) del carico di lavoro riducendo la complessità dei client e implementando tecniche di auto-conservazione affidabili. Altri migliorano la sicurezza del carico di lavoro spostando i controlli di accesso su modelli specifici, allontanandoli dal servizio di IA sottostante. Assicurarsi che l'introduzione del gateway non funzioni contro questi obiettivi. Comprendere i rischi dell'aggiunta di un nuovo singolo punto di errore, che si tratti di errori del servizio o problemi di configurazione causati dall'utente nel gateway, logica di routing complessa o rischi di esporre più modelli a client non autorizzati di quanto previsto.

Sovranità dei dati

Valuta diversi approcci attivi-attivi e attivi-passivi per il tuo carico di lavoro dal punto di vista della conformità ai requisiti di residenza dei dati. Molti di questi modelli sono applicabili per l'architettura del carico di lavoro se le aree coinvolte rimangono entro il limite geopolitico. Per supportare questo scenario, è necessario considerare i limiti geopolitici come francobolli isolati e applicare la gestione attiva-attiva o attiva-passiva esclusivamente all'interno di tale timbro.

In particolare, qualsiasi routing basato sulle prestazioni deve essere attentamente esaminato per la conformità alla sovranità dei dati. Negli scenari di sovranità dei dati non è possibile gestire i client in un'altra area geografica e rimanere conformi. Tutte le architetture di gateway che implicano la residenza dei dati devono imporre che i client usino solo gli endpoint nella propria area geopolitica. Ai client deve essere impedito di utilizzare altri endpoint del gateway e il gateway stesso non dovrebbe tradire la fiducia del client effettuando una richiesta tra aree geopolitiche diverse. Il modo più affidabile per implementare questa segmentazione consiste nel creare l'architettura intorno a un gateway completamente indipendente e a disponibilità elevata per ogni area geopolitica.

Quando si valuta se sfruttare la capacità aumentata usando distribuzioni globali o di zona dati , è necessario comprendere in che modo queste distribuzioni influiscono sulla residenza dei dati. I dati archiviati inattivi rimangono nell'area geografica Azure designata sia per le distribuzioni globali che per le zone dati. Tali dati possono essere trasmessi ed elaborati per l'inferenza in qualsiasi posizione di hosting per le distribuzioni globali o in qualsiasi posizione di hosting all'interno della zona dati specificata Microsoft per le distribuzioni di Zona dati.

Autorizzazione del servizio

Il gateway deve eseguire l'autenticazione con tutte le istanze model-host con cui si interfaccia. A meno che il gateway non sia stato progettato per eseguire l'autenticazione pass-through, il gateway deve usare un'identità gestita per le credenziali. Ogni istanza deve quindi configurare Azure RBAC con il privilegio minimo per le identità gestite dei gateway. Per le architetture attive-attive e di failover, assicurarsi che l'identità del gateway disponga di autorizzazioni equivalenti in tutte le istanze coinvolte.

Criteri di Azure

La coerenza tra le distribuzioni di modelli e le istanze è importante sia nelle situazioni attive-attive che attive-passive. Usare Criteri di Azure per applicare la coerenza tra le varie istanze o distribuzioni di modelli. Se i criteri predefiniti per i servizi di intelligenza artificiale non sono sufficienti a garantire la coerenza tra questi, valuta la creazione o l’uso di criteri personalizzati creati dalla community.

Ridondanza di Gateway

Anche se questa considerazione non è specifica per più back-end, realizzare l'implementazione del gateway di ogni area con ridondanza e disponibilità elevata all'interno dell'unità di scala. Scegliere le regioni con zone di disponibilità e assicurarsi che il gateway sia distribuito tra di esse. Distribuire più istanze del gateway in modo che un singolo punto di guasto sia limitato a un'interruzione completa a livello di regione e non al guasto di una singola istanza di calcolo nel gateway.

• Gestione API: Distribuire due o più unità tra due o più zone.
• Implementazioni di codice personalizzate: Distribuire almeno tre istanze con una distribuzione per quanto possibile uniforme tra le zone di disponibilità.

Implementazioni del gateway

Azure non fornisce una soluzione chiavi in mano completa o un'architettura di riferimento per la creazione di un gateway incentrato sul routing del traffico tra più back-end. Tuttavia, Gestione API è preferibile perché il servizio fornisce una soluzione basata su PaaS che usa funzionalità predefinite, ad esempio pool back-end, criteri di interruzione del circuito e criteri personalizzati, se necessario. Per valutare le funzionalità disponibili in tale servizio per le esigenze multi-back-end del carico di lavoro, vedere Gateway di intelligenza artificiale in Gestione API.

Sia che si usi Gestione API o si crei una soluzione personalizzata, come indicato nell'articolo introduttivo, il team del carico di lavoro deve compilare e gestire il gateway. Gli esempi di Gestione API seguenti illustrano alcuni dei casi d'uso indicati in precedenza. Valuta la possibilità di fare riferimento a questi esempi quando crei la tua proof of concept.

• I back-end in Gestione API forniscono esempi di configurazione per pool back-end e circuit breaker.
• I lab gateway di intelligenza artificiale contengono criteri di Gestione API di esempio, modelli Bicep e strumenti per testare il comportamento dei criteri.

Routing tra più back-end per altri modelli

Il modello di gateway non è limitato a un singolo provider. Un gateway può unificare l'accesso a back-end di intelligenza artificiale diversi, ad esempio modelli self-hosted o servizi di intelligenza artificiale non Microsoft che espongono API compatibili con OpenAI. Questo approccio consente una singola superficie API coerente per le applicazioni client, abilitando al tempo stesso il routing flessibile in base a casi d'uso, costi o caratteristiche delle prestazioni.

Miglioramenti di Gestione API per i gateway di intelligenza artificiale

Gestione API offre funzionalità specializzate per carichi di lavoro generativi di intelligenza artificiale. Queste funzionalità includono la limitazione della frequenza basata su token, la memorizzazione nella cache delle risposte semantiche, il bilanciamento del carico back-end predefinito e l'interruzione del circuito e l'onboarding semplificato degli endpoint compatibili con OpenAI.

Usando queste funzionalità predefinite, è possibile ridurre significativamente la quantità di logica del gateway personalizzata necessaria e migliorare l'affidabilità e la governance delle soluzioni che instradano il traffico a più distribuzioni di modelli o ad altri back-end di intelligenza artificiale.

Passaggio successivo

Un'implementazione del gateway per il carico di lavoro offre vantaggi oltre al vantaggio di routing multi-back-end tattico descritto in questo articolo. Per informazioni sulle altre sfide che un gateway può risolvere, vedere Principali sfide.

Risorse correlate

• carichi di lavoro di intelligenza artificiale in Azure
• Gateway API in Gestione API