複数の Azure OpenAI デプロイまたはインスタンスの前にゲートウェイを使用する

Azure OpenAI Service を含むワークロード アーキテクチャは、単一の Azure OpenAI モデル デプロイを 1 つ以上のクライアント アプリケーションで直接使用するという単純な形態にすることもできますが、すべてのワークロードをこのように単純に設計できるわけではありません。 より複雑なシナリオでは、複数のクライアント、複数の Azure OpenAI デプロイ、または複数の Azure OpenAI インスタンスなどを含むトポロジを使用します。 そのような場合は、Azure OpenAI の前にゲートウェイを導入すると、ワークロードの設計にメリットをもたらす可能性があります。

ワークロード アーキテクチャ内の要件によっては、複数の Azure OpenAI インスタンスまたはモデル デプロイで解決できます。 このような要件は、4 つの主要なトポロジに分類できます。

• 単一の Azure OpenAI インスタンスで複数のモデル デプロイを使用する
• 単一リージョンかつ単一サブスクリプション内で複数の Azure OpenAI インスタンスを使用する
• 複数のサブスクリプションにまたがる単一リージョン内で複数の Azure OpenAI インスタンスを使用する
• 複数のリージョンにまたがって複数の Azure OpenAI インスタンスを使用する

これらのトポロジだけであれば、ゲートウェイを使用する必要はありません。 ゲートウェイを選択する際は、アーキテクチャに組み込むことでワークロードにメリットが生じるかどうかを根拠として決めます。 この記事では、4 つのトポロジごとに対処する課題と、各トポロジにゲートウェイを含めることによって生じるメリットとコストについて説明します。

単一の Azure OpenAI インスタンスで複数のモデル デプロイを使用する

複数のモデル デプロイに対応するトポロジの詳細

• Azure OpenAI モデル デプロイ: 複数
• Azure OpenAI インスタンス: 1 つ
• サブスクリプション: 1 件
• リージョン: 1 つ

複数のモデル デプロイに対応するトポロジのユース ケース

単一の Azure OpenAI インスタンスを含み、同時にデプロイされた複数のモデルを格納しているトポロジは、次のようなユース ケースをサポートします。

• gpt-35-turbo や gpt-4 などのさまざまなモデル機能とカスタム微調整モデルを公開する。

• 0613 や 1106 などのさまざまなモデル バージョンとカスタム微調整モデルを公開して、ワークロードの進化やブルーグリーン デプロイをサポートする。

• 割り当てられた異なるクォータ (30,000 TPM (1 分あたりのトークン数)、60,000 TPM) を公開して、複数クライアント間での従量課金の調整をサポートする。

複数のモデル デプロイ用にゲートウェイを導入する

このトポロジにゲートウェイを導入する主な意図は、クライアントがインスタンス上の利用可能なデプロイの中から特定のモデル インスタンスを自己選択する状況を回避することです。 ゲートウェイを使用すると、クライアント コードの再デプロイやクライアント構成の変更を必要とせずに、サーバー側の制御により、クライアント要求を特定のモデルに転送できます。

ゲートウェイの使用は、クライアント コードを制御しない場合に、特に便利です。 また、ゲートウェイ ルーティング構成への変更をデプロイするよりもクライアント構成をデプロイするほうが複雑または高リスクである場合にも、メリットがあります。 モデル バージョンのブルーグリーン ロールアウト戦略に基づいて、クライアントが指定するモデルを変更する場合があります。たとえば、新しい微調整されたモデルをロールアウトする場合や、同じモデルのバージョン X から X+1 に移行する場合です。

ゲートウェイは、単一の API エントリ ポイントとしても使用できます。これにより、ゲートウェイはクライアントを識別できます。 さらに、そのクライアントの ID または HTTP 要求内のその他の情報に基づいて、プロンプトを提供するために使用されているモデル デプロイを判断できます。 たとえば、マルチテナント ソリューションでは、テナントが特定のスループットに制限される可能性があり、アーキテクチャの実装は、特定のクォータを持つテナントごとのモデル デプロイになります。 この場合、HTTP 要求内の情報に基づき、ゲートウェイの責任でテナントのモデルへのルーティングが行われます。

このトポロジでゲートウェイを使用すると、クライアントベースの使用状況の追跡が可能になります。 クライアントが個別の Microsoft Entra サービス プリンシパルを使用していない限り、Azure OpenAI のアクセス ログでは複数のクライアントを区別できません。 デプロイの前にゲートウェイを配置することで、ワークロードでは、チャージバック モデルまたはショーバック モデルをサポートするために利用できるさまざまなモデル デプロイにわたってクライアントごとの使用状況を追跡する機会が生じます。

複数のモデル デプロイ トポロジのヒント

• ゲートウェイでは、使用されているモデルを gpt-35-turbo から gpt-4 に変更するなど、完全に変更することも可能ですが、その変更はクライアントへの破壊的変更と見なされる可能性があります。 ゲートウェイの新たな機能によって、ワークロードに対する 安全なデプロイ プラクティス の常時実行が妨げられないようにしてください。

