Share via

Azure OpenAI サービスに関する Azure Well-Architected Framework のパースペクティブ

  • [アーティクル]

Azure OpenAI Service は、OpenAI 大言語モデル (LLM) への REST API アクセスを提供し、Azure ネットワークとセキュリティ機能を追加します。 この記事では、ワークロードのアーキテクチャの一部として Azure OpenAI を使用するときに、情報に基づいた意思決定を行う際に役立つアーキテクチャに関する推奨事項について説明します。 このガイダンスは、 Azure Well-Architected Framework の柱に基づいています。

重要

このガイドを使用する方法

各セクションには、 アーキテクチャ の関心領域と、テクノロジスコープにローカライズされた設計戦略を示す設計チェックリストがあります。

また、これらの戦略を具体化するのに役立つテクノロジ機能に関する 推奨事項 も含まれています。 推奨事項は、Azure OpenAI で使用できるすべての構成とその依存関係の完全な一覧を表しているわけではありません。 代わりに、設計パースペクティブにマップされた主要な推奨事項を一覧表示します。 推奨事項を使用して概念実証を構築するか、既存の環境を最適化します。

主要な推奨事項を示す基本的なアーキテクチャ: ベースライン OpenAI エンド ツー エンド チャット参照アーキテクチャ。

テクノロジスコープ

このレビューでは、Azure OpenAI のみに焦点を当てています。

[信頼性]

信頼性の柱の目的は、 十分な回復性と障害から迅速に回復する機能を構築することで、継続的な機能を提供することです。

信頼性設計の原則は、個々のコンポーネント、システム フロー、およびシステム全体に適用される高度な設計戦略を提供します。

設計チェック リスト

信頼性の設計レビュー チェックリストに基づいて 、設計戦略を開始します。 ビジネス要件との関連性を判断します。 戦略を拡張して、必要に応じてより多くのアプローチを含めます。

  • 回復性: ユース ケースに基づいて、従量課金制または プロビジョニング済みスループット のいずれかの適切なデプロイ オプションを選択します。 予約容量によって回復性が向上するため、運用ソリューションのプロビジョニング済みスループットを選択します。 従量課金制のアプローチは、開発/テスト環境に最適です。

  • 冗長性: Azure OpenAI デプロイの前に適切なゲートウェイを追加します。 ゲートウェイには、調整などの一時的な障害に耐え、複数の Azure OpenAI インスタンスにもルーティングする機能が必要です。 リージョンの冗長性を構築するために、異なるリージョン内のインスタンスへのルーティングを検討してください。

  • 回復性: プロビジョニングされたスループットを使用している場合は、オーバーフローを処理するために従量課金制インスタンスをデプロイすることも検討してください。 プロビジョニングされたスループット モデルが調整されると、ゲートウェイ経由で従量課金制インスタンスに呼び出しをルーティングできます。 監視を使用して、モデルが調整されるタイミングを予測し、従量課金制インスタンスへの呼び出しを先取りしてルーティングすることもできます。

  • 回復性: 容量の使用状況を監視して、スループットの制限を超えないことを確認します。 容量の使用状況を定期的に確認して、より正確な予測を実現し、容量の制約によるサービスの中断を防ぎます。

  • 回復性: 大きなデータ ファイルのガイダンス に従い、Azure BLOB ストアからデータをインポートします。 100 MB 以上の大きなファイルは、要求がアトミックであり、再試行または再開できないため、マルチパート 形式でアップロードすると不安定になる可能性があります。

  • 回復: 微調整されたモデルと、Azure OpenAI にアップロードされたトレーニング データの復旧計画を含む復旧戦略を定義します。 Azure OpenAI には自動フェールオーバーがないため、サービス全体とすべての依存関係 (トレーニング データを含むストレージなど) を含む戦略を設計する必要があります。

Recommendations

推奨 特長
従量課金制のレート制限を監視する: 従量課金制のアプローチを使用している場合は、モデルのデプロイのレート制限を管理し、1 分あたりのトークンの使用状況 (TPM) と 1 分あたりの要求数 (RPM) を監視します。 この重要なスループット情報は、デプロイの需要を満たすためにクォータから十分な TPM を割り当てるために必要な情報を提供します。

