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

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

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

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

Essas topologias por si só não exigem o uso de um gateway. A escolha de um gateway depende de ser bom ou não para a carga de trabalho a sua inclusão na arquitetura. Este artigo descreve os desafios que cada uma das quatro topologias e das vantagens e custos da inclusão de um gateway em cada topologia.

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

Detalhes de topologia para várias implantações de modelos

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

Casos de uso de topologia para várias implantações de modelo

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

• Expor diferentes recursos do modelo, como gpt-35-turbo, gpt-4 e modelos detalhados personalizados.

• Expor diferentes versões de modelo, como 0613, 1106 e modelos detalhados personalizados para oferecer suporte à evolução da carga de trabalho ou implantações azuis/verdes.

• Expor diferentes cotas atribuídas (30.000 Tokens por Minuto (TPM), 60.000 TPM) para oferecer suporte à limitação de consumo em vários clientes.

Introduzir um gateway para várias implantações de modelo

A introdução de um gateway nessa topologia tem como objetivo principal evitar que clientes precisem por si só selecionem 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. Ele 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 na implantação de um novo modelo ajustado ou ao ir da versão X para X+1 do mesmo modelo.

O gateway também pode ser usado como um único ponto de entrada da 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, os roteiros para o modelo do locatário seriam 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 princípios de serviço distintos do Microsoft Entra, os logs de acesso do OpenAI do Azure não seriam capazes de distinguir vários clientes. Ter um gateway na frente da implantação dá à sua carga de trabalho uma oportunidade de controlar o uso por cliente em várias implantações de modelo disponíveis com o objetivo de oferecer suporte a modelos de estorno ou showback.

Dicas para a topologia de várias implantações de modelo

• Embora o gateway esteja em posição de mudar completamente qual modelo está sendo usado, como gpt-35-turbo para gpt-4, essa mudança provavelmente seria considerada uma mudança de ruptura para o cliente. Não deixe que os novos recursos funcionais do gateway distraiam você de sempre realizar as práticas de implantação seguras dessa carga de trabalho.

• A topologia geralmente é simples de implementar por meio da política de API Management do Azure em vez de uma solução de código personalizado.

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

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

• Se o gateway for projetado para usar credenciais de passagem, certifique-se de que 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 OpenAI do Azure.

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

• Implante o gateway em uma rede virtual que contém uma sub-rede para o ponto de extremidade privado do link privado da instância do OpenAI do Azure. 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 OpenAI do Azure 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 os roteiros no nível do gateway, o impacto adicional de confiabilidade, segurança, custo, manutenção e desempenho do gateway pode não valer 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 OpenAI do Azure. Por exemplo, considere várias instâncias do OpenAI do Azure se você tiver vários clientes que devem usar RBAC ou chaves de acesso diferentes para acessar seu modelo. Usar várias implantações em uma única instância do OpenAI do Azure 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 OpenAI do Azure.

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

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

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

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

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

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

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

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

• Habilita uma estratégia de failover para a disponibilidade de cota do OpenAI do Azure, como emparelhar 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 OpenAI do Azure ou problemas relacionados a operações de carga de trabalho, como configuração incorreta de rede ou uma exclusão por acidente 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 no lado do cliente ou 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.

Utilizar um gateway com várias instâncias do OpenAI do Azure em uma única região e assinatura permite que você trate todos os back-ends como implantações ativas-ativas e não apenas para uso em failovers ativos-passivos. Você pode implantar o mesmo modelo baseado em PTU em várias instâncias do OpenAI do Azure e usar o gateway para equilibrar a carga entre elas.

