次の方法で共有

Azure での AI ワークロードの設計原則

  • [アーティクル]

この記事では、アーキテクチャの AI の側面に焦点を当てて、Azure 上の AI ワークロードの主要な原則について説明します。 トレードオフを含め、すべての Azure Well-Architected Framework の柱をまとめて検討することが不可欠です。 ワークロードの機能要件と非機能要件に各柱を適用します。

信頼性

Azure で AI ワークロードを実行する場合は、他の種類のワークロードで考慮するのと同じ信頼性要件の多くを考慮する必要があります。 ただし、モデルトレーニング、ホスティング、推論に関する具体的な考慮事項は特に重要であり、この記事の焦点です。 これらのプラクティスを、AI ワークロードにも適用されるクラウド アプリケーションの標準的な設計のベスト プラクティスと統合することが重要です。

信頼性設計の原則を確認して、ここで説明する概念の基本的な理解を得ます。

設計原則 考慮事項
単一障害点を軽減します。 重要なコンポーネントを 1 つのインスタンスに依存すると、重大な問題が発生する可能性があります。 このような問題を回避するには、すべての重要なコンポーネントに冗長性を組み込みます。 フォールト トレランスと高可用性機能が組み込まれているプラットフォームを使用し、複数のインスタンスまたはノードをデプロイして冗長性を実装します。
障害モード分析を実施します。

よく知られている設計パターンを活用します。		 システム コンポーネントの潜在的な障害モードを定期的に分析し、これらの障害に対する回復性を構築します。 よく知られた設計パターンを使用して、システムの一部を分離し、連鎖障害を防ぎます。 たとえば、Bulkhead パターンはエラーを特定するのに役立ち、再試行メカニズムとサーキット ブレーカーは調整要求などの一時的なエラーを処理できます。
依存コンポーネント間で信頼性目標のバランスを取ります。 推論エンドポイントまたはモデル、およびデータ ストアが信頼性の観点から揃っていることを確認します。 アプリケーション コンポーネントは、同時ユーザーの急増など、予期しない条件下でも引き続き使用できる必要があります。 さらに、障害が発生した場合にワークロードをバックアップ システムにフェールオーバーできる必要があります。 1 つのコンポーネントが失敗した場合、もう一方のコンポーネントの信頼性に影響します。

同様に、重要な運用リソースであるサービス 層 API は、他の重要度の高いワークロード フローと同じ信頼性標準に準拠する必要があります。 これらの API で高可用性が必要な場合、ホスティング プラットフォームは、継続的な操作と回復性を確保するために、可用性ゾーンまたはマルチリージョン設計をサポートする必要があります。
運用上の信頼性を確保するための設計。 更新プログラムが頻繁かつタイムリーに行われるので、モデル応答の信頼性を維持します。 最新のデータを使用するか、少し古いデータを使用するかを決定し、up-to-date 情報の必要性と更新頻度の実用的さのバランスを取る。 頻度と信頼性の要件により、オンライン トレーニングを自動化する必要があります。 オフライン トレーニングは、コストメリット分析を通じて正当化できます。 オフライン トレーニングには、より安価なリソースを使用できます。
信頼性の高いユーザー エクスペリエンスを実現する設計。 負荷テストを使用してワークロードがストレスを処理する方法を評価し、応答時間に対するユーザーの期待を管理するようにユーザー インターフェイスを設計します。 潜在的な待機時間をユーザーに通知する UI 要素を実装し、非同期のクラウド設計原則を採用して、通信間、待機時間、または障害に対処します。

セキュリティ

モデルでは、多くの場合、機密性の高い運用データを使用して関連する結果が生成されます。 したがって、アーキテクチャのすべてのレイヤーで堅牢なセキュリティ対策を実装する必要があります。 これらの対策には、ライフサイクルの早い段階でのセキュリティで保護されたアプリケーション設計の実装、保存時と転送中の両方のデータの暗号化、業界のコンプライアンス基準への準拠が含まれます。 定期的なセキュリティ評価は、脆弱性を特定して軽減するために重要です。 高度な脅威検出メカニズムは、潜在的な脅威に対する迅速な対応を保証するのに役立ちます。

