Azure での AI ワークロード操作

AI ワークロードを構築して運用環境に移行する場合、運用チームは、他の運用ワークロードと同様に、これらのワークロードを完全にサポートできる状態にすることが重要です。 運用チームは AI テクノロジの経験が限られている可能性があるため、これらのテクノロジをトレーニングし、プロセスの早い段階で AI ワークロードをワークフローに統合することが不可欠です。 AI ワークロードの開発の早い段階で運用チームとデータ チームをまとめ、各チームのプロセスの相互理解を促進します。 この早期コラボレーションは、AI ワークロードを効果的にサポートするために両チームが緊密に連携する必要があるため、非常に重要です。 データ チームは、信頼性の高い正常性シグナルと実用的なアラートを提供するために運用チームに依存しています。 運用チームは、潜在的な問題を診断し、運用基準に従って実際の問題を解決するために、データ チームに依存しています。 このパートナーシップは、スムーズで効率的なシステムパフォーマンスを保証するのに役立ちます。

このガイドでは、AI ワークロードのサポートを改善するための運用メカニズムとプラクティスを開発する方法に関する推奨事項を示します。 運用チームとデータ チーム間の効率的なコラボレーションが重視されます。

推奨事項

この記事で提供される推奨事項の概要を次に示します。

可観測性プラットフォームを拡張する

オペレーショナル エクセレンスを実現するには、堅牢な可観測性が不可欠です。 組織が AI テクノロジを採用する場合、ワークロードの正常性を包括的に監視できるように監視プラットフォームを強化することが重要です。 AI を初めて使用する組織には、運用チーム内にビッグ データ、データ サイエンス、DataOps の専門知識がない可能性があります。 そのため、運用上のベスト プラクティスに関するトレーニングは、監視プラットフォームを改善するための重要な最初のステップです。 このため、運用チームとデータ チームは共同作業して、キャプチャおよび分析する監視とメトリックの正しいモードを決定する必要があります。

モデルの正常性を評価するには、その特定の品質メトリックの包括的な概要が必要です。 品質測定には、通常、モデルの鮮度、出力の正確性、応答の待機時間などのメトリックが含まれます。 ただし、データ サイエンティストやエンジニアと協力して、ワークロードの品質を定義する特定のメトリックを確立する必要があります。 AI ワークロードの非決定的な性質により、品質の監視は特に重要になります。これらの測定値はデプロイ後いつでも予期せず変更される可能性があるためです。 可観測性に関する推奨事項は次のとおりです。

• データ サイエンティストやエンジニアと協力して、品質メトリックを決定します。

• ダッシュボードを構築または拡張して、ワークロードの全体的な正常性を評価します。 このアプローチには、コンポーネントの可用性メトリックと品質メトリックが含まれている必要があります。

• 運用チームが理解して対処できる、適切に設計された可用性と品質のアラートを実装します。

• 運用チームが品質アラートにどのように対応するかを定義する標準の運用手順 (データ チームと協力して潜在的な誤動作を調査および修復するなど) を体系化します。

• AI ワークロードを実行するにはコストがかかる可能性があるため、使用率メトリックに細心の注意を払います。 ワークロード チームがリソースを使用していないときにシャットダウン、スケールダウン、または割り当てを解除しないと、コストが迅速に増加する可能性があります。 運用は、使用率を監視することで、コストが予想されるパラメーター内に収まるようにするのに役立ちます。

安全なデプロイ プラクティスに AI ワークロード コンポーネントを含める

AI ワークロードは、多くの場合、機密情報を含む運用データに依存します。 そのため、これらのワークロードに関して最高レベルの安全性を維持することが重要です。 データを保護するために、 セーフなデプロイ プラクティスを拡張し ワークロードの AI コンポーネントに関連するすべてのコードを含めます。 ワークロードにダウンタイムゼロの要件がある場合は、それに応じて AI コンポーネントのデプロイ アプローチを設計します。

