Usar um gateway na frente de várias implantações ou instâncias do Azure OpenAI

As arquiteturas de carga de trabalho que envolvem o Serviço OpenAI do Azure podem ser tão simples quanto um ou mais aplicativos cliente consumindo diretamente uma única implantação de modelo OpenAI do Azure diretamente, mas nem todas as cargas de trabalho podem ser projetadas com essa simplicidade. Cenários mais complexos incluem topologias com vários clientes, várias implantações do Azure OpenAI ou várias instâncias do Azure OpenAI. Nessas situações, introduzir um gateway na frente do Azure OpenAI pode ser benéfico para o design da carga de trabalho.

Várias instâncias ou implantações de modelo do Azure OpenAI resolvem requisitos específicos em uma arquitetura de carga de trabalho. Eles podem ser classificados em quatro topologias principais.

• Várias implantações de modelo em uma única instância do Azure OpenAI
• Várias instâncias do Azure OpenAI em uma única região e uma única assinatura
• Várias instâncias do Azure OpenAI em uma única região em várias assinaturas
• Várias instâncias do Azure OpenAI em várias regiões

Essas topologias por si só não exigem o uso de um gateway. A escolha de um gateway depende se a carga de trabalho se beneficia de sua inclusão na arquitetura. Este artigo descreve os desafios que cada uma das quatro topologias aborda e os benefícios e custos de incluir um gateway em cada topologia.

Várias implantações de modelo em uma única instância do Azure OpenAI

Detalhes da topologia para implantações de vários modelos

• Implantações de modelo OpenAI do Azure: várias
• Instâncias do Azure OpenAI: uma
• Subscrições: uma
• Regiões: uma

Casos de uso de topologia para implantações de vários modelos

Uma topologia que inclui uma única instância do Azure OpenAI, mas contém mais de um modelo implantado simultaneamente, dá suporte aos seguintes casos de uso:

• Exponha diferentes recursos de modelo, como gpt-35-turbo, gpt-4e modelos personalizados ajustados.

• Exponha diferentes versões de modelo, como 0613, 1106e modelos personalizados ajustados para dar suporte à evolução da carga de trabalho ou implantações azul-verde.

• Exponha diferentes cotas atribuídas (30.000 Token-Per-Minute (TPM), 60.000 TPM) para dar suporte à limitação de consumo em vários clientes.

Introduzir um gateway para implantações de vários modelos

A introdução de um gateway nessa topologia destina-se principalmente a abstrair os clientes da autoseleção de uma instância de modelo específica entre as implantações disponíveis na instância. Um gateway permite que o controle do lado do servidor direcione uma solicitação do cliente para um modelo específico sem a necessidade de reimplantar o código do cliente ou alterar a configuração do cliente.

Um gateway é especialmente benéfico quando você não controla o código do cliente. Também é benéfico quando a implantação da configuração do cliente é mais complexa ou arriscada do que a implantação de alterações em uma configuração de roteamento de gateway. Você pode alterar para qual modelo um cliente está apontando com base em uma estratégia de distribuição azul-verde de suas versões de modelo, como lançar um novo modelo ajustado ou passar da versão X para X+1 do mesmo modelo.

O gateway também pode ser usado como um único ponto de entrada de API que permite que o gateway identifique o cliente. Em seguida, ele pode determinar qual implantação de modelo é usada para atender ao prompt com base na identidade desse cliente ou em outras informações na solicitação HTTP. Por exemplo, em uma solução multilocatário, os locatários podem ser limitados a uma taxa de transferência específica, e a implementação da arquitetura é uma implantação de modelo por locatário com cotas específicas. Nesse caso, o roteamento para o modelo do locatário seria de responsabilidade do gateway com base nas informações da solicitação HTTP.

O uso de um gateway nessa topologia permite o rastreamento de uso baseado no cliente. A menos que os clientes estejam usando entidades de serviço distintas do Microsoft Entra, os logs de acesso do Azure OpenAI não seriam capazes de distinguir vários clientes. Ter um gateway na frente da implantação dá à sua carga de trabalho a oportunidade de acompanhar o uso por cliente em várias implantações de modelo disponíveis para oferecer suporte a modelos de estorno ou showback.

Dicas para a topologia de implantações de vários modelos

• Embora o gateway esteja em posição de alterar completamente qual modelo está sendo usado, por exemplo gpt-35-turbogpt-4, essa alteração provavelmente seria considerada uma mudança de rutura para o cliente. Não deixe que os novos recursos funcionais do gateway distraiam de sempre executar práticas de implantação seguras para essa carga de trabalho.