セキュリティの原則 は、AI ソリューションにおけるデータの整合性、設計の整合性、およびユーザーのプライバシーを保護するための基本です。 ワークロード所有者は、信頼を構築し、機密情報を保護して、安全なユーザー エクスペリエンスを確保する責任があります。

設計原則 考慮事項
ユーザーの信頼を獲得します。 カスタム コード、ツール、および効果的なセキュリティ制御を使用して、ライフサイクルのあらゆる段階でコンテンツの安全性を統合します。

集計データ ストア、検索インデックス、キャッシュ、アプリケーションなど、すべてのデータ ストレージ ポイントで不要な個人情報と機密情報を削除します。 アーキテクチャ全体でこのレベルのセキュリティを一貫して維持します。

データを双方向に検査し、不適切なコンテンツや不快なコンテンツを除外する、徹底したコンテンツ モデレーションを実装してください。
ワークロードの秘密度要件に従って、保存中、転送中、使用中のデータを保護します。 少なくとも、アーキテクチャ内のすべてのデータ ストアで、Microsoft が管理するキーまたはカスタマー マネージド キーを使用してプラットフォーム レベルの暗号化を使用します。 より高いレベルの暗号化が必要な場所を決定し、必要に応じて二重暗号化を使用します。

すべてのトラフィックで暗号化に HTTPS が使用されていることを確認します。 各ホップの TLS 終端ポイントを決定します。

トレーニング中に使用される機密情報を攻撃者が抽出しないように、モデル自体を保護する必要があります。 このモデルには、最高レベルのセキュリティ対策が必要です。 暗号化されたデータに対する推論を可能にする同型暗号化の使用を検討してください。
システムにアクセスする ID (ユーザーとシステム) の堅牢なアクセス管理に投資します。 制御プレーンとデータ プレーンの両方に対して、ロールベースのアクセス制御 (RBAC) や属性ベースのアクセス制御 (ABAC) を実装します。

プライバシーを保護するために、適切な ID セグメント化を維持します。 ID が表示を許可されているコンテンツへのアクセスのみを許可します。
セグメント化を実装することで、設計の整合性を保護します。 コンテナー イメージ、データ、およびコード資産の一元化されたリポジトリにアクセスするためのプライベート ネットワークを提供します。

インフラストラクチャを他のワークロードと共有すると、セグメント化が作成されます。たとえば、Azure Kubernetes Service で推論サーバーをホストする場合は、ノード プールを他の API やワークロードから分離します。
セキュリティ テストを実施する。 変更がシステムに導入されるたびに非倫理的な動作を検出するためのテストを含む詳細なテスト計画を作成します。

AI コンポーネントを既存のセキュリティ テストに統合します。 たとえば、推論エンドポイントを他のパブリック エンドポイントと共に定期的なテストに組み込みます。

潜在的な脆弱性を効果的に特定して対処するために、侵入テストや赤いチーム演習などのライブ システムでテストを実施することを検討してください。
厳密なユーザー アクセスと API 設計を適用することで、攻撃対象領域を減らします。 システム間呼び出しを含むすべての推論エンドポイントに対して認証を要求します。 匿名エンドポイントは使用しないでください。

クライアント側の柔軟性を犠牲にして、制約付き API 設計を優先します。

トレードオフ。 最高レベルのセキュリティを実装すると、暗号化されたデータを分析、検査、またはログに記録する機能が限られているため、コストと精度のトレードオフが発生します。 コンテンツの安全性チェックと説明可能性の実現は、高度にセキュリティで保護された環境でも困難な場合があります。

次の設計領域では、上記の原則と考慮事項について詳しく説明します。

コストの最適化

コスト最適化の柱の目的は、投資を最大化することです。必ずしもコストを削減するとは限りません。 すべてのアーキテクチャの選択により、直接的および間接的な財務上の影響が生まれます。 ビルドと購入の決定、テクノロジの選択、課金モデル、ライセンス、トレーニング、運用費など、さまざまなオプションに関連するコストを理解します。 選択したレベルへの投資を最大化し、継続的に課金モデルを再評価することが重要です。 アーキテクチャ、ビジネス ニーズ、プロセス、チーム構造の変化に関連するコストを継続的に評価します。

レートと使用量の最適化に重点を置いて、コスト最適化の原則を確認します。