Uma opção que uma equipe de carga de trabalho tem ao provisionar o OpenAI do Azure é decidir se o modelo de cobrança e de produção é baseado em PTU ou consumo. Uma estratégia de otimização de custos para evitar desperdício por meio de PTU não utilizado é provisionar ligeiramente para baixo a instância de PTU e também implantar como auxílio uma instância baseada em consumo. O objetivo com essa topologia é fazer com que os clientes consumam primeiro todos os PTU disponíveis e só depois "partam" para a implantação baseada em consumo para o excesso de consumo. O benefício para essa forma de recuperação planejada é o mesmo mencionado no parágrafo inicial desta seção: não colocar essa complexidade no código do cliente.

Quando um gateway está envolvido, ele se encontra 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 OpenAI do Azure possa capturar sua própria telemetria, fazer isso no 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 a unificação de painéis e emissão de alertas.

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

• Verifique se o gateway está usando as informações de Retry-After disponíveis na resposta HTTP do OpenAI do Azure ao dar suporte a cenários de failover no gateway. Essas informações confiáveis devem ser usadas para controlar a implementação da quebra de circuito. Não acesse continuamente um ponto de extremidade que retorne um 429 Too Many Requests. Em vez disso, quebre o circuito para essa instância de modelo.

• A tentativa de prever eventos de limitação antes que aconteçam rastreando o consumo do modelo por meio de solicitações anteriores é possível no gateway, mas essa situação leva a vários casos extremos. Na maioria dos casos, é melhor não tentar prever, mas usar códigos de resposta HTTP para direcionar decisões futuras de roteamento.

• Ao executar round-robin ou failover em um ponto de extremidade diferente, incluindo PTU que afeta o consumo, sempre se certifique de que esses endpoints estejam usando o mesmo modelo na mesma versão. Por exemplo, não execute failover de gpt-4 para gpt-35-turbo ou da versão X para a versão X+1 ou balanceamento de carga entre eles. 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 API Management do Azure. Talvez você possa fornecer uma abordagem mais sofisticada usando uma solução de gateway baseada em código, mas o API Management é suficiente para esse caso de uso.

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

• Implante o gateway em um grupo de recursos dedicado na assinatura separada das instâncias do OpenAI do Azure. Isolar o gateway dos back-ends pode ajudar a impulsionar uma abordagem APIOps por meio de separações que devem ser consideradas.

• Coloque todos os pontos de extremidade privados do link privado da instância do OpenAI do Azure em uma única sub-rede na rede virtual do gateway. Aplique as regras 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 OpenAI do Azure devem ser proibidos.

• Para simplificar a lógica no código de roteiros do gateway, use o mesmo nome de implantação de modelo para minimizar a diferença entre as rotas HTTP. Por exemplo, o nome do modelo gpt4-v1 pode ser usado em todas as instâncias com balanceamento de carga ou excedentes, independentemente de ser baseado em consumo ou em 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 modelos de estorno em relação a clientes diferentes para essa topologia específica. Nessa topologia, os clientes poderiam ter acesso a suas próprias instâncias dedicadas do OpenAI do Azure, o que daria suporte à capacidade da sua equipe de carga de trabalho de realizar um estorno ou apresentação de despesas. Esse modelo oferece suporte a perímetros de rede e identidade exclusivos, portanto, um gateway não precisaria ser introduzido especificamente para segmentação.

Se você tiver alguns clientes na área em que você 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 tiver o código do cliente ou quando a complexidade for demais para os clientes lidarem.

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

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

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

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

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

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

• Permite obter mais cotas baseadas no consumo, já que o limite de assinatura é um fator disponível para o modelo de consumo. Você pode usar essa cota adicional para dar suporte a um 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 a essa topologia também dá suporte a uma equipe centralizada que fornece um modelo "OpenAI do Azure como serviço" para sua organização. Como uma cota baseada em consumo é vinculada à assinatura, uma equipe centralizada que fornece serviços OpenAI do Azure que usam o modelo baseado em consumo deve implantar instâncias do OpenAI do Azure em várias assinaturas para obter a cota necessária. A lógica do gateway ainda permanece praticamente a mesma.

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