• Normalmente, essa topologia é simples o suficiente para ser implementada por meio da política de Gerenciamento de API do Azure, em vez de uma solução de código personalizada.

• Para dar suporte ao uso de SDKs nativos com especificações de APIs do Azure OpenAI publicadas, mantenha a compatibilidade da API com a API do Azure OpenAI. Essa situação é uma preocupação maior quando sua equipe não está criando todo o código dos clientes de carga de trabalho. Ao decidir projetar a API HTTP para o gateway, considere os benefícios de manter a compatibilidade da API HTTP do Azure OpenAI.

• Embora essa topologia ofereça suporte técnico a credenciais de cliente de passagem (tokens de acesso ou chave de API) para a instância do Azure OpenAI, considere fortemente a implementação do encerramento e restabelecimento de credenciais. Dessa forma, o cliente é autorizado no gateway e, em seguida, o gateway é autorizado por meio do RBAC do Azure para a instância do Azure OpenAI.

• Se o gateway for projetado para usar credenciais de passagem, certifique-se de que os clientes não possam ignorar o gateway ou quaisquer restrições de modelo com base no cliente.

• Implante seu gateway na mesma região que a instância do Azure OpenAI.

• Implante o gateway em um grupo de recursos dedicado na assinatura separada da instância do Azure OpenAI. Isolar a assinatura dos back-ends pode ajudar a conduzir uma abordagem APIOps por meio de separações de preocupação.

• Implante o gateway em uma rede virtual que contenha uma sub-rede para o ponto de extremidade privado do Azure Private Link da instância do Azure OpenAI. Aplique regras de NSG (grupo de segurança de rede) a essa sub-rede para permitir apenas o acesso do gateway a esse ponto de extremidade privado. Todos os outros acessos de plano de dados às instâncias do Azure OpenAI devem ser proibidos.

Razões para evitar um gateway para implantações de vários modelos

Se controlar a configuração de seus clientes for tão ou mais fácil do que controlar o roteamento no nível do gateway, a confiabilidade, a segurança, o custo, a manutenção e o impacto no desempenho adicionais do gateway podem não valer a pena o componente de arquitetura adicionado.

Além disso, alguns cenários de carga de trabalho podem se beneficiar da migração de uma abordagem de implantação de vários modelos para uma abordagem de implantação de várias instâncias do Azure OpenAI. Por exemplo, considere várias instâncias do Azure OpenAI se você tiver vários clientes que devem estar usando RBAC ou chaves de acesso diferentes para acessar seu modelo. Usar várias implantações em uma única instância do Azure OpenAI e manipular a segmentação de identidade lógica no nível do gateway é possível, mas pode ser excessivo quando uma abordagem de segmentação RBAC física está disponível usando instâncias distintas do Azure OpenAI.

Várias instâncias do Azure OpenAI em uma única região e uma única assinatura

Detalhes da topologia para várias instâncias em uma única região e uma única assinatura

• Implantações de modelo OpenAI do Azure: uma ou mais
• Instâncias do Azure OpenAI: várias
• Subscrições: uma
• Regiões: uma

Casos de uso de topologia para várias instâncias em uma única região e uma única assinatura

Uma topologia que inclui várias instâncias do Azure OpenAI em uma única região e uma única assinatura dá suporte aos seguintes casos de uso:

• Permite limites de segmentação de segurança, como chave ou RBAC por cliente

• Permite um modelo de chargeback fácil para diferentes clientes

• Permite uma estratégia de failover para a disponibilidade do Azure OpenAI, como uma interrupção da plataforma que afeta uma instância específica, uma configuração incorreta de rede ou uma implantação excluída acidentalmente

• Permite uma estratégia de failover para a disponibilidade de cota do Azure OpenAI, como o emparelhamento de uma instância baseada em PTU e uma instância baseada em consumo para spillover

Introduzir um gateway para várias instâncias em uma única região e assinatura

Um modelo pode não estar acessível a um cliente por vários motivos. Esses motivos incluem interrupções no Serviço OpenAI do Azure, solicitações de limitação do Azure OpenAI ou problemas relacionados a operações de carga de trabalho, como configuração incorreta de rede ou exclusão inadvertida de uma implantação de modelo. Para enfrentar esses desafios, você deve implementar a lógica de repetição e quebra de circuito.

Essa lógica pode ser implementada em clientes ou no lado do servidor em um gateway. A implementação da lógica em um gateway abstrai a lógica dos clientes, resultando em nenhum código repetido e um único local para testar a lógica. Não importa se você possui o código do cliente ou não, essa mudança pode aumentar a confiabilidade da carga de trabalho.