• このトポロジは通常、カスタム コード ソリューションではなく Azure API Management ポリシーを通じて簡単に実装できます。

• 公開されている Azure OpenAI API 仕様でネイティブ SDK の使用をサポートするには、Azure OpenAI API との API 互換性を維持する必要があります。 ワークロードのクライアント コードを自分のチームですべて作成していない場合は、この状況が大きな懸案事項になります。 ゲートウェイの HTTP API の設計を決定するときは、Azure OpenAI HTTP API との互換性を維持するメリットを考慮してください。

• このトポロジでは、Azure OpenAI インスタンスのパススルー クライアント資格情報 (アクセス トークンまたは API キー) が技術的にサポートされていますが、資格情報の終了と再確立の実装を強くお勧めします。 この方法を使用すると、クライアントがゲートウェイで承認され、ゲートウェイによる Azure OpenAI インスタンスへのアクセスが Azure RBAC を通じて承認されます。

• ゲートウェイがパススルー資格情報を使用するように設計されている場合は、クライアントがゲートウェイ、またはクライアントに基づくモデル制限をバイパスできないようにします。

• ゲートウェイを、Azure OpenAI インスタンスと同じリージョンにデプロイします。

• ゲートウェイを、Azure OpenAI インスタンスとは別のサブスクリプション内の専用リソース グループにデプロイします。 サブスクリプションをバックエンドから分離することで、懸念事項が分離され APIOps アプローチを推進できます。

• Azure OpenAI インスタンスの Azure Private Link プライベート エンドポイントのサブネットを含む仮想ネットワークに、ゲートウェイをデプロイします。 そのサブネットにネットワーク セキュリティ グループ (NSG) 規則を適用して、そのプライベート エンドポイントへのアクセスのみをゲートウェイに許可します。 Azure OpenAI インスタンスへの他のデータ プレーン アクセスはすべて禁止する必要があります。

複数のモデル デプロイでゲートウェイを回避する理由

クライアントの構成を制御することが、ゲートウェイ レベルでのルーティングを制御することと同程度またはそれ以上に簡単である場合、ゲートウェイによってもたらされる信頼性、セキュリティ、コスト、メンテナンス、およびパフォーマンスへの影響の増大には、アーキテクチャ コンポーネントを追加するだけの価値がない可能性があります。

また、一部のワークロード シナリオでは、複数のモデル デプロイ アプローチから複数の Azure OpenAI インスタンス デプロイ アプローチに移行することでメリットが得られる場合があります。 たとえば、複数のクライアントが、異なる RBAC またはアクセス キーを使用してモデルにアクセスする必要がある場合は、複数の Azure OpenAI インスタンスを検討します。 単一の Azure OpenAI インスタンスで複数のデプロイを使用し、ゲートウェイ レベルで論理 ID のセグメント化を処理することはできますが、個別の Azure OpenAI インスタンスを使用して物理 RBAC セグメント化アプローチを使用できる場合は、処理が過剰になる可能性があります。

単一リージョンかつ単一サブスクリプション内で複数の Azure OpenAI インスタンスを使用する

単一リージョンかつ単一サブスクリプション内で複数のインスタンスを使用するトポロジの詳細

• Azure OpenAI モデル デプロイ: 1 つ以上
• Azure OpenAI インスタンス: 複数
• サブスクリプション: 1 件
• リージョン: 1 つ

単一リージョンかつ単一サブスクリプション内で複数のインスタンスを使用するトポロジのユース ケース

単一リージョンかつ単一サブスクリプション内に複数の Azure OpenAI インスタンスを含むトポロジでは、以下のユース ケースがサポートされます。

• クライアントごとのキーや RBAC などのセキュリティ セグメント化境界を有効にする

• さまざまなクライアントに対して簡単なチャージバック モデルを有効にする

• 特定のインスタンスに影響を与えるプラットフォームの停止、ネットワークの構成ミス、誤りによるデプロイの削除など、Azure OpenAI の可用性に関するフェールオーバー戦略を有効にする

• PTU ベースのインスタンスと従量課金ベースのインスタンスの両方をスピルオーバー用にペアリングするなど、Azure OpenAI クォータの可用性に関するフェールオーバー戦略を有効にする

単一のリージョンとサブスクリプション内で複数のインスタンス用のゲートウェイを導入する

いくつかの理由により、クライアントからモデルにアクセスできない場合があります。 理由としては、Azure OpenAI Service の中断や Azure OpenAI 調整要求のほか、ネットワークの構成ミスや不注意によるモデル デプロイの削除といったワークロード操作に関連する問題が挙げられます。 これらの課題に対処するには、再試行ロジックや回路遮断ロジックを実装する必要があります。

このロジックは、ゲートウェイのクライアントまたはサーバー側に実装できます。 ゲートウェイにロジックを実装すると、ロジックがクライアントから分離されるため、コードの繰り返しがなくなり、ロジックをテストする場所が 1 か所になります。 クライアント コードを所有しているかどうかにかかわらず、この移行によってワークロードの信頼性が向上する可能性があります。

