こんにちは。ISID AIトランスフォーメーションセンターの山田です。
本記事では、Azure OpenAI ServiceとAzure AppServiceを利用したアプリケーション開発に当たってのアーキテクチャ設計のポイントを、通信経路の選択やスケーラビリティ、監視の観点から紹介したいと思います。
- 前提
- 想定アーキテクチャ
- Azure OpenAI Serviceをデプロイできるリージョンの制約を把握する
- アプリケーションとAzure OpenAI Serviceの通信経路を選択する
- スケーラビリティの考慮
- 監視・正常性チェック
- その他の要件を検討する
- 最後に
- 参考リンク
前提
前提知識としてAzure OpenAI ServiceとAzure App Serviceについて紹介します。
Azure OpenAI Serviceとは？
Azure OpenAI Serviceは、Azure Cognitive Servicesの一部として位置づけられてます。 Azure Cognitive Servicesは、API呼び出しによってAI系のソリューションを提供する PaaS ソリューションになります。
Azure OpenAI Serviceを利用すると、最近話題のChatGPTやGPT-4などのLLMをAPI経由で利用でき自社のシステムに取り入れることができます。
Azure App Serviceとは？
Azure App Serviceは、WebアプリケーションなどHTTPベースのサービスをホストする PaaS ソリューションになります。
Azure App ServiceではDockerイメージをもとにしたコンテナデプロイにも対応でき、アプリケーション開発者がインフラの運用コストを下げながらサービスを提供できます。
Azure App Serviceで少しややこしいのは、Azure App Serviceでアプリケーションをデプロイするには「Azure App Service プラン」というリソースを作成する必要があります。 Azure App Serviceプランは、Azure App Serviceのインフラ部分を抽象化したリソースであり、裏側は Azure の仮想マシンによって構成されています。 そのため、アプリケーションの基盤で利用するOSやデプロイするリージョン、マシンスペックなどは、Azure App Serviceプランによって決まります。
Azure App Serviceを利用する場合は、Azure App Serviceプランの単位でアプリケーションの実行環境を借りるといったイメージを持っておくと良いでしょう。
想定アーキテクチャ
本記事の内容は、 AppServiceとAzure OpenAI Serviceによって構築するアーキテクチャを想定しています。
Azure OpenAI Serviceをデプロイできるリージョンの制約を把握する
2023年7月現在、Azure OpenAI Service モデルはモデル毎にデプロイできるリージョンに制約があります。
そのためこの制約を考慮してアーキテクチャの設計をする必要があります。
参考までにChatGPT系で利用されるGPT-4やGPT-3.5のモデルは以下のリージョンでのみデプロイ可能です。
| モデルID | デプロイ可能なリージョン |
|---|---|
| gpt-4 | 米国東部、フランス中部 |
| gpt-4-32k | 米国東部、フランス中部 |
| gpt-35-turbo (0301) | 米国東部、フランス中部、米国中南部、英国南部、西ヨーロッパ |
| gpt-35-turbo (0613) | 米国東部、フランス中部、英国南部 |
| gpt-35-turbo016k (0613) | 米国東部、フランス中部、英国南部 |
モデルごとにどのリージョンでデプロイできるかの詳細情報はMicrosoft公式のAzure OpenAI Service モデルのページをご覧ください。
アプリケーションとAzure OpenAI Serviceの通信経路を選択する
Azure App ServiceでホストされたアプリケーションとAzure OpenAI Serviceをどのように通信させるかを考える必要があります。
ここでは以下の3つのシナリオを取り上げます。
- 設定をしないパブリックIPを用いた通信
- サービスエンドポイントによる通信
- プライベートエンドポイントによる通信
設定をしないパブリックIPを用いた通信
特に何も設定をしない場合、Azure App ServiceとAzure OpenAI Service間はパブリックIPを用いて通信相手を特定しての通信が行われます。
ただし、この場合でもAzureのリソース間の通信はインターネット越しではなくMicrosoftのネットワークを介して行われます*1。
このアプローチは検証作業には有効ですが、運用を見据えたアプリケーションを構築する際にネットワークに制限を設ける必要がある場合は別の手法を検討する必要があります。
サービスエンドポイントによる通信
サービスエンドポイントを利用することで、素のパブリックIPを用いた通信よりも最適化され、よりセキュアな通信を実現できます。
サービスエンドポイントを用いて、Azure AppService と Azure OpenAI Serviceを実現するためには、それぞれに追加の設定をする必要があります。
Azure App Service のVNet統合の有効化
Azure AppS erviceからのトラフィックをAzureの仮想ネットワークに流すために、VNet統合（仮想ネットワークの統合）機能を利用する必要があります。 VNet統合はBasicプラン以上のAzure App Serviceプランで利用できます。
VNet統合はAzure App Serviceに対し、特定のVNet内のサブネットを統合します。 Azure App Service からのアウトバウンドのトラフィックがこのサブネット内に流れるようになります。
Azure OpenAI Service のネットワーク制約の追加
Azure OpenAI Serviceでは、ネットワーク制約を追加して、Azure App Serviceに統合されているサブネットからのみアクセスを受けるようにします。 これによって、Azure 内部で最適化された経路で、Azure App ServiceとAzure OpenAI Serviceをつなぐことができます。
プライベートエンドポイントによる通信
プライベートエンドポイントでの通信では、接続先をプライベートIPで指定して通信を行う形になります。
プライベートエンドポイントでの通信をするためには、サービスエンドポイントと同様に Azure App Service側は、VNet統合機能を利用し、アウトバウンドトラフィックが仮想ネットワーク内に流れるように構成をします。 そして、Azure OpenAI Service側ではプライベートエンドポイントを構成します。
プライベートエンドポイントを構成すると、仮想ネットワーク内にネットワークインターフェースが作成されプライベートIPを用いてAzure OpenAI Serviceと通信が可能になります。
プライベートエンドポイントは最もセキュアな構成ですが、サービスエンドポイントとは異なり、追加で料金が発生します。
どの通信経路を選択するか？
最終的にどの通信経路を選択するかはアプリケーションの要件に依存しますが、ベースラインとしてはサービスエンドポイントがおすすめです。
サービスエンドポイントはプライベートエンドポイントとは異なり、追加料金は発生しません。さらに、今回の想定ではAzureのPaaSソリューション間の通信になるので、プライベートエンドポイントで通信を構成するのは過剰な構成とも考えられます。
スケーラビリティの考慮
スケーラビリティについて考慮するにあたっては、Azure App ServiceとAzure OpenAI Serviceのそれぞれ側面で考えなければいけません。
Azure App Serviceのスケーラビリティ
Azure App Serviceはスケーラビリティについて柔軟な選択肢が用意されています。
サービスプランを上げることでサーバスペックを向上させるスケールアップ、CPUやメモリのメトリクスに基づいてインスタンス数を増減させるルールベースのスケールアウト、まだプレビューですがHTTPのリクエスト数に応じた自動スケールも可能です。
なおAzure App Serviceのスケールアップについては、App Serviceプランの価格レベルの変更を伴うので注意が必要です。
コスト面と求める性能を考慮して、最適な方法を選択するのが良いでしょう。
Azure OpenAI Serviceのクォーター制限
Azure OpenAI Serviceのクォーター制限について考慮しておく必要があります。
特に1分間で使用できるトークン数の制限については考慮しておかなければなりません。以下はモデルごとに1分間で使用できるトークン数です。
| モデル名 | 1分間で使用できるトークン数（デフォルト値） |
|---|---|
| GPT-4 | 20K |
| GPT-4-32K | 60K |
| その他すべて | 240K |
アプリケーションにスケーラビリティが備わっていたとしても、1分間に使用できるトークン数を超えてしまうとAzure OepnAI Serviceからエラーが返されるため十分に機能を満たすことができない場合があります。
ですのでスケーラビリティについて考える際はクォーター制限も考慮してコミュニケーションを取る必要があります。
監視・正常性チェック
アプリケーションを運用していく場合、アプリケーションが正常に稼働しているかを知るために監視や正常性チェックを構成するのがおすすめです。
今回のようにAzure App ServiceとAzure OpenAI ServiceでAzureのPaaSソリューションを組み合わせて利用する場合は、それぞれに正常性チェックを構成しておきましょう。
それぞれにリソースに正常性チェックを構成をしておくことで、アプリケーションがダウンしているなどの問題が発生した際にApp Service側の問題なのかAzure OpenAI Service側の問題なのかを判断することができます。
Azure App Serviceの監視・正常性チェック
Azure App Serviceでは、デプロイしたアプリケーションの特定のパスに対して定期的にリクエストを送信し、正常なレスポンスが返ってくるかでインスタンスの正常性を確認できます。
これは複数インスタンスで運用している場合、インスタンスの削除・置き換えにも利用されます。
アプリケーションにヘルスチェック用のエンドポイントを用意しておくことで、簡単に正常性チェックを組むことが可能です。
Azure OpenAI Serviceの監視・正常性チェック
Azure OpenAI Servcieではリソース正常性とアラートを構築することで、サービスの稼働状況について通知を構成できます。
Azure OpenAI ServiceはCognitive Servicesの1つとしてSLAが定められていますが、まだまだ不安定なリソースでダウンすることがあります。
それぞれに監視と通知（アラート）を構成しておくことで稼働状況を把握し原因の切り分けが可能になります。
その他の要件を検討する
ここまで紹介をしたポイント以外の要件に対応することが求められる場合についても簡単に書いておきます。
例えば、アプリケーションに認証が必要な場合は、Azure App Serviceの組み込みの認証機能（Easy Auth）を使うのが良いでしょう。
他にもアプリケーションログのアーカイブや転送が必要であれば、Azure App Serviceの診断設定によって対応できることがあります。
最後に
本記事では、Azure OpenAI ServiceとAzure App Serviceを使ったアプリケーションのアーキテクチャを設計するにあたってポイントとなる事項をまとめて紹介しました。
これらの内容は他のAzureのPaaS系ソリューションでも応用できる部分があります。
PaaS系ソリューションによってでできることの幅は広がっていますが仕様上の制約によっては、対応可能な要件が絞られる場合もあります。
それらを理解した上で実現可能な範囲を明確にし、関係者とコミュニケーションを取ることが大切です。
参考リンク
- Cognitive Services - AI ソリューション向け API | Microsoft Azure
- Azure OpenAI Service モデル - Azure OpenAI | Microsoft Learn
- アプリを Azure 仮想ネットワークと統合する - Azure App Service | Microsoft Learn
- Azure OpenAI Service のクォータと制限 - Azure Cognitive Services | Microsoft Learn
- サービス エンドポイントとプライベート エンドポイントの違い | Japan Azure IaaS Core Support Blog