生成AIチャットボットのリファレンスアーキテクチャ（信頼性・スケーラビリティ・必要コスト）

# はじめに
以下のブログでリファレンスアーキテクチャについてコンポーネント軸でご紹介しました。今回はリファレンスアーキテクチャの（1）信頼性、（2）スケーラビリティ、（3）必要コストの観点で確認していきます。[Microsoftのドキュメント](https://learn.microsoft.com/ja-jp/azure/architecture/ai-ml/architecture/baseline-openai-e2e-chat?WT.mc_id=DT-MVP-4039781#architecture)をベースに紹介していますので、詳細気になる方は合わせてご確認ください。

https://qiita.com/k-kimino/items/b0ba4286520a71b81ddf

# 信頼性
可用性ゾーンを使用することでリージョン内の物理的に離れた場所で冗長化を図ります。可用性ゾーンはAzureサービスごとに設定が用意されているため、それぞれのサービスの視点で検討が必要です。現状、Azure Machine LearningおよびAzure OpenAI Serviceについては可用性ゾーンがサポートされていないため、データセンター規模の障害に備えるためにはリージョン冗長を検討する必要があります。以下では実際にリファレンスアーキテクチャをデプロイした際の設定値を確認していきます。

## Azure Application Gateway
Azure Application Gateway v2をデプロイすることでゾーン冗長を満たします。以下の画面では最小インスタンス数が2になっていますが、障害発生時に6~7分の起動時間を回避したい場合は最小インスタンスを3以上にすることが推奨されています。

![AGW-zone.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3322105/570e0a60-d7b0-5d92-376c-d915a4bfed8d.png)

## App Service
可用性ゾーンをサポートする3つ以上のApp Servicesインスタンスをデプロイすることでゾーン冗長を満たします。以下の画面ではインスタンス数が3になっていることを確認できます。

![AppService-zone.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3322105/37df4f36-6980-8380-dab8-076374123032.png)

## Azure Machine Learning
現状、Azure Machine Learningのコンピューティングクラスターは可用性ゾーンをサポートしていません。回避策としてはプロンプトフローをAzure Machine Learningのコンピューティングクラスター上にデプロイするのではなく、チャットUIのようにAzure App Serviceなどにデプロイする方法が考えられます。

## Azure OpenAI Service
現状、Azure OpenAI Serviceは可用性ゾーンをサポートしていません。データセンターレベルの大災害による影響を軽減するためには、Azure OpenAI Serviceを複数リージョンでデプロイし、ロードバランサーにより負荷分散する方法が考えられます。

## Azure AI Search
可用性ゾーンをサポートするリージョンにStandard以上のSKUをデプロイすることでレプリカを作成することができるようになります。読み取り/書き込み操作で99.9%の可用性を得るためには3つ以上のレプリカが必要です。以下の図ではFree SKUを使っているためレプリカ数を変更することができません。価格レベルはアップグレードできないため、ゾーン冗長が必要な場合最初からStandard以上のSKUにする必要があります。

![AzureAISearch-zone.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3322105/0c098a4b-fe4c-2457-c750-6231aa1d826f.png)

# スケーラビリティ
ユーザーの要求に合わせて効率的な方法でワークロードをスケーリングすることでパフォーマンスを最適化します。Azureサービスごとに設定が用意されているため、それぞれの観点から検討が必要です。以下では実際にリファレンスアーキテクチャをデプロイした際の設定値を確認していきます。

## App Service
リファレンスアーキテクチャを[GitHub](https://github.com/Azure-Samples/openai-end-to-end-baseline?tab=readme-ov-file)からデプロイした場合、Premium v2 P2V2（2vCPU, 7GB RAM）の3インスタンスの冗長構成で動作しています。自動スケーリングを設定することでリソースの使用状況に応じてスケールアウトとスケールインを実行するルールを規定できます。以下の図ではCPU使用率が70%を超えた場合にインスタンスを1増やすルールが設定されています。
![AppService-Autoscaling.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3322105/14a6e672-3a96-220c-8868-e9e0f89d0499.png)

## Azure OpenAI Service
プロビジョニングされたスループットを要求することでリソースを予約し、安定した待ち時間を見込むことが可能です。パフォーマンス要件によっては共有ホスティングモデルを使用することでコスト効率のよいモデルを使用することができます。以下の画面の下部でプロビジョニングスループットユニット（予約するスループットの量）を指定してデプロイすることが可能です。筆者のアカウントはgpt-4の利用申請を行っていないため、利用可能なクォータ（時間あたりに利用可能なトークン数の単位）がないためにエラーが表示されています。
![AzureOpenAI-PTU.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3322105/13c09b12-faaf-c80d-a930-9f57203494de.png)

## Azure Machine Learning
Azure Machine LearningのCompute Clusterスケーリングの設定を行うことで使用状況に応じてスケールアウトとスケールインを実行するルールを規定できます。以下の図のように規定では手動スケーリングの設定のままですが、パフォーマンス観点では自動スケーリングの設定をしておいた方がよいです。
![MachineLearning-AutoScaling.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3322105/a9b37a39-1a10-79e3-15ed-2d4889b400a1.png)

# 必要コスト
今回のリファレンスアーキテクチャを実行するのに必要なAzureコストの見積の詳細は[こちら（Microsoftサイト）](https://azure.microsoft.com/en-us/pricing/calculator/?shared-estimate=a5a243c3b0794b2787e611c65957217f)から確認できます。以下の画像がコスト見積のサマリになります。今回のケース（アプリのインスタンス数3の最小構成）で\\$4,424/月必要となり目安としてご確認いただけるかと思います。また本構成で最も高価なコンポーネントはチャットUIを実行するApp Service（\\$876/月）とAzure AI Search（\\$1,962/月）であることがわかります。
![AIChat-CostEstimate.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3322105/e8fbff10-2b9d-55eb-5b2f-2a1098e6b485.png)

# まとめ
AIチャットボットのリファレンスアーキテクチャについて、信頼性、スケーラビリティ、必要コストの観点で確認しました。コストについては最低限の規模感でも月額60万円のコストが必要となりそうな感覚がつかめました。コンピューティングリソースやAzure OpenAI Serviceは利用量によってスケールするサービスなので、規模が10倍になれば価格もその分大きくなり、月額数百万円のコストが必要となりそうです。監視やパフォーマンスについてチェックできておらず、どの規模のユースケースに対応できるのか考察できていないので、その辺りの深掘りを今後していきたいと思っています。