A utilização de um gateway com várias instâncias do Azure OpenAI em uma única região e assinatura permite tratar todos os back-ends como implantações ativas-ativas e não apenas usá-las em failovers ativo-passivo. Você pode implantar o mesmo modelo baseado em PTU em várias instâncias do Azure OpenAI e usar o gateway para balancear a carga entre elas.

Uma opção que uma equipe de carga de trabalho tem ao provisionar o Azure OpenAI é decidir se o modelo de cobrança e taxa de transferência é baseado em PTU ou em consumo. Uma estratégia de otimização de custos para evitar desperdício por meio de PTU não utilizada é provisionar ligeiramente a instância de PTU e também implantar uma instância baseada em consumo ao lado dela. O objetivo com essa topologia é fazer com que os clientes primeiro consumam toda a PTU disponível e, em seguida, "explodam" para a implantação baseada em consumo para excessos. Essa forma de failover planejado se beneficia do mesmo motivo mencionado no parágrafo de abertura desta seção: manter essa complexidade fora do código do cliente.

Quando um gateway está envolvido, ele está em uma posição exclusiva para capturar detalhes sobre todas as implantações de modelo com as quais os clientes estão interagindo. Embora cada instância do Azure OpenAI possa capturar sua própria telemetria, fazer isso dentro do gateway permite que a equipe de carga de trabalho publique telemetria e respostas de erro em todos os modelos consumidos em um único armazenamento, o que facilita o painel unificado e o alerta.

Dicas para várias instâncias em uma única região e topologia de assinatura

• Verifique se o gateway está usando as Retry-After informações disponíveis na resposta HTTP do Azure OpenAI ao dar suporte a cenários de failover no gateway. Use essas informações confiáveis para controlar a implementação do disjuntor. Não bata continuamente em um ponto de extremidade que retorna um 429 Too Many Requestsarquivo . Em vez disso, quebre o circuito para essa instância de modelo.

• Tentar prever eventos de limitação antes que eles aconteçam, rastreando o consumo do modelo por meio de solicitações anteriores, é possível no gateway, mas está repleto de casos de borda. Na maioria dos casos, é melhor não tentar prever, mas usar códigos de resposta HTTP para orientar futuras decisões de roteamento.

• Ao fazer round-robining ou failover para um endpoint diferente, incluindo PTU transbordando para o consumo, sempre certifique-se de que esses endpoints estão usando o mesmo modelo na mesma versão. Por exemplo, não faça failover de gpt-4 ou para gpt-35-turbo a versão X para a versão X+1 ou balanceie de carga entre elas. Essa alteração de versão pode causar um comportamento inesperado nos clientes.

• O balanceamento de carga e a lógica de failover são implementáveis nas políticas de Gerenciamento de API do Azure. Você pode fornecer uma abordagem mais sofisticada usando uma solução de gateway baseada em código, mas o Gerenciamento de API é suficiente para esse caso de uso.

• Implante seu gateway na mesma região que a instância do Azure OpenAI.

• Implante o gateway em um grupo de recursos dedicado na assinatura separada das instâncias do Azure OpenAI. Ter o gateway isolado dos back-ends pode ajudar a conduzir uma abordagem APIOps por meio de separações de preocupação.

• Coloque todos os pontos de extremidade privados Private Link da instância do Azure OpenAI em uma única sub-rede na rede virtual do gateway. Aplique as regras do NSG a essa sub-rede para permitir apenas o acesso do gateway a esses pontos de extremidade privados. Todos os outros acessos de plano de dados às instâncias do Azure OpenAI devem ser proibidos.

• Para simplificar a lógica no código de roteamento do gateway, use o mesmo nome de implantação do modelo para minimizar a diferença entre as rotas HTTP. Por exemplo, o nome gpt4-v1 do modelo pode ser usado em todas as instâncias com balanceamento de carga ou transbordamento, seja com base no consumo ou na PTU.

Razões para evitar um gateway para várias instâncias em uma única região e assinatura

Um gateway em si não melhora a capacidade de estorno de modelos em clientes diferentes para essa topologia específica. Nessa topologia, os clientes poderiam ter acesso às suas próprias instâncias dedicadas do Azure OpenAI, o que daria suporte à capacidade da sua equipe de carga de trabalho de executar chargeback ou showback. Esse modelo suporta identidade exclusiva e perímetros de rede, portanto, um gateway não precisaria ser introduzido especificamente para segmentação.

Se você tiver alguns clientes na área onde controla o código e os clientes forem facilmente atualizáveis, a lógica que você teria que criar no gateway poderia ser adicionada diretamente ao código. Considere usar a abordagem de gateway para failover ou balanceamento de carga principalmente quando você não possui o código do cliente ou a complexidade é demais para os clientes lidarem.

