Azure での AI ワークロードの設計原則
この記事では、アーキテクチャの AI の側面に焦点を当てて、Azure 上の AI ワークロードの主要な原則について説明します。 トレードオフを含め、すべての適切に設計されたフレームワークの柱をまとめて検討することが不可欠です。 ワークロードの機能要件と非機能要件に各柱を適用します。
信頼性
Azure で実行されている AI ワークロードでは、他のクラスのワークロードと同じ信頼性要件の多くを考慮する必要があります。 ただし、モデルのトレーニング、ホスティング、推論に関する具体的な考慮事項は特に重要であり、主にこの原則で取り上げています。 ここで説明するプラクティスは、クラウド アプリケーションの標準的な設計のベスト プラクティスに加え、それに応じて統合する必要があることに注意してください。
責任設計の原則を確認して、ここで説明する概念の基本的な理解を得ます。
| 設計原則 | 考慮事項 |
|---|---|
| 単一障害点を軽減します。 | 重要なコンポーネントを 1 つのインスタンスに依存すると、重大な問題が発生する可能性があります。 これを防ぐには、すべての重要なコンポーネントに冗長性を組み込みます。 フォールト トレランスと高可用性機能が組み込まれたプラットフォームを使用し、複数のインスタンスまたはノードをデプロイして冗長性を実装します。 |
| 障害モード分析を実施します。 よく知られている設計パターンを活用します。 |
システム コンポーネントの潜在的な障害モードを定期的に分析し、これらの障害に対する回復性を構築します。 よく知られている設計パターンを利用して、システムの一部を分離し、連鎖障害を防ぎます。 たとえば、バルクヘッド パターンはエラーを分離するのに役立ちますが、再試行メカニズムとサーキット ブレーカーは調整要求などの一時的なエラーを処理できます。 |
| 依存コンポーネント間で信頼性目標のバランスを取ります。 | 推論エンドポイントまたはモデル、およびデータ ストアが信頼性の観点から揃っていることを確認します。 アプリケーション コンポーネントは、同時ユーザーの急増など、予期しない条件下でも引き続き使用できる必要があります。 さらに、障害が発生した場合に、ワークロードはバックアップ システムにフェールオーバーする機能を備えている必要があります。 1 つのコンポーネントが失敗した場合、もう一方のコンポーネントの信頼性に影響します。 同様に、重要な運用リソースであるレイヤー API を提供するには、他の重要度の高いワークロード フローと同じ信頼性標準に準拠する必要があります。 これらの API で高可用性が必要な場合、ホスティング プラットフォームは、継続的な操作と回復性を確保するために、可用性ゾーンまたはマルチリージョン設計をサポートする必要があります。 |
| 運用上の信頼性を確保するための設計。 | 更新が頻繁かつタイムリーに行われるので、モデルの応答の信頼性を維持します。 最新のデータを使用するか、少し古いデータで十分かを決定し、最新の情報の必要性と更新頻度の実用的さのバランスを取る。 オンライン トレーニングは頻度と信頼性の要件により自動化する必要があります。一方、オフライン トレーニングはコストメリット分析を通じて正当化し、安価なリソースを使用して実行できます。 |
| 信頼性の高いユーザー エクスペリエンスを実現する設計。 | 負荷テストを使用して、ワークロードがストレスを処理する方法を評価し、応答時間に関するユーザーの期待を管理するためのユーザー インターフェイスを設計します。 潜在的な待機時間をユーザーに通知する UI 要素を実装し、非同期のクラウド設計原則を採用して、相互通信、待機時間、または障害に対処します。 |
セキュリティ
モデルでは、多くの場合、機密性の高い運用データを使用して関連する結果が生成されます。 そのため、堅牢なセキュリティ対策は、アーキテクチャのすべてのレイヤーで使用する必要があります。 これには、ライフサイクルの早い段階でのセキュリティで保護されたアプリケーション設計の実装、保存時と転送中の両方のデータの暗号化、業界のコンプライアンス標準への準拠が含まれます。 定期的なセキュリティ評価は脆弱性の特定と軽減に不可欠ですが、高度な脅威検出メカニズムにより、潜在的な脅威に対する迅速な対応が保証されます。
セキュリティの原則 は、AI ソリューションの基礎であり、データの整合性、設計の整合性、およびユーザーのプライバシーを保護します。 ワークロード所有者は、信頼を構築し、機密情報を保護し、安全なユーザー エクスペリエンスを確保する責任があります。
| 設計原則 | 考慮事項 |
|---|---|
| ユーザーの信頼を獲得します。 | カスタム コード、適切なツール、効果的なセキュリティ制御を使用して、ライフサイクルのあらゆる段階でコンテンツの安全性を統合します。 集計データ ストア、検索インデックス、キャッシュ、アプリケーションなど、すべてのデータ ストレージ ポイントで不要な個人情報と機密情報を削除します。 アーキテクチャ全体でこのレベルのセキュリティを一貫して維持します。 双方向のデータを検査し、不適切で不快なコンテンツを除外する、徹底したコンテント モードレーションがあることを確認します。 |
| ワークロードの秘密度要件に従って、保存中、転送中、使用中のデータを保護します。 | 少なくとも、アーキテクチャで使用されるすべてのデータ ストアで、Microsoft が管理するキーまたはカスタマー マネージド キーを使用してプラットフォーム レベルの暗号化を使用します。 より高いレベルの暗号化が必要な場所を評価し、必要に応じて二重暗号化を使用します。 すべてのトラフィックで暗号化に HTTPS が使用されていることを確認します。 各ホップの TLS 終端ポイントを決定します。 トレーニング中に攻撃者が機密情報を抽出するのを防ぐために、モデル自体を保護する必要があります。 これには、最高レベルのセキュリティ対策が必要です。 暗号化されたデータに対する推論を可能にする同型暗号化の使用を検討してください。 |
| システムにアクセスする ID (ユーザーとシステム) を保持するための堅牢なアクセス管理に投資します。 | 制御プレーンとデータ プレーンの両方に、ロールベースのアクセス制御 (RBAC) と属性ベースのアクセス制御 (ABAC) を実装します。 適切な ID セグメント化を維持してプライバシーを保護し、表示が許可されているコンテンツへのアクセスのみを許可します。 |
| セグメント化によって設計の整合性を保護します。 | コンテナー イメージ、データ、およびコード資産の一元化されたリポジトリにアクセスするためのプライベート ネットワークを提供します。 インフラストラクチャを他のワークロードと共有すると、セグメント化が作成されます。たとえば、AKS で推論サーバーをホストする場合は、ノード プールを他の API やその他のワークロードから分離する必要があります。 |
| セキュリティ テストを実施する。 | 変更がシステムに導入されるたびに非倫理的な動作を検出するテストを含む詳細なテスト計画を作成します。 AI コンポーネントを既存のセキュリティ テストに統合します。 たとえば、推論エンドポイントを他のパブリック エンドポイントと共に定期的なテストに組み込みます。 潜在的な脆弱性を効果的に特定して対処するために、侵入テストや赤いチーム演習などのライブ システムでテストを実施することを検討してください。 |
| 厳密なユーザー アクセスと API 設計を適用することで、攻撃対象領域を減らします。 | システム間呼び出しを含むすべての推論エンドポイントに対して認証を要求します。 匿名エンドポイントは使用しないでください。 クライアント側の柔軟性を犠牲にして、制約付き API 設計を優先します。 |
Tradeoff. 最も高いセキュリティを提供すると、暗号化されたデータを分析、検査、またはログに記録する機能が制限されるため、コストと精度にトレードオフがあります。 コンテンツの安全性チェックと説明可能性の実現は、高度にセキュリティで保護された環境でも困難な場合があります。
これらの設計領域では、上記の原則と考慮事項について詳しく説明します。
コストの最適化
コスト最適化の柱は、投資を最大化することを目的とします。必ずしもコストを削減するとは限りません。 すべてのアーキテクチャの選択は、直接的および間接的な財務上の影響の両方を伴います。 ビルドと購入の決定、テクノロジの選択、課金モデル、ライセンス、トレーニング、運用費など、さまざまなオプションに関連するコストを理解します。 選択したレベルへの投資を最大化し、継続的に課金モデルを再評価することが重要です。 アーキテクチャ、ビジネス ニーズ、プロセス、チーム構造の変化に関連するコストを継続的に評価します。
コスト最適化の原則を確認し速度と使用状況の最適化に重点を置きます。
| 設計原則 | 考慮事項 |
|---|---|
| 包括的なコスト モデリング演習を実行して、コスト 要因を決定します。 | データとアプリケーション プラットフォームの主な要因を考慮してください。 - データの量。 インデックス作成と処理を行うデータの量を見積もります。 ボリュームが大きくなると、ストレージと処理のコストが増加する可能性があります。 - クエリの数。 クエリの頻度と複雑さを予測します。 クエリの量が多いほど、特に大量の計算リソースが必要な場合に、コストが増加する可能性があります。 - スループット。 予想されるスループットを評価します。これは、必要なパフォーマンス レベルに影響します。 スループットの要求が高いほど、コストが高くなる可能性があります。 - 依存関係のコスト。 依存関係に非表示のコストが発生する可能性があります。 たとえば、インデックスのコストを計算する場合は、データ処理の一部であるがインデックス スコープ外であるスキル セットのコストを含めます。 |
| 使用する予定の料金を支払います。 | 不要な費用を発生させることなく、ニーズを満たすテクノロジ ソリューションを選択します。 高度な機能が必要ない場合は、より経済的なオプションとオープンソース ツールを検討してください。 使用頻度を考慮します。 オーケストレーション ツールのエラスティック コンピューティング オプションを使用して、使用率のコストを最小限に抑えます( オン。 コストのエスカレーションが発生する可能性があるため、フルタイムの操作ではサーバーレス コンピューティングを回避します。 容量を最大限に活用せずに、より高いレベルの料金を支払う必要はありません。 選択したレベルが運用環境の使用パターンと一致していることを確認して、支出を最適化します。 通常のタスクには標準価格を使用し、非常に中断可能なトレーニングにはスポット価格を使用します。 GPU ベースのコンピューティングは、コストを削減するために AI ワークロード関数にのみ使用します。 トレーニングと微調整を広範にテストしてベンチマークし、パフォーマンスとコストのバランスを取る理想的な SKU を見つけます。 |
| 支払い内容を活用します。 無駄を最小限に抑えます。 | 使用状況メトリックを注意深く監視します。 AI ワークロードはコストがかかる場合があり、リソースがシャットダウン、スケールダウン、または使用されていないときに割り当てが解除されていない場合は、コストが迅速にエスカレートする可能性があります。 書き込みを 1 回行い、多くを読み取りデータ ストレージの過剰な保留を回避するようにシステムを最適化します。 トレーニング データでは、実稼働データベースの即時の応答性は必要ありません。 Azure OpenAI 推論エンドポイントのストレス テストは、呼び出しごとに料金がかかるため、コストがかかる場合があります。 コストを削減するには、テスト環境で OpenAI の未使用の PTU を使用するか、代わりに推論エンドポイントをシミュレートします。 探索的データ分析 (EDA)、モデルトレーニング、微調整などのアクティビティは、通常はフルタイムで実行されず、使用されていないときに停止できるプラットフォームを好みます。 たとえば、EDA ジョブは通常対話型であるため、ユーザーは VM を起動し、ジョブを実行する際に停止できる必要があります。 運用チームにコストの説明責任を設定します。このチームは、リソース使用率を積極的に監視および管理することで、コストが予想されるパラメーター内に収まるようにする必要があります。 |
| 運用コストを最適化します。 | オンライン トレーニングは、その頻繁な性質のためにコストがかかる場合があります。 このプロセスを自動化することで、一貫性を維持し、人的エラーによるコストを最小限に抑えることができます。 さらに、少し古いデータをトレーニングおよび更新の遅延に使用すると、可能な場合は、モデルの精度に大きな影響を与えることなく、経費をさらに削減できます。 オフライン トレーニングの場合は、オフライン ハードウェアなど、安価なリソースを使用できるかどうかを評価します。 一般に、機能ストアからデータを削除して、機能の乱雑さとストレージ コストを削減します。 |
オペレーショナル エクセレンス
主な目的は、開発ライフサイクル全体にわたって効率的に機能を提供することです。 これには、実験の設計手法をサポートする反復可能なプロセスを確立し、結果を生成してモデルのパフォーマンスを向上させる必要があります。 オペレーショナル エクセレンスは、時間の経過に伴うモデルの持続的な精度、リスクを最小限に抑えるための効果的な監視プラクティスとガバナンスの実装、モデルの誤差に適応するための変更管理プロセスの開発についても説明します。
すべての 運用エクセレンスの原則 AI ワークロードに適用されますが、運用戦略として自動化と監視に優先順位を付けます。
| 設計原則 | 考慮事項 |
|---|---|
| アプリケーション開発、データ処理、AI モデル管理のライフサイクル全体を通して、継続的な学習と実験の考え方を促進します。 | ワークロード操作は、DevOps、DataOps、MLOps、GenAIOps などの業界で実証済みの手法に基づいて構築する必要があります。 運用チーム、アプリケーション開発チーム、データ チーム間の早期コラボレーションは、許容可能なモデル パフォーマンスの相互理解を確立するために不可欠です。 運用チームは品質シグナルと実用的なアラートを提供しますが、アプリケーションチームとデータ チームは問題の診断と解決を効率的に行うことができます。 |
| 運用上の負担を最小限に抑えるテクノロジを選択します。 | プラットフォーム ソリューションを選択する場合は、セルフホステッド オプションよりも PaaS を優先して、設計を簡略化し、ワークフロー オーケストレーションを自動化し、Day-2 操作を簡単にします。 |
| ログ記録や監査可能性など、アラート機能をサポートする自動化された監視システムを構築します。 | AI の非決定的な性質を考えると、品質測定はライフサイクルの早い段階で確立することが重要です。 データ サイエンティストと協力して品質メトリックを定義し、包括的なダッシュボードで継続的な分析情報を視覚化します。 コード バージョン、環境、パラメーター、実行、結果などの詳細をキャプチャできるツールを使用して実験を追跡します。 オペレーターが迅速に応答するのに十分な情報を含む実用的なアラートを実装します。 |
| モデルの減衰の検出と軽減を自動化します。 | 自動テストを使用して、時間の経過に伴うドリフトを評価します。 応答が予想される結果から逸脱し始めたときに監視システムがアラートを送信し、定期的にアラートを送信するようにします。 新しいモデルを自動的に検出して更新できるツールを使用します。 必要に応じて、データ処理とモデル トレーニング ロジックを調整して、新しいユース ケースに適応します。 |
| 安全なデプロイを実践する。 | ダウンタイムを最小限に抑えるために、サイド バイ サイドデプロイとインプレース更新のどちらかを選択します。 デプロイ前に徹底的なテストを実装して、モデルが正しく構成され、ターゲット、ユーザーの期待、品質基準を満たしていることを確認します。 展開戦略に関係なく、常に緊急時の運用を計画します。 |
| 運用環境でのユーザー エクスペリエンスを継続的に評価する | ワークロード ユーザーが自分のエクスペリエンスに関するフィードバックを提供し、トラブルシューティングのために関連するログの一部またはすべての会話を共有することに同意できるようにします。 実際のユーザー操作を使用してワークロードのパフォーマンスを評価するために、データを熱心にキャプチャして使用するために、実行可能で準拠した安全で有用なユーザー操作の量を検討します。 |
これらの設計領域では、上記の原則と考慮事項について詳しく説明します。
パフォーマンス効率
AI モデルのパフォーマンス評価の目的は、モデルが目的のタスクをどの程度効果的に実行するかを判断することです。 これには、精度、精度、公平性など、さまざまなメトリックの評価が含まれます。 さらに、モデルをサポートするプラットフォームとアプリケーション コンポーネントのパフォーマンスが重要です。
モデルのパフォーマンスも、実験の追跡やデータ処理などの操作の効率の影響を受けます。 パフォーマンス効率の原則を適用は、劣化や減衰を検出するための鍵となる許容品質バーに対するパフォーマンスの測定に役立ちます。 AI コンポーネントを含むワークロードを維持するには、継続的な監視と評価のための自動化されたプロセスが必要です。
| 設計原則 | 考慮事項 |
|---|---|
| パフォーマンス ベンチマークを確立します。 | さまざまなアーキテクチャ領域で厳格なパフォーマンス テストを実施し、許容可能なターゲットを設定します。 この継続的な評価は、1 回限りのテストだけでなく、運用プロセスの一部である必要があります。 ベンチマークは予測パフォーマンスに適用されます。 ベースラインから始めて初期モデルのパフォーマンスを理解し、継続的に再評価して期待を満たしていることを確認します。 |
| パフォーマンス目標を満たす必要があるリソースを評価します。 | 適切なプラットフォームと適切なサイズのリソースを選択するための負荷特性を理解します。 このデータを考慮して、大規模な運用を計画します。 たとえば、ロード テストを使用して、最適なコンピューティング プラットフォームと SKU を決定します。 多くの場合、モデルのトレーニングと微調整には高パフォーマンスの GPU 最適化コンピューティングが必要ですが、汎用 SKU はオーケストレーション ツールに適しています。 同様に、データ インジェストを効率的に処理し、同時書き込みを管理し、個々の書き込みパフォーマンスを低下させることなく維持するデータ プラットフォームを選択します。 推論サーバーによってパフォーマンス特性が異なるため、実行時のモデルのパフォーマンスに影響します。 ベースラインの期待を満たすサーバーを選択します。 |
| パフォーマンス メトリックを収集して分析し、ボトルネックを特定します。 |
データ パイプラインからのテレメトリを評価して、スループットと読み取り/書き込み操作のパフォーマンス目標が満たされていることを確認します。 検索インデックスでは、クエリの待機時間、スループット、結果の精度などのメトリックを考慮してください。 データ量が増えるにつれて、エラー率が上昇しないようにする必要があります。 サービス呼び出しからデータを収集するオーケストレーターなどのコード コンポーネントからのテレメトリを分析します。 そのデータを分析すると、ローカル処理とネットワーク呼び出しに費やされた時間を把握し、他のコンポーネントの潜在的な待機時間を特定するのに役立ちます。 エンゲージメント メトリックを使用して UI エクスペリエンスを評価し、ユーザーが積極的に関与しているか、または不満を抱いているかを判断します。 ページの時間の増加は、どちらかを示すことができます。 音声やビデオの応答などのマルチモーダル機能では、大幅な待機時間が発生し、応答時間が長くなる可能性があります。 |
| 生産からの品質測定を使用してベンチマークのパフォーマンスを継続的に向上させます。 | モデルの有効性を維持するには、パフォーマンス メトリック、アラート、モデルの再トレーニングの自動収集と分析が必要です。 |
これらの設計領域では、上記の原則と考慮事項について詳しく説明します。