設計原則 考慮事項
包括的なコスト モデリング演習を実行して、コスト 要因を決定します。 データとアプリケーション プラットフォームの主な要因を考慮してください。
- データの量。 インデックス作成と処理を行うデータの量を見積もります。 ボリュームが大きくなると、ストレージと処理のコストが増加する可能性があります。
- クエリの数。 クエリの頻度と複雑さを予測します。 クエリの量が多いほど、特にクエリに大量の計算リソースが必要な場合に、コストが増加する可能性があります。
- スループット。 予想されるスループットを評価して、必要なパフォーマンス レベルを決定します。 スループットの要求が高いほど、コストが高くなる可能性があります。
- 依存関係のコスト。 依存関係に隠れたコストが発生する可能性があることを理解します。 たとえば、インデックス作成のコストを計算する場合、スキル セットのコストを含めます。スキル セットはデータ処理の一部ですが、インデックススコープ外です。
使用する予定の料金を支払います。 不要な費用を発生させることなく、ニーズを満たすテクノロジ ソリューションを選択します。 高度な機能が不要な場合は、コストの低いオプションとオープンソース ツールを検討してください。

使用頻度を考慮します。 オーケストレーション ツールは常時オンになるため、使用コストを最小限に抑えるためにエラスティック コンピューティング オプションを優先します。 コストがエスカレートされる可能性があるため、フルタイムの操作ではサーバーレス コンピューティングを回避します。

完全な容量を使用せずに、上位レベルの料金を支払う必要はありません。 選択したレベルが運用の使用パターンと一致していることを確認して、支出を最適化します。 通常のタスクには標準価格を使用し、非常に中断可能なトレーニングにはスポット価格を使用します。 コストを削減するには、AI ワークロード関数にのみ GPU ベースのコンピューティングを使用します。

トレーニングと微調整を広範にテストしてベンチマークし、パフォーマンスとコストの最適なバランスを取る SKU を見つけます。
支払い内容を活用します。 無駄を最小限に抑えます。 使用状況メトリックを注意深く監視します。 AI ワークロードはコストがかかる可能性があり、リソースが使用されていないときにシャットダウン、スケールダウン、または割り当て解除が行われなければ、コストが迅速にエスカレートされる可能性があります。

書き込みを 1 回行い、多くを読み取りデータ ストレージの過剰な保留を回避するようにシステムを最適化します。 トレーニング データでは、実稼働データベースの即時の応答性は必要ありません。

Azure OpenAI Service 推論エンドポイントのストレス テストは、すべての呼び出しで料金が発生するため、コストがかかる場合があります。 コストを削減するには、テスト環境で OpenAI サービスの未使用の PTU を使用するか、代わりに推論エンドポイントをシミュレートします。

探索的データ分析 (EDA)、モデル トレーニング、微調整などのタスクは、通常、フルタイムでは実行されません。 これらのタスクでは、使用されていないときに停止できるプラットフォームを使用します。 たとえば、EDA ジョブは通常対話型であるため、ユーザーは VM を起動し、ジョブを実行する際に停止できる必要があります。

運用チームにコスト勘定を割り当てます。 これらのチームは、リソース使用率を積極的に監視および管理することで、コストが予想されるパラメーター内に収まるようにする必要があります。
運用コストを最適化します。 オンライン トレーニングは、頻度の要件のためにコストがかかる場合があります。 このプロセスを自動化することで、一貫性を維持し、人的エラーによるコストを最小限に抑えることができます。 さらに、トレーニングに少し古いデータを使用し、可能な場合は更新を延期することで、モデルの精度に大きな影響を与えることなく、経費をさらに削減できます。

オフライン トレーニングの場合は、オフライン ハードウェアなど、安価なリソースを使用できるかどうかを評価します。

一般に、機能ストアからデータを削除して、機能の乱雑さとストレージ コストを削減します。

トレードオフ: コストの最適化とパフォーマンスの効率。 データベース管理のパフォーマンスとコストのバランスを取る場合、トレードオフが伴います。 効率的なインデックス設計によりクエリが高速化されますが、メタデータ管理とインデックス サイズによりコストが増加する可能性があります。 同様に、大きなテーブルをパーティション分割すると、クエリのパフォーマンスが向上し、ストレージの負荷が軽減されますが、追加のコストが発生します。 逆に、過剰なインデックス作成を回避する手法はコストを削減できますが、適切に管理されていない場合はパフォーマンスに影響する可能性があります。

