

# オペレーションのパースペクティブ: AI 環境の正常性と可用性
<a name="operations-perspective-health-and-availability-of-the-aiml-landscape"></a>

 ML アプリケーションの運用は、多くのお客様にとって初めてのことです。新しい CAF-AI 機能である [AI のライフサイクル管理と MLOps](platform-perspective-infrastructure-for-and-applications-of-aiml.md#aiml-lifecycle-management-and-mlops) では、これに取り組むためのいくつかのパースペクティブとガイダンスを既に紹介しました。すでに説明した内容以外にも、インシデント管理とパフォーマンスについて考慮する必要があります。この CAF-AI の視点をさらに深く掘り下げるには、AWS Well-Architected Framework の「[MLOps の成熟度フレームワーク](https://aws.amazon.com/blogs/machine-learning/mlops-foundation-roadmap-for-enterprises-with-amazon-sagemaker/)」と「[機械学習レンズ](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/well-architected-machine-learning.html)」をご覧になることをお勧めします。両方とも、これらの課題に関する豊富なドキュメントとベストプラクティスで構成されています。


|  **基礎的能力**  |  **説明**  | 
| --- | --- | 
|  インシデントと問題の管理  |  予期しない AI の動作を特定して管理します。 | 
|  パフォーマンスと容量  |  AI ワークロードのパフォーマンスをモニタリングおよび管理します。 | 
|  可観測性  |  この能力は AI にとって充実したものではなく、[AWS CAF を参照してください](https://aws.amazon.com/professional-services/CAF/)。 | 
|  イベント管理 (AIOps)  |  この能力は AI にとって充実したものではなく、[AWS CAF を参照してください](https://aws.amazon.com/professional-services/CAF/)。 | 
|  変更およびリリース管理  |  この能力は AI にとって充実したものではなく、[AWS CAF を参照してください](https://aws.amazon.com/professional-services/CAF/)。 | 
|  設定管理  |  この能力は AI にとって充実したものではなく、[AWS CAF を参照してください](https://aws.amazon.com/professional-services/CAF/)。 | 
|  パッチ管理  |  この能力は AI にとって充実したものではなく、[AWS CAF を参照してください](https://aws.amazon.com/professional-services/CAF/)。 | 
|  可用性と継続性管理  |  この能力は AI にとって充実したものではなく、[AWS CAF を参照してください](https://aws.amazon.com/professional-services/CAF/)。 | 

## インシデントと問題の管理
<a name="incident-and-problem-management"></a>

 **予期しない AI の動作を特定して管理します。**

AI システムは、1 人の人物の専門知識だけでは問題を把握または解決するのに十分ではない状況でよく使用されます。AI システムのこのような性質により、システムやエッジケースの一般的な動作を理解することは困難で、時間の経過とともにパフォーマンスが低下する可能性を予測することが難しくなります。このため、実務者はプロキシと簡略化された統計を通じて AI システムを調べます。AI の[観察とモニタリング](https://aws.amazon.com/blogs/architecture/optimize-ai-ml-workloads-for-sustainability-part-3-deployment-and-monitoring/)を導入する際、このような AI システムの簡略化されたビューが重要になります。これは開発の初期段階ですでに当てはまりますが、システムを実際の条件下で使用する場合に特に重要です。

AI システムは確認されても検証されないこと、および持続的で継続的な管理とモニタリングが必要であることを認識したプラクティスを確立するようにしてください。その一例が共変量シフトで、ラボで開発された AI システムのパフォーマンスが、本番環境で見られるものとは大きく異なります。必要に応じて、顧客やユーザーが「好ましくない」または「間違っている」と結果にフラグ付けできるようにしてください。顧客やユーザーが直接やり取りしてインシデントを報告するための手段を設けましょう。最初から、ドリフト、共変量シフト、ブラックスワンイベント、観測されていないデータポイントなどを通じて、データ、そしてパフォーマンスの変更に備えます。システムで可能であれば、適切に障害を発生させ、そのようなインシデントを報告して対応し、そこから学ぶ方法を提供します。システムがうまく機能しない顧客やユーザーはデータに表れないことが多いと予想してください。最後に、このようなインシデントは発生するものと想定し、何も報告されない場合は疑わしいと考えてください。この課題は、AI システムの規模と複雑さに比例して大きくなることが予想されます。例えば、基礎モデルは、単純なデシジョンツリーと比較して修正とモニタリングが非常に困難です。

## パフォーマンスと容量
<a name="performance-and-capacity"></a>

 **AI ワークロードのパフォーマンスをモニタリングおよび管理します。**

 AI は、従来のソフトウェアとは異なる開発サイクルをたどるため、パフォーマンスとワークロードのプロファイルが異なります。開発の初期段階でデータが調査され、コストとパフォーマンスの点では、非常に多くのさまざまなワークロードへの適応が求められます。このようなワークロードの大半は、多くの場合、強力なマシン、専用のハードウェア、メモリ効率の高いアーキテクチャを必要とする実験やトレーニングのワークロードです。クラウドを使用すると、それぞれがまばらに、開発ライフサイクルの特定の時点でのみ発生するこのようなワークロードのプロファイルに動的に対応する機能が提供されるため、この多数のワークロードを有効にできます。

時間が経つにつれて、トレーニングと合理化された前処理がワークロードプロファイルを引き継いで支配するようになり、一貫性と予測可能性が高まります。イノベーションのスピードは、この新しいプロファイルに適応し、開発と生産の境界を明確にしながら、両者の間を迅速かつ継続的に移行する能力に影響されます。モデルアーティファクトと、このような合理化されたワークロードを促進しているデータが、潜在的なフォールバックに利用できることを確認してください。モデルがデプロイおよび運用段階に移行したら、非機能要件 (レイテンシーやスループットなど) のコストに対して推論が最適化され、パフォーマンスと容量のモニタリングが実施されていることを確認します。[AI のライフサイクル管理](platform-perspective-infrastructure-for-and-applications-of-aiml.md#aiml-lifecycle-management-and-mlops) 機能については、MLOps の成熟度モデルを導入しました。運用に関するより深い洞察を得るには、このリンクを参照してください。時間の経過とともに[複数の種類のワークロードプロファイルが混在および混合し](https://www.amazon.science/blog/building-systems-that-automatically-adjust-to-workloads-and-data)、データサイエンティストが立ち上げ前に個別に開発した際のプロファイル (多くの場合、ラボで呼び出されたもの**) とはほぼ異なるものになります。Well-Architected-Framework と、クラウドでそのようなシステムを構築する方法を説明する専用の ML レンズを詳しく見てみましょう。