単一のリージョンとサブスクリプション内に複数の Azure OpenAI インスタンスを持つゲートウェイを使用すると、すべてのバックエンドをアクティブ/パッシブ フェールオーバーで使用できるだけでなく、アクティブ/アクティブ デプロイとして扱うことができます。 複数の Azure OpenAI インスタンスに同じ PTU ベースのモデルをデプロイし、ゲートウェイを使用してインスタンス間の負荷分散を行うことができます。

Azure OpenAI をプロビジョニングするときにワークロード チームが選択できる 1 つのオプションは、請求とスループット モデルを PTU ベースにするか従量課金ベースにするかを決定することです。 未使用の PTU による無駄を避けるためのコスト最適化戦略は、PTU インスタンスのプロビジョニングを控えめに行い、これと並行して従量課金ベースのインスタンスもデプロイすることです。 このトポロジの目標は、クライアントが最初に利用可能な PTU をすべて消費し、その後で超過分について従量課金ベースのデプロイに切り替えることです。 この形式の計画フェールオーバーには、このセクションの冒頭の段落で説明したのと同じ理由で、つまり、この複雑さをクライアント コードから排除できるというメリットがあります。

ゲートウェイが必要な場合、ゲートウェイは、クライアントが対話しているすべてのモデル デプロイに関する詳細を取得できる独自の立場になります。 Azure OpenAI のすべてのインスタンスで独自のテレメトリを取得できますが、ゲートウェイ内でこれを行うと、ワークロード チームは、使用されているすべてのモデルにわたるテレメトリとエラー応答を 1 つのストアに公開することにより、ダッシュボードとアラートの統合を容易に実現できます。

単一のリージョンとサブスクリプションのトポロジ内で複数のインスタンスを使用する場合のヒント

• ゲートウェイでフェールオーバー シナリオをサポートする場合、ゲートウェイが Azure OpenAI からの HTTP 応答で利用可能な Retry-After 情報を使用していることを確認します。 サーキット ブレーカーの実装を制御するには、この権限情報を使用します。 429 Too Many Requests を返すエンドポイントには継続的にアクセスしないでください。 その代わりに、そのモデル インスタンスの回路を遮断します。

• ゲートウェイでは、以前の要求を通じてモデルの使用を追跡して、調整イベントが発生する前に予測を試みることは可能ですが、これにはエッジ ケースが伴います。 ほとんどの場合、予測を試みるのではなく、HTTP 応答コードを使用して今後のルーティング決定を進めることをお勧めします。

• 別のエンドポイントにラウンドロビンまたはフェイルオーバーする場合 (PTU から従量課金へのスピルオーバーなど)、それらのエンドポイントで同じバージョンの同じモデルが使用されていることを常に確認してください。 たとえば、 gpt-4 から gpt-35-turbo またはバージョン X からバージョン X+1 へのフェールオーバーや、これらの間での負荷分散は行わないでください。 このバージョン変更により、クライアントで予期しない動作が発生する可能性があります。

• 負荷分散とフェールオーバー ロジックは、Azure API Management ポリシー内で実装できます。 コードベースのゲートウェイ ソリューションを使用すると、より高度なアプローチを提供できる場合がありますが、このユース ケースには API Management で十分です。

• ゲートウェイを、Azure OpenAI インスタンスと同じリージョンにデプロイします。

• ゲートウェイを、Azure OpenAI インスタンスとは別のサブスクリプション内の専用リソース グループにデプロイします。 ゲートウェイをバックエンドから分離することで、懸念事項が分離され、 APIOps アプローチを推進できます。

• すべての Azure OpenAI インスタンスの Private Link プライベート エンドポイントを、ゲートウェイの仮想ネットワーク上の単一サブネットに配置します。 そのサブネットに NSG ルールを適用して、それらのプライベート エンドポイントへのアクセスのみをゲートウェイに許可します。 Azure OpenAI インスタンスへの他のデータ プレーン アクセスはすべて禁止する必要があります。

• ゲートウェイ ルーティング コードのロジックを簡略化するには、同じモデル デプロイ名を使用して、HTTP ルート間の違いを最小限に抑えます。 たとえば、モデル名 gpt4-v1 は、従量課金ベースか PTU ベースかを問わず、すべての負荷分散インスタンスまたはスピルオーバー インスタンスで使用できます。

単一のリージョンとサブスクリプション内で複数のインスタンス用にゲートウェイを使用しないほうがよい理由

この特定のトポロジのさまざまなクライアントに対してモデルをチャージバックする機能は、ゲートウェイ自体によって向上されるわけではありません。 このトポロジでは、クライアントに専用の Azure OpenAI インスタンスへのアクセスを許可することができ、これによってワークロード チームがチャージバックまたはショーバックを実行できるようになります。 このモデルは一意の ID とネットワーク境界をサポートしているため、セグメント化のために特別にゲートウェイを導入する必要はありません。

領域内で少数のクライアントのコードを制御していて、そのクライアントを簡単に更新できる場合は、ゲートウェイに組み込む必要があるロジックをコードに直接追加できます。 主に、クライアント コードを所有していない場合や、処理が複雑すぎてクライアントできない場合は、フェールオーバーまたは負荷分散のためのゲートウェイ アプローチの使用を検討してください。