十分なクォータを割り当てると、デプロイされたモデルへの呼び出しの調整が防止されます。
プロビジョニングされたスループットのプロビジョニングマネージド使用率を監視する: プロビジョニングされたスループット 支払いモデルを使用している場合は、 プロビジョニングマネージド使用率を監視します。 デプロイされたモデルへの呼び出しの調整を防ぐために、プロビジョニングマネージド使用率を監視して 100% を超えないようにすることが重要です。
動的クォータ機能を有効にする: ワークロード予算でサポートされている場合は、モデルデプロイで動的クォータを有効にしてオーバープロビジョニングを実行します。 動的クォータを使用すると、Azure の観点から使用可能な容量がある限り、デプロイで通常よりも多くの容量を消費できます。 クォータ容量が増えると、望ましくない調整が妨げとなる可能性があります。
コンテンツ フィルターを調整する: 過度に積極的なフィルターからの誤検知を最小限に抑えるためにコンテンツ フィルターを調整します。 コンテンツ フィルターは、不透明なリスク分析に基づいてプロンプトまたは入力候補をブロックします。 ワークロードで予想される使用を許可するようにコンテンツ フィルターが調整されていることを確認します。

セキュリティ

セキュリティの柱の目的は 、ワークロードに機密性、整合性、可用性の 保証を提供することです。

セキュリティ設計の原則は、Azure OpenAI に関する技術設計にアプローチを適用することで、これらの目標を達成するための高度な設計戦略を提供します。

設計チェック リスト

セキュリティの設計レビュー チェックリストに基づいて設計戦略を開始し、セキュリティ体制を改善するための脆弱性と制御を特定します。 次に、 Azure OpenAI の Azure セキュリティ ベースラインを確認します。 最後に、必要に応じてより多くのアプローチを含むように戦略を拡張します。

  • 機密性の保護: トレーニング データを Azure OpenAI にアップロードする場合は、データ暗号化に カスタマー マネージド キー を使用し、キーローテーション戦略を実装し、 トレーニング、検証、トレーニングの結果データを削除します。 トレーニング データに外部データ ストアを使用する場合は、そのストアのセキュリティのベスト プラクティスに従ってください。 たとえば、Azure Blob Storageでは、暗号化にカスタマー マネージド キーを使用し、キーローテーション戦略を実装します。 マネージド ID ベースのアクセスを使用し、プライベート エンドポイントを使用してネットワーク境界を実装し、アクセス ログを有効にします。

  • 機密性の保護: Azure OpenAI リソースがアクセスできる送信 URL を制限することで、データ流出から保護します。

  • 整合性の保護: 最小限の特権の原則を使用し、キーではなく個々の ID を使用して、システムへのユーザー アクセスを認証および承認するためのアクセス制御を実装します。

  • 整合性の保護: 脱獄リスク検出 を実装して、迅速なインジェクション攻撃から言語モデルのデプロイを保護します。

  • 可用性の保護: セキュリティ コントロールを使用して、モデルの使用量クォータを使い果たす可能性のある攻撃を防ぎます。 ネットワーク上のサービスを分離するようにコントロールを構成できます。 サービスにインターネットからアクセスできる必要がある場合は、ゲートウェイを使用して、ルーティングまたは調整を使用して不正使用の疑いをブロックすることを検討してください。

Recommendations

推奨 特長
セキュリティで保護されたキー: アーキテクチャで Azure OpenAI キーベースの認証が必要な場合は、アプリケーション コードではなく、Azure Key Vaultにこれらのキーを格納します。 シークレットを Key Vault に格納してコードから分離すると、シークレットが漏洩する可能性が低くなります。 分離により、シークレットの一元管理も容易にされ、キーローテーションなどの責任が緩和されます。
アクセスを制限する: ワークロードで必要な場合を除き、Azure OpenAI への パブリック アクセスを無効にします 。 Azure 仮想ネットワーク内のコンシューマーから接続している場合は、 プライベート エンドポイント を作成します。 Azure OpenAI へのアクセスを制御すると、承認されていないユーザーからの攻撃を防ぐことができます。 プライベート エンドポイントを使用すると、ネットワーク トラフィックがアプリケーションとプラットフォームの間でプライベートなままになります。
Microsoft Entra ID: 認証にMicrosoft Entra IDを使用し、ロールベースのアクセス制御 (RBAC) を使用して Azure OpenAI へのアクセスを承認します。 Azure AI Services でローカル認証を無効に し、 を に設定 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 デプロイの安全性メカニズムをバイパスしようとするプロンプトを特定してブロックします。

