本記事の内容は2024/3/16時点の情報です
要約
- AWS Well-Architected - Machine Leaning Lensが2023/7に更新された
- Well-Architected ToolでMachine Leaning Lensが扱えるようになっていた為、手順を紹介
- Machine Leaning Lensの中身も簡単に紹介
はじめに
AWS Well-Architected Frameworkとは
AWS Well-Architected Framework（以下、WA FW）は公式に以下の説明があります。
AWS Well-Architected は、クラウドアーキテクトがさまざまなアプリケーションやワークロード向けに高い安全性、性能、障害耐性、効率性を備えたインフラストラクチャを構築する際に役立ちます。AWS Well-Architected では、6 つの柱 (優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性) に基づいて、お客様とパートナーがアーキテクチャを評価し、スケーラブルな設計を実装するための一貫したアプローチを提供しています。
WA FWは AWSを基盤とするシステムを設計、運用していくにあたって、設計原則やアーキテクチャのベストプラクティスおよびガイドラインをAWS公式で整理し提供してくれているもの というのが私の理解です。
WA FWの文書総量はそれなりにあり、全てのベストプラクティスを確認していくのは相応の時間とコストがかかります。当然すべての柱について確認するのが良いという前提はありつつも、プロジェクトの規模や状況に応じて6つの柱から重要なものを選択したり、確認の粒度を調整して負荷がかかりすぎない形で活用していくのがベターだと思います。
AWS Well-Architected Tool
AWS Well-Architected Tool（以下、WA Tool）についても、公式を参照しておきます。
AWS Well-Architected Tool は、アーキテクチャのベストプラクティスに照らしてアプリケーションとワークロードの状態を確認し、改善の機会を特定し、時間の経過に伴う進行状況を追跡できるように設計されています。
要するにWA FWのレビューツールです。AWSマネージドコンソール上から利用することが可能で、ベストプラクティスを実践できているかの確認項目に回答していくことで、Well-Archiなシステムとなっているかをレビューすることができます。レビュー結果は記録されレポートとして出力することができ、内部での改善検討資料や顧客への説明資料として利用することができます。
利用できるFrameworkはWA FWだけではなく、サーバーレスアプリケーションレンズやデータ分析レンズなどカテゴリごとのプラクティスを扱うことも利用可能です。
Machine Learning Lens
いよいよ本題のAWS Machine Learning Lens（以下、ML Lens）です。
端的に言えば、機械学習ライフサイクルの各フェーズに対するAWSアーキテクチャのガイドライン だと理解しています。
Lensのベストプラクティスに従ったアーキテクチャとなっているかを確認し、改善していくことでより最善なワークロードへと近づけることができます。
公式ドキュメントのIntroductionにはこう書かれています。
This whitepaper provides you with a set of proven best practices. You can apply this guidance and architectural principles when designing your ML workloads, and after your workloads have entered production as part of continuous improvement. Although the guidance is cloud- and technology-agnostic, the paper also includes guidance and resources to help you implement these best practices on AWS.
このホワイトペーパーは、実証済みのベストプラクティスを提供する。このガイダンスとアーキテクチャの原則は、 ML ワークロードを設計する際や、ワークロードが本番稼動した後に、継続的な改善の一環として適用することができます。このガイダンスはクラウドやテクノロジーにとらわれませんが、AWS上でこれらのベストプラクティスを実装するためのガイダンスやリソースも含まれています。
個人的に重要だと思ったのは太字の部分で、「これから構築するシステムも、既に稼働中のシステムでも、いつだってLensを参考にして改善していい」ということです。
また、ML Lensの立ち位置として、
While application workloads rely on step-by-step instructions to solve a problem, ML workloads enable algorithms to learn from data through an iterative and continuous cycle. The ML Lens complements and builds upon the Well-Architected Framework to address this difference between these two types of workloads.
アプリケーションのワークロードが問題を解決するためにステップバイステップの指示に依存するのに対し、MLのワークロードはアルゴリズムが反復的かつ継続的なサイクルを通じてデータから学習することを可能にする。ML Lensは、Well-Architected Frameworkを補完し、その上に構築することで、この2つのタイプのワークロードの違いに対処します。
とあるように、WA FWを補完する立場であることが分かります。
Applicationの基本部分はWA FWで担保しつつ、AIの不確実性や反復的な学習サイクルなどのML固有部分への対応はML Lensで対応する形となります。ML Lensだけ見ればAIシステムとしてWell-Archiになるわけではないということを認識しておきましょう。
最後にML Lensの対象者読者についても言及しています。
This paper is intended for those in a technology role, such as chief technology officers (CTOs), architects, developers, data scientists, and ML engineers. After reading this paper, you will understand the best practices and strategies to use when you design and operate ML workloads on AWS.
本稿は、CTO（最高技術責任者）、アーキテクト、開発者、データサイエンティスト、MLエンジニアなど、技術的な役割を担う方々を対象としています。このペーパーを読めば、AWS 上で ML ワークロードを設計・運用する際のベストプラクティスと戦略を理解できるでしょう。
AI/MLに関わるプロジェクトメンバは全員対象ということでしょう。AWS上のアーキテクチャ設計者やインフラを担当する人間だけを対象としている訳ではないということは抑えておきたいです。
ML Lensの基本構成は、WA FWと同じく6つの柱（オペレーショナルエクセレンス、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性）について設計原則・ベストプラクティスがかかれています。 WA FWよりは分量として少な目ですが、全量に目を通すのは時間がない人は、図表とベストプラクティスのタイトル一覧を見るだけでも面白いかもしれません。
なお、ML Lensは2023/7が最終更新となっており、BedrockやKendraといった最近のサービスやLLM、ベクトルDBなどに関する記述も見当たりませんでした。LLMが流行する前までの特性をとらえたWell-Archiであるともいえるかもしれません。
AWS Well-Architected ToolでMachine Learning Lensのレビューを実施する
では、実際にWell-Architected ToolでMachine Learning Lensのレビューを開始するまでの手順を記載します。
レビュー項目についても最後に概要を記載しています。
レビューの事前準備
レビュー定義のダウンロード
現時点では、ML LensはWA Toolでデフォルトのカタログに含まれていないため、定義ファイルをインポートしカスタムレンズとして登録する必要があります。
従って、まずはML Lensのレビュー定義ファイルをダウンロードします。
以下のAWSリポジトリにアクセスします。
GitHub - aws-samples/aws-machine-learning-lens-well-architected
必要なファイルは以下のwaf-ml-lens-v3.jsonです。こちらをダウンロードします。
現在はv3となっていますが、最新のものを取得してください。
カスタムレンズの登録
AWS マネジメントコンソールからAWS Well-Architected Toolを開きます。
左メニューから「カスタムレンズ」を開きます。
「カスタムレンズを作成」をクリックします。
「ファイルを選択」から先ほどダウンロードしたJSONファイルを選択します。
適宜タグをつけたら、「送信」をクリックします。
カスタムレンズが登録されました。
レンズ名はJSON内に定義されている名称です。レンズ名をクリックして詳細を開きます。
「レンズを公開」
バージョン名を入力して、「カスタムレンズを公開します」をクリックします
ステータスが発行済みになりました。これでこのカスタムレンズを利用可能です。
ワークロードの定義
メニューから「ワークロード」を開きます。
「ワークロードの定義」
レビューに関する基本情報を記入していきます。
レビュー対象のワークロードについて、記入します。
環境、リージョン（もしくはAWS以外の領域）の情報は必須入力です。
今回はテスト実行なので本番稼働前、東京を選択しています。
このほかにオプションで指定できる項目がいくつかありますが、今回は本筋と外れるのでスキップします。実際のレビュー時には適切な値を入力してください。
「次へ」で進むとプロファイルの選択画面になります。
必要があればプロファイルを作成しアタッチしておきましょう。プロファイルに応じて、優先的なチェック項目の表示が変わります。
先ほど追加したカスタムレンズが表示されるため、選択します。
ここで表示されない場合は、カスタムレンズの公開が上手くいっていない可能性があるので前の手順を確認してください。
今回はマネージドのレンズカタログは、特に選択しません。
AWS Well-Architected Frameworkは強制的に選択済みとなっているので、このままにしておきます。
「ワークロードの定義」をクリックします。
これでワークロードの定義が完了です。ML Lensの内容に基づいたレビューが可能となります。
レビュー開始
それではレビューを開始して内容を確認しましょう。
「レビューを続ける」のプルダウンからML Lensを選択します。
レビュー画面は以下のようになります。
今回だと20の設問に対して、それぞれ以下の画像のように詳細の説明とチェック項目が提示されます。
レビュー対象のワークロードに対して、質問内容が上手く合致しない場合や理由があって改善を見送る場合などは「質問はこのワークロードには該当しません」をONにして理由を選択し、評価をスキップすることもできます。
質問だけでなく個々のベストプラクティスのチェックボックスに対しても同様に理由を記載することができます。
以上、ML LensをWA Toolで使用する手順でした。
レビュー内容
折角なので実際のML Lensのレビュー内容を紹介しておこうと思います。
各設問の原文は英語のため、機械翻訳に頼って日本語に直した内容を記載します。
なお、チェック項目自体はBest practices arranged by pillarの内容と同じで、設問の順番がレビュー用に並び替えされているものとなります。
べスプラの原典は下記リンクを参考ください。
Best practices arranged by pillar
オペレーショナルエクセレンスの柱
1. 組織構造と企業文化は、どのように事業成果を支えているか？
説明
組織構造と組織文化は、ビジネスの成果に直接的な影響を与える。チームは、ビジネス成果を達成するための自分たちの役割を理解しなければならない。チームは、他のチームの成功における自分の役割、自分の成功における他のチームの役割を理解し、目標を共有する必要がある。責任、オーナーシップ、意思決定の方法、決定権を持つ者を理解することは、努力を集中させ、チームからの利益を最大化するのに役立つ。
チェック項目
- 説明責任と権限委譲で正しいスキルを身につける
- MLの役割と責任の確立
- モデルの説明可能性のレベルについて議論し、合意する
2. 継続的な発展と改善のために、どのような計画を立てているか？
説明
業務の有効性と効率を改善するために、継続的な改善を可能にするツールとプロセスを使用する。
チェック項目
- モデル改善戦略の確立
- MLライフサイクルの各フェーズにおけるフィードバックループの確立
- 系統追跡システムの確立
- トラッキングとバージョン管理の仕組みを作る
- 品質向上のためのデータプロファイ
- ビジネス要件に対するモデルのコンプライアンスを監視
3. スケーラブルな開発と配備をどのように管理するか？
説明
本番環境への変更の流れを改善し、リファクタリング、品質に関する迅速なフィードバック、バグ修正を可能にするアプローチを採用する。これにより、本番環境に入る有益な変更を加速し、デプロイされる問題を制限し、デプロイ活動によってもたらされた問題の迅速な特定と修復を可能にする。
チェック項目
- MLOpsとCI/CDによる運用の自動化
- アーキテクチャとコンフィギュレーションの同期、環境間のスキューのチェック
- 承認されたパブリック・ライブラリにアクセスするための信頼できるパッケージング・パターンを確立する。
4.MLワークロードの運用状況をどのように把握しているか？
説明
オペレーション・メトリクスを定義、把握、分析し、ワークロードとオペレーション・イベントを可視化することで、適切なアクションを取ることができる。
チェック項目
- デプロイ環境のメトリクスを確立する
- MLプロファイル・テンプレートを準備する
- デプロイ環境のメトリクスを確立する
- 公平性と説明可能性の見直し
セキュリティの柱
1.MLワークロードへのアクセスをどのように制御しているか？
説明
アイデンティティとアクセス管理は、情報セキュリティ・プログラムの重要な部分であり、許可され認証されたユーザとコンポーネントのみが、意図した方法でのみリソースにアクセスできるようにする。インフラ保護は、ベストプラクティスや組織または規制上の義務を満たすために必要な、深層防御などの管理手法を包含する。
チェック項目
- MLデータの許可、プライバシー、ソフトウェア、ライセンス条項の検証
- セキュアなデータとモデリング環境
- セキュアなガバメントML環境
2.MLワークロードへのアクセスをどのように制御しているか？
説明
アイデンティティとアクセス管理は、情報セキュリティ・プログラムの重要な部分であり、許可され認証されたユーザとコンポーネントのみが、意図した方法でのみリソースにアクセスできるようにする。インフラ保護は、ベストプラクティスや組織または規制上の義務を満たすために必要な、深層防御などの管理手法を包含する。
チェック項目
- 最小特権アクセスの確保
- 正当な消費者にアクセスを制限する
- 機密データのプライバシー保護
この設問は、タイトルと説明文が一つ前のものと同じになっています。これはJSON定義の記載からして同じためです。仕様かミスかは分かりません。個人的には2つの設問グループに分ける必要はない気がします。
3.どのようにデータを保護するか？
説明
システムを構築する前に、セキュリティに影響を与える基本的なプラクティスを整えておく必要がある。例えば、データの分類は、機密性のレベルに基づいて組織のデータを分類する方法を提供し、暗号化は、不正アクセスからデータをわからなくする方法でデータを保護する。これらのツールや技術は、経済的損失の防止や規制上の義務の遵守といった目的をサポートするため、重要である。
チェック項目
- データ・リネージの実施
- 関連するデータのみを保持する
- 安全なノード間クラスタ通信
- データポイズニングの脅威からの保護
- データの暗号化と難読化の設計
4.ワークロードをどのように監視、検出し、リスクや脅威から保護するか？
説明
システムを構築する前に、セキュリティに影響を与える基本的なプラクティスを整えておく必要がある。例えば、データの分類は、機密性のレベルに基づいて組織のデータを分類する方法を提供し、暗号化は、不正アクセスからデータをわからなくする方法でデータを保護する。これらのツールや技術は、経済的損失の防止や規制上の義務の遵守といった目的をサポートするため、重要である。
チェック項目
- データと人間の相互作用を監視し、異常な活動を監視する
- 敵対的で悪意のある活動から保護する
信頼性の柱
1.失敗を防ぐために、MLワークロードのアーキテクチャをどのように設計するか？
説明
信頼性の高いワークロードは、ソフトウェアとインフラストラクチャの両方について、前もって設計を決定することから始まります。アーキテクチャの選択は、Well-Architectedの5つの柱すべてにおいて、ワークロードの動作に影響を与えます。信頼性を高めるためには、従わなければならない特定のパターンがある。
チェック項目
- 機械学習マイクロサービス戦略の採用
- APIを使用して、モデル消費アプリケーションからの変更を抽象化する
- モデルエンドポイントの自動スケーリングを可能にする
2.変化に対応するために、MLのワークロードをどのように設計するか？
説明
管理された変更は、新しい機能を展開するために必要であり、ワークロードとオペレーティング環境が既知のソフトウェアを実行し、予測可能な方法でパッチを当てたり置き換えたりできることを保証するために必要である。
チェック項目
- データ変更管理の自動化
- データカタログの使用
- データ・パイプラインを使う
- パイプラインを使ってエンドポイントの変更を自動化する
- 学習と推論における特徴の一貫性の確保
- 関連データによるモデル検証の確実な実施
- データバイアスの検出と緩和の確立
3.失敗を管理し、それに耐えるために、MLのワークロードをどのように準備するか？
説明
複雑なシステムでは、故障が発生することが予想される。信頼性を確保するためには、ワークロードが障害が発生したことを認識し、可用性への影響を回避するための措置を講じることが必要です。ワークロードは、障害に耐えるとともに、問題を自動的に修復できなければならない。
チェック項目
- 適切なデプロイメントとテスト戦略
- トレーサビリティのあるCI/CD/CT自動化を可能にする
- 管理されたバージョン管理戦略でリカバリ可能なエンドポイントを確保する
パフォーマンス効率の柱
1.MLのパフォーマンス効率をどのように評価し、改善計画を立てているか？
説明
クラウド技術は急速に進化しているため、ワークロードコンポーネントが最新の技術とアプローチを使用してパフォーマンスを継続的に改善していることを確認する必要がある。ワークロードコンポーネントのパフォーマンスとコスト目標を確実に達成するために、ワークロードコンポーネントを継続的に評価し、変更を検討しなければならない。ソリューションをアーキテクトする際には、最適なアプローチを確保するためのトレードオフについて考える。状況に応じて、一貫性、耐久性、スペースを時間やレイテンシとトレードオフして、より高いパフォーマンスを実現することができる。
チェック項目
- KPI(主要業績評価指標)の決定
- 関連する評価指標の定義
- モデルの説明可能性の評価
- 性能トレードオフ分析を行う
2.アーキテクチャとインフラをどのように進化させるか？
説明
特定のワークロードに対する最適なソリューションは様々であり、ソリューションはしばしば複数のアプローチを組み合わせる。うまく設計されたワークロードは、複数のソリューションを使用し、パフォーマンスを向上させるためにさまざまな機能を有効にしている。ソリューションをアーキテクトする際には、最適なアプローチを確保するためのトレードオフについて考える。状況によっては、一貫性、耐久性、スペースを時間やレイテンシとトレードオフすることで、より高いパフォーマンスを実現することができる。
チェック項目
- 最新のデータアーキテクチャを使用する
- 専用のAIおよびMLサービスとリソースを使用する
- 再トレーニングのための更新されたデータ/機能をレビューする
- 訓練と推論のインスタンスタイプを最適化する
- 性能向上のための選択肢を探る
- 機械学習の導入オプションを評価（クラウドかエッジか）する
- クラウドでの最適な導入オプションを選択する
3.MLのパフォーマンスをどのように監視し、見直し、改善するか？
説明
ワークロードを実装した後は、そのパフォーマンスを監視し、顧客に影響を与える前に問題を修正できるようにする必要がある。監視指標は、しきい値に違反した場合にアラームを発するために使用されるべきである。
チェック項目
- モデル性能評価パイプラインの確立
- モデル性能劣化の監視、検出、対処
- 特徴統計の確立
- データドリフトを評価する
- 自動再トレーニングフレームワークを確立する
- Human-in-the-loop モニタリングを行う
- 転移学習使用時のパフォーマンス問題を検出する
コスト最適化の柱
1. どのように支出をビジネス目標に合わせ、利用意識を高めるか？
説明
クラウドを利用することで、システムの利用状況やコストを正確に把握することが容易になり、ITコストのワークロード所有者への透明な帰属が可能になる。これは投資収益率（ROI）の測定に役立ち、ワークロード所有者にリソースを最適化してコストを削減する機会を与える。リソース・コストを個々の組織や製品の所有者に帰属させる機能は、効率的な使用行動を促進し、無駄の削減に役立つ。正確なコスト帰属により、どの製品が本当に収益性が高いかを知ることができ、予算を配分する場所について、より多くの情報に基づいた意思決定が可能になる。
チェック項目
- 総合的な投資収益率（ROI）と機会費用を定義する
- 機械学習が適切なソリューションかどうかを見極める
- MLアクティビティによる使用量とコストを監視する
- MLモデルの投資収益率を監視する
2.費用対効果の高い資源の選択と利用をどのように確保するか？
説明
ワークロードに応じて適切なインスタンス、リソース、ツール、サービスを使用することが、コスト削減の鍵となる。適切なサービスを選択することで、使用量とコストを削減することもできる。
チェック項目
- 最適なMLフレームワークを選択する
- 最適なアルゴリズムを選択する
- カスタムモデルと事前学習済みモデルのトレードオフ分析を行う
- 管理されたデータ・ラベリングを使用する
- インタラクティブな分析のためのデータラングラーツールを使用する
- 自動機械学習を利用する
- データと計算の近接性を可能にする
- 最適な計算インスタンスサイズを選択する
- 分散トレーニングを使用する
- 適切な配置オプションを使用する
- 費用対効果の高いハードウェア・オプションを検討する
- ホスティングインスタンスモデルを適正化する
3.需要と供給のリソースをどのように管理するか？
説明
費用とパフォーマンスのバランスが取れたワークロードの場合、支払った費用がすべて使用されていることを確認し、インスタンスの使用率が著しく低くなることを避ける。いずれかの方向に偏った利用指標は、運用コスト（過剰利用によるパフォーマンスの低下）または無駄なAWS支出（過剰プロビジョニングによる）のいずれかにおいて、組織に悪影響を及ぼす。
チェック項目
- マネージド・サービスを利用して総所有コスト（TCO）を削減する
- 未使用時のリソースを停止する
- 機能の再利用を可能にする
- デバッグとロギングを有効化する
- マネージド・データ処理機能を使用する
- 予算を設定し、リソースタグを使用してコストを追跡する
- エンドポイントの使用状況を監視し、インスタンス・フリートのサイズを適正化する
4.どのようにモデルトレーニング中のコストを最適化するか？
説明
ワークロードに応じて適切なインスタンス、リソース、ツール、サービスを使用することが、コスト削減の鍵となる。適切なサービスを選択することで、使用量とコストを削減することもできる。
チェック項目
- 小規模実験のためのローカルトレーニングを選択する
- 小規模なデータセットで学習を開始する
- ハイパーパラメータ最適化技術を使う
- ウォームスタートとチェックポイントによるハイパーパラメータ・チューニングを利用する
- マネージドトレーニング機能を使用する
- 管理されたビルド環境を使用する
持続可能性の柱
1.持続可能性の目標を事業目標と整合させ、意識を高める。
説明
サステナビリティは、環境への影響、特にエネルギー消費と効率に焦点を当てます。なぜなら、これらはアーキテクトにとって、資源の使用量を削減する方法について直接的な行動を導く重要なレバーだからです。ビジネス要件を満たしながら、持続可能性の目標をサポートするサービス・レベル・アグリーメント（SLA）を定義する。ビジネス要件を満たすようにSLAを定義する。サービスレベルの許容可能な低下と引き換えに、環境への影響を大幅に削減するトレードオフを行う。
チェック項目
- 総合的な環境影響または便益を定義する
- AIサービスと訓練済みモデルを検討する
- 持続可能な地域を選択する
- 持続可能性の目標に沿ったデータライフサイクルポリシーを導入する
- 持続可能なパフォーマンス基準を定義する
- SLAと持続可能性目標の整合をとる
- 材料効率を測定する
2.持続可能な資源の選択と利用をどのように確保するか？
説明
最小限のリソース使用で望ましい結果が得られるアルゴリズムを選択する。最も効率的なアルゴリズムバージョン、モデル展開インスタンスタイプ、推論インスタンス、展開モードを選択し、可能であればサーバーレスパイプラインを使用することで、最適化の機会を継続的に評価する。適切なリージョン、リソースタイプ、ストレージタイプ、推論エンドポイントタイプを選択することは、より持続可能なワークロードの構築に役立つ。
チェック項目
- エネルギー効率の高いアルゴリズムを選択する
- アイドルリソースを最小化する
- 持続可能なストレージオプションを採用する
- 不要なトレーニング成果物をアーカイブまたは削除する
- 効率的なモデルチューニング方法を使用する
- 推論モデルを最適化する
- 単一のエンドポイントのバックエンドに複数のモデルを配置する
- 必要なときだけ再学習する
おわりに
今回はAWS Well-Architected ToolでMachine Learning Lensに基づくレビューを行う手順を紹介しました。
現時点でML LensではLLMや基盤モデルサービスに関する記述はありませんが、機械学習を用いたシステムに共通するベストプラクティスや検討事項はあるはずなので、LLMが流行した今の時代でも参考になる部分はあるように感じます。特に出力や精度をいかに予測し制御するか、コスト予測と最適化をどのように行うか、セキュリティとガバナンスをどうコントロールするか、などは引き続きの課題であり、AIの健全な運用や顧客への説明責任のために検討しなければいけない事項は沢山あります。こういったチェック事項を一通り提供してくれるという点で、AWS Well-Architected Tool＆Machine Learning Lensはアーキテクトをサポートしてくれるツールといってよいでしょう。うまく活用していきたいところです。
以上、ML Lensの普及と更新を期待しての投稿でした。