複数のサブスクリプションにまたがる単一リージョン内で複数の Azure OpenAI インスタンスを使用する

複数のサブスクリプションにまたがる単一リージョン内で複数の Azure OpenAI インスタンスを使用するトポロジの詳細

• Azure OpenAI モデル デプロイ: 1 つ以上
• Azure OpenAI インスタンス: 複数
• サブスクリプション: 複数
• リージョン: 1 つ

複数のサブスクリプションにまたがる単一リージョン内で複数の Azure OpenAI インスタンスを使用するトポロジのユース ケース

複数のサブスクリプションにまたがる単一リージョン内に複数の Azure OpenAI インスタンスを含むトポロジでは、以下のユース ケースがサポートされます。

• 単一リージョンかつ単一サブスクリプション内の複数の Azure OpenAI インスタンスに関するユースケースがすべて含まれます。

• サブスクリプション境界は従量課金モデルで使用できる要素であるため、従量課金ベースで取得するクォータを増加できます。 この余分なクォータを使用すると、高度な同時使用をサポートできます。

単一リージョンと複数のサブスクリプション内に複数のインスタンス用のゲートウェイを導入する

「単一リージョンかつ単一サブスクリプション内に複数のインスタンス用のゲートウェイを導入する」で説明したものと同じ理由が、このトポロジにも当てはまります。

これらの理由に加えて、このトポロジにゲートウェイを追加すると、組織に "サービスとしての Azure OpenAI" モデルを提供する一元的なチームもサポートされます。 従量課金ベースのクォータはサブスクリプションにバインドされているため、一元的なチームで、従量課金ベースのモデルを使用した Azure OpenAI サービスを提供している場合、必要なクォータを取得するには、複数のサブスクリプションにまたがって Azure OpenAI インスタンスをデプロイする必要があります。 ゲートウェイのロジックはほとんど変わりません。

単一リージョンと複数のサブスクリプションのトポロジで複数のインスタンスを使用する場合のヒント

• 理想的には、Azure RBAC と Azure Policy の一貫性をサポートするために、すべてのサブスクリプションを同じ Microsoft Entra テナントでバックアップする必要があります。

• ゲートウェイを、Azure OpenAI インスタンスと同じリージョンにデプロイします。

• Azure OpenAI インスタンスとは別の専用サブスクリプションにゲートウェイをデプロイします。 これにより、Azure OpenAI インスタンスへの対応の一貫性が確保され、Azure OpenAI のデプロイとそのルーティングの間で業務が論理的に分割されます。

• ゲートウェイからの要求をサブスクリプション間でルーティングする場合は、プライベート エンドポイントに到達可能であることを確認します。 ハブ経由の推移的なルーティングを使用して、それぞれのスポークでバックエンドのプライベート エンドポイントにルーティングできます。 サブスクリプション間の Private Link 接続を使用することにより、ゲートウェイ サブスクリプションで Azure OpenAI サービスのプライベート エンドポイントを直接公開できる場合があります。 アーキテクチャと組織でこのアプローチがサポートされている場合は、サブスクリプション間の Private Link 接続が推奨されます。

単一リージョンと複数のサブスクリプション内で複数のインスタンス用にゲートウェイを使用しないほうがよい理由

単一のリージョンとサブスクリプション内で複数のインスタンス用にゲートウェイを使用しないほうがよい理由 はすべて、このトポロジに当てはまります。

複数のリージョンにまたがって複数の Azure OpenAI インスタンスを使用する

複数のリージョンにまたがる複数の Azure OpenAI インスタンスを使用するトポロジの詳細

• Azure OpenAI モデル デプロイ: 複数
• Azure OpenAI インスタンス: 複数
• サブスクリプション: 1 つ以上
• リージョン: 複数

複数のリージョンにまたがる複数の Azure OpenAI インスタンスを使用するトポロジのユース ケース

2 つ以上の Azure リージョンにまたがる複数の Azure OpenAI インスタンスを含むトポロジでは、以下のユース ケースがサポートされます。

• 複数のサブスクリプションにまたがる単一リージョン内で複数の Azure OpenAI インスタンスを使用するユース ケースがすべて含まれます。

• リージョン間ペアの使用など、サービスの可用性に関する フェールオーバー戦略を有効にする。

• データ所在地とコンプライアンスの設計を有効にする。

• 混合モデルの可用性を有効にする。 一部のリージョンでは、モデルが異なり、モデルに利用できるクォータも異なります。

Azure リージョンが技術的に異なるわけではありませんが、このトポロジは、オンプレミスや別のクラウドなど、クロスプレミスの状況で AI モデルを公開している場合にも適用できます。

複数のリージョンに複数のインスタンス用のゲートウェイを導入する

完全なリージョン停止が発生しても運用を停止できないビジネス クリティカルなアーキテクチャの場合、グローバルな統合ゲートウェイは、クライアント コードからフェールオーバー ロジックを排除するために役立ちます。 この実装では、ゲートウェイがリージョン停止の影響を受けないようにする必要があります。

