Azure OpenAI Service は、アプリケーションで OpenAI の言語モデルを使用することで、埋め込みや補完を実行するための HTTP API を公開します。 インテリジェント アプリケーションは、これらの HTTP API をクライアントまたはオーケストレーターから直接呼び出します。 クライアントの例としては、チャット UI コードやカスタム データ処理パイプラインなどがあります。 オーケストレーターの例としては、LangChain、Semantic Kernel、Azure Machine Learning プロンプト フローなどがあります。 ワークロードが 1 つ以上の Azure OpenAI インスタンスに接続する場合、これらのコンシューマーが直接接続するか、リバース プロキシ API ゲートウェイ経由で接続するかを決定する必要があります。
このガイドでは、コンシューマーから Azure OpenAI データ プレーン API への直接アクセスが含まれるワークフロー設計で発生する、 Azure Well-Architected Framework の 5 つの柱に関する主要な課題について説明します。 次に、アーキテクチャにゲートウェイを導入して、こうした直接アクセスに関する課題を解決する方法について説明し、新しい課題についても紹介します。 この記事では、アーキテクチャ パターンについて説明しますが、ゲートウェイの実装方法については説明しません。
ゲートウェイは特定のシナリオを解決するために使用できますが、これらはどのワークロードにも該当するわけではないため、ゲートウェイの特定のユース ケースの詳細については、 特定のシナリオに関するガイダンスを参照してください。
主な課題
API ゲートウェイがない場合、または Azure OpenAI HTTP API にロジックを追加する機能がない場合は、再試行メカニズムや回線の中断などの API クライアント ロジックをクライアント側で処理する必要があります。 この状況は、クライアント コードを直接制御できない場合や、特定の SDK を使用したコードに制限される場合は、困難になる可能性があります。 複数のクライアントまたは複数の Azure OpenAI インスタンスとデプロイでは、安全なデプロイや監視の調整など、さらなる課題が生じます。
このセクションでは、コンシューマーから Azure OpenAI への直接アクセスのみをサポートしているアーキテクチャで生じる可能性がある、アーキテクチャ上の主な課題の例を示します。 課題は、 Azure Well-Architected Framework の柱に従って整理されています。
信頼性に関する課題
ワークロードの信頼性は、自己保持と自己回復の能力など、いくつかの要因によって決まります。これらは多くの場合、レプリケーションとフェールオーバーのメカニズムを通じて実装されます。 ゲートウェイを使用していない場合、信頼性に関するすべての問題に、クライアント ロジックと Azure OpenAI Service 機能のみで対処する必要があります。 これら 2 つのどちらでも十分な信頼性制御が利用できない場合、ワークロードの信頼性が損なわれます。
冗長性: サービスの可用性に基づいて複数の Azure OpenAI インスタンス間でフェールオーバーを行うことはクライアントの責任であり、構成とカスタム ロジックを通じて制御する必要があります。
スパイクを処理するためのスケールアウト: 調整時に容量のある Azure OpenAI インスタンスにフェールオーバーすることもクライアントの責任であり、構成とカスタム ロジックを通じて制御する必要があります。 新しい Azure OpenAI インスタンスに関する複数のクライアント構成を更新すると、高リスクにつながり、適時性が懸念されます。 要求の多い期間中に優先度の低い要求をキューに送信するなど、ロジックの変更を実装するためにクライアント コードを更新する場合も同様です。
負荷分散/調整: Azure OpenAI API は、従量課金モデルの TPM (1 分あたりのトークン数) または RPM (1 分あたりの要求数) を超える要求に対し、HTTP 429 エラー応答コードを返すことによって要求数を調整します。 Azure OpenAI API は、事前プロビジョニング済み課金モデルの PTU (プロビジョニング済みスループット ユニット数) 容量を超える数の要求についても調整を行います。 適切なバックオフおよび再試行ロジックの処理は、クライアント実装のみに委ねられます。
セキュリティに関する課題
セキュリティ制御により、ワークロードの機密性、整合性、可用性の保護を支援する必要があります。 ゲートウェイを使用していない場合、セキュリティに関するすべての問題に、クライアント ロジックと Azure OpenAI Service 機能のみで対処する必要があります。 ワークロード要件によっては、直接通信のために、クライアント セグメント化、クライアント制御、サービス セキュリティ機能で利用できる以上のものが要求される場合があります。
ID 管理 - 認証スコープ: Azure OpenAI によって公開されるデータ プレーン API は、API キーと Azure ロールベースのアクセス制御 (RBAC) のうち、いずれかを使用して保護できます。 どちらの場合も、認証は個々のデプロイのレベルではなく、Azure OpenAI インスタンスのレベルで行われます。これにより、特定のデプロイ モデルに最小特権アクセスと ID セグメント化を提供するための複雑さが生じます。
ID 管理 - ID プロバイダー: Azure OpenAI インスタンスを支援する Microsoft Entra テナントにある ID を使用できないクライアントは、単一のフルアクセス API キーを共有する必要があります。 API キーにはセキュリティ上の有用性に関する制限があるため、複数のクライアントが関係し、すべてが同じ ID を共有する場合には問題が生じやすくなります。
ネットワーク セキュリティ: Azure OpenAI インスタンスから見たクライアントの場所によっては、言語モデルへのパブリック インターネット アクセスが必要になる場合があります。
データ主権: Azure OpenAI のコンテキストにおけるデータ主権とは、特定の国または地域の地理的境界内で行うデータの保存と処理に関連する法的要件と規制要件を指します。 ワークロードでは、クライアントがデータ所在地とデータ主権に関する法律を遵守できるように、リージョン アフィニティを確認する必要があります。 このプロセスには、複数の Azure OpenAI デプロイが必要になります。
コスト最適化に関する課題
アーキテクチャで無駄を最小限に抑え、実用性を最大化すると、ワークロードのメリットにつながります。 強力なコスト モデリングとコスト監視は、あらゆるワークロードでの重要な要件です。 ゲートウェイを使用していない場合、PTU の使用率またはクライアントごとのコスト追跡を適切に達成する手段は、Azure OpenAI インスタンスの使用状況テレメトリの集計のみです。
コスト追跡: Azure OpenAI の使用状況に関する財務的な観点を提供できる対象は、Azure OpenAI インスタンスの使用状況テレメトリから集約されたデータに限定されます。 チャージバックまたはショーバックを行う必要がある場合、その使用状況テレメトリを、さまざまな部門のさまざまなクライアント、またはマルチテナント シナリオの顧客に帰属させる必要があります。
プロビジョニング済みスループット使用率: ワークロードでは、料金に含まれるプロビジョニング済みスループットをフル活用することで無駄を回避する必要があります。 つまり、従量課金ベースのモデル デプロイへ移行する前に、クライアントは信頼されており、PTU ベースのモデル デプロイを使用するように調整されている必要があります。
オペレーショナル エクセレンスに関する課題
ゲートウェイを使用していない場合、監視、変更制御、開発のプロセスは、クライアントからサーバーへの直接通信によって提供されるものに限定されます。
クォータ制御: HTTP API が調整されると、クライアントは Azure OpenAI から直接 429 応答コードを受け取ります。 ワークロード オペレーターは、正当な使用に対して十分なクォータが利用可能であることと、不適切な動作を行うクライアントによる消費が過剰でないことを確認する責任があります。 ワークロードが複数のモデル デプロイで構成されている場合、クォータの使用状況と クォータの可用性を理解して視覚化することが難しい場合があります。
モニタリングと監視: Azure OpenAI の既定のメトリックは Azure Monitor を介して利用できます。 ただし、データの可用性に伴う待機時間があり、リアルタイムの監視は提供されません。
安全なデプロイ プラクティス: GenAIOps プロセスでは、Azure OpenAI でデプロイされたモデルとクライアントとの間で調整する必要があります。 ブルーグリーンやカナリアなど高度なデプロイ アプローチの場合は、ロジックをクライアント側で処理する必要があります。
パフォーマンス効率に関する課題
ゲートウェイを使用していない場合、ワークロードでは、個々が適切に動作し、限られた容量で他のクライアントと適切に連携することの責任がクライアントに課せられます。
パフォーマンスの最適化 - 優先順位によるトラフィック: 優先順位の高いクライアントが優先順位の低いクライアントよりも優先的にアクセスできるように、クライアント要求に優先順位を付けるには、クライアント間の調整が必要になります。この調整は広範囲にわたり、不合理である可能性があります。 ワークロードによっては、モデルの使用率が低いときに、優先順位の低い要求をキューに入れて実行する方が望ましいことがあります。
パフォーマンスの最適化 - クライアントのコンプライアンス: 容量を共有するには、クライアントが適切に動作する必要があります。
max_tokensとbest_ofが承認済みの値に設定されているかどうかをクライアントが確認することは、その一例です。 ゲートウェイを使用していない場合、Azure OpenAI インスタンスの容量を維持するためにクライアントが最善の動作を行うことを信頼する必要があります。待機時間の最小化: 通常、ネットワーク待機時間は、プロンプトと完了要求フロー全体から見ると小さな要素ですが、クライアントがネットワーク エンドポイントとそれらに近いモデルにルーティングされるようにしておくとプラスになる可能性があります。 ゲートウェイを使用していない場合、クライアントは、使用するモデル デプロイ エンドポイントと、その特定の Azure OpenAI データ プレーン API に必要な資格情報を自己選択する必要があります。
解決策
図 1: ゲートウェイ経由で Azure OpenAI にアクセスする概念アーキテクチャ
「主な課題」に記載されている多くの課題に対処するには、リバース プロキシ ゲートウェイを挿入して、インテリジェント アプリケーションを Azure OpenAI から切り離すことができます。 この ゲートウェイ オフロード により、責任、複雑さ、監視をクライアントから切り離すことができ、組み込まれていない他の機能を提供して Azure OpenAI を拡張する機会を得られます。 いくつかの例を次に示します。
フェデレーション認証の実装が可能。
レート制限を通じてモデルへの負荷を制御する機能。
分野やモデルを横断したモニタリング。
キューベースの負荷平準化 のために優先度の低いメッセージをキューに ルーティング したり、タスクを実行するために計算したりするなど、 ゲートウェイ集約 と高度な ルーティング を複数のサービスに導入する機能。
正常性エンドポイントのモニタリング を使用して、使用できないモデル デプロイ時または過負荷のモデル デプロイ時に 回線を切断 することにより、正常性エンドポイントのみにルーティングする負荷分散。
特定のシナリオには、API ゲートウェイと Azure OpenAI インスタンスを直接扱うガイダンスがさらに多く用意されていることがあります。 これらのシナリオについては、「次のステップ」セクションを参照してください。
考慮事項
新しいコンポーネントをアーキテクチャに導入する際は、新たに生じるトレードオフを評価する必要があります。 いずれかの 主な課題に対処するためにクライアントと Azure OpenAI データ プレーンの間に API ゲートウェイを挿入すると、アーキテクチャに新たな考慮事項が生じます。 アーキテクチャに関するこれらの考慮事項にワークロードが及ぼす効果が、ゲートウェイの付加価値や実用性の十分な根拠になるかどうかを慎重に評価してください。
信頼性
信頼性とは、顧客に確約したことをアプリケーションで確実に実現することです。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。
ゲートウェイ ソリューションによって、単一障害点が生じる可能性があります。 この障害は、ゲートウェイ プラットフォームのサービス可用性、コードまたは構成のデプロイによる中断、さらにはゲートウェイ内のクリティカルな API エンドポイントの構成ミスが原因で発生する可能性があります。 ワークロードの可用性要件が確実に満たされるように実装を設計してください。 実装における復元性とフォールト トレランス機能を考慮して、ワークロードの 障害モード分析 にゲートウェイを含めることをご検討ください。
複数のリージョンに Azure OpenAI インスタンスを必要とするアーキテクチャでは、ソリューションにグローバル ルーティング機能が必要になる場合があります。 この状況により、余分の完全修飾ドメイン名、TLS 証明書、およびさらに多くのグローバル ルーティング コンポーネントの管理が必要になるため、トポロジがさらに複雑になります。
重要
ゲートウェイを実装することで、合意済みのサービス レベル目標 (SLO) を達成するための能力がワークロードから損なわれる場合は、実装しないでください。
セキュリティ
API ゲートウェイがアーキテクチャにどのようにメリットをもたらすかを検討する場合は、 セキュリティに関する設計レビュー チェックリスト を使用して設計を評価します。 セキュリティについては、次のような考慮事項に対処する必要があります。
ゲートウェイを追加すると、ワークロードの対象領域が増加します。 この増加に伴い、Azure リソースの ID およびアクセス管理 (IAM) に関する考慮事項や、強化作業などが増えます。
ゲートウェイは、クライアント ネットワーク空間とプライベート Azure OpenAI ネットワーク空間の間を移行するためのネットワーク境界として使用できます。 ゲートウェイにより、以前はインターネットに接続していた Azure OpenAI エンドポイントがプライベート リンクの使用を通じてプライベートになりますが、ゲートウェイが新しいエントリ ポイントになり、適切な保護が必要になります。
ゲートウェイは、未加工の要求データと言語モデルからの定型応答を参照できる独自の立場にあります。これらのデータや応答には、いずれかのソースからの機密データが含まれる可能性があります。 データ コンプライアンスと規制の範囲は、現在、このような他のコンポーネントにまで拡張されています。
ゲートウェイにより、Microsoft Entra ID と API キーの認証を超えて、場合によっては複数の ID プロバイダー (IdP) にまたがって、クライアントの承認と認証の範囲を拡張できます。
複数のリージョンを実装する場合、実装におけるデータ主権の考慮が必要になります。 ゲートウェイのコンピューティングおよびルーティング ロジックが、ワークロードに対する主権要件に準拠していることを確認してください。
重要
ゲートウェイの実装により、ワークロード自体またはユーザーのデータの機密性、整合性、可用性を保護できなくなる場合は、実装しないでください。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。
実装したすべての API ゲートウェイから、ランタイム コストが発生します。これについては、予算を策定して考慮する必要があります。 これらのコストは通常、ゲートウェイ自体の信頼性、セキュリティ、パフォーマンスに対処するための追加機能に加え、APIOps 管理の追加によって生じる運用コストによって増加します。 これらの追加コストは、ゲートウェイを備えたシステムから提供される新しい価値に照らし合わせて評価する必要があります。 ゲートウェイを使用することで導入される新しい機能によるメリットが、ゲートウェイの実装と保守にかかるコストを上回る状態に達することが望まれます。 ワークロードとユーザーの関係によっては、使用分をチャージバックできる場合があります。
オペレーショナル エクセレンス
API ゲートウェイがアーキテクチャにどのようにメリットをもたらすかを検討する場合は、 オペレーショナル エクセレンスに関する設計レビュー チェックリスト を使用して設計を評価します。 オペレーショナル エクセレンスについては、次のような考慮事項に対処する必要があります。
ゲートウェイ自体は、ワークロードの監視ソリューションで、また場合によってはクライアントで監視する必要があります。 これは、ゲートウェイのコンピューティングと操作をワークロードの 正常性モデリングに含める必要があることを意味します。
安全なデプロイ プラクティスでは、API ゲートウェイ インフラストラクチャのデプロイと、ゲートウェイ ルーティングのコードまたは構成に対処する必要があります。 インフラストラクチャの自動化と IaC (コードとしてのインフラストラクチャ) ソリューションでは、ゲートウェイをワークロード内で有効期間の長いリソースとして扱う方法を検討する必要があります。
ゲートウェイで公開されている API をカバーするには、APIOps アプローチを構築または拡張する必要があります。
パフォーマンス効率
API ゲートウェイがアーキテクチャにどのようにメリットをもたらすかを検討する場合は、 パフォーマンス効率に関する設計レビュー チェックリスト を使用して設計を評価します。 パフォーマンス効率については、次のような考慮事項に対処する必要があります。
ゲートウェイ サービスにより、スループットのボトルネックが発生する可能性があります。 ゲートウェイが完全な同時負荷を処理できる十分なパフォーマンスを備えており、成長予測に合わせて簡単に拡張できることを確認します。 普通営業日の使用など、需要が低いときにゲートウェイが供給を削減 (スケールダウン) できるように、ソリューションの弾力性を確保してください。
ゲートウェイ サービスには要求ごとに実行を要する処理があり、API 呼び出しごとに追加の待ち時間が発生します。 要求のパフォーマンスを良好に保つには、ルーティング ロジックを最適化する必要があります。
ほとんどの場合、待機時間を短縮するには、ゲートウェイをユーザーと Azure OpenAI インスタンスの両方から地理的に近い場所に配置する必要があります。 通常、ネットワーク待機時間が言語モデルへの API 呼び出し全体の時間に占める割合はわずかですが、ワークロードの競合要因となる可能性があります。
ストリーミング応答や、Assistants API などのステートフルなやり取りを行うためのインスタンスの固定など、Azure OpenAI の機能に対するゲートウェイの影響を評価します。
重要
ゲートウェイを実装することで、取り決められたパフォーマンス目標の達成が不可能になったり、他のトレードオフが過度に犠牲になったりする場合は、ゲートウェイを実装しないでください。
実装オプション
Azure では、Azure OpenAI の HTTP API やその他のカスタム言語モデル推論 API をプロキシするために特別に設計されたターンキー ソリューションは提供されていません。 ただし、Azure にゲートウェイを実装するなど、ワークロード チームが実装できるオプションはいくつかあります。
Azure API Management の使用
Azure API Management は、HTTP ベースの API に関する横断的な問題を軽減するために設計されたプラットフォーム管理サービスです。 これは構成駆動型であり、受信および送信した要求を処理するポリシー システムによるカスタマイズをサポートします。 単一のコントロール プレーンを使用することで、高可用性、ゾーン冗長、さらには複数リージョンのレプリカをサポートします。
ゲートウェイ ルーティングと要求処理ロジックのほとんどは、API Management のポリシー システムに実装する必要があります。 組み込みのポリシー (Azure OpenAI API トークンの使用を制限する または Azure OpenAI トークンを使用するためのメトリックを出力するなど) と、独自のカスタム ポリシーを組み合わせることができます。 カスタム ポリシーとシナリオの例は、 API Management ゲートウェイ ツールキット コミュニティの GitHub リポジトリで確認できます。
Azure API Management を含むソリューションを設計する場合は、 API Management の Well-Architected Framework サービス ガイド を使用します。
一般に、ゲートウェイの実装に Azure API Management を使用することが、Azure OpenAI ゲートウェイの構築と運用に推奨されるアプローチです。 このサービスが推奨されるのは、豊富な組み込み機能、高可用性、ネットワーク オプションを備えた PaaS (サービスとしてのプラットフォーム) オファリングであるためです。 また、完了 API を管理するための堅牢な APIOps アプローチも用意されています。
カスタム コードを使用する
カスタム コードのアプローチでは、ソフトウェア開発チームがカスタム コードのソリューションを作成し、チームが選択した Azure アプリケーション プラットフォームにソリューションをデプロイする必要があります。 ゲートウェイ ロジックを処理する自己管理ソリューションの構築は、ネットワークとルーティング コードの管理に熟練したワークロード チームに適しています。
ワークロードでは通常、Azure App Services、Azure Container Apps、または Azure Kubernetes Service でゲートウェイ コードをホストするなど、使い慣れたコンピューティングを使用できます。
カスタム コードのデプロイには API Management を使用することもできます。この場合、API Management は、クライアントとカスタム コードの間のコア HTTP API ゲートウェイ機能のみに使用されます。 このように、カスタム コードでは、必要なビジネス ロジックに基づいて、Azure OpenAI HTTP API のみとやり取りします。
Azure によってネイティブ提供されていない製品またはサービスである、Microsoft 以外のゲートウェイ テクノロジの使用を、このアプローチの一部として検討することもできます。
サンプル アーキテクチャ
図 2: Azure API Management ベースのゲートウェイを介して Azure OpenAI にアクセスするアーキテクチャの例
次のステップ
インテリジェント アプリケーションと Azure OpenAI デプロイの間にゲートウェイをデプロイしてワークロード要件に対処する特定のシナリオについて説明します。
Azure OpenAI モデルのログと監視を実装する方法について説明します。