Várias instâncias do Azure OpenAI em uma única região em várias assinaturas

Detalhes da topologia para várias instâncias do Azure OpenAI em uma única região em várias assinaturas

• Implantações de modelo OpenAI do Azure: uma ou mais
• Instâncias do Azure OpenAI: várias
• Subscrições: múltiplas
• Regiões: uma

Casos de uso de topologia para várias instâncias do Azure OpenAI em uma única região em várias assinaturas

Uma topologia que inclui várias instâncias do Azure OpenAI em uma única região em várias assinaturas dá suporte aos seguintes casos de uso:

• Inclui todos os casos de uso listados para várias instâncias do Azure OpenAI em uma única região e uma única assinatura.

• Permite obter mais cotas baseadas no consumo, uma vez que o limite de assinatura é um fator disponível para o modelo de consumo. Você pode usar essa cota extra para dar suporte ao consumo altamente simultâneo.

Introduzir um gateway para várias instâncias em uma única região e várias assinaturas

Os mesmos motivos abordados em Introduzir um gateway para várias instâncias em uma única região e assinatura se aplicam a essa topologia.

Além desses motivos, adicionar um gateway nessa topologia também dá suporte a uma equipe centralizada que fornece um modelo "Azure OpenAI as a service" para sua organização. Como uma cota baseada em consumo é vinculada à assinatura, uma equipe centralizada que fornece serviços do Azure OpenAI que usam o modelo baseado em consumo deve implantar instâncias do Azure OpenAI em várias assinaturas para obter a cota necessária. A lógica de entrada continua a ser praticamente a mesma.

Dicas para várias instâncias em uma única região e topologia de várias assinaturas

• Idealmente, todas as assinaturas devem ser apoiadas com o mesmo locatário do Microsoft Entra ID para dar suporte à consistência no RBAC do Azure e na Política do Azure.

• Implante seu gateway na mesma região que a instância do Azure OpenAI.

• Implante o gateway em uma assinatura dedicada separada das instâncias do Azure OpenAI. Isso ajuda a impor uma consistência no endereçamento das instâncias do Azure OpenAI e fornece uma segmentação lógica de tarefas entre as implantações do Azure OpenAI e seu roteamento.

• Ao rotear solicitações do seu gateway entre assinaturas, certifique-se de que os pontos de extremidade privados estejam acessíveis. Você pode usar o roteamento transitivo através de um hub para pontos de extremidade privados para os back-ends em seus respetivos raios. Talvez você consiga expor pontos de extremidade privados para os serviços do Azure OpenAI diretamente na assinatura do gateway usando conexões de Link Privado entre assinaturas. As ligações de ligação privada entre subscrições são preferidas se a sua arquitetura e organização suportarem esta abordagem.

Razões para evitar um gateway para várias instâncias em uma única região e várias assinaturas

Todos os motivos para evitar um gateway para várias instâncias em uma única região e assinatura se aplicam a essa topologia.

Várias instâncias do Azure OpenAI em várias regiões

Detalhes da topologia para várias instâncias do Azure OpenAI em várias regiões

• Implantações de modelo OpenAI do Azure: várias
• Instâncias do Azure OpenAI: várias
• Subscrições: uma ou mais
• Regiões: múltiplas

Casos de uso de topologia para várias instâncias do Azure OpenAI em várias regiões

Uma topologia que inclui várias instâncias do Azure OpenAI espalhadas por duas ou mais regiões do Azure dá suporte aos seguintes casos de uso:

• Inclui todos os casos de uso listados para várias instâncias do Azure OpenAI em uma única região em várias assinaturas.

• Permite uma estratégia de failover para disponibilidade de serviço, como o uso de pares entre regiões.

• Permite um design de residência e conformidade de dados.

• Permite a disponibilidade de modelos mistos. Algumas regiões têm modelos diferentes e quotas diferentes disponíveis para os modelos.

Embora tecnicamente não sejam diferentes regiões do Azure, essa topologia também é aplicável quando você tem um modelo de IA exposto em uma situação de prevenção cruzada, como no local ou em outra nuvem.

Introduzir um gateway para várias instâncias em várias regiões

Para arquiteturas críticas para os negócios que precisam sobreviver a uma interrupção regional completa, um gateway global e unificado ajuda a eliminar a lógica de failover do código do cliente. Essa implementação exige que o gateway não seja afetado por uma interrupção regional.