リージョン間での負荷分散は一般的ではありませんが、リージョン間の従量課金ベースのデプロイで使用可能なクォータを組み合わせるために、戦略的に使用することもできます。 このシナリオでは、ゲートウェイがリージョン停止の影響を受けないようにする必要はありませんが、ワークロードの信頼性を最大限に高めるには、そのようにすることが推奨されます。

Azure API Management を使用する (単一リージョンのデプロイ)

このトポロジでは、Azure API Management はゲートウェイ テクノロジ専用に使用されます。 ここでは、API Management が単一リージョンにデプロイされています。 このゲートウェイ インスタンスから、リージョン間でアクティブ/アクティブの負荷分散を実行します。 ゲートウェイ内のポリシーでは、すべての Azure OpenAI インスタンスを参照します。 ゲートウェイには、リージョン間の仮想ネットワーク ピアリングまたはプライベート エンドポイントを介して、複数のリージョンにまたがって各バックエンドにつながるネットワーク通信経路が必要です。 このゲートウェイから、別のリージョンの Azure OpenAI インスタンスを呼び出した場合は、ネットワーク待機時間とエグレス料金が増加します。

ゲートウェイは、Azure OpenAI インスタンスからのスロットルと可用性のシグナルを尊重し、障害が発生した、またはスロットルされた Azure OpenAI インスタンスを安全に再追加できるようになるまで、障害が発生したバックエンドをプールから削除する必要があります。 ゲートウェイは、フォールバックしてゲートウェイ エラーを返す前に、障害が発生した場合にプール内の別のバックエンド インスタンスに対して現在の要求を再試行する必要があります。 バックエンドの Azure OpenAI インスタンスが使用できない場合は、ゲートウェイの正常性チェックで異常を通知する必要があります。

このトポロジでは単一障害点 (ゲートウェイ) が生じるため、この特定のアーキテクチャの有用性はかなり制限されます。 PTU 割り当ての予測があまりにも難しいことがわかっている場合、このモデルは Azure OpenAI での従量課金ベースの請求に適しています。

アクティブ/パッシブ バリアント

このモデルを使用すると、特に Azure OpenAI のみのリージョン障害を処理するためのアクティブ/パッシブ アプローチを提供することもできます。 このモードでは通常、トラフィックはゲートウェイから、API 管理サービスと同じリージョンにある Azure OpenAI インスタンスに流れます。 この Azure OpenAI インスタンスは、リージョン障害を発生させることなく、予想されるすべてのトラフィック フローを処理します。 選択した課金モデルに応じて、PTU ベースまたは従量課金ベースを指定できます。 Azure OpenAI のみのリージョン障害が発生した場合、ゲートウェイは、Azure OpenAI が従量課金モードで既にデプロイされている別のリージョンにトラフィックをリダイレクトできます。

Azure API Management を使用する (マルチリージョンのデプロイ)

以前の Azure API Management ベースのアーキテクチャの信頼性を向上させるために、API Management では、 複数の Azure リージョンへのインスタンスのデプロイがサポートされています。 このデプロイ オプションでは、単一の API Management インスタンスを介して単一コントロール プレーンが提供され、選択したリージョンにゲートウェイがレプリケートされます。 このトポロジでは、アクティブ/アクティブのゲートウェイ アーキテクチャを提供する Azure OpenAI インスタンスを含んだ各リージョンに、ゲートウェイ コンポーネントをデプロイします。

ルーティングや要求処理ロジックなどのポリシーは、個々のゲートウェイにレプリケートされます。 現在のゲートウェイと同じリージョンにある Azure OpenAI インスタンスを確実に呼び出すには、そのポリシーのすべてのポリシー ロジックに条件付きロジックが含まれている必要があります。 詳細については、「リージョンのバックエンド サービスに API 呼び出しをルーティングする」を参照してください。 次に、ゲートウェイ コンポーネントでは、同じリージョン内の Azure OpenAI のみへの、通常はプライベート エンドポイントを介したネットワーク通信経路が必要です。

API Management は、最小の待機時間に基づいて、すぐに使用できるグローバル FQDN (完全修飾ドメイン名) ルーティングを提供しています。 アクティブ/アクティブ ゲートウェイのデプロイには、このパフォーマンス ベースの組み込み機能を使用します。 この組み込み機能は、パフォーマンスへの対処と、リージョン ゲートウェイが停止した場合の処理に役立ちます。 組み込みのグローバル ルーターでは、個々のゲートウェイを無効にすることでリージョンをシミュレートできるため、ディザスター リカバリー テストもサポートされます。 クライアントが FQDN の TTL (Time to Live) を尊重し、最近の DNS フェールオーバーを処理するための適切な再試行ロジックを備えていることを確認してください。