トレードオフ: コストの最適化とオペレーショナル エクセレンス。 モデル トレーニングに使用する 2 つの主要なアプローチのうちどれを使用するかを決定する際に考慮すべきトレードオフがあります。 完全な運用データを使用して開発環境でトレーニングを行うと、モデルは 1 回だけトレーニングされ、成果物のみが昇格されるため、計算コストを削減できます。 ただし、このアプローチでは、より低い環境で運用データを処理するための厳格なセキュリティ対策が必要であり、複雑でリソースを大量に消費する可能性があります。 逆に、各環境でモデルをトレーニングすると、コードのレビューとテストが徹底されるため、安定性と信頼性が向上しますが、トレーニングの実行が複数回行われるため、このモデルでは計算コストが増加します。

オペレーショナル エクセレンス

オペレーショナル エクセレンスの主な目的は、開発ライフサイクル全体にわたって効率的に機能を提供することです。 この目標を達成するには、実験の設計手法をサポートする反復可能なプロセスを確立し、モデルのパフォーマンスを向上させるために結果を得る必要があります。 オペレーショナル エクセレンスは、時間の経過と伴うモデルの精度の維持、リスクを最小限に抑えるための効果的な監視プラクティスとガバナンスの実装、モデルの誤差に適応するための変更管理プロセスの開発についても説明します。

すべての オペレーショナル エクセレンスの原則 AI ワークロードに適用されますが、基本的な運用戦略として自動化と監視に優先順位を付けます。

設計原則 考慮事項
アプリケーション開発、データ処理、AI モデル管理のライフサイクル全体を通して、継続的な学習と実験の考え方を促進します。 ワークロード操作は、DevOps、DataOps、MLOps、GenAIOps などの業界で実証済みの手法に基づいて構築する必要があります。

運用チーム、アプリケーション開発チーム、データ チーム間の早期コラボレーションは、許容可能なモデル パフォーマンスの相互理解を確立するために不可欠です。 運用チームは、品質シグナルと実用的なアラートを提供します。 アプリケーションチームとデータ チームは、問題を効率的に診断して解決するのに役立ちます。
運用上の負担を最小限に抑えるテクノロジを選択します。 プラットフォーム ソリューションを選択する場合は、セルフホステッド オプションよりもサービスとしてのプラットフォーム (PaaS) を優先して、設計を簡略化し、ワークフロー オーケストレーションを自動化し、2 日目の操作を簡単にします。
ログ記録や監査可能性など、アラート機能をサポートする自動化された監視システムを作成します。 AI の非決定的な性質を考えると、ライフサイクルの早い段階で品質測定を確立することが重要です。 データ サイエンティストと協力して、品質メトリックを定義します。 包括的なダッシュボードで継続的な分析情報を視覚化します。

コードバージョン、環境、パラメーター、実行、結果などの詳細をキャプチャできるツールを使用して実験を追跡します。

オペレーターが迅速に対応できるように、十分な情報を提供する実用的なアラートを実装します。
モデルの減衰の検出と軽減を自動化します。 自動テストを使用して、時間の経過に伴うドリフトを評価します。 監視システムが応答の結果が予想から逸脱し始めた際にアラートを送信し、それを定期的に行うようにしてください。 新しいモデルを自動的に検出して更新できるツールを使用します。

必要に応じて、データ処理とモデル トレーニング ロジックを調整して、新しいユース ケースに適応します。
安全なデプロイを実装します。 ダウンタイムを最小限に抑えるために、サイド バイ サイドデプロイとインプレース更新のどちらかを選択します。 デプロイ前に徹底的なテストを実装して、モデルが正しく構成され、ターゲット、ユーザーの期待、品質基準を満たしていることを確認します。 展開戦略に関係なく、常に緊急時の運用を計画します。
運用環境でのユーザー エクスペリエンスを継続的に評価します。 ワークロード ユーザーが自分のエクスペリエンスに関するフィードバックを提供できるようにします。 トラブルシューティングのために、関連するログで会話の一部またはすべてを共有することに同意します。 ユーザーインタラクションがどの程度実行可能で、準拠し、安全で、有用であるかを考慮し、実際のユーザー操作を使ってワークロードのパフォーマンスを評価するために、データを慎重に利用します。

