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 API Management ベースのゲートウェイとカスタム コード ゲートウェイの両方に適しています。 これを説明するために、アーキテクチャ図ではほとんどの場合、一般的にゲートウェイ コンポーネントを表しています。
単一の 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 要求内の情報に基づき、ゲートウェイの責任でテナントのモデルへのルーティングが行われます。
ヒント
API キーと Azure ロールベース アクセス制御 (RBAC) は、モデル デプロイのレベルではなく、Azure OpenAI インスタンスのレベルで適用されるため、このシナリオでゲートウェイを追加すると、セキュリティをゲートウェイに移行できます。 その場合ゲートウェイは、同時にデプロイされたモデル間で追加のセグメント化を提供します。他の方法では、Azure OpenAI の ID およびアクセス管理 (IAM) または IP ファイアウォールを介してこれを制御することはできません。
このトポロジでゲートウェイを使用すると、クライアントベースの使用状況の追跡が可能になります。 クライアントが個別の 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 の可用性に関するフェールオーバー戦略を有効にする
プロビジョニングされたインスタンスと標準インスタンスの両方をスピルオーバー用にペアリングするなど、Azure OpenAI クォータの可用性のフェールオーバー戦略を有効にします
単一のリージョンとサブスクリプション内で複数のインスタンス用のゲートウェイを導入する
いくつかの理由により、クライアントからモデルにアクセスできない場合があります。 理由としては、Azure OpenAI Service の中断や Azure OpenAI 調整要求のほか、ネットワークの構成ミスや不注意によるモデル デプロイの削除といったワークロード操作に関連する問題が挙げられます。 これらの課題に対処するには、再試行ロジックや回路遮断ロジックを実装する必要があります。
このロジックは、ゲートウェイのクライアントまたはサーバー側に実装できます。 ゲートウェイにロジックを実装すると、ロジックがクライアントから分離されるため、コードの繰り返しがなくなり、ロジックをテストする場所が 1 か所になります。 クライアント コードを所有しているかどうかにかかわらず、この移行によってワークロードの信頼性が向上する可能性があります。
単一のリージョンとサブスクリプション内に複数の Azure OpenAI インスタンスを持つゲートウェイを使用すると、すべてのバックエンドをアクティブ/パッシブ フェールオーバーで使用できるだけでなく、アクティブ/アクティブ デプロイとして扱うことができます。 同じプロビジョニング済みモデルを複数の Azure OpenAI インスタンスにデプロイし、ゲートウェイを使用してそれらの間で負荷分散を行うことができます。
メモ
Standard クォータはサブスクリプション レベルであり、Azure OpenAI インスタンス レベルではありません。 同じサブスクリプション内の標準インスタンスに対する負荷分散では、追加のスループットは実現されません。
Azure OpenAI のプロビジョニング時にワークロード チームが持つオプションの 1 つは、課金とスループットのモデルがプロビジョニングされているか標準かを決定することです。 未使用のプロビジョニング済み容量による無駄を回避するためのコスト最適化戦略は、プロビジョニングされたインスタンスを少し下にして、標準インスタンスをそれと共にデプロイすることです。 このトポロジの目標は、クライアントが最初に使用可能なすべての事前割り当てスループットを使用し、次に超過分の標準デプロイに "バースト" することです。 この形式の計画フェールオーバーには、このセクションの冒頭の段落で説明したのと同じ理由で、つまり、この複雑さをクライアント コードから排除できるというメリットがあります。
ゲートウェイが必要な場合、ゲートウェイは、クライアントが対話しているすべてのモデル デプロイに関する詳細を取得できる独自の立場になります。 Azure OpenAI のすべてのインスタンスで独自のテレメトリを取得できますが、ゲートウェイ内でこれを行うと、ワークロード チームは、使用されているすべてのモデルにわたるテレメトリとエラー応答を 1 つのストアに公開することにより、ダッシュボードとアラートの統合を容易に実現できます。
単一のリージョンとサブスクリプションのトポロジ内で複数のインスタンスを使用する場合のヒント
ゲートウェイでフェールオーバー シナリオをサポートする場合、ゲートウェイが Azure OpenAI からの HTTP 応答で利用可能な
Retry-After情報を使用していることを確認します。 サーキット ブレーカーの実装を制御するには、この権限情報を使用します。429 Too Many Requestsを返すエンドポイントには継続的にアクセスしないでください。 その代わりに、そのモデル インスタンスの回路を遮断します。ゲートウェイでは、以前の要求を通じてモデルの使用を追跡して、調整イベントが発生する前に予測を試みることは可能ですが、これにはエッジ ケースが伴います。 ほとんどの場合、予測を試みるのではなく、HTTP 応答コードを使用して今後のルーティング決定を進めることをお勧めします。
ラウンド ロビン処理または別のエンドポイントへのフェールオーバー (標準デプロイへのプロビジョニングされたスピルなど) の場合は、常にそれらのエンドポイントが同じバージョンで同じモデルを使用していることを確認してください。 たとえば、
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は、標準またはプロビジョニングのどちらであっても、すべての負荷分散インスタンスまたはスピルオーバー インスタンスで使用できます。
単一のリージョンとサブスクリプション内で複数のインスタンス用にゲートウェイを使用しないほうがよい理由
この特定のトポロジのさまざまなクライアントに対してモデルをチャージバックする機能は、ゲートウェイ自体によって向上されるわけではありません。 このトポロジでは、クライアントに専用の Azure OpenAI インスタンスへのアクセスを許可することができ、これによってワークロード チームがチャージバックまたはショーバックを実行できるようになります。 このモデルは一意の ID とネットワーク境界をサポートしているため、セグメント化のために特別にゲートウェイを導入する必要はありません。
領域内で少数のクライアントのコードを制御していて、そのクライアントを簡単に更新できる場合は、ゲートウェイに組み込む必要があるロジックをコードに直接追加できます。 主に、クライアント コードを所有していない場合や、処理が複雑すぎてクライアントできない場合は、フェールオーバーまたは負荷分散のためのゲートウェイ アプローチの使用を検討してください。
容量の制約に特に対処するためにゲートウェイを使用している場合は、データ ゾーンベースの容量機能がワークロードに十分かどうかを評価します。
複数のサブスクリプションにまたがる単一リージョン内で複数の Azure OpenAI インスタンスを使用する
複数のサブスクリプションにまたがる単一リージョン内で複数の Azure OpenAI インスタンスを使用するトポロジの詳細
- Azure OpenAI モデル デプロイ: 1 つ以上
- Azure OpenAI インスタンス: 複数
- サブスクリプション: 複数
- リージョン: 1 つ
複数のサブスクリプションにまたがる単一リージョン内で複数の Azure OpenAI インスタンスを使用するトポロジのユース ケース
複数のサブスクリプションにまたがる単一リージョン内に複数の Azure OpenAI インスタンスを含むトポロジでは、以下のユース ケースがサポートされます。
単一リージョンかつ単一サブスクリプション内の複数の Azure OpenAI インスタンスに関するユースケースがすべて含まれます。
標準デプロイでより多くのクォータを取得する必要があり、モデルの使用を 1 つの特定のリージョンに制限する必要があります。
メモ
モデルの使用を特定のリージョンに制限する必要がない場合は、Azure のグローバル インフラストラクチャを利用して、使用可能な容量を持つデータ センターに推論要求を動的にルーティングする 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 インスタンスが使用できない場合は、ゲートウェイの正常性チェックで異常を通知する必要があります。
メモ
ゲートウェイ インスタンスで何らかのサービス停止が発生すると、すべてのリージョンにアクセスできなくなるため、このゲートウェイにより、グローバルな単一リージョン障害点がアーキテクチャ内に発生します。 ビジネス クリティカルなワークロードや、クライアント ベースの負荷分散で十分な場合には、このトポロジを使用しないでください。
このトポロジでは単一障害点 (ゲートウェイ) が発生するため、この特定のアーキテクチャのユーティリティはかなり制限されており、リージョンの Azure OpenAI エンドポイントの停止から保護されます。
警告
いずれかの Azure OpenAI リージョンが複数の地政学的境界にまたがる場合、データ主権コンプライアンスを伴うシナリオではこのアプローチを使用できません。
アクティブ/パッシブ バリアント
このモデルを使用すると、特に Azure OpenAI のみのリージョン障害を処理するためのアクティブ/パッシブ アプローチを提供することもできます。 このモードでは通常、トラフィックはゲートウェイから、API 管理サービスと同じリージョンにある Azure OpenAI インスタンスに流れます。 この Azure OpenAI インスタンスは、リージョン障害を発生させることなく、予想されるすべてのトラフィック フローを処理します。 お好みの課金モデルに応じて、プロビジョニングすることも標準にすることもできます。 Azure OpenAI だけがリージョンで障害が発生した場合、ゲートウェイは、Azure OpenAI が標準デプロイに既にデプロイされている別のリージョンにトラフィックをリダイレクトできます。
Azure API Management を使用する (マルチリージョンのデプロイ)
以前の Azure API Management ベースのアーキテクチャの信頼性を向上させるために、API Management では、 複数の Azure リージョンへのインスタンスのデプロイがサポートされています。 このデプロイ オプションでは、単一の API Management インスタンスを介して単一コントロール プレーンが提供され、選択したリージョンにゲートウェイがレプリケートされます。 このトポロジでは、アクティブ/アクティブのゲートウェイ アーキテクチャを提供する Azure OpenAI インスタンスを含んだ各リージョンに、ゲートウェイ コンポーネントをデプロイします。
ルーティングや要求処理ロジックなどのポリシーは、個々のゲートウェイにレプリケートされます。 現在のゲートウェイと同じリージョンにある Azure OpenAI インスタンスを確実に呼び出すには、そのポリシーのすべてのポリシー ロジックに条件付きロジックが含まれている必要があります。 詳細については、「リージョンのバックエンド サービスに API 呼び出しをルーティングする」を参照してください。 次に、ゲートウェイ コンポーネントでは、同じリージョン内の Azure OpenAI のみへの、通常はプライベート エンドポイントを介したネットワーク通信経路が必要です。
メモ
このトポロジには、トラフィック処理の観点から見たグローバルな障害点はありませんが、Azure API Management コントロール プレーンが単一リージョンにのみあるため、アーキテクチャは部分的に単一障害点の影響を受けます。 コントロール プレーンの制限が、ビジネス基準またはミッションクリティカル基準に違反する可能性がないか評価してください。
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% 吸収する必要があります。 つまり、新しいトラフィックのバーストを処理したり、フェールオーバーに
ゲートウェイのリソース プロバイダーへのアクセス能力に影響する、関連するリージョン停止の影響範囲を縮小するには、Azure API Management を含むリソース グループが API Management インスタンス自体と同じ場所であることを確認してください。
警告
いずれかのゲートウェイ リージョンが複数の地政学的境界にまたがる場合、データ所在地コンプライアンスを伴うシナリオではこのアプローチを使用できません。
アクティブ/アクティブ ゲートウェイおよびアクティブ/パッシブ Azure OpenAI バリアント
前のセクションでは、アクティブ/アクティブ ゲートウェイ トポロジの提供によるゲートウェイの可用性について説明しました。 このトポロジは、そのアクティブ/アクティブ ゲートウェイと、コスト効率の高いアクティブ/パッシブ Azure OpenAI トポロジを組み合わせたものです。 アクティブ/パッシブ ロジックをゲートウェイに追加して、プロビジョニングされたデプロイから標準の Azure OpenAI デプロイにフェールオーバーすると、ワークロードの信頼性が大幅に向上する可能性があります。 このモデルでも、クライアントは API Management の組み込み FQDN ルーティング ソリューションを使用して、パフォーマンス ベースのルーティングを行うことができます。
警告
いずれかのリージョンが複数の地政学的境界にまたがる場合、データ所在地コンプライアンスを伴うシナリオでは、このアクティブ/アクティブおよびアクティブ/パッシブのアプローチを使用できません。
カスタム コードを伴うゲートウェイを使用する
ゲートウェイごとのルーティング規則が複雑すぎるため、チームが Azure 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 の他の利点については、Azure API Management を使用してゲートウェイ ロジックの実装を前面に配置することも検討できます。 こうすることにより、API に関する一般的な懸念がゲートウェイ内のカスタム コードから除外され、ゲートウェイは Azure OpenAI インスタンスとモデル デプロイ ルーティングに特化して対処できるようになります。
データ所在地コンプライアンスに対応するには、このアーキテクチャのデプロイを地政学的境界ごとに分離して配置し、承認されたエンドポイントのみにクライアントがアクセスできるようにします。
複数のリージョン内で複数のインスタンス用にゲートウェイを使用しないほうがよい理由
データ所在地とデータ コンプライアンスが必要な場合は、複数の地政学的リージョンにまたがる統合ゲートウェイを実装しないでください。 このことは、データ所在地の要件に対する違反につながります。 リージョンごとに個別対応が可能なゲートウェイを使用し、ここまでのセクションのいずれかのガイダンスに従ってください。
クォータの増加のみを目的として統合ゲートウェイを実装しないでください。 Azure OpenAI のグローバル デプロイ
クライアントがリージョン間でフェールオーバーすることが想定されておらず、クライアントに使用する特定のゲートウェイを提供できる場合は、代わりに複数のゲートウェイ (リージョンごとに 1 つ) を使用し、ここまでのセクションのいずれかのガイダンスに従います。 単一障害点となるゲートウェイを含むリージョンに、他のリージョンの可用性関を連付けないようにしてください。
ゲートウェイによって公開されるすべてのリージョンで、必要なモデルとバージョンを使用できない場合は、統合ゲートウェイを実装しないでください。 クライアントは、同じモデルおよび同じモデル バージョンにルーティングする必要があります。 マルチリージョンの負荷分散ゲートウェイとフェールオーバー ゲートウェイを使用する場合は、関係するすべてのリージョンで利用できる共通のモデルとモデル バージョンを選択する必要があります。 詳細については、 モデルの可用性を参照してください。 モデルとモデル バージョンを標準化できなければ、ゲートウェイの利点は限定されます。
一般的な推奨事項
ワークロードに必要なトポロジを問わず、ゲートウェイ ソリューションを構築する際に考慮すべき推奨事項がいくつかあります。
ステートフルな操作
クライアントが Assistants API など Azure OpenAI のステートフル機能を使用する場合は、その操作の間、クライアントが特定のバックエンドに固定されるようにゲートウェイを構成する必要があります。 この操作は、インスタンス データを Cookie に保存することで実行できます。 これらのシナリオでは、別の Azure OpenAI インスタンスにリダイレクトするのではなく、ピン留めされたクライアントに 429 のような 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 認証
ゲートウェイは、接続するすべての Azure OpenAI インスタンスで認証を行う必要があります。 パススルー認証を行うようにゲートウェイが設計されているケースを除き、ゲートウェイは資格情報にマネージド ID を使用する必要があります。 このため、各 Azure OpenAI インスタンスで、ゲートウェイのマネージド ID に対して最小特権の RBAC を構成する必要があります。 アクティブ/アクティブ アーキテクチャとフェールオーバー アーキテクチャの場合は、関係するすべての Azure OpenAI インスタンスに対する同等のアクセス許可がゲートウェイの ID に付与されていることを確認してください。
Azure Policy
モデル デプロイと Azure OpenAI インスタンスの間の整合性は、アクティブ/アクティブとアクティブ/パッシブの両方の状況で重要です。 さまざまな Azure OpenAI インスタンス間またはモデル デプロイ間の一貫性を確保するには、Azure Policy を使用します。 ポリシー間の一貫性を確保するうえで、Azure OpenAI の 組み込みポリシー が十分ではない場合は、 コミュニティで作成された カスタム ポリシーを作成または使用することを検討します。
ゲートウェイの冗長性
複数バックエンドの場合に限らず、各リージョンのゲートウェイ実装は常に冗長性を備えて構築し、スケール ユニット内で高可用性を確保する必要があります。 可用性ゾーンがあるリージョンを選択し、ゲートウェイがそれら全体に分散されていることを確認します。 単一障害点がゲートウェイの単一のコンピューティング インスタンスの障害ではなく、完全なリージョン停止に限定されるように、ゲートウェイの複数インスタンスをデプロイします。 Azure API Management の場合は、2 つ以上のゾーンに 2 つ以上のユニットをデプロイします。 カスタム コード実装の場合は、可用性ゾーン間でベスト エフォート分散を使用して、3 つ以上のインスタンスをデプロイします。
ゲートウェイの実装
Azure では、複数のバックエンド間でトラフィックをルーティングすることに重点を置くゲートウェイを構築するための完全なターンキー ソリューションや参照アーキテクチャは提供されていません。 ただし、Azure API Management は、バックエンド プール、回線切断ポリシー、カスタム ポリシーなどの組み込み機能を使用して PaaS ベースのソリューションを提供するサービスであるため、必要に応じて推奨されます。 「Azure API Management の生成 AI ゲートウェイ機能の概要」を参照して、ワークロードのマルチバックエンド のニーズに合わせて、そのサービスで使用できる機能を評価します。
の概要記事で説明されているように、API Management を使用する場合でも、カスタム ソリューションを構築する場合でも、ワークロード チームはこのゲートウェイを構築して運用する必要があります。 前述のユース ケースの一部を取り上げた例を次に示します。 API Management またはカスタム コードを使用して独自の概念実証を構築する場合は、これらのサンプルを参照することを検討してください。
| 実装 | 例 |
|---|---|
| Azure API Management |
Azure API Management の使用による Azure OpenAI のスマート負荷分散 - この GitHub リポジトリには、サンプル ポリシー コードと、サブスクリプションにデプロイする手順が含まれています。 Azure API Management を使用した Azure OpenAI のスケーリング - この GitHub リポジトリには、プロビジョニングおよび標準のスピルオーバーに関するサンプル ポリシー コードと手順が含まれています。 GenAI ゲートウェイ ツールキットには、API Management ポリシーの例と、ポリシーの動作をテストするためのロード テストセットアップが含まれています。 |
| カスタム コード |
Azure Container Apps の使用による Azure OpenAI のスマート負荷分散 この GitHub リポジトリには、サンプルの C# コードと、コンテナーを構築してサブスクリプションにデプロイするための手順が含まれています。 |
Azure のクラウド導入フレームワークには、このマルチバックエンド シナリオを含む生成 AI シナリオ用の Azure API Management ランディング ゾーンの実装に関するガイダンスも含まれています。 ワークロードがアプリケーション ランディング ゾーンに存在する場合は、実装に関する考慮事項と推奨事項については、このガイダンスを参照してください。
次のステップ
ワークロードにゲートウェイを実装すると、この記事で説明した戦術的な複数バックエンド ルーティングをはじめ、多くの利点がもたらされます。 ゲートウェイで解決できる他の 重要な課題 についてもご確認ください。