O balanceamento de carga entre regiões não é típico, mas pode ser usado estrategicamente para combinar cotas disponíveis em implantações baseadas no consumo entre regiões. Esse cenário não exige que o gateway não seja afetado por uma interrupção regional, mas o recomendamos para máxima confiabilidade da carga de trabalho.

Usar o Gerenciamento de API do Azure (implantação de região única)

Nessa topologia, o Gerenciamento de API do Azure é usado especificamente para a tecnologia de gateway. Aqui, o Gerenciamento de API é implantado em uma única região. A partir dessa instância de gateway, você executa o balanceamento de carga ativo-ativo entre regiões. As políticas em seu gateway fazem referência a todas as instâncias do Azure OpenAI. O gateway requer linha de visão de rede para cada back-end entre regiões, seja por meio de emparelhamento de rede virtual entre regiões ou pontos de extremidade privados. As chamadas desse gateway para uma instância do Azure OpenAI em outra região incorrem em mais latência de rede e encargos de saída.

Seu gateway deve respeitar os sinais de limitação e disponibilidade das instâncias do Azure OpenAI e remover back-ends com falha do pool até que seja seguro adicionar novamente a instância do Azure OpenAI com falha ou limitada. O gateway deve repetir a solicitação atual contra outra instância de back-end no pool em caso de falha, antes de retornar um erro de gateway. A verificação de integridade do gateway deve sinalizar não íntegro quando nenhuma instância back-end do Azure OpenAI estiver disponível.

Como essa topologia introduz um único ponto de falha (o gateway), a utilidade dessa arquitetura específica é bastante limitada. Esse modelo se presta bem ao faturamento baseado no consumo no Azure OpenAI quando a previsão de alocação de PTU pode ser muito desafiadora.

Variante ativo-passivo

Esse modelo também pode ser usado para fornecer uma abordagem ativo-passivo para lidar especificamente com falhas regionais apenas do Azure OpenAI. Nesse modo, o tráfego normalmente flui do gateway para a instância do Azure OpenAI na mesma região que o serviço de gerenciamento de API. Essa instância do Azure OpenAI lidaria com todo o fluxo de tráfego esperado sem a ocorrência de falhas regionais. Pode ser baseado em PTU ou em consumo, dependendo do seu modelo de faturamento preferido. No caso de uma falha regional apenas do Azure OpenAI, o gateway pode redirecionar o tráfego para outra região com o Azure OpenAI já implantado no modo de consumo.

Usar o Gerenciamento de API do Azure (implantação em várias regiões)

Para melhorar a confiabilidade da arquitetura anterior baseada em Gerenciamento de API do Azure, o Gerenciamento de API dá suporte à implantação de uma instância em várias regiões do Azure. Essa opção de implantação oferece um único plano de controle, por meio de uma única instância de Gerenciamento de API, mas fornece gateways replicados nas regiões de sua escolha. Nessa topologia, você implanta componentes de gateway em cada região que contém instâncias do Azure OpenAI que fornecem uma arquitetura de gateway ativo-ativo.

Políticas como roteamento e lógica de tratamento de solicitações são replicadas para cada gateway individual. Toda a lógica de política deve ter lógica condicional na política para garantir que você esteja chamando instâncias do Azure OpenAI na mesma região do gateway atual. Para obter mais informações, consulte Rotear chamadas de API para serviços back-end regionais. Em seguida, o componente de gateway requer linha de visão de rede apenas para instâncias do Azure OpenAI em sua própria região, geralmente por meio de pontos de extremidade privados.

O Gerenciamento de API oferece roteamento FQDN (nome de domínio totalmente qualificado) global pronto para uso com base na latência mais baixa. Use essa funcionalidade interna baseada em desempenho para implantações de gateway ativo-ativo. Essa funcionalidade integrada ajuda a resolver o desempenho e lida com uma interrupção de gateway regional. O roteador global integrado também suporta testes de recuperação de desastres, pois as regiões podem ser simuladas por meio da desativação de gateways individuais. Certifique-se de que os clientes respeitem o TTL no FQDN e tenham uma lógica de repetição apropriada para lidar com um failover de DNS recente.

Se você precisar introduzir um firewall de aplicativo Web (WAF) nessa arquitetura, ainda poderá usar a solução de roteamento FQDN interna como a origem de back-end para seu roteador global que implementa o WAF. O roteador global delegaria a responsabilidade de failover ao Gerenciamento de API. Como alternativa, você pode usar os FQDNs do gateway regional como membros do pool de back-end. Nessa última arquitetura, use o ponto de extremidade interno em /status-0123456789abcdef cada gateway regional ou outro ponto de extremidade de API de integridade personalizado para dar suporte ao failover regional. Se não tiver certeza, comece com a abordagem FQDN de back-end de origem única.