• O ideal é que todas as assinaturas sejam apoiadas pelo mesmo locatário do Microsoft Entra para dar suporte à consistência no RBAC do Azure e na Azure Policy.

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

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

• Ao fazer roteiros de solicitações do seu gateway entre assinaturas, certifique-se de que os pontos de extremidade privados estejam acessíveis. Você pode usar o roteiro transitivo por meio de um hub para pontos de extremidade privados para os back-ends em seus respectivos raios. Você pode expor pontos de extremidade privados para os serviços do OpenAI do Azure diretamente na assinatura do gateway usando Conexões de link privado entre assinaturas. As conexões de Link Privado entre assinaturas são preferíveis se sua arquitetura e organização oferecessem suporte a essa 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 OpenAI do Azure em várias regiões

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

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

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

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

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

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

• Habilita uma residência de dados e um design de conformidade.

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

Embora tecnicamente não sejam regiões do Azure diferentes, essa topologia também é aplicável quando você tem um modelo de IA exposto em uma situação de premissa 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 requer que o gateway não seja afetado por uma interrupção regional.

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

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

Nessa topologia, o API Management do Azure é usado especificamente para a tecnologia de gateway. Aqui, o API Management é 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 OpenAI do Azure. O gateway requer linha de visão de rede para cada back-end entre regiões, por meio de emparelhamento de rede virtual entre regiões ou pontos de extremidade privados. As chamadas desse gateway para instância do OpenAI do Azure em outra região incorrem em mais latência de rede e encargos de saída.

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

Como essa topologia introduz um único ponto de falha (o gateway), a utilidade dessa arquitetura específica é bastante limitada. Esse modelo é adequado para a cobrança baseada em consumo no OpenAI do Azure ao prever que a alocação de PTU pode ser muito desafiadora.

Variante ativa-passiva

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

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

Para melhorar a confiabilidade da arquitetura anterior baseada na API Management do Azure, a API Management oferece 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 do API Management, mas oferece gateways replicados nas regiões que você escolher. Nessa topologia, você implanta componentes de gateway em cada região que contenha instâncias do OpenAI do Azure que fornecem uma arquitetura de gateway ativo-ativo.

Políticas como roteiros 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 OpenAI do Azure na mesma região que o gateway atual. Para mais informações, consulte Rotear chamadas de API para serviços de back-end regionais. O componente de gateway requer linha de visão de rede apenas para instâncias do OpenAI do Azure em sua própria região, geralmente por meio de pontos de extremidade privados.

O API Management oferece roteamento de FQDN (nome de domínio completamente qualificado) global pronto para uso com base na menor latência. Use essa funcionalidade interna baseada em desempenho para implantações de gateway ativo-ativo. Essa funcionalidade integrada ajuda a resolver o desempenho e a lidar com uma interrupção de gateway regional. O uso do roteador global integrado também oferece suporte a 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 a vida útil (TTL) no FQDN e tenham a lógica de repetição apropriada para lidar com um failover de DNS recente.

Se você precisar introduzir um firewall do aplicativo Web nessa arquitetura, ainda poderá usar a solução de roteamento FQDN interna como a origem de back-end para seu roteador global que implementa um firewall do aplicativo Web. O roteador global delegaria a responsabilidade de failover à API Management. Como alternativa, você pode usar os FQDNs de gateway regional como membros do pool de back-end. Nessa última arquitetura, use o ponto de extremidade interno /status-0123456789abcdef em cada gateway regional ou outro ponto de extremidade de API de integridade personalizado para oferecer 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 regiões como totalmente disponíveis ou totalmente indisponíveis. Isso significa que, se o gateway da API Management ou a instância do OpenAI do Azure não estiver disponível, você vai querer que o tráfego do cliente não seja mais roteado para o gateway da API Management nessa região. A menos que outra provisão seja feita, se o gateway regional ainda aceitar tráfego enquanto o OpenAI do Azure não estiver disponível, o erro deverá ser propagado para o cliente. Para evitar erros da parte do cliente, consulte uma abordagem aprimorada em Gateway ativo-ativo e variante ativa-passiva do OpenAI do Azure.