このアーキテクチャに Web アプリケーション ファイアウォールを導入する必要がある場合でも、Web アプリケーション ファイアウォールを実装するグローバル ルーターのバックエンド オリジンとして、組み込みの FQDN ルーティング ソリューションを使用できます。 フェイルオーバーに関する責任は、グローバル ルーターから API Management に委任されます。 あるいは、リージョン ゲートウェイの FQDN をバックエンド プールのメンバーとして使用することもできます。 後者のアーキテクチャでは、各リージョン ゲートウェイの組み込みの /status-0123456789abcdef エンドポイントまたは別のカスタムの正常性 API エンドポイントを使用して、リージョンのフェールオーバーをサポートします。 どちらを使用すべきか不明な場合は、単一の起点バックエンドを使用する FQDN アプローチから始めてください。

このアーキテクチャは、リージョンを完全に利用可能または完全に利用不可能として扱うことができる場合に最適です。 これは、API Management ゲートウェイまたは Azure OpenAI インスタンスのいずれかが利用不可能である場合、クライアント トラフィックがそのリージョンの API Management ゲートウェイにルーティングされないようにすることを意味します。 Azure OpenAI を利用できない間もリージョン ゲートウェイがトラフィックを受け入れる場合は、別のプロビジョニングを行わない限り、エラーをクライアントに伝達する必要があります。 クライアント エラーを回避するには、「アクティブ/アクティブ ゲートウェイおよびアクティブ/パッシブ Azure OpenAI バリアント」の改善されたアプローチを参照してください。

リージョンで API Management ゲートウェイの停止が発生しているか、異常が報告されている場合は、残りの利用可能なリージョンで、そうした他のリージョンからのトラフィックを 100% 吸収する必要があります。 つまり、新しいトラフィックのバーストを処理する場合や、 フェールオーバーにアクティブ/パッシブのアプローチを使用するには、PTU ベースの Azure OpenAI インスタンスをオーバープロビジョニングする必要があります。 容量計画には、 Azure OpenAI 容量計算ツール を使用します。

ゲートウェイのリソース プロバイダーへのアクセス能力に影響する、関連するリージョン停止の影響範囲を縮小するには、Azure API Management を含むリソース グループが API Management インスタンス自体と同じ場所であることを確認してください。

アクティブ/アクティブ ゲートウェイおよびアクティブ/パッシブ Azure OpenAI バリアント

前のセクションでは、アクティブ/アクティブ ゲートウェイ トポロジの提供によるゲートウェイの可用性について説明しました。 このトポロジは、そのアクティブ/アクティブ ゲートウェイと、コスト効率の高いアクティブ/パッシブ Azure OpenAI トポロジを組み合わせたものです。 PTU ベースのデプロイから従量課金ベースの Azure OpenAI デプロイにフェールオーバーするアクティブ/パッシブ ロジックをゲートウェイに追加すると、ワークロードの信頼性が大幅に高まります。 このモデルでも、クライアントは API Management の組み込み FQDN ルーティング ソリューションを使用して、パフォーマンス ベースのルーティングを行うことができます。

カスタム コードを伴うゲートウェイを使用する

ゲートウェイごとのルーティング規則が複雑すぎて、API Management ポリシーとして合理的であると判断できない場合は、チームで独自のソリューションをデプロイして管理する必要があります。 このアーキテクチャは、リージョンごとに 1 つの高可用性スケール ユニットを備えた、ゲートウェイのマルチリージョン デプロイである必要があります。 これらのデプロイの前に Azure Front Door (Anycast) または Azure Traffic Manager (DNS) を配置する必要があります。これには通常、待機時間ベースのルーティングと、ゲートウェイ可用性の適切な正常性チェックが使用されます。

Web アプリケーション ファイアウォールとパブリック インターネット アクセスが必要な場合は、Azure Front Door を使用します。 Web アプリケーション ファイアウォールが不要で、DNS TTL で十分な場合は、Traffic Manager を使用します。 ゲートウェイ インスタンスの前に Azure Front Door (または任意のリバース プロキシ) を配置する場合は、ゲートウェイをバイパスできないようにしておきます。 Azure Front Door を使用する場合は、ゲートウェイ インスタンスをプライベート エンドポイント経由でのみ利用できるようにし、ゲートウェイの実装時に X_AZURE_FDID HTTP ヘッダーの検証を追加します。

カスタム ゲートウェイでリージョンごとに使用するリソースは、リージョン別のリソース グループに配置します。 こうすることにより、そのリージョンにおけるゲートウェイ リソース プロバイダーへのアクセス能力に影響する、リージョン停止の影響範囲を縮小できます。

また、TLS、認証、正常性チェック、ラウンドロビン負荷分散など、API Management の他のメリットを得るために、API Management を使用してゲートウェイ ロジックの実装を前面に配置することも検討できます。 こうすることにより、API に関する一般的な懸念がゲートウェイ内のカスタム コードから除外され、ゲートウェイは Azure OpenAI インスタンスとモデル デプロイ ルーティングに特化して対処できるようになります。

データ所在地コンプライアンスに対応するには、このアーキテクチャのデプロイを地政学的境界ごとに分離して配置し、承認されたエンドポイントのみにクライアントがアクセスできるようにします。

複数のリージョン内で複数のインスタンス用にゲートウェイを使用しないほうがよい理由