• 推論エンドポイントの場合は、デプロイ モデルに応じて、トラフィック ミラーリングの有無に関係なく、ブルーグリーンデプロイまたはカナリア デプロイを使用します。

• インデックスサービスの場合は、エイリアスの更新を伴うサイドバイサイドデプロイモデルを使用してトラフィックをカットします。

• オーケストレーション コードの場合は、機能フラグまたは青緑色のデプロイを使用します。

アプリケーション、データ プラットフォーム、および特定のネットワーク トポロジによっては、Azure アプリlication Gateway、Azure Front Door など、ゲートウェイ ソリューションの使用が必要になる場合があります。

ツール

Azure Machine Learning では、 ブルーグリーン デプロイがサポートされます トラフィックの分割が組み込まれています。

作業を一からやり直すことを避ける

オンライン推論エンドポイントは基本的にマイクロサービスであるため、ワークフロー内の特定の機能を提供する独自のデータとコードを使用して、完全に自己完結型のワークロード コンポーネントとして動作します。 このため、オンライン推論エンドポイントは、独自のライフ サイクルを持つ他の重要なマイクロサービスと同様に扱います。 オンライン推論エンドポイントは個別に更新できます。 ただし、大規模なワークロードの他のマイクロサービスと同様に、シームレスに連携する必要があります。 そのため、更新プログラムをデプロイするときは、統合テストに優先順位を付ける必要があります。 デプロイが他のサービス (モデル サービスやオーケストレーターなど) に悪影響を与えないことを確認します。 また、バッチ推論エンドポイントは、多くの場合、ジョブ処理コンピューティングと密接に結合され、データ パイプラインに含まれます。 このような場合は、マイクロサービスとしてではなく、より大きなソリューションの一部として扱います。

運用環境でのテストのサポート

運用チームは、 AI ワークロード テストを設計または実行しない可能性があります。 ただし、運用環境ではテストが必要であるため、監視、アラート、調査を通じて AI ワークロードテストをサポートする必要があります。 AI の非決定的な性質のため、運用環境でのテストは、ワークロードが時間の経過と同時に期待どおりに動作していることを確認するために必要です。 運用チームは、ワークロード チームと緊密に連携して、異常なテスト結果を効率的かつ運用標準に従ってキャプチャして診断する必要があります。 運用がテストをサポートできることと、ワークロード チームがテストを実行できるようにするには、両方のチームが連携するプロセスを調整する必要があります。 非運用環境でのテスト アクティビティに関するトレーニングは、チームが運用の順序を理解するのに役立ちます。

可能な場合は運用プラクティスを自動化する

監視、アラート、テスト プロセスなど、ワークロード関連のすべての運用プラクティスを自動化します。 自動化は、プロセスを反復可能で効率的で一貫性のある状態に保つための主要な戦略です。 自動化戦略を設計するときは、モデルの不整合やその他の品質シグナルを適切に診断するなど、アクティビティに対する人間の監視が必要です。 これは、最初のリリースに特に当てはまります。 モデルの維持に関連するプロセスは運用チームにとって新しいため、この段階では品質シグナルに対する不適切な応答のリスクが高くなります。 ワークロードが成熟するにつれて、自動化を使用して、適切に設計された品質ゲートで誤ったアラームを識別できる場合がありますが、その時点に進むには、長く複雑なプロセスになる可能性があります。

可能であれば、既存の自動化ツールを再利用して、AI ワークロードの新しい自動化タスクを実行します。 たとえば、既に Azure Pipelines または GitHub ワークフローを使用している場合は、別のツールを使用する代わりに、それらを引き続きオーケストレーション コードのデプロイに使用します。 ただし、1 つの自動化ツールのみを使用する作業では、過剰なエンジニアリングは避けてください。 特定のタスクまたはジョブが選択したツールに適していない場合は、不要な複雑さを追加するカスタム ソリューションを構築する代わりに、より適切なツールを選択します。

DevOps プラクティスを採用する