Se uma região estiver enfrentando uma interrupção do gateway da API Management 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 em excesso instâncias do OpenAI do Azure baseadas em PTU para lidar com a nova explosão de tráfego ou usar uma abordagem ativa-passiva para failover. Use a calculadora de capacidade do OpenAI do Azure para planejamento de capacidade.

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

Gateway ativo-ativo e variante ativa e passiva do OpenAI do Azure

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 ativa-passiva econômica do OpenAI do Azure. Adicionar uma lógica ativa-passiva ao gateway para failover em uma implantação do OpenAI do Azure 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 roteiros FQDN integrada do API Management para roteiros baseados em desempenho.

Usar um gateway codificado personalizado

Se suas regras de roteiros por gateway forem muito complexas para sua equipe considerar viáveis como políticas de API Management, você precisará implantar e gerenciar sua própria solução. Essa arquitetura deve ser uma implantação de várias regiões do gateway, com uma unidade de escala altamente disponível por região. Você precisa fazer o fronting dessas implantações com o Azure Front Door (Anycast) ou o Gerenciador de Tráfego do Azure (DNS), normalmente usando roteiros baseados em latência e verificações de integridade apropriadas da disponibilidade do gateway.

Use o Azure Front Door se precisar de um firewall do aplicativo Web e acesso público à Internet. Use o Gerenciador de Tráfego se você não precisar de um firewall do aplicativo Web e o TTL DNS for suficiente. Ao fazer o fronting das suas instâncias de gateway com o Azure Front Door (ou qualquer proxy reverso), verifique se o gateway não pode ser ignorado. Disponibilize as instâncias de gateway somente por meio de ponto de extremidade privado quando você usa o Azure Front Door e adicione validação do cabeçalho HTTP X_AZURE_FDID 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. Fazer 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 fazer o fronting da sua implementação de lógica de gateway com o próprio API Management, para os outros benefícios do API Management, tais como TLS, autenticação, verificação de integridade ou balanceamento de carga round-robin. Fazer isso elimina as "preocupações de API" comuns do código personalizado em seu gateway, deixando para seu gateway abordar especificamente os roteiros de implantação de modelo e instância do OpenAI do Azure.

Para conformidade de 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 entre regiões geopolíticas quando a residência de dados e a conformidade forem necessárias. 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 se faça failover entre regiões e você tiver a capacidade de fornecer aos clientes um gateway específico a ser usado, 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 seu modelo e 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 de modelo que esteja disponível em todas as regiões envolvidas. Para mais informações, consulte Disponibilidade de modelos. 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 usarem os recursos com estado do OpenAI do Azure, como a API de Assistentes, você precisará configurar seu gateway para fixar um cliente em um back-end específico durante a interação. Isso pode ser feito armazenando os dados da instância em um cookie. Nesses cenários, considere retornar uma resposta da API do OpenAI do Azure como um 429 para um cliente fixo em vez de redirecioná-lo para uma instância diferente do OpenAI do Azure. Isso permite que o cliente lide explicitamente com a indisponibilidade repentina, em vez de ocultá-la e ser roteado para uma instância de modelo que não tenha histórico.

Verificações de integridade do gateway

Há duas perspectivas de verificação de integridade que precisam ser consideradas, independentemente da topologia.