データ所在地とデータ コンプライアンスが必要な場合は、複数の地政学的リージョンにまたがる統合ゲートウェイを実装しないでください。 このことは、データ所在地の要件に対する違反につながります。 リージョンごとに個別対応が可能なゲートウェイを使用し、ここまでのセクションのいずれかのガイダンスに従ってください。

クライアントがリージョン間でフェールオーバーすることが想定されておらず、クライアントに使用する特定のゲートウェイを提供できる場合は、代わりに複数のゲートウェイ (リージョンごとに 1 つ) を使用し、ここまでのセクションのいずれかのガイダンスに従います。 単一障害点となるゲートウェイを含むリージョンに、他のリージョンの可用性関を連付けないようにしてください。

ゲートウェイによって公開されるすべてのリージョンで、必要なモデルとバージョンを使用できない場合は、統合ゲートウェイを実装しないでください。 クライアントは、同じモデルおよび同じモデル バージョンにルーティングする必要があります。 マルチリージョンの負荷分散ゲートウェイとフェールオーバー ゲートウェイを使用する場合は、関係するすべてのリージョンで利用できる共通のモデルとモデル バージョンを選択する必要があります。 詳細については、 モデルの可用性を参照してください。 モデルとモデル バージョンを標準化できなければ、ゲートウェイの利点は限定されます。

一般的な推奨事項

ワークロードに必要なトポロジを問わず、ゲートウェイ ソリューションを構築する際に考慮すべき推奨事項がいくつかあります。

ステートフルな操作

クライアントが Assistants API など Azure OpenAI のステートフル機能を使用する場合は、その操作の間、クライアントが特定のバックエンドに固定されるようにゲートウェイを構成する必要があります。 この操作は、インスタンス データを Cookie に保存することで実行できます。 このようなシナリオでは、別の Azure OpenAI インスタンスにリダイレクトするのではなく、固定されたクライアントに 429 などの Azure OpenAI API 応答を返すことを検討してください。 こうすることによってクライアントは、突然インスタンスが使用不可能になっても、そのインスタンスを非表示にして履歴のないモデル インスタンスにルーティングするのではなく、明示的に処理できるようになります。

ゲートウェイの正常性チェック

正常性チェックについては、トポロジを問わず、考慮すべき観点が 2 つあります。

ゲートウェイがラウンド ロビンを中心に構築されている場合、またはサービスの可用性フェールオーバーを厳密に実行している場合は、Azure OpenAI インスタンス (またはモデル) を可用性状態から除外する手段が必要になります。 Azure OpenAI では、要求を処理できるかどうかを事前に把握するための正常性チェック エンドポイントが提供されません。 疑似的な切り替えを送信することもできますが、その場合はモデルの容量が消費されます。 Azure OpenAI インスタンスとモデルの可用性に関する別の信頼できる信号ソースがない限り、ゲートウェイは Azure OpenAI インスタンスが稼働していると想定し、そのインスタンスまたはモデルでの今後の要求に対する回線中断の信号として、 429、 500、および 503 の HTTP 状態コードをしばらくの間処理する必要があります。 調整を必要とする状況では、回線切断ロジックでの応答コード Retry-After に対する Azure OpenAI API 応答にあるヘッダー 429 のデータに常に配慮してください。 Azure API Management を使用している場合は、 組み込みのサーキット ブレーカー 機能を使用して評価します。

クライアントまたはワークロード運用チームが、独自のルート指定またはイントロスペクションの目的で、ゲートウェイに関する正常性チェックの公開を求めることがあります。 API Management を使用している場合、既定の /status-0123456789abcdef では主にバックエンドではなく API Management ゲートウェイ インスタンスを対処するため、詳細が十分ではない可能性があります。 ゲートウェイの可用性またはゲートウェイ内の特定のルートに関して、有用なデータをクライアントまたは監視システムに返すことができる専用の正常性チェック API を追加することを検討してください。

安全なデプロイ プラクティス

ゲートウェイ実装を使用すると、更新されたモデルのブルーグリーン デプロイを調整できます。 Azure OpenAI モデルは、新しいモデル バージョンと新しいモデルで更新されているため、微調整された新たなモデルが存在する可能性があります。

運用前の変更の効果をテストした後、運用クライアントを新しいモデル バージョンに切り替える必要があるか、あるいはトラフィックを変更する必要があるかを評価します。 上記のゲートウェイ パターンを使用すると、バックエンドで両方のモデルを同時にデプロイできます。 モデルを同時にデプロイすると、ワークロード チームの安全なデプロイ プラクティスである増分ロールアウトに基づいて、ゲートウェイがトラフィックをリダイレクトできるようになります。

ブルーグリーン デプロイを使用しない場合も、ワークロードの APIOps アプローチを定義し、バックエンド インスタンスとモデル デプロイの変化率を考慮して、十分に自動化する必要があります。

過不足のない実装

この記事で紹介されているシナリオの多くは、クライアントの複雑さを軽減し、信頼性の高い自己保存手法を実装することで、ワークロードの潜在的なサービス レベル目標 (SLO) の向上に役立ちます。 アクセス制御を Azure OpenAI から特定のモデルに移すことで、ワークロードのセキュリティを向上させるものもあります。 ゲートウェイの導入によって、これらの目標に反する結果を招かないように注意してください。 ゲートウェイのサービス障害または構成に関する人為的な問題、複雑なルーティング ロジックなどによって、新しい単一障害点が追加されるリスクや、意図したよりも多くのモデルが未承認のクライアントに公開されるリスクを理解しましょう。

