Azure OpenAI Service 上の Azure Well-Architected フレームワークの分析観点
Azure OpenAI Service は、OpenAI の大規模言語モデル (LLM) への REST API アクセスを提供し、Azure ネットワークとセキュリティの機能を追加します。 この記事では、ワークロードのアーキテクチャの一部として Azure OpenAI を使用する場合に、情報に基づいた意思決定を行うのに役立つアーキテクチャに関する推奨事項について説明します。 このガイダンスは、Azure Well-Architected フレームワークの柱に基づいています。
重要
このガイドを使用する方法
各セクションには、"設計チェックリスト" があり、アーキテクチャの関心領域と、テクノロジ スコープに限定した設計戦略が示されています。
これらの戦略の具体化に役立つテクノロジ機能に関する "推奨事項" も含まれています。 これらの推奨事項は、Azure OpenAI とその依存関係で利用できるすべての構成の完全な一覧とはなっていません。 そうではなく、設計パースペクティブにマップされた主要な推奨事項が一覧表示されます。 推奨事項を使用して概念実証を構築するか、既存の環境を最適化してください。
主要な推奨事項をデモする基本的なアーキテクチャ: OpenAI のベースラインとなるエンド ツー エンド チャットのリファレンス アーキテクチャ。
テクノロジ スコープ
このレビューでは、Azure OpenAI のみに焦点を当てます。
信頼性
信頼性の柱の目的は、十分な回復性と障害から迅速に復旧する能力を構築することで、継続的な機能を提供することです。
信頼性の設計原則は、個々のコンポーネント、システム フロー、およびシステム全体に適用されるおおまかな設計戦略を提供します。
設計チェック リスト
信頼性の設計レビュー チェックリストに基づいて、設計戦略を開始します。 これの自分のビジネス要件との関連性を判断します。 必要に応じて、より多くのアプローチを含むように戦略を拡張します。
回復性: ユース ケースに基づいて従量課金制またはプロビジョニングされたスループットの内のどちらか適切なデプロイ オプションを選択します。 予約容量によって回復性が向上するため、運用ソリューションに対してはプロビジョニングされたスループットを選択します。 従量課金制のアプローチは、開発/テスト環境に最適です。
冗長性: Azure OpenAI デプロイの前に適切なゲートウェイを追加します。 このゲートウェイには、一時的な障害に耐え、複数の Azure OpenAI インスタンスへのルーティングも行うスロットリングなどの機能を持たせる必要があります。 リージョンの冗長性を構築するには、異なるリージョン内のインスタンスへのルーティングを検討してください。
回復性: プロビジョニングされたスループットを使用している場合は、オーバーフローを処理するための従量課金制インスタンスのデプロイも検討してください。 プロビジョニングされたスループット モデルがスロットリングされたときに、ゲートウェイ経由で従量課金制インスタンスに呼び出しをルーティングすることができます。
回復性: 容量の使用状況を監視して、スループットの制限を超えないようにします。 容量の使用状況を定期的に確認して、より正確な予測を実現し、容量の制約によるサービスの中断を防ぎます。
回復性: 大規模なデータ ファイルに関する微調整のガイダンスに従って Azure BLOB ストアからデータをインポートします。 100 MB 以上の大規模ファイルは、マルチパート フォームを通してアップロードすると不安定になる可能性があります。これは要求がアトミックであり、再試行や再開が行えないためです。
復旧: 微調整されたモデルと、Azure OpenAI にアップロードされたトレーニング データの復旧計画を含む復旧戦略を定義します。 Azure OpenAI には自動フェールオーバーがないため、サービス全体とすべての依存関係 (トレーニング データを含むストレージなど) をカバーする戦略を設計する必要があります。
推奨事項
| 推奨事項 | 特長 |
|---|---|
| 従量課金制のレート制限の監視: 従量課金制のアプローチを使用している場合は、モデル デプロイのレート制限を管理し、1 分あたりのトークン数 (TPM) と 1 分あたりの要求数 (RPM) の使用状況を監視します。 | この重要なスループットに関する情報は、クォータからデプロイの需要を満たすために十分な TPM を割り当てられるようにするのに必要な情報を提供します。 十分なクォータを割り当てることで、デプロイされたモデルへの呼び出しのスロットリングが防止されます。 |
| プロビジョニングされたスループットのプロビジョニング管理された使用率の監視: プロビジョニングされたスループット支払いモデルを使用している場合は、プロビジョニング管理された使用率を監視します。 | デプロイされたモデルへの呼び出しのスロットリングを防ぐためには、プロビジョニング管理された使用率を監視してそれが 100% を超えないようにすることが重要です。 |
| 動的クォータ機能の有効化: ワークロード予算でサポートされている場合は、モデル デプロイ上の動的クォータを有効にすることで、オーバープロビジョニングを実行します。 | 動的クォータを使用すると、Azure の観点から利用可能な容量がある限り、クォータで通常使用できるよりも多くの容量をデプロイで使用できます。 余分なクォータ容量によって望ましくないスロットリングを防げる可能性があります。 |
| コンテンツ フィルターの調整: コンテンツ フィルターを調整して、過度にアグレッシブなフィルターが原因の誤検知を最小限に抑えます。 | コンテンツ フィルターは、不透明なリスク分析に基づいてプロンプトまたは補完をブロックします。 ワークロードの想定されている使用は許可するようにコンテンツ フィルターが調整されていることを確認します。 |
セキュリティ
セキュリティの柱の目的は、ワークロードに機密性、整合性、可用性の保証を提供することです。
セキュリティ設計原則は、Azure OpenAI を中心とした技術設計にアプローチを適用することで、これらの目標を達成するための高度な設計戦略を提供します。
設計チェック リスト
セキュリティの設計レビュー チェックリストに基づいて設計戦略を開始し、セキュリティ態勢を改善するための脆弱性と管理策を特定します。 次に、Azure OpenAI の Azure セキュリティ ベースラインを確認します。 最後に、必要に応じて、より多くのアプローチを含めるように戦略を拡張します。
機密性を保護する:トレーニング データを Azure OpenAI にアップロードする場合は、データ暗号化にカスタマー マネージド キーを使用し、キー ローテーション戦略を実装して、トレーニング、検証、トレーニング結果のデータを削除します。 トレーニング データに外部データ ストアを使用する場合は、そのストアのセキュリティのベスト プラクティスに従ってください。 たとえば、Azure Blob Storage の場合、暗号化にカスタマー マネージド キーを使用し、キー ローテーション戦略を実装します。 マネージド ID ベースのアクセスを使用し、プライベート エンドポイントを使ってネットワーク境界を実装し、アクセス ログを有効にします。
機密性を保護する:Azure OpenAI リソースがアクセスできる送信 URL を制限することで、データ流出から保護します。
整合性を保護する:最小特権の原則を使用し、キーではなく個人の ID を使用して、システムへのユーザー アクセスを認証および認可するためのアクセス制御を実装します。
整合性を保護する:ジェイルブレイク リスク検出を実装して、言語モデルのデプロイをプロンプト インジェクション攻撃から保護します。
可用性を保護する:セキュリティ管理策を使用して、モデルの使用量クォータを使い果たす可能性のある攻撃を防ぎます。 ネットワーク上のサービスを分離するように管理策を構成することもできます。 インターネットからサービスにアクセスできる必要がある場合は、ゲートウェイを使用して、ルーティングまたはスロットリングの使用により乱用の疑いをブロックすることを検討してください。
推奨事項
| 推奨事項 | 特長 |
|---|---|
| キーをセキュリティで保護する:アーキテクチャで Azure OpenAI キーベースの認証が必要な場合は、それらのキーをアプリケーション コードではなく Azure Key Vault に保存します。 | シークレットを Key Vault に格納してコードから分離すると、シークレットが漏洩する可能性が低くなります。 また、分離によりシークレットの一元管理が容易になり、キーのローテーションなどの責任が軽減されます。 |
| アクセスを制限する:ワークロードで必要な場合を除き、Azure OpenAI へのパブリック アクセスを無効にします。 Azure 仮想ネットワーク内のコンシューマーから接続する場合は、プライベート エンドポイントを作成します。 | Azure OpenAI へのアクセスを制御すると、承認されていないユーザーからの攻撃を防ぐことができます。 プライベート エンドポイントを使用すると、アプリケーションとプラットフォーム間のネットワーク トラフィックが非公開に保たれます。 |
Microsoft Entra ID:Microsoft Entra ID を認証に使用し、ロールベースのアクセス制御 (RBAC) を使って Azure OpenAI へのアクセスを認可します。 Azure AI サービスでローカル認証を無効にし、disableLocalAuth を true に設定します。 補完または画像生成を実行する ID に、Cognitive Services OpenAI ユーザー ロールを付与します。 モデル自動化パイプラインとアドホック データ サイエンスのアクセスに、Cognitive Services OpenAI 共同作成者などのロールを付与します。 |
Microsoft Entra ID を使用すると、ID 管理コンポーネントが一元化され、API キーの使用が不要になります。 Microsoft Entra ID で RBAC を使用すると、ユーザーまたはグループがジョブを実行するために必要なアクセス許可を正しく持つことができます。 Azure OpenAI API キーでは、この種のきめ細かいアクセス制御はできません。 |
| カスタマー マネージド キーを使用する:Azure OpenAI にアップロードされる微調整されたモデルとトレーニング データには、カスタマー マネージド キーを使用します。 | カスタマー マネージド キーを使用すると、アクセス制御の作成、ローテーション、無効化、取り消しをより柔軟に行うことができます。 |
| 脱獄の攻撃から保護する:Azure AI Content Safety Studio を使用して脱獄のリスクを検出します。 | 脱獄の試みを検出し、Azure OpenAI デプロイの安全メカニズムをバイパスしようとするプロンプトを特定してブロックします。 |
コストの最適化
コストの最適化は、支出パターンを検出し、重要な領域への投資を優先し、その他への投資を最適化することに重点を置いて、ビジネス要件を満たしながら組織の予算に合わせます。
「コスト最適化設計の原則」を参照して、それらの目標を達成するためのアプローチと Azure OpenAI に関連する技術的な設計の選択に必要なトレードオフについて確認してください。
設計チェック リスト
コスト最適化の設計レビュー チェックリストに基づいて、投資の設計戦略を開始します。 ワークロードが割り当てられた予算に合ったものとなるように設計を微調整します。 設計では、適切な Azure 機能を使用し、投資を監視し、時間をかけて最適化する機会を見つける必要があります。
コスト管理: プロンプト サイズを考慮して、コスト モデルを開発します。 プロンプト入力および応答のサイズと、テキストがどのようにトークンに変換されるかを理解することは、現実的なコスト モデルを作成するのに役立ちます。
使用状況の最適化: トークンの使用量が予測可能になるまでは、Azure OpenAI に対して従量課金制価格を使用します。
レートの最適化: トークンの使用量が一定期間にわたって十分に高く予測可能な場合は、コスト最適化のためにプロビジョニングされたスループット価格モデルを使用します。
使用状況の最適化: モデルを選択する際にはモデル価格と機能を検討してください。 テキスト生成や補完タスクなどの複雑でないタスクに対しては、まずコストの低いモデルを使用します。 言語翻訳やコンテンツの解釈などのより複雑なタスクに対しては、より高度なモデルの使用を検討してください。 テキスト埋め込み、画像生成、文字起こしのシナリオなどのユース ケースに適したモデルを選択する場合は、さまざまなモデルの機能と最大トークン使用量の制限を考慮します。 ニーズに最も適したモデルを慎重に選択することで、必要なアプリケーション パフォーマンスを実現しながらコストを最適化できます。
使用状況の最適化: 生成するべき補完の数を示す
max_tokensやnなどの API 呼び出しによって提供されるトークン制限制約を使用します。使用状況の最適化: たとえば、微調整や画像生成などのモデル ブレークポイントに関して Azure OpenAI 価格ブレークポイントを最大限に利用します。 微調整に対する課金は 1 時間ごとに行われるため、次の請求期間にはみださないようにしながら、1 時間あたりに利用できる時間をできるだけ長く使用して、微調整の結果を向上させます。 同様に、100 個の画像を生成するためのコストは、1 個の画像のコストと同じです。 自分の有利になるように価格ブレークポイントを最大限に利用します。
使用状況の最適化: 未使用の微調整されたモデルは使用されなくなったタイミングで削除して、継続的なホスティング料金が発生することを防ぎます。
使用方法の調整: プロンプト入力と応答の長さを最適化します。 プロンプトが長いほど、より多くのトークンを消費することでコストが高くなります。 ただし、十分なコンテキストが欠けているプロンプトは、モデルが良い結果を生成する助けにはなりません。 モデルが有用な応答を生成するのに十分なコンテキストを提供する簡潔なプロンプトを作成します。 また、応答の長さの制限を最適化することも忘れないでください。
コスト効率: 呼び出しごとのオーバーヘッドを最小限に抑えるために可能な限りバッチ要求を行うことで、全体的なコストを削減できます。 バッチ サイズを最適化することを忘れないでください。
コスト効率: モデルの微調整コストはそれぞれ異なるため、ソリューションで微調整が必要な場合は、それぞれのコストを考慮します。
監視と最適化: モデルの使用状況を監視するコスト追跡システムを設定します。 その情報を使用して、モデルの選択とプロンプト サイズを決定します。
推奨事項
| 推奨事項 | 特長 |
|---|---|
制限を設定するようにクライアント コードを設計する: カスタム クライアントでは、モデルあたりのトークン数の上限 (max_tokens) や生成するべき補完の数 (n) などの Azure OpenAI completions API の制限機能を使用する必要があります。 制限を設定することで、サーバーがクライアントのニーズ以上のものを生成しないことが保証されます。 |
API 機能を使用して使用を制限することで、サービス消費がクライアントのニーズに合うようになります。 これにより、モデルが必要以上に多くのトークンを消費する長い応答を生成することがなくなりコストを節約できます。 |
| 従量課金制の使用状況の監視: 従量課金制のアプローチを使用する場合は、TPM と RPM の使用状況を監視します。 その情報を使用して、どのモデルを使用するべきかなどのアーキテクチャ設計に関する判断を行い、プロンプト サイズを最適化します。 | TPM と RPM を継続的に監視することで、Azure OpenAI モデルのコストを最適化するために必要なメトリックが手に入ります。 この監視をモデル機能とモデル価格と組み合わせることで、モデルの使用状況を最適化できます。 また、この監視を使用してプロンプト サイズを最適化することもできます。 |
| プロビジョニングされたスループットの使用状況の監視: プロビジョニングされたスループットを使用する場合、プロビジョニング管理された使用率を監視することで、購入済みのプロビジョニングされたスループットの利用が不十分ということがないことを確認します。 | プロビジョニング管理された使用率を継続的に監視することで、プロビジョニングされたスループットの利用が不十分でないかを理解するために必要な情報が得られます。 |
| コスト管理: OpenAI でのコスト管理機能を使用して、コストの監視、コストを管理するための予算の設定、関係者にリスクや異常を通知するアラートの作成を行います。 | コストの監視、予算の設定、アラートの設定により、ガバナンスと適切なアカウンタビリティ プロセスが提供されます。 |
オペレーショナル エクセレンス
オペレーショナル エクセレンスは主に、開発プラクティス、監視、リリース管理の手順に重点を置きます。
オペレーショナル エクセレンスの設計原則は、ワークロードの運用要件へ向けたこれらの目標を達成するためのおおまかな設計戦略を提供します。
設計チェック リスト
オペレーショナル エクセレンスのための設計レビュー チェックリストに基づいて設計戦略を開始します。 このチェックリストは、Azure OpenAI に関連する監視、テスト、デプロイのプロセスを定義しています。
Azure DevOps カルチャ: 開発、テスト、運用など、さまざまな環境にわたる Azure OpenAI インスタンスのデプロイを実現します。 開発サイクル全体にわたって継続的な学習と実験をサポートする環境があることを確認します。
監視: 適切なメトリックの監視、集計、視覚化を行います。
監視: Azure OpenAI 診断が自分のニーズにとって不十分な場合は、Azure OpenAI の前で Azure API Management などのゲートウェイを使用して、許可されている場所で受信プロンプトと送信応答の両方をログすることを検討してください。 この情報は、受信プロンプトに対するモデルの有効性を理解するのに役立ちます。
自信を持ったデプロイ: コードとしてのインフラストラクチャ (IaC) を使用して、Azure OpenAI、モデル デプロイ、およびモデルの微調整に必要なその他のインフラストラクチャをデプロイします。
自信を持ったデプロイ: 大規模言語モデル操作 (LLMOps) プラクティスに従って、デプロイ、微調整、プロンプト エンジニアリングなどの Azure OpenAI LLM の管理を運用可能にします。
効率性のための自動化: キーベース認証を使用する場合は、自動化されたキーローテーション戦略を実装します。
推奨事項
| 推奨事項 | 特長 |
|---|---|
| Azure Diagnostics の有効化と構成: Azure OpenAI Service に対して Diagnostics を有効にして構成します。 | Diagnostics はメトリックとログを収集して分析し、Azure OpenAI の可用性、パフォーマンス、および操作を監視するのに役立ちます。 |
パフォーマンス効率
パフォーマンス効率とは、容量を管理することで、負荷が増加したときにも、ユーザー エクスペリエンスを維持することです。 この戦略には、リソースのスケーリング、潜在的なボトルネックの特定と最適化、ピーク パフォーマンスの最適化が含まれます。
パフォーマンス効率設計の原則は、予想される使用に対してこれらの容量目標を達成するためのおおまかな設計戦略を提供します。
設計チェック リスト
Azure OpenAI ワークロードのキー パフォーマンス指標に基づいてベースラインを定義するためにパフォーマンス効率のための設計レビュー チェックリストに基づいて設計戦略を開始します。
容量: 消費者の弾力性に関する需要を見積もります。 同期応答を必要とする優先度の高いトラフィックと、非同期でバッチ処理できる優先順位の低いトラフィックを特定します。
容量: 推定される消費者からの需要に基づいてトークン消費要件のベンチマークを行います。 プロビジョニングされたスループット ユニット (PTU) デプロイを使用している場合は、Azure OpenAI ベンチマーク ツールを使用してスループットを検証することを検討してください。
容量: 運用ワークロードに対してはプロビジョニングされたスループットを使用します。 プロビジョニングされたスループットは、指定されたモデル バージョンに対して、専用のメモリとコンピューティング、予約容量、および一貫した最大待機時間を提供します。 従量課金制オファリングは、使用量が多いリージョン内の待機時間の増加やスロットリングなどの "うるさい隣人" 問題の影響を受ける可能性があります。 また、従量課金制のアプローチでは、保証された容量は提供されません。
容量: Azure OpenAI デプロイの前に適切なゲートウェイを追加します。 このゲートウェイが同じリージョンまたは異なるリージョン内の複数のインスタンスにルーティングできるようにします。
容量: 予測される使用量をカバーできる PTU を割り当て、TPM デプロイでこれらの PTU を補完することで、その制限を超える弾力性を処理します。 このアプローチはベース スループットとエラスティック スループットを組み合わせて効率を高めます。 他の考慮事項と同様に、このアプローチでは、PTU の制限に達したときに TPM デプロイに要求をルーティングするカスタム ゲートウェイの実装が必要です。
容量: 優先度の高い要求を同期的に送信します。 優先順位の低い要求はキューに入れ、需要が少ないときにそれらをバッチで送信します。
容量: 速度と出力の複雑さのトレードオフを考慮して、パフォーマンス要件に合ったモデルを選択します。 モデル パフォーマンスは、選択したモデルの種類によって大きく異なる可能性があります。 速度を目的として設計されたモデルはより早い応答時間を提供し、これは迅速なやり取りを必要とするアプリケーションに適しています。 逆に、より高度なモデルは応答時間の増加と引き換えにより高品質の出力を提供できます。
パフォーマンスの実現: チャットボットや会話インターフェイスなどのアプリケーションでは、ストリーミングの実装を検討してください。 ストリーミングは段階的な方法でユーザーに応答を提供することで、Azure OpenAI アプリケーションの認識されるパフォーマンスを向上させ、ユーザー エクスペリエンスを改善することができます。
パフォーマンスの実現: 微調整にコミットする前に微調整を使用するべきタイミングを判断します。 モデルの操縦に必要な情報が長すぎる場合や複雑すぎてプロンプトに収まらない場合など、微調整が適切となるユース ケースは存在しますが、プロンプト エンジニアリングや取得拡張生成 (RAG) アプローチが機能しないか、明確にコストが高くなることを確認してください。
パフォーマンスの実現: コンシューマー グループごとの専用モデル デプロイを使用して、コンシューマー グループ間のうるさい隣人を防ぐのに役立つモデルごとの使用の分離を提供することを検討してください。
推奨事項
Azure OpenAI のパフォーマンス効率を高めるために推奨される構成は存在しません。
Azure Policy
Azure には、Azure OpenAI とその依存関係に関連する広範な組み込みポリシー セットが用意されています。 前述の推奨事項の一部は、Azure Policy を使用して監査できます。 以下のポリシー定義について検討してください。
- キー アクセスを無効にする
- ネットワーク アクセスを制限する
- パブリック ネットワーク アクセスの無効化
- Azure Private Link を使用する
- カスタマーマネージド キーを使用したデータ暗号化を有効にする
これらの Azure Policy 定義は、Azure Advisor による Azure OpenAI のセキュリティのベスト プラクティスに関する推奨事項でもあります。
次のステップ
この記事で示された推奨事項を実践するリソースとしては、以下の記事を検討してください。
- このリファレンス アーキテクチャは、この記事のガイダンスをワークロードに適用する方法の例として使用してください: OpenAI のベースラインとなるエンド ツー エンド チャットのリファレンス アーキテクチャ。
- Azure Machine Learning 製品ドキュメントを使用して実装の専門知識を身に着けます。