コストの最適化

コストの最適化では、支出パターンの検出、重要な領域への投資の優先順位付け、ビジネス要件を満たしながらorganizationの予算を満たすように他のユーザーでの最適化に重点を置いています。

これらの目標を達成するためのアプローチと、Azure OpenAI に関連する技術的な設計の選択に必要なトレードオフについては、 コスト最適化設計の原則 に関するページを参照してください。

設計チェック リスト

投資の コスト最適化の設計レビュー チェックリスト に基づいて、設計戦略を開始します。 ワークロードが割り当てられた予算に合わせて調整されるように、設計を微調整します。 設計では、適切な Azure 機能を使用し、投資を監視し、時間の経過と同時に最適化する機会を見つける必要があります。

  • コスト管理: プロンプト サイズを考慮してコスト モデルを開発します。 プロンプト入力と応答のサイズと、テキストがトークンに変換される方法を理解することは、実行可能なコスト モデルを作成するのに役立ちます。

  • 使用量の最適化: トークンの使用量が予測可能になるまで、Azure OpenAI の 従量課金制の価格 から始めます。

  • レートの最適化: トークンの使用量が十分に高く、一定期間にわたって予測可能な場合は、 プロビジョニングされたスループット 価格モデルを使用してコストの最適化を向上させます。

  • 使用の最適化: モデル を選択する場合は、モデルの価格と機能を検討してください。 テキスト生成タスクや完了タスクなどの複雑でないタスクの場合は、コストの低いモデルから始めます。 言語翻訳やコンテンツ理解などのより複雑なタスクについては、より高度なモデルの使用を検討してください。 テキスト埋め込み、画像の生成、文字起こしのシナリオなどのユース ケースに適したモデルを選択する場合は、さまざまな モデル機能 と最大トークン使用量の制限を考慮してください。 ニーズに最適なモデルを慎重に選択することで、必要なアプリケーション パフォーマンスを実現しながらコストを最適化できます。

  • 使用の最適化: API 呼び出しによって提供されるトークン制限制約 (や nなどmax_tokens) を使用します。これは、生成する完了の数を示します。

  • 使用の最適化: Azure OpenAI の価格ブレークポイントを最大化します。たとえば、イメージ生成などの微調整やモデル ブレークポイントなどです。 微調整は 1 時間あたりに課金されるため、次の請求期間に陥らないようにしながら、微調整の結果を向上させるには、1 時間あたりの利用可能な時間と同じ時間を使用します。 同様に、100 個のイメージを生成するためのコストは、1 つのイメージのコストと同じです。 価格ブレークポイントを最大限に活用します。

  • 使用量の最適化: 使用されなくなった未使用の微調整されたモデルを削除して、継続的なホスティング料金が発生しないようにします。

  • 使用状況を調整する: プロンプト入力と応答の長さを最適化します。 プロンプトが長いほど、より多くのトークンを使用することでコストが発生します。 ただし、十分なコンテキストがないプロンプトは、モデルが良好な結果を得るのに役立つわけではありません。 モデルが有用な応答を生成するのに十分なコンテキストを提供する簡潔なプロンプトを作成します。 また、応答の長さの制限を最適化してください。

  • コスト効率: 可能な限りバッチ要求を行い、呼び出しごとのオーバーヘッドを最小限に抑え、全体的なコストを削減できます。 バッチ サイズを最適化していることを確認します。

  • コスト効率: モデルの微調整コストは異なるため、ソリューションで微調整が必要な場合は、これらのコストを考慮してください。

  • 監視と最適化: モデルの使用状況を監視するコスト追跡システムを設定します。 この情報は、モデルの選択肢とプロンプト サイズを通知するのに役立ちます。

Recommendations

推奨 特長
制限を設定するようにクライアント コードを設計する: カスタム クライアントでは、モデルあたりのトークン数の上限 () や生成までの完了数 (max_tokensn) など、Azure OpenAI 入力候補 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 の管理を運用化します。

  • 効率を高める自動化: キーベースの認証を使用する場合は、自動化されたキーローテーション戦略を実装します。

Recommendations

推奨 特長
Azure Diagnosticsを有効にして構成する: Azure OpenAI サービスの診断を有効にして構成します。 診断では、メトリックとログが収集および分析され、Azure OpenAI の可用性、パフォーマンス、および操作を監視するのに役立ちます。