Essa arquitetura funciona melhor se você puder tratar as regiões como totalmente disponíveis ou totalmente indisponíveis. Isso significa que, se o gateway de Gerenciamento de API ou a instância do Azure OpenAI não estiver disponível, você desejará que o tráfego do cliente não seja mais roteado para o gateway de Gerenciamento de API nessa região. A menos que outra provisão seja feita, se o gateway regional ainda aceitar tráfego enquanto o Azure OpenAI não estiver disponível, o erro deverá ser propagado para o cliente. Para evitar o erro do cliente, consulte uma abordagem aprimorada em Active-active gateway plus active-passive Azure OpenAI variant.

Se uma região estiver passando por uma interrupção do gateway de Gerenciamento de API ou for sinalizada como não íntegra, as regiões disponíveis restantes precisarão absorver 100% do tráfego dessas outras regiões. Isso significa que você precisa provisionar demais instâncias do Azure OpenAI baseadas em PTU para lidar com a nova explosão de tráfego ou usar uma abordagem ativo-passivo para failover. Use a calculadora de capacidade do Azure OpenAI para planejamento de capacidade.

Certifique-se de que o grupo de recursos que contém o Gerenciamento de API do Azure seja o mesmo local que a própria instância de Gerenciamento de API para reduzir o raio de explosão de uma interrupção regional relacionada que afeta sua capacidade de acessar o provedor de recursos para seus gateways.

Gateway ativo-ativo mais variante do Azure OpenAI ativo-passivo

A seção anterior aborda a disponibilidade do gateway fornecendo uma topologia de gateway ativo-ativo. Essa topologia combina o gateway ativo-ativo com uma topologia econômica do Azure OpenAI ativo-passivo. Adicionar lógica ativo-passiva ao gateway para failover em uma implantação do Azure OpenAI baseada em consumo a partir de uma implantação baseada em PTU pode aumentar significativamente a confiabilidade da carga de trabalho. Esse modelo ainda permite que os clientes usem a solução de roteamento FQDN integrada do Gerenciamento de API para roteamento baseado em desempenho.

Usar um gateway codificado personalizado

Se suas regras de roteamento por gateway forem muito complexas para sua equipe considerar razoáveis como políticas de Gerenciamento de API, você precisará implantar e gerenciar sua própria solução. Essa arquitetura deve ser uma implantação de várias regiões do seu gateway, com uma unidade de escala altamente disponível por região. Você precisa fazer frente a essas implantações com o Azure Front Door (Anycast) ou o Azure Traffic Manager (DNS), normalmente usando roteamento baseado em latência e verificações de integridade apropriadas da disponibilidade do gateway.

Use o Azure Front Door se precisar de um WAF e acesso público à Internet. Use o Gerenciador de Tráfego se você não precisar de um WAF e DNS TTL for suficiente. Ao frontar suas instâncias de gateway com o Azure Front Door (ou qualquer proxy reverso), certifique-se de que o gateway não possa ser ignorado. Disponibilize as instâncias de gateway somente por meio de ponto de extremidade privado quando você usar o Azure Front Door e adicionar a X_AZURE_FDID validação do cabeçalho HTTP em sua implementação de gateway.

Coloque os recursos por região que são usados em seu gateway personalizado em grupos de recursos por região. Isso reduz o raio de explosão de uma interrupção regional relacionada, afetando sua capacidade de acessar o provedor de recursos para seus recursos de gateway nessa região.

Você também pode considerar a antecipação da implementação da lógica do gateway com o Gerenciamento de API, para obter os outros benefícios do Gerenciamento de API, como TLS, autenticação, verificação de integridade ou balanceamento de carga round-robin. Isso desloca as preocupações comuns da API para fora do código personalizado em seu gateway e permite que seu gateway aborde especificamente a instância do Azure OpenAI e o roteamento de implantação de modelo.

Para conformidade com a residência de dados, certifique-se de que cada limite geopolítico tenha sua própria implantação isolada dessa arquitetura e que os clientes só possam alcançar seu ponto de extremidade autorizado.

Razões para evitar um gateway para várias instâncias em várias regiões

Não implemente um gateway unificado em regiões geopolíticas quando a residência e a conformidade de dados forem necessárias. Fazer isso violaria os requisitos de residência de dados. Use gateways endereçáveis individualmente por região e siga as orientações em uma das seções anteriores.

Se não for esperado que os clientes façam failover entre regiões e você tiver a capacidade de fornecer aos clientes um gateway específico para usar, use vários gateways, um por região, e siga as orientações em uma das seções anteriores. Não vincule a disponibilidade de outras regiões à região que contém seu gateway como um único ponto de falha.