データの主権

アクティブ/アクティブおよびアクティブ/パッシブのさまざまなアプローチは、ワークロードのデータ所在地コンプライアンスの観点から評価する必要があります。 関係するリージョンが常に地政学的境界内に納まる場合、これらのパターンの多くをワークロードのアーキテクチャに適用できます。 このシナリオをサポートするには、地政学的境界を独立したスタンプとして扱い、そのスタンプ内でのみアクティブ/アクティブまたはアクティブ/パッシブの処理を適用する必要があります。

特に、パフォーマンス ベースのルーティングでは、データ主権コンプライアンスを十分に調査する必要があります。 データ主権のシナリオでは、別の geography でクライアントにサービスを提供しながら、準拠した状態を維持することはできません。 データ所在地を伴うすべてのゲートウェイ アーキテクチャでは、クライアントが地政学的リージョン内のエンドポイントのみを使用するように強制する必要があります。 クライアントに対して他のゲートウェイ エンドポイントの使用をブロックするとともに、ゲートウェイ自体も、地政学的境界を超えた要求を行ってクライアントの信頼を侵害しないようにする必要があります。 このセグメント化を実装する最も信頼性の高い方法は、地政学的リージョンごとに完全に独立した高可用性ゲートウェイを中心にアーキテクチャを構築することです。

Azure OpenAI 認証

ゲートウェイは、接続するすべての Azure OpenAI インスタンスで認証を行う必要があります。 パススルー認証を行うようにゲートウェイが設計されているケースを除き、ゲートウェイは資格情報にマネージド ID を使用する必要があります。 このため、各 Azure OpenAI インスタンスで、ゲートウェイのマネージド ID に対して最小特権の RBAC を構成する必要があります。 アクティブ/アクティブ アーキテクチャとフェールオーバー アーキテクチャの場合は、関係するすべての Azure OpenAI インスタンスに対する同等のアクセス許可がゲートウェイの ID に付与されていることを確認してください。

Azure Policy

アクティブ/アクティブまたはアクティブ/パッシブの状況では、モデル デプロイと Azure OpenAI インスタンス間の一貫性が重要になります。 さまざまな Azure OpenAI インスタンス間またはモデル デプロイ間の一貫性を確保するには、Azure Policy を使用します。 ポリシー間の一貫性を確保するうえで、Azure OpenAI の 組み込みポリシー が十分ではない場合は、 コミュニティで作成された カスタム ポリシーを作成または使用することを検討します。

ゲートウェイの冗長性

複数バックエンドの場合に限らず、各リージョンのゲートウェイ実装は常に冗長性を備えて構築し、スケール ユニット内で高可用性を確保する必要があります。 可用性ゾーンがあるリージョンを選択し、ゲートウェイがそれら全体に分散されていることを確認します。 単一障害点がゲートウェイの単一のコンピューティング インスタンスの障害ではなく、完全なリージョン停止に限定されるように、ゲートウェイの複数インスタンスをデプロイします。 API Management の場合は、2 つ以上のゾーンに 2 つ以上のユニットをデプロイします。 カスタム コード実装の場合は、可用性ゾーン間でベスト エフォート分散を使用して、3 つ以上のインスタンスをデプロイします。

ゲートウェイの実装

Azure では、このようなゲートウェイを構築するためのターンキー ソリューションや参照アーキテクチャが提供されていません。 紹介記事に示されているように、このゲートウェイをワークロード チームが構築して運用する必要があります。 ここで示したユース ケースの一部に対応する、コミュニティでサポートされているサンプル実装の例を以下に示します。 独自の概念実証を構築する場合は、これらの GitHub サンプルの参照を検討してください。

実装	例
Azure API Management	Azure API Management の使用による Azure OpenAI のスマート負荷分散 - この GitHub リポジトリには、サンプル ポリシー コードと、サブスクリプションにデプロイする手順が含まれています。 Azure API Management の使用による Azure OpenAI のスケーリング - この GitHub リポジトリには、PTU と使用量スピルオーバーのサンプル ポリシー コードと手順が含まれています。 GenAI ゲートウェイ ツールキットには、API Management ポリシーの例と、ポリシーの動作をテストするためのロード テストセットアップが含まれています。
カスタム コード	Azure Container Apps の使用による Azure OpenAI のスマート負荷分散 この GitHub リポジトリには、サンプルの C# コードと、コンテナーを構築してサブスクリプションにデプロイするための手順が含まれています。

次のステップ

ワークロードにゲートウェイを実装すると、この記事で説明した戦術的な複数バックエンド ルーティングをはじめ、多くの利点がもたらされます。 ゲートウェイで解決できる他の 重要な課題 についてもご確認ください。

関連リソース

• Azure OpenAI Service
• Azure API Managementの API ゲートウェイ