Amazon Web Services ブログ
Amazon SageMakerを利用したエンタープライズのためのMLOps基盤ロードマップ
この記事はMLOps foundation roadmap for enterprises with Amazon SageMakerを翻訳したものです。
企業が組織全体で機械学習 (ML)の採用を進めるにつれて 、MLモデルの構築、学習、デプロイのための手動ワークフローがイノベーションのボトルネックになる傾向にあります。これを克服するために、企業はデータサイエンティスト、データエンジニア、MLエンジニア、IT、ビジネス関係者などの複数のペルソナがどのように協業すべきか、懸念事項、責任、スキルをどのように分離するか、AWSのサービスをどのようにして最適に使用するかなどについて明らかにし、明確な運用モデルを構築する必要があります。
このようなMLと運用の組み合わせ(MLOps)により、企業は高いモデル精度を維持し、セキュリティとコンプライアンスを強化しながら、エンド・ツー・エンドのMLライフサイクルを整備し、データサイエンティストの生産性を高めることができます。
本稿では、MLOps 基盤を構築する重要なフェーズや、MLOps基盤上で複数のペルソナがどのように連携するか、Amazon SageMakerのような専用ツール、エンタープライズビジネス全体でMLの採用を加速させる他の AWS サービスとの統合について学びます。
MLOps 成熟度モデル
企業顧客の運用、人材、およびテクノロジーのニーズを包括的に満たせる MLOps基盤を構築することは、難易度が高く、やりがいのある取り組みです。そこで、MLOps基盤に必要な機能に応じた4つのフェーズで示す成熟度モデルを以下のように定義します。
- 初期 (Initial)フェーズ
このフェーズでは、データサイエンティストは SageMakerサービスを使用して AWS上でモデルを実験、構築、学習、デプロイできます。推奨される開発環境はAmazon SageMaker Studioです。この環境では、データサイエンティストが Studio ノートブックに基づいて、実験や共同作業を行えます。
- 反復可能 (Repeatable)フェーズ
AWSで実験を行えるようになったら、次のステップはデータを前処理し、モデルを構築・学習するための自動ワークフロー (MLパイプライン) を作成することです。データサイエンティストは、MLエンジニアとそれぞれ別の環境で協力して、Amazon SageMaker Pipelinesを使用してオーケストレーションされた、堅牢で本番稼働可能なアルゴリズムとソースコードを作成します。生成されたモデルは Amazon SageMaker Model Registryに保存され、ベンチマークされます。
- 信頼可能 (Reliable) フェーズ
モデルはMLパイプラインで生成されていますが、production環境に移行する前にテストする必要があります。そのため、このフェーズでは、分離されたstaging環境（またはpre-production環境）において、モデルやこれをトリガーがするインフラストラクチャの両方に対して自動テストを導入します。staging環境とは、production環境をシミュレートするための環境です。テストが正常に実行されると、モデルは分離されたproduction環境にデプロイされます。複数の環境をまたいでモデルをデプロイするためには、手動による評価と承認が必要です。
- スケーラブルフェーズ
最初の MLソリューションを本番稼働させた後は、複数のデータサイエンスチームが数十または数百の MLユースケースを共同で運用できるようにするために MLOps基盤を拡張する必要があります。このフェーズでは、ソリューションのテンプレート化を導入します。これにより、新たに製品化するソリューションの開発時間を数週間から数日に短縮し、このソリューションが価値を発揮するまでの期間を短縮します。さらに、セキュアなMLOps環境のインスタンス化を自動化して、複数のチームがそれぞれ所有するデータを自身で操作できるようにすることで、IT部門への依存とオーバーヘッドを減らします。
以降のセクションでは、前述の成熟度モデルと以下の原則に基づいて MLOps 基盤を構築する方法を示します。
- 柔軟性
データサイエンティストはどんなフレームワーク (TensorFlow や PyTorch など) にも対応できる - 再現性
データサイエンティストは過去の実験（コード、データ、結果）を再現または観測できる - 再利用性
データサイエンティストとMLエンジニアはソースコードと ML パイプラインを再利用することで、不整合やコスト増を回避できる - スケーラビリティ
データサイエンティストとMLエンジニアは、リソースとサービスをオンデマンドで拡張できる - 監査性
データサイエンティスト、IT、法務部門は、ログ、バージョン、アーティファクトとデータの依存関係を監査できる - 一貫性
MLOps は複数の環境で構成されているため、基盤は環境間のばらつきを排除する必要がある
初期 (Initial) フェーズ
初期フェーズにおけるゴールは、セキュアな実験環境を作ることです。データサイエンティストは、この環境を使ってデータのスナップショットを取得し、SageMakerノートブックを使用して実験します。 また、MLを利用して特定のビジネス上の問題を解決できることを実証します。これを実現するには、Studio環境に対してVPC エンドポイント経由でのアクセスを提供することを推奨します。リファレンスアーキテクチャのソースコードは、SageMakerチームが提供する “Secure Data Science With Amazon SageMaker Studio Reference Architecture” GitHub レポジトリの例が利用できます。
SageMakerサービスに加えて、データサイエンティストは Amazon EMR、Amazon Athena、AWS Glueなどの他のサービスを使用してデータを処理できます。ノートブックはAWS CodeCommitリポジトリに保存され、バージョン管理されます (次図を参照)。
反復可能 (Repeatable) フェーズ
データサイエンティストが MLでビジネス上の問題を解決できることを証明し、SageMakerの実験、学習、モデルのデプロイに慣れたら、次のステップは MLソリューションの本番稼働化を開始することです。次の図でこのアーキテクチャを示します。
このステージでは、懸念事項の分離が必要です。ここでは、環境を次のように複数の AWS アカウントに分割します。
- データレイク アカウント ( Data Lake Account)
オンプレミス (または他のシステム) から取り込まれたすべてのデータをクラウドに保存します。データエンジニアは、複数のデータソースを組み合わせた抽出 (Extract)、変換 (Transform)、読み込み (Load)のETLパイプラインを作成し、MLのユースケースに必要なデータセットを準備します。データは AWS Glue Data Catalogでカタログ化され、AWS Lake Formation (データガバナンスレイヤー) によって他のユーザーやアカウントと共有されます。同じアカウントでAmazon SageMaker Feature Storeをホストできますが、本稿では取り上げません。ご興味のある方は、“Enable feature reuse across accounts and teams using Amazon SageMaker Feature Store” を参照してください。
- 実験アカウント ( Experimentation Account)
データサイエンティストが研究を行えるようにします。初期フェーズとの唯一の違いは、データスナップショットの取得元がデータレイクであることです。データサイエンティストは特定のデータセットにのみアクセス可能で、GDPRやその他のデータプライバシーの制約に応じて匿名化されていることがあります。さらに、実験アカウントはインターネットにアクセスして、データサイエンティストが新しいデータサイエンスフレームワークまたはサードパーティのオープンソースライブラリを使用できるようにする場合があります。そのため、実験用アカウントはproductionとは別の環境として必要です。
- 開発アカウント ( Dev Account)
production環境の第１ステージとなるアカウントです。データサイエンティストはノートブックの世界から自動ワークフローと SageMaker Pipelinesの世界へと移行します。また、MLエンジニアと協力してコードを抽象化し、テストのカバレッジ、エラー処理、コード品質を保証します。目標は MLパイプラインを開発することです。MLパイプラインとは、モデルの前処理、学習、評価、および SageMaker Model Registryへの登録を行う自動ワークフローです。MLパイプラインのデプロイは CI/CD パイプライン経由でのみ行われ、AWS マネジメントコンソールへのアクセスは制限されます。ML パイプラインはデータレイク内の本番データにアクセス (読み取り専用)できるため、インターネット接続は許可されません。
- ツール (自動化)アカウント ( Tooling Account)
CodeCommitリポジトリ、AWS CodePipeline CI/CD パイプライン、SageMaker Model Registry、および カスタムコンテナをホストするためのAmazon ECR をホストします。データレイクはデータに対する信頼できる唯一の情報源 (single point of truth)であるため、ツールアカウントにおいてはコード、コンテナ、作成されたアーティファクトを管理対象とします。
このアカウント命名規則とマルチアカウント戦略はビジネスニーズによって異なる場合があり、この構造はあくまで推奨される分離レベルを示すためのものです。たとえば、開発アカウントの名前をモデル学習アカウントまたはビルドアカウントとする場合もあるでしょう。
デプロイを自動化するには、ノートブックから ML パイプラインに移行し、かつコードリポジトリとデータ構造を標準化する方法を理解することが重要です。これについて次のセクションで説明します。
ノートブックからMLパイプラインへ
開発環境のゴールは、ノートブックのコードを再構築、補完、改善、スケール、ML パイプラインに移行することです。MLパイプラインは、データの前処理、モデルの学習または利用、結果の後処理を行う一連のステップです。各ステップは正確に 1 つのタスク (ある特定のデータ変換) を実行し、再利用できるように十分に抽象化 (たとえば、カラム名を入力パラメータとして渡すなど) する必要があります。次の図は、パイプラインの例を示しています。
ML パイプラインを実装するには、データサイエンティスト (または ML エンジニア) が SageMaker Pipelinesを使用します。MLパイプラインは連続した一連のステップ (SageMaker Processingジョブ、学習、HPO) で、SageMaker PipelinesではJSON形式で記述できます。JSON形式のパイプライン定義ファイルを作るためにPython SDKを利用できます。パイプライン定義は、有向非巡回グラフ (Directed Acyclic Graph: DAG) を使用してパイプラインをエンコードします。この DAGは、MLパイプラインの各ステップの要件と各ステップ間の関係を定義します。
ユースケースに応じて、MLパイプラインを学習とバッチ推論という 2 つの主なタイプに分けられます。次の図は、学習用 MLパイプラインのフローを示しています。
前処理 (Pre-Processing) フェーズは複数のステップで構成されている場合があります。一般的なデータサイエンスにおけるデータ変換には、データの分割とサンプリング (学習、検証、テストセット)、ワンホットエンコーディングまたはベクトル化、ビン化、スケーリングがあります。モデル学習 (Model Training) ステップでは、データサイエンティストが最適なモデル構成を知っている場合は、1つの学習ジョブを実施します。もしくは、ハイパーパラメータ最適化 (HPO) ジョブを実施することで、AWS がモデルに最適なハイパーパラメータを（ベイズ最適化などにて）発見し、該当するモデルアーティファクトを作成します。
評価 (Model Evaluation)ステップでは、作成されたモデルアーティファクトを使用して、検証データセットに対する推論を実行します。次に MLパイプラインは、生成された精度指標 (F1、精度、ゲイン十分位数など) が必要な閾値チェックを通過したかどうかを確認します。このステップが成功すると、モデルアーティファクトとメタデータがモデルレジストリに登録され、production環境へのデプロイに利用されます。
ベースライン抽出 (Export Baseline) ステップでは、 Amazon SageMaker Model Monitorの機能を使います。このステップで生成される統計量を含む JSON オブジェクトは、後にモデルドリフト検出に使用され、SageMaker モデルレジストリでモデルメタデータとしてホストすることが可能です。
バッチ推論において、データサイエンティストは上記と同様のパイプラインを作成できます。(次図参照)
バッチ推論の前処理 (Pre-Processing) ステップは、データサンプリングや正解データのカラムの扱い以外はほぼ学習の時と同じです。バッチ推論 (Batch Inference) は、推論用のデータを対応するエンドポイントにバッチで送信するステップで、SageMakerのバッチ変換を使用して実装できます。後処理 (Post-Processing) ステップでは、結果の分布などの追加の統計情報を生成したり、結果を外部 ID と結合したりします。
次に、モデルモニター (Model Monitoring) ステップは、学習に使用されたデータ (モデルレジストリ内のモデル JSON メタデータ) のベースライン統計を、推論用の新しいデータと比較します。
データサイエンティストが SageMaker Model Registryに保存できるパイプラインモデルを作成する場合は、前処理ステップをスキップできます。詳細については、“Host models along with pre-processing logic as serial inference pipeline behind one endpoint”を参照してください。
リポジトリの標準化
データサイエンティストと ML エンジニアのコラボレーションを実現するには、コードリポジトリ構造の標準化が必要です。さらに、標準化はCI/CDパイプライン構造にとって有益であり、自動検証、ビルド（カスタムコンテナのビルドなど）、およびテスト手順を組み込むことができます。
次の例では、ML ソリューションを 2 つのリポジトリに分けています。1 つは学習 (およびオプションでパイプラインモデル (訳注：パイプラインモデルとは、前処理、推論、後処理などの流れをまとめたモデルのこと)) 用のモデル構築・学習のリポジトリ、もう 1 つはバッチ推論パイプラインモデルを作成したり、リアルタイムエンドポイントをインスタンス化したりするためのデプロイ用リポジトリです。
モデル構築・学習リポジトリ
デプロイリポジトリ
モデル構築・学習リポジトリは３つの主要なフォルダに分かれています。
- アルゴリズム
データサイエンティストは、アルゴリズムのルートフォルダにあるMLパイプラインの各ステップのコードを作成します。ステップは、前処理、学習、バッチ推論、および後処理 (評価) にグループ分けできます。各グループでは、対応するサブフォルダに複数のステップを定義できます。サブフォルダには、 (オプションの入力と出力を含む)ユニットテスト 用のフォルダ、メイン関数、readme、およびカスタムコンテナが必要な場合のDockerファイルが含まれます。メインのほかに、複数のコードファイルを同じフォルダにホストできます。すべてのステップの共通ヘルパーライブラリは、共有ライブラリフォルダでホストできます。
データサイエンティストはステップのロジックを担当しているためユニットテストの開発を担当し、ML エンジニアはエラー処理の強化とテストカバレッジの向上を担当します。CI/CDパイプラインは、テストを実行し、必要に応じて自動的にコンテナを構築し、複数のソースコードファイルをパッケージ化します。 - MLパイプライン
各ステップのソースコードとテストを開発したら、次は別のルートフォルダにSageMakerパイプラインを定義します。各MLパイプライン定義は、.pyファイルと、ハイパーパラメータ範囲などの入力パラメータ用のJSONまたは.yamlファイルを含むサブフォルダに配置されます。MLパイプラインを説明する readme ファイルも用意しましょう。 - ノートブック
データサイエンティストが実験中に使用した、パイプラインの原型となるノートブックが格納されます。
デプロイリポジトリも３つの主要なパートで構成されます。
- 推論の設定
インスタンスタイプなど、リアルタイムエンドポイントまたはバッチ推論の設定を含みます。設定ファイルは環境ごとに用意します。 - アプリケーションのインフラストラクチャ
推論の実行に必要なインフラストラクチャのソースコードをホストします。必要に応じて、Amazon EventBridge、Amazon API Gateway、AWS Lambda関数、SageMaker Pipelinesを介したトリガーを利用することがあります。 - テスト
お客様のテスト方法に応じて複数のサブフォルダで構成されます。最低限のテストとして、統合テスト (アプリケーションインフラストラクチャを含む推論のエンドツーエンドの実行)、負荷テスト (エッジケース、極限状態の検証)、MLテスト (信頼スコアや確率の分布など) をお勧めします。
モデル構築・学習リポジトリに変更をコミットすることで、CI/CDパイプラインはリポジトリ構造の検証、テストの実行、MLパイプラインのデプロイと実行を行います。別のCI/CDパイプラインがモデルの展開を担当します。これについては次のセクションで説明します。
リポジトリのブランチとCI/CDの標準化
開発アカウントにおいてML パイプラインの設計変更による他コードへの影響を最小限にする(ロバスト性確保)ために、マルチブランチリポジトリ戦略が推奨されます。一方で、デプロイは CI/CD パイプラインのみを介して実行されます。データサイエンティストは、featureブランチを利用して新しい機能 (ソースコード) を開発する必要があります。対応する ML パイプラインをデプロイする準備ができたら、これを開発ブランチにプッシュできます。このアプローチに代わる方法として、featureブランチごとに ML パイプラインをデプロイできるようにしてもよいでしょう。詳細については、“Improve your data science workflow with a multi-branch training MLOps pipeline using AWS”を参照してください。
次の図は、ブランチ戦略と必要な CI/CD パイプラインのステップを示しています。
マルチブランチアプローチのコード例が”Multi-Branch MLOps training pipeline”にあります。featureブランチベースの ML パイプラインで作成されたモデルは、別のfeatureモデルグループに保存し、メインブランチとのマージリクエスト中に廃止できます。メインモデルグループのモデルは、production環境用に昇格したモデルです。
データ構造の標準化
ソースコードの標準化と同じくらい、データ構造の標準化は大事です。データ構造を標準化すると、データサイエンティストや機械学習エンジニアはMLモデルやパイプラインのデバック、監査、出所と履歴の監視ができるようになります。下のダイアグラムが例を示しています。
議論を単純にするため、入力の履歴データが開発用アカウントのバケット内でinputという名前のサブキーの下に置かれているとしましょう（通常はデータレイクに置かれています）。それぞれのMLユースケースごとにサブキーを作る必要があります。
データサイエンティストはMLパイプラインをトリガーするため、git commitとpushを行います。これを行うと、CI/CDパイプラインが開始します。CI/CDパイプラインは、まずビルドIDがついたサブキーを作成し、その下にcode、inputという名前のサブキーをそれぞれ作成します。codeの下にコードアーティファクト、inputの下に入力データをコピーします。ビルドIDには、例えば、日付文字列とgit commitハッシュの組み合わせや、SageMaker pipeline run IDを使用できます。この構造によって、データサイエンティストは過去のデプロイやパイプライン実行を監査したり、検索したりできるようになります。
CI/CDパイプラインが終了すると、MLパイプラインがトリガーされます。MLパイプラインの実行中、各ステップにおける中間成果物がml-pipeline-outputs配下に保存されていきます。開発中のfeatureブランチに紐付いたデプロイ/パイプライン実行中にも中間成果物が保存されていくことが大事です。そのためには、featureブランチのIDを含んだサブキーまたはプレフィックス/サフィックスを付与することが必要です。
こうすることで個々の実験に対する完全な監査可能性が担保されます。しかし複数のブランチによって大量のデータが生成されるのでデータのライフサイクルポリシーが必要です。少なくともpull/mergeリクエストが正常に完了した後でそのfeatureブランチのデータを削除することをおすすめしますが、運用体制やビジネス上のニーズにより要求される監査粒度を考慮して適切に設定してください。
信頼性フェーズ
ここまでデータサイエンティスト、MLエンジニア、データエンジニアのそれぞれの関心事を複数のアカウントを使うことで分離する方法を議論してきました。次のステップは、作成されモデルレジストリに登録された機械学習モデルを、推論を行うための分離された環境へのデプロイすることですが、デプロイするモデルの頑健性を保証するため、staging (pre-prod)環境でのシミュレーションが必要です。下の図がアーキテクチャを示しています。
staging環境のエンドポイントへモデルをデプロイするためには、モデルレジストリのステータス更新イベントを利用します（もしくはデプロイ用のレジストリへgit pushします）。すると、EventBridge経由でもう１つのCI/CDパイプラインがトリガーされます。
（訳注：「もう１つのCI/CD」とは上図右上の“Promote to PreProd CI/CD”を示しており、下図でも詳しく説明されています。前のセクションの図で登場する「モデル構築のCI/CD」が、1つ目のCI/CDパイプラインです。）
CI/CDの最初のステップでは、リードデータサイエンティスト（場合によってはプロダクトオーナーやビジネスアナリストを加えてもよいでしょう）が手動でリクエストを承認します。承認者は、モデルのパフォーマンスKPIとデプロイレポジトリのコードをQAします。承認後、CI/CDパイプラインはデプロイレポジトリのコードをテストします（統合テスト、負荷テスト、MLテスト）。モデルのエンドポイントに加え、CI/CDはEventBridge、Lambda関数、API Gatewayなどのトリガーとなるインフラのテストも行います。下の図は、このアップデートしたアーキテクチャを示しています。
CI/CDパイプラインが正常に終了したら、production環境へデプロイする準備ができたことを承認者に通知します。この時点で、ビジネスアナリストが追加の統計的仮説検定を行うこともあります。承認されると、モデルとインフラがproduction環境にデプロイされます。
SageMaker では、ブルー/グリーン、カナリア、A/B テストなど、複数のデプロイの方法が用意されています。デプロイ方法に関する詳細についてはDeployment guardrailsをご参照ください。もしCI/CDパイプラインの実行が失敗した場合は、ロールバックの仕組みによって最後にうまく動いていた状態に戻されます。
下の図は、モデルおよびAPI Gateway、Lambda、EventBridge等によるエンドポイントをトリガーするためのインフラをデプロイするCI/CDパイプラインを示しています。
データレイクとMLOpsの統合
この段階までくると開発ステージやアカウントごとのデータ要件の理解が大切になり、そのためにはデータレイクをMLOpsの中で使う方法が必要です。下の図はその方法を示しています。
データレイクについては、データエンジニアが複数のデータソースを統合してデータセットを作成することに責任を持ちます。例えば、構造化データなら単一のテーブル、画像データならPDFファイルや画像ファイルを含んだ単一のフォルダ等です。このため、データエンジニアは、データ解析の段階でデータサイエンティストが定義したパイプラインにしたがってETLパイプラインを構築します。このデータセットは、必要に応じて学習用、推論用、テスト用など用途別に分割します。
すべてのデータは、AWS Glue Data Catalog等を用いてカタログ化されます。また、構造化データについてはLake Formationをデータガバナンスレイヤーとして利用して他のアカウントと共有できるようにします。執筆時点では、Lake Formationは、Athenaクエリ、AWS Glueジョブ、Amazon EMRと互換性があります。
しかしdev, pre-prod (staing), productionの環境で、ローカルバケットに保存されたデータ（つまりデータレイク上にないデータ）が必要なこともあるでしょう。dev環境はデータレイクからオンデマンドでデータを引き出しモデルを学習させることに責任を持っています。したがって、パイプラインの最初のステップとしてAthenaもしくはEMRを使うとよいでしょう。Athenaはシンプルなサンプリングとクエリのみで解決できる場合、EMRはそれ以上の複雑なデータ変換が必要な場合に向いています。もしくは、SageMaker Pipelinesのコールバックステップ（ネイティブステップではなく）としてGlue jobを使うことも考えられます。（訳注：SageMaker PipelinesでGlue ETLを使用する方法についてはこちらのサンプルコードをご参照ください。）
pre-prod (staing)及びprod環境ではテスト、リアルタイム推論、バッチ推論が行われます。リアルタイム推論を行う場合は、推論のためのインプットデータをMLOpsのpre-prod及びprod環境に送る必要はありません。データはAPI Gatewayリクエストのペイロードとしてインプットされるからです。バッチ推論（入力データが大きい場合）の場合は、テストデータや推論用のデータはpre-prodやprodのローカルMLバケットにコピーされている必要があります。
pre-prod (staging)やprod環境へデータを移動させるには2つの方法があります。1つ目は、AthenaやAmazon EMRをトリガーしてデータレイクからデータを「引っ張って (pull)」くる方法です。2つ目は、データレイクからそれぞれの環境へデータを「押し出す (push)」方法で、スケジューリングされたEventBridgeイベントや、データレイク内のS3へのデータ到着によってトリガーされるEventBridgeイベントを使用できます（スケジューリングされたトリガーを使用した場合、データレイクのデータがアップデートされているとは限りません）。詳細については、Simplifying cross-account access with Amazon EventBridge resource policiesをご覧ください。
AthenaクエリもしくはAmazon EMRによってMLOpsの環境にデータをフェッチしてきた後、非同期推論またはバッチ推論をトリガーできます。この一連の流れは、SageMaker Pipelinesを使えばシンプルにできます。
ETLパイプラインの最後にMLOpsバケットへデータをプッシュするステップを加えることでも実現できますが、この方法では責任範囲が曖昧になります。データレイクが推論をトリガーすることになるからです。また、Lake FormationがMLOpsのバケットにデータを書き込む権限も必要です。
最後のステップは、推論結果をデータレイクに書き戻すことです。データをカタログし他のユーザーからアクセス可能にするため、データは新しいデータソースとしてバケットに返される必要があります。
スケーラブルフェーズ
MLOps基盤と最初のMLユースケース製品化のための開発が終われば、dev/pre-prod/prod環境のインフラ、レポジトリ、CI/CDパイプライン、データ構造がテストされて準備が整ったことになります。
次のステップは、新たなMLユースケースとチームをMLOps基盤にオンボーディングすることです。
すばやくビジネス価値を創出するため、SageMakerではカスタムSageMakerプロジェクトテンプレートを利用できます。カスタムSageMakerプロジェクトテンプレートを使えば、テンプレートのレポジトリとCI/CDパイプラインを自動的にインスタンス化できます。リードデータサイエンティストは、MLユースケースごとに新しいプロジェクトのインスタンス化と専任チームの配属に責任を持ちます。下の図はこのプロセスを示しています。
複数のデータサイエンスチームやMLの製品化を行う複数の部署がある場合、問題は複雑になります。また、複数のチームが様々なコンフィデンシャルデータへアクセスする必要がある場合や、複数のプロダクトオーナーが学習、デプロイ、運用ごとに分割された請求費用に対する責任を持っている場合への対処も複雑になります。
したがって、それぞれのチームごとに、それぞれの環境（experimentation, dev, pre-prod, prod）ごとのAWSアカウントが必要です。新しいAWSアカウントの発行を担うため、IT部門の社員が利用するガバナンス用のAWSアカウントを1つ作成します。このガバナンスアカウントはIT部門の社員が利用し、各AWSアカウントに対するサービスカタログの提供とアカウントの有効化/無効化を行います。具体的には、ガバナンスアカウントはMLOpsを行うAWSアカウントのインフラコード（VPC, サブネット, エンドポイント, バケット, AWS Identity and Access Management (IAM) ロール, IAMポリシー, AWS CloudFormationスタック）を保管するレポジトリをホストし、AWS Service Catalogを用いて複数のアカウントに対するインフラのデプロイをワンクリックで行います。また、Amazon DynamoDBを使って、どのチームがどのAWSアカウントに責任を持っているかなどのメタデータを管理します。
こうすることで、IT部門はMLOpsのためのAWSアカウントを必要なユーザーに対して、適切なデータアクセス制限と一貫したセキュリティとともに提供できます。
このシナリオでは、アカウントは使い捨てのものと、長期的に使用するものに分けましょう。データレイクとツール仕様を管理するアカウントは長期使用とし、データとソースコードの信頼できる唯一の情報源（single point of truth）を管理することになります。その他のMLOpsを担うアカウントはステートレスで、需要に応じて有効にしたり無効にしたりできるものとします。過去の実験や成果物は長期使用アカウントに保存されているため、ユーザーは使い捨てのアカウントが無効になった後でもそれらを確認できます。Studio UIをMLOpsのために使う場合、それを用意するアカウントはdevアカウントに所属します。
AWS CDKを利用したMLOps基盤のソースコード例は“Secure multi-account MLOps foundation based on CDK”でご覧になれます。SageMakerでは、デプロイメントツールとしてCodeCommitやCodePipelineの代わりにGitHubやJenkinsなどのサードパーティ製品もご使用いただけます。詳細については Create Amazon SageMaker projects using third-party source control and Jenkins及びAmazon SageMaker Projects MLOps Template with GitLab and GitLab Pipelinesをご覧ください。
ペルソナと担当する運用、それに必要な技術のまとめ
MLOpsの成熟度モデルによって、アーキテクチャ設計とデリバリーロードマップが明確になります。各ペルソナが各々の運用において使用するAWSアカウントやAWSサービスについても、下の図で明確にしておきましょう。
結論
頑健なMLOps基盤では、複数のペルソナと技術の間のインタラクションが明確です。そして、価値を創出するスピードを加速し、コストを削減し、データサイエンティストがイノベーションに集中できるようにします。本稿では、複数のデータサイエンスチームが複数の機械学習ユースケースをプロダクション運用する状況を想定し、MLOpsの成熟度モデルに則った構築方法を紹介しました。私たちは、それぞれ異なるスキルと責任を持つ複数のペルソナを含む運用モデルを定義しました。最後に、開発環境（レポジトリ、CI/CD）の標準化、データの保存/共有、MLOpsのためのセキュリティについて具体例を紹介しました。多くのお客様が、このアプローチを採用してMLソリューションの製品化にかかる時間を数ヶ月間から数日間へと短縮しています。
この記事はMLエンジニアの真木勇人とデータアナリティクスコンサルタントの大平賢司が翻訳しました。
著者について
Dr. Sokratis Kartakisは、AWSのシニア機械学習スペシャリストソリューションアーキテクトです。エンタープライズのお客様がAWSのベストプラクティスを活用し、機械学習の実用化やMLOpsによる業務改革、変革のロードマップを作成することを支援しています。革新的なend-to-end機械学習及びIoT製品の発明、設計、リード、実装に関する15年以上の経験があり、エネルギー、小売、ヘルスケア、金融/銀行、モータースポーツなどの業界のお客様を支援してきました。余暇の時間は、家族や友人と時間を過ごしたり、モーターバイクに乗って過ごすのが好きです。
Georgios Schinasは、AWSのAI/ML担当のスペシャリストソリューションアーキテクトです。ロンドンを拠点に、イギリスとアイルランドのお客様がAWSを用いて機械学習アプリケーションの設計とデプロイをすることを支援しています。特にMLOpsのプラクティスを活用してお客様にスケーラブルな機械学習を活用いただくことに興味を持っています。余暇の時間は、旅行や料理、友人や家族と時間を楽しんでいます。
Giuseppe Angelo Porcelliは、AWSのプリンシパル機械学習スペシャリストソリューションアーキテクトです。機械学習に関するソフトウェアエンジニアリングの経験があり、様々な規模のお客様のビジネスと技術的ニーズを深く理解したうえで、お客様がAWSの機械学習スタックのベストプラクティスを活用した機械学習ソリューションを設計することを支援しています。MLOps、画像認識、自然言語処理など様々なドメインの経験があります。余暇の時間は、フットボールをプレイして楽しんでいます。
Shelbee Eigenbrodeは、AWSのプリンシパル機械学習スペシャリストソリューションアーキテクトです。技術に関する24年間のキャリアをもち、様々な業界、技術、役割を経験してきました。様々な技術領域で35以上の特許を持ち、継続的なイノベーションとデータを活用したビジネス成果の創出に情熱を持っています。現在はお客様がスケーラブルに機械学習を活用するため、DevOpsと機械学習の経験を組み合わせてMLOpsに注力しています。CouseraのPractical Data Science Specializationで共同制作および講師を務めています。また、Women In Big Data (WiBD) デンバー支部の共同ディレクターです。余暇の時間は、家族と友人、そして元気すぎる犬との時間を楽しんでいます。