Se o seu gateway for criado em torno de round-robining ou executando estritamente o failover de disponibilidade de serviço, você vai precisar tirar uma instância (ou modelo) do OpenAI do Azure do status de disponibilidade. O OpenAI do Azure não fornece nenhum tipo de ponto de extremidade de verificação de integridade para saber preventivamente se está disponível para lidar com solicitações. Você poderia 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 disponibilidade da instância e do modelo do OpenAI do Azure, seu gateway provavelmente deve assumir que a instância do OpenAI do Azure está ativa e, em seguida, manipular códigos de status HTTP 429, 500 e 503 como um sinal para interrupção de circuito para solicitações futuras nessa instância ou modelo por um certo período. Para casos de limitação, sempre respeite os dados no cabeçalho Retry-After encontrado nas respostas da API do OpenAI do Azure para 429 códigos de resposta na sua lógica de quebra de circuito. Se você estiver usando o API Management do Azure, avalie o uso da funcionalidade de quebra de circuito integrada.

Seus clientes ou sua equipe de operações de carga de trabalho podem desejar ter uma verificação de integridade exposta no gateway para fins de roteamento ou introspecção. Se você usar a API Management, o padrão /status-0123456789abcdef pode não ser detalhado o suficiente, já que ele aborda principalmente a instância do gateway da API Management, em vez dos 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 implantação segura

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

Depois de testar os efeitos de uma alteração na pré-produção, avalie se os clientes de produção devem ser "transferidos" para a nova versão do modelo ou se é preciso mudar 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 permite ao gateway redirecionar o tráfego com base na prática de implantação segura da equipe de carga de trabalho de implantação incremental.

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

Implementação suficiente

Muitos dos cenários apresentados neste artigo ajudam a aumentar o objetivo de nível de serviço (SLO) potencial 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 longe do OpenAI do Azure. 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, além do pretendido, mais modelos a clientes não autorizados.

Soberania de dados

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

Em particular, qualquer roteamento baseado em desempenho precisa ser bastante examinado em termos de conformidade com a soberania de dados. Em cenários de soberania de dados, não é possível 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 da 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 pode violar 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 OpenAI do Azure

O gateway precisa se autenticar com todas as instâncias do OpenAI do Azure 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 OpenAI do Azure precisa configurar o RBAC com privilégios mínimos para as identidades gerenciadas dos gateways. Para arquiteturas ativo-ativo e de failover, certifique-se de que a identidade do gateway tem permissão equivalente em todas as instâncias do OpenAI do Azure envolvidas.

Azure Policy

A consistência entre implantações de modelo e instâncias do OpenAI do Azure é importante em situações ativo-ativo ou ativo-passivo. Use o Azure Policy para ajudar a impor a consistência entre as várias instâncias ou implantações de modelo do OpenAI do Azure. Se as políticas internas do OpenAI do Azure 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 de gateway de cada região deve ser sempre criada 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 seja distribuído 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 a uma falha de uma única instância de computação em seu gateway. Para o API Management, implante duas ou mais unidades em duas ou mais zonas. Para implementações de código personalizadas, implante pelo menos três instâncias com a melhor distribuição de esforço entre zonas de disponibilidade.

Implementações de gateway

O Azure não oferece uma solução pronta para uso nem uma arquitetura de referência para criar esse gateway. Conforme mencionado no artigo de introdução, sua equipe de carga de trabalho deve criar e operar esse gateway. A seguir, há alguns exemplos de implementações 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
Gerenciamento de API do Azure	Balanceamento de carga inteligente para o OpenAI do Azure usando o Azure API Management – Esse repositório do GitHub contém código de política de exemplo e instruções de implantação em sua assinatura. Dimensionamento do OpenAI do Azure usando o Azure API Management – Esse repositório do GitHub contém código de política de exemplo e instruções para PTU e excedente de consumo. O kit de ferramentas do gateway da GenAI contém exemplos de políticas de Gerenciamento de API, juntamente com uma configuração de teste de carga para testar o comportamento das políticas.
Código personalizado	Balanceamento de carga inteligente para o OpenAI do Azure usando Aplicativos de Contêiner do Azure Esse repositório do GitHub contém código C# de exemplo e instruções para criar o contêiner e implantar em sua assinatura.

Próximas etapas

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

Recursos relacionados

• Serviço OpenAI do Azure
• Gateway de API no Gerenciamento de API do Azure