Não implemente um gateway unificado se o modelo e a versão não estiverem disponíveis em todas as regiões expostas pelo gateway. Os clientes precisam ser roteados para o mesmo modelo e a mesma versão do modelo. Para gateways de failover e balanceamento de carga de várias regiões, você precisa escolher um modelo comum e uma versão do modelo que esteja disponível em todas as regiões envolvidas. Para obter mais informações, consulte Disponibilidade do modelo. Se você não puder padronizar o modelo e a versão do modelo, o benefício do gateway será limitado.

Recomendações gerais

Não importa qual topologia sua carga de trabalho precisa, há algumas recomendações transversais a serem consideradas ao criar sua solução de gateway.

Interações com estado

Quando os clientes usam os recursos stateful do Azure OpenAI, como a API de Assistentes, você precisa configurar seu gateway para fixar um cliente em um back-end específico durante essa interação. Isso pode ser feito armazenando dados de instância em um cookie. Nesses cenários, considere retornar uma resposta da API do Azure OpenAI como uma 429 para um cliente fixo em vez de redirecioná-los para uma instância diferente do Azure OpenAI. Isso permite que o cliente manipule explicitamente a indisponibilidade repentina em vez de ocultá-la e ser roteado para uma instância de modelo que não tem histórico.

Verificações de integridade do gateway

Há duas perspetivas de verificação de integridade a serem consideradas, independentemente da topologia.

Se o gateway for criado em torno do round-robining ou da execução estrita do failover de disponibilidade do serviço, você deseja uma maneira de retirar uma instância (ou modelo) do Azure OpenAI do status de disponibilidade. O Azure OpenAI não fornece nenhum tipo de ponto de extremidade de verificação de integridade para saber preventivamente se ele está disponível para lidar com solicitações. Você pode enviar transições sintéticas, mas isso consome a capacidade do modelo. A menos que você tenha outra fonte de sinal confiável para a instância do Azure OpenAI e a disponibilidade do modelo, seu gateway provavelmente deve assumir que a instância do Azure OpenAI está ativa e, em seguida, manipular 429, 500, 503 códigos de status HTTP como um sinal para quebra de circuito para solicitações futuras nessa instância ou modelo por algum tempo. Para situações de limitação, sempre respeite os dados no cabeçalho encontrados nas respostas da Retry-After API do Azure OpenAI para 429 códigos de resposta em sua lógica de quebra de circuito. Se você estiver usando o Gerenciamento de API do Azure, avalie usando a funcionalidade interna de disjuntor .

Seus clientes ou sua equipe de operações de carga de trabalho podem desejar ter uma verificação de integridade exposta em seu gateway para seus próprios fins de roteamento ou introspeção. Se você usar o Gerenciamento de API, o padrão /status-0123456789abcdef pode não ser detalhado o suficiente, pois aborda principalmente a instância do gateway de Gerenciamento de API, não seus back-ends. Considere adicionar uma API de verificação de integridade dedicada que possa retornar dados significativos para clientes ou sistemas de observabilidade sobre a disponibilidade do gateway ou rotas específicas no gateway.

Práticas de implementação segura

Você pode usar implementações de gateway para orquestrar implantações azul-verde de modelos atualizados. Os modelos do Azure OpenAI são atualizados com novas versões de modelo e novos modelos, e você pode ter novos modelos ajustados.

Depois de testar os efeitos de uma alteração na pré-produção, avalie se os clientes de produção devem ser "cortados" para a nova versão do modelo ou, em vez disso, deslocar o tráfego. O padrão de gateway descrito anteriormente permite que o back-end tenha ambos os modelos implantados simultaneamente. A implantação simultânea de modelos dá ao gateway o poder de redirecionar o tráfego com base na prática segura de implantação incremental da equipe de carga de trabalho.

Mesmo que você não use implantações azul-verde, a abordagem APIOps da sua carga de trabalho precisa ser definida e suficientemente automatizada com a taxa de alteração de suas implantações de modelo e instância de back-end.

Apenas implementação suficiente

Muitos dos cenários introduzidos neste artigo ajudam a aumentar o potencial objetivo de nível de serviço (SLO) de sua carga de trabalho, reduzindo a complexidade do cliente e implementando técnicas confiáveis de autopreservação. Outros melhoram a segurança da carga de trabalho movendo os controles de acesso para modelos específicos do Azure OpenAI. Certifique-se de que a introdução do gateway não acabe indo contra esses objetivos. Compreenda os riscos de adicionar um novo ponto único de falha por falhas de serviço ou problemas de configuração causados por humanos no gateway, lógica de roteamento complexa ou os riscos de expor mais modelos a clientes não autorizados do que o pretendido.