次の設計領域では、上記の原則と考慮事項について詳しく説明します。

パフォーマンス効率

AI モデルのパフォーマンス評価の目的は、モデルが目的のタスクをどの程度効果的に実行するかを判断することです。 この目標を達成するには、精度、精度、公平性など、さまざまなメトリックを評価する必要があります。 さらに、モデルをサポートするプラットフォームとアプリケーション コンポーネントのパフォーマンスが重要です。

モデルのパフォーマンスは、実験の追跡やデータ処理などの操作の効率にも影響されます。 パフォーマンス効率の原則 適用すると、許容できる品質バーに対するパフォーマンスの測定に役立ちます。 この比較は、劣化または減衰を検出するための鍵となります。 AI コンポーネントを含むワークロードを維持するには、継続的な監視と評価のための自動化されたプロセスが必要です。

設計原則 考慮事項
パフォーマンス ベンチマークを確立します。 さまざまなアーキテクチャ領域で厳格なパフォーマンス テストを実施し、許容可能なターゲットを設定します。 この継続的な評価は、1 回限りのテストではなく、運用プロセスの一部である必要があります。

ベンチマークは予測パフォーマンスに適用されます。 ベースラインから始めて、初期モデルのパフォーマンスを理解し、パフォーマンスを継続的に再評価して、期待を満たしていることを確認します。
パフォーマンス目標を満たすためのリソースニーズを評価します。 適切なプラットフォームと適切なサイズのリソースを選択するための負荷特性について理解します。 容量計画を大規模に運用するために、このデータを考慮します。

たとえば、ロード テストを使用して、最適なコンピューティング プラットフォームと SKU を決定します。 高パフォーマンスの GPU 最適化コンピューティングは、多くの場合、モデルのトレーニングと微調整に必要ですが、汎用 SKU はオーケストレーション ツールに適しています。

同様に、データ インジェストを効率的に処理し、同時書き込みを管理し、個々の書き込みパフォーマンスを低下させることなく維持するデータ プラットフォームを選択します。

推論サーバーが異なると、パフォーマンス特性が異なります。 これらの特性は、実行時のモデルのパフォーマンスに影響します。 ベースラインの期待を満たすサーバーを選択します。
パフォーマンス メトリックを収集して分析し、ボトルネックを特定します。

データ パイプラインからのテレメトリを評価して、スループットと読み取り/書き込み操作のパフォーマンス ターゲットが満たされていることを確認します。

検索インデックスについては、クエリの待機時間、スループット、結果の精度などのメトリックを検討してください。 データ量が増えるにつれて、エラー率を上げることはできません。

サービス呼び出しからデータを収集するオーケストレーターなどのコード コンポーネントからのテレメトリを分析します。 そのデータを分析すると、ローカル処理とネットワーク呼び出しに費やされた時間を把握し、他のコンポーネントの潜在的な待機時間を特定するのに役立ちます。

エンゲージメント メトリックを使用して UI エクスペリエンスを評価し、ユーザーが積極的に関与しているか、または不満を抱いているかを判断します。 ページの時間の増加は、どちらかを示すことができます。 音声やビデオの応答などのマルチモーダル機能により、大幅な待機時間が発生し、応答時間が長くなる可能性があります。
生産からの品質測定を使用してベンチマークのパフォーマンスを継続的に向上させます。 モデルの有効性を維持するために、パフォーマンス メトリック、アラート、モデルの再トレーニングの自動収集と分析を実装します。

トレードオフ。 プラットフォームの機能を検討する場合は、コストとパフォーマンスのバランスを取る必要があります。 たとえば、GPU SKU はコストがかかるため、使用率が不足しているリソースと適切なサイズのリソースを必要に応じて継続的に監視します。 調整後、ベースラインで示されているように、リソース使用率をテストして、プラットフォーム リソースのコストとその運用と予想されるパフォーマンスのバランスを確保します。 コスト最適化戦略については、「 コンポーネント コストを最適化するための推奨事項を参照してください。

次の設計領域では、上記の原則と考慮事項について詳しく説明します。

次のステップ

設計領域: アプリケーション設計