ワークロード開発の初期段階で、開発プロセスで DevOps プラクティス の使用を標準化します。 サンドボックス環境以外のすべての環境では、厳密に定義および適用された標準によって、開発ライフ サイクル全体を管理する必要があります。 手動展開アクティビティを厳密に禁止して、これらの標準を適用します。 更新プログラム、パッチ、新しいリソースデプロイのいずれであっても、すべてのデプロイは、 安全なデプロイプラクティスに準拠した継続的インテグレーションと継続的デプロイパイプラインを通じて実行する必要があります。 DevOps の適切な衛生プラクティスには、次のものが含まれている必要があります。

• バージョン管理: 可能な限り、すべてのコード資産に対してバージョン管理を使用します。 バージョン管理は、DevOps と適切な変更管理プラクティスの基礎となるものであり、スムーズなコラボレーションに不可欠です。 SDK やコンテナー イメージを含むライブラリ パッケージにバージョン管理を適用します。 ソフトウェア開発ライフサイクル (SDLC) 全体で特定のバージョンのライブラリ パッケージを使用する場合は、一貫性を保ちます。 さまざまな開発環境で XGBoost や scikit-learn などのライブラリのバージョンが異なると、ワークロードの動作が変動する可能性があります。 モデルのバージョン管理にも同じことが当てはまります。 実稼働前環境でモデルの 1 つのバージョンをテストし、運用環境で別のバージョンをリリースしないように、モデルのバージョンが SDLC 全体で一貫していることを確認します。

• 簡易バージョンの名前付けスキーム: 単純なバージョンの名前付けスキームを使用して、特定の資産の最新の承認済みバージョンを常に使用できるようにします。 AI 固有の資産には、次のものが含まれます。

  • ノートブック コード。
  • オーケストレーター コード。
  • データ処理ジョブ コード。
  • Machine Learning ジョブ コード。
  • モデル。

• 操作可能なツール: 一部のツールは実験には適していますが、運用化用に設計されていません。 この制限により、運用の自動化に統合するのが困難または不可能になる可能性があります。 たとえば、ノートブックは実験や探索的データ分析の作業に適したツールですが、運用パイプライン開発作業には適したツールではありません。 実験を完了したら、これらのツールからロジックをプルし、ジョブ コードに使用できる Python パッケージに配置します。

適切なドキュメント プラクティスを採用する

適切なドキュメントの習慣は、すべての種類のワークロードにとって重要です。 AI ワークロードの複雑さは、これらの習慣をさらに重要にします。 ドキュメントが安全に格納され、バージョン管理されているワークロード チームに固有のリポジトリがあることを確認します。 他のワークロードと同様に、標準情報を文書化する必要があります。 この標準情報には、ワークロード、セキュリティ構成、ネットワーク設計、セットアップ ガイドで使用されるすべてのツールが含まれます。 次の AI 固有のワークロード情報を文書化することを検討してください。

• モデルトレーニングと接地データインデックス管理情報: データ ソースの所有者、データ ソースの所有者、更新頻度、バイアス除去プロセスを文書化して、モデルのトレーニング方法と接地データの処理方法を確立します。

• トレーニング プロセスの履歴: 特定のハイパーパラメーター、温度、重み、およびその他のパラメーターを選択した理由を文書化することで、現在承認された構成に到達した方法を詳しく説明します。 テストした他の構成と、トレーニング プロセス全体で観察した動作の変更を含めます。 この情報は、失敗または非効率的な構成の繰り返しを防ぐのに役立ちます。

• フィーチャー ストア情報: 予測能力が最も高い機能とその決定方法を文書化します。

• データ サイエンティスト ワークステーションの構成: データ サイエンティストのオンボード プロセスを合理化するために、ワークステーションの構成を徹底的に文書化します。 conda 環境を使用するために必要なライブラリと依存関係を指定します。

• データ変換情報: データ変換が発生したときに、プロセス全体を最初から最後まで文書化します。 インジェスト時のデータの表示方法と、変換後のデータの表示方法を文書化します。

ツール

MLFlow と Machine Learning を使用した自動構成と履歴キャプチャを利用します。

次のステップ