Soberania dos dados

As várias abordagens ativo-ativo e ativo-passivo precisam ser avaliadas de uma perspetiva de conformidade de residência de dados para sua carga de trabalho. Muitos desses padrões seriam aplicáveis à arquitetura da sua carga de trabalho se as regiões envolvidas permanecessem dentro dos limites geopolíticos. Para dar suporte a esse cenário, você precisa tratar os limites geopolíticos como selos isolados e aplicar o tratamento ativo-ativo ou ativo-passivo exclusivamente dentro desse carimbo.

Em particular, qualquer roteamento baseado em desempenho precisa ser altamente examinado quanto à conformidade com a soberania de dados. Em cenários de soberania de dados, você não pode atender clientes com outra geografia e permanecer em conformidade. Todas as arquiteturas de gateway que envolvem residência de dados devem impor que os clientes usem apenas pontos de extremidade em sua região geopolítica. Os clientes devem ser impedidos de usar outros pontos de extremidade de gateway e o gateway em si não viola a confiança do cliente ao fazer uma solicitação geopolítica cruzada. A maneira mais confiável de implementar essa segmentação é construir sua arquitetura em torno de um gateway totalmente independente e altamente disponível por região geopolítica.

Autorização do Azure OpenAI

O gateway precisa se autenticar com todas as instâncias do Azure OpenAI com as quais ele faz interface. A menos que você tenha projetado o gateway para fazer autenticação de passagem, o gateway deve usar uma identidade gerenciada para suas credenciais. Portanto, cada instância do Azure OpenAI precisa configurar o RBAC menos privilegiado para as identidades gerenciadas dos gateways. Para arquiteturas ativo-ativo e de failover, verifique se a identidade do gateway tem permissões equivalentes em todas as instâncias envolvidas do Azure OpenAI.

Azure Policy

A consistência entre implantações de modelo e instâncias do Azure OpenAI é importante em situações ativas-ativas ou ativas-passivas. Use a Política do Azure para ajudar a impor a consistência entre as várias instâncias ou implantações de modelo do Azure OpenAI. Se as políticas internas do Azure OpenAI não forem suficientes para garantir a consistência entre elas, considere criar ou usar políticas personalizadas criadas pela comunidade.

Redundância de gateway

Embora não seja específica para vários back-ends, a implementação do gateway de cada região deve sempre ser construída com redundância e estar altamente disponível dentro da unidade de escala. Escolha regiões com zonas de disponibilidade e certifique-se de que seu gateway esteja espalhado por elas. Implante várias instâncias do gateway para que um único ponto de falha seja limitado a uma interrupção regional completa e não à falha de uma única instância de computação em seu gateway. Para o Gerenciamento de API, implante duas ou mais unidades em duas ou mais zonas. Para implementações de código personalizado, implante pelo menos três instâncias com melhor distribuição de esforço entre zonas de disponibilidade.

Implementações de gateway

O Azure não oferece uma solução turn-key ou arquitetura de referência para criar esse gateway. Como mencionado no artigo de introdução, sua equipe de carga de trabalho deve criar e operar esse gateway. A seguir estão alguns exemplos de implementações de exemplo suportadas pela comunidade que abrangem alguns dos casos de uso mencionados anteriormente. Considere fazer referência a esses exemplos do GitHub ao criar sua própria prova de conceito.

Implementação	Exemplo
API Management do Azure	Balanceamento de carga inteligente para o Azure OpenAI usando o Gerenciamento de API do Azure - Este repositório GitHub contém código de política de exemplo e instruções para implantar em sua assinatura. Dimensionamento do Azure OpenAI usando o Gerenciamento de API do Azure - Este repositório GitHub contém código de política de exemplo e instruções para PTU e spillover de consumo. Há também algumas políticas de Gerenciamento de API OpenAI do Azure com suporte da comunidade disponíveis.
Código personalizado	Balanceamento de carga inteligente para o Azure OpenAI usando Aplicativos de Contêiner do Azure Este repositório GitHub contém código C# de exemplo e instruções para criar o contêiner e implantar em sua assinatura.

Próximos passos

Ter uma implementação de gateway para sua carga de trabalho oferece benefícios além do benefício tático de roteamento de back-end múltiplo descrito neste artigo. Saiba mais sobre os outros principais desafios que um gateway pode resolver.

Recursos relacionados

• Azure OpenAI Service
• Gateway de API no Gerenciamento de API do Azure
• Políticas de Gerenciamento de API do Azure OpenAI