パフォーマンス効率

パフォーマンス効率は、容量を管理することで 負荷が増加した場合でも、ユーザー エクスペリエンスを維持 することです。 この戦略には、リソースのスケーリング、潜在的なボトルネックの特定と最適化、ピーク パフォーマンスの最適化が含まれます。

パフォーマンス効率設計原則は、予想される使用に対してこれらの容量目標を達成するための高レベルの設計戦略を提供します。

設計チェック リスト

Azure OpenAI ワークロードの主要業績評価指標に基づいてベースラインを定義するための パフォーマンス効率の設計レビュー チェックリスト に基づいて設計戦略を開始します。

  • 容量: コンシューマーの弾力性の要求を見積もります。 同期応答を必要とする優先度の高いトラフィックと、非同期でバッチ処理できる優先順位の低いトラフィックを特定します。

  • 容量: コンシューマーからの推定需要に基づいてトークン消費要件をベンチマークします。 プロビジョニング済みスループット ユニット (PTU) デプロイを使用している場合は、スループットの検証に役立つ Azure OpenAI ベンチマーク ツール の使用を検討してください。

  • 容量: 運用ワークロードにプロビジョニングされたスループットを使用します。 プロビジョニングされたスループットは、指定されたモデル バージョンの専用メモリとコンピューティング、予約容量、および一貫した最大待機時間を提供します。 従量課金制サービスは、待機時間の増加や、大量の使用下のリージョンでの調整など、 うるさい近隣の 問題に苦しむ可能性があります。 また、従量課金制のアプローチでは、容量が保証されません。

  • 容量: Azure OpenAI デプロイの前に適切なゲートウェイを追加します。 ゲートウェイが同じリージョンまたは異なるリージョン内の複数のインスタンスにルーティングできることを確認します。

  • 容量: 予測される使用量をカバーするために PTU を割り当て、これらの PTU を TPM デプロイで補完して、その制限を超える弾力性を処理します。 この方法では、基本スループットとエラスティック スループットを組み合わせて効率を高めます。 他の考慮事項と同様に、このアプローチでは、PTU の制限に達したときに TPM デプロイに要求をルーティングするカスタム ゲートウェイの実装が必要です。

  • 容量: 優先度の高い要求を同期的に送信します。 優先度の低い要求をキューに入れ、要求が少ない場合はバッチで送信します。

  • 容量: 速度と出力の複雑さのトレードオフを考慮して、パフォーマンス要件に合ったモデルを選択します。 モデルのパフォーマンスは、選択したモデルの種類によって大きく異なる場合があります。 速度を考慮して設計されたモデルは応答時間を短縮し、迅速な対話を必要とするアプリケーションに役立ちます。 逆に、より高度なモデルは、応答時間の増加を犠牲にして、より高品質の出力を提供する可能性があります。

  • パフォーマンスの実現: チャットボットや会話インターフェイスなどのアプリケーションでは、ストリーミングの実装を検討してください。 ストリーミングでは、ユーザーに対する応答を段階的に提供することで、Azure OpenAI アプリケーションの認識されるパフォーマンスを向上させ、ユーザー エクスペリエンスを向上させることができます。

  • パフォーマンスを実現する: 微調整をコミットする前に、 微調整を使用するタイミングを決定します。 モデルの操作に必要な情報が長すぎる場合や複雑すぎてプロンプトに収まらない場合など、微調整には適したユース ケースがありますが、プロンプト エンジニアリングと取得拡張生成 (RAG) アプローチが機能しないか、明らかに高価であることを確認してください。

  • パフォーマンスの実現: コンシューマー グループごとの専用モデル デプロイを使用して、コンシューマー グループ間のノイズの多い近隣を防ぐのに役立つモデルごとの使用分離を提供することを検討してください。

Recommendations

Azure OpenAI のパフォーマンス効率に推奨される構成はありません。

Azure Policy

Azure には、Azure OpenAI とその依存関係に関連する広範な組み込みポリシーセットが用意されています。 上記の推奨事項の一部は、Azure Policyを使用して監査できます。 次のポリシー定義を検討してください。

これらのAzure Policy定義は、Azure OpenAI の Azure Advisor セキュリティのベスト プラクティスの推奨事項でもあります。

次の手順

この記事で強調表示されている推奨事項を示すリソースとして、次の記事を検討してください。