エンタープライズビジネスが組織全体で機械学習(ML)を採用しているため、MLモデルを構築、トレーニング、および展開するための手動ワークフローは、イノベーションのボトルネックになる傾向があります。 これを克服するために、企業は、データサイエンティスト、データエンジニア、MLエンジニア、IT、ビジネスの利害関係者などの複数のペルソナがどのように協力して相互作用するかを定義する明確な運用モデルを形成する必要があります。 懸念、責任、スキルをどのように分離するか。 AWSサービスを最適に使用する方法。 MLと運用(MLOps)のこの組み合わせは、企業がエンドツーエンドのMLライフサイクルを合理化し、データサイエンティストの生産性を高めながら、高いモデル精度を維持し、セキュリティとコンプライアンスを強化するのに役立ちます。
この投稿では、MLOps基盤を構築するための主要なフェーズ、この基盤で複数のペルソナがどのように連携するか、および アマゾンセージメーカー 専用ツールと他のAWSサービスとの組み込み統合により、エンタープライズビジネス全体でのMLの採用を加速できます。
MLOps成熟度モデル
企業顧客の運用、人員、および技術のニーズをカバーできるMLOps基盤を構築することは困難です。 したがって、XNUMXつの主要なフェーズでMLOpsの必要な機能を定義する次の成熟度モデルを定義します。
- 初期段階: このフェーズでは、データサイエンティストは、SageMakerサービスを使用して、AWSでモデルを実験、構築、トレーニング、およびデプロイできます。 推奨される開発環境は Amazon SageMakerスタジオ、データサイエンティストは、Studioノートブックに基づいて実験とコラボレーションを行うことができます。
- 繰り返し可能なフェーズ – AWSで実験する機能を備えた次のステップは、データを前処理し、モデル(MLパイプライン)を構築およびトレーニングするための自動ワークフローを作成することです。 データサイエンティストは、別の環境でMLエンジニアと協力して、堅牢で本番環境に対応したアルゴリズムとソースコードを構築し、 AmazonSageMakerパイプライン。 生成されたモデルは、Amazon SageMakerモデルレジストリに保存され、ベンチマークされます。
- 信頼できるフェーズ –モデルはMLパイプラインを介して生成されていますが、本番環境に昇格する前にテストする必要があります。 したがって、このフェーズでは、モデルとトリガーインフラストラクチャの両方に対して、本番環境をシミュレートする分離されたステージング(本番環境前)環境に自動テスト方法が導入されます。 テストが正常に実行された後、モデルは本番環境の分離された環境にデプロイされます。 複数の環境間でモデルを宣伝するには、手動による評価と承認が必要です。
- スケーラブルフェーズ –最初のMLソリューションの生産後、複数のデータサイエンスチームが協力して数十または数百のMLユースケースを生産することをサポートするために、MLOps基盤をスケーリングする必要があります。 このフェーズでは、ソリューションのテンプレート化を紹介します。これにより、新しい本番ソリューションの開発時間が数週間から数日に短縮され、価値にスピードがもたらされます。 さらに、安全なMLOps環境のインスタンス化を自動化して、複数のチームがデータを操作できるようにし、ITへの依存とオーバーヘッドを削減します。
次のセクションでは、前述の成熟度モデルと次の信条に基づいてMLOps基盤を構築する方法を示します。
- 柔軟性 –データサイエンティストは、あらゆるフレームワーク(TensorFlowやPyTorchなど)に対応できます
- 再現性 –データサイエンティストは、過去の実験(コード、データ、および結果)を再現または観察できます。
- 再利用性 –データサイエンティストとMLエンジニアは、ソースコードとMLパイプラインを再利用して、不整合とコストを回避できます
- スケーラビリティ –データサイエンティストとMLエンジニアは、リソースとサービスをオンデマンドで拡張できます
- 監査能力 –データサイエンティスト、IT、および法務部門は、ログ、バージョン、およびアーティファクトとデータの依存関係を監査できます。
- 一貫性 – MLOpsは複数の環境で構成されているため、基盤は環境間の差異を排除する必要があります
初期段階
初期段階の目標は、データサイエンティストがデータのスナップショットを受け取り、SageMakerノートブックを使用して実験を行い、MLが特定のビジネス上の問題を解決できることを証明する安全な実験環境を作成することです。 これを実現するには、VPCエンドポイントを介したサービスへのアクセスを調整したStudio環境をお勧めします。 リファレンスアーキテクチャのソースコードは、SageMakerチームが提供する例で入手できます。 AmazonSageMakerStudioリファレンスアーキテクチャを使用した安全なデータサイエンス GitHubレポ。
SageMakerサービスに加えて、データサイエンティストは、他のサービスを使用してデータを処理できます。 アマゾンEMR, アマゾンアテナ, AWSグルー、ノートブックが保存され、バージョン管理されている AWS コードコミット リポジトリ(次の図を参照)。
繰り返し可能なフェーズ
データサイエンティストがMLがビジネス上の問題を解決できることを証明し、SageMakerの実験、トレーニング、モデルのデプロイに精通したら、次のステップはMLソリューションの生産を開始することです。 次の図は、このアーキテクチャを示しています。
この段階では、関心の分離が必要です。 環境を複数のAWSアカウントに分割します。
- データレイク –オンプレミス(または他のシステム)からクラウドに取り込まれたすべてのデータを保存します。 データエンジニアは、複数のデータソースを組み合わせて抽出、変換、読み込み(ETL)パイプラインを作成し、MLのユースケースに必要なデータセットを準備できます。 データはAWSGlueデータカタログを介してカタログ化され、を介して他のユーザーやアカウントと共有されます AWSレイクフォーメーション (データガバナンス層)。 同じアカウントで、 Amazon SageMaker フィーチャーストア ホストすることはできますが、この投稿では取り上げません。 詳細については、を参照してください。 Amazon SageMaker Feature Storeを使用して、アカウントおよびチーム間で機能の再利用を可能にします.
- 実験 –データサイエンティストが調査を実施できるようにします。 唯一の違いは、データスナップショットの発信元がデータレイクであるということです。 データサイエンティストは特定のデータセットにのみアクセスでき、GDPRやその他のデータプライバシーの制約がある場合は匿名化できます。 さらに、実験アカウントはインターネットにアクセスして、データサイエンティストが新しいデータサイエンスフレームワークまたはサードパーティのオープンソースライブラリを使用できるようにする場合があります。 したがって、実験アカウントは非本番環境の一部と見なされます。
- 開発(開発) –実稼働環境の最初の段階。 データサイエンティストは、ノートブックから自動ワークフローとSageMakerパイプラインの世界に移行します。 MLエンジニアと協力してコードを抽象化し、テスト、エラー処理、コード品質を確実にカバーする必要があります。 目標は、MLパイプラインを開発することです。これは、モデルを前処理、トレーニング、評価し、SageMakerモデルレジストリに登録する自動ワークフローです。 MLパイプラインのデプロイは、CI / CDパイプラインを介してのみ駆動され、 AWSマネジメントコンソール 制限されています。 MLパイプラインはデータレイク内の本番データにアクセスできるため、インターネット接続は許可されていません(読み取り専用)。
- ツーリング(または自動化) –CodeCommitリポジトリをホストします。 AWS コードパイプライン カスタムコンテナをホストするCI/CDパイプライン、SageMakerモデルレジストリ、AmazonECR。 データレイクはデータの信頼できる唯一の情報源であるため、ツールアカウントはコード、コンテナ、および生成されたアーティファクトを対象としています。
このアカウントの命名規則とマルチアカウント戦略は、ビジネスニーズによって異なる場合がありますが、この構造は、推奨される分離レベルを示すことを目的としています。 たとえば、開発アカウントの名前をモデルトレーニングまたはビルドアカウントに変更できます。
自動デプロイを実現するには、ノートブックからMLパイプラインに移行する方法を理解し、コードリポジトリとデータ構造を標準化することが重要です。これについては次のセクションで説明します。
ノートブックからMLパイプラインへ
開発環境の目標は、ノートブックのコードを再構築、拡張、改善、スケーリングして、MLパイプラインに移動することです。 MLパイプラインは、データの前処理、モデルのトレーニングまたは使用、および結果の後処理を担当する一連のステップです。 各ステップは、正確にXNUMXつのタスク(特定の変換)を実行し、再利用を可能にするために十分に抽象的(たとえば、入力パラメーターとして列名を渡す)である必要があります。 次の図は、パイプラインの例を示しています。
MLパイプラインを実装するために、データサイエンティスト(またはMLエンジニア)はSageMakerパイプラインを使用します。 SageMakerパイプラインは、Python SDKを使用したJSONパイプライン定義によって定義される一連の相互接続されたステップ(SageMaker処理ジョブ、トレーニング、HPO)です。 このパイプライン定義は、有向非巡回グラフ(DAG)を使用してパイプラインをエンコードします。 このDAGは、MLパイプラインの各ステップの要件と関係に関する情報を提供します。
ユースケースに応じて、MLパイプラインをトレーニングとバッチ推論のXNUMXつの主要なタイプに分けることができます。
次の図は、トレーニングMLパイプラインフローを示しています。
前処理フェーズは、複数のステップで構成される場合があります。 一般的なデータサイエンスの変換は、データの分割とサンプリング(トレーニング、検証、テストセット)、ワンホットエンコーディングまたはベクトル化、ビニング、スケーリングです。 モデルトレーニングステップは、データサイエンティストが最適なモデル構成を認識している場合は、1つのトレーニングジョブ、またはAWSがモデルに最適なハイパーパラメーターを定義して対応するハイパーパラメーターを生成するハイパーパラメーター最適化(HPO)ジョブのいずれかです。モデルアーティファクト。 評価ステップでは、生成されたモデルアーティファクトを使用して、検証データセットへの推論を実行します。 次に、MLパイプラインは、生成された精度メトリック(FXNUMX、精度、ゲインの十分位数など)が必要なしきい値を超えているかどうかをチェックします。 この手順が成功すると、モデルのアーティファクトとメタデータがモデルレジストリに移動されて本番環境に移行します。 エクスポートベースラインステップは悪用されることに注意してください Amazon SageMakerモデルモニター 機能。後でモデルのドリフト検出に使用され、モデルのメタデータとしてSageMakerモデルレジストリでホストできる統計を使用してJSONオブジェクトを生成します。
バッチ推論の場合、データサイエンティストは、次の図に示すように、同様のパイプラインを作成できます。
バッチ推論の前処理ステップは、多くの場合、データサンプリングとグラウンドトゥルースの列を除外することによるトレーニングと同じです。 バッチ推論は、推論のためにデータをバッチで対応するエンドポイントに送信するステップであり、を使用して実装できます。 バッチ変換。 後処理ステップでは、結果の分布などの追加の統計を生成するか、結果を外部IDと結合します。 次に、モデルモニターのステップで、トレーニングに使用されたデータ(モデルレジストリ内のモデルJSONメタデータ)のベースライン統計を、推論のために新しい受信データと比較できます。
データサイエンティストがSageMakerモデルレジストリに保存できるパイプラインモデルを作成する場合は、前処理手順をスキップできます。 詳細については、を参照してください。 XNUMXつのエンドポイントの背後にあるシリアル推論パイプラインとしての前処理ロジックとともにホストモデル.
リポジトリの標準化
データサイエンティストとMLエンジニア間のコラボレーションを可能にするには、コードリポジトリ構造の標準化が必要です。 さらに、標準化はCI / CDパイプライン構造にとって有益であり、自動検証、構築(カスタムコンテナ構築など)、およびテスト手順を組み込むことができます。
次の例は、MLソリューションをXNUMXつのリポジトリに分離する方法を示しています。トレーニング用の構築およびトレーニングリポジトリ(およびオプションでパイプラインモデル)と、バッチ推論パイプラインモデルをプロモートするかリアルタイムエンドポイントをインスタンス化するためのデプロイです。
リポジトリの構築/トレーニング
デプロイメントリポジトリ
構築およびトレーニングリポジトリは、XNUMXつの主要なフォルダに分かれています。
- アルゴリズム –データサイエンティストは、アルゴリズムのルートフォルダーでMLパイプラインの各ステップのコードを開発します。 ステップは、前処理、トレーニング、バッチ推論、および後処理(評価)にグループ化できます。 各グループでは、対応するサブフォルダーで複数のステップを定義できます。このサブフォルダーには、単体テスト用のフォルダー(オプションの入力と出力を含む)、メイン関数、readme、およびカスタムコンテナーが必要な場合のDockerファイルが含まれます。 メインに加えて、複数のコードファイルを同じフォルダーでホストできます。 すべてのステップに共通のヘルパーライブラリは、共有ライブラリフォルダーでホストできます。 データサイエンティストは、ステップのロジックを所有しているため、単体テストの開発を担当し、MLエンジニアは、エラー処理の強化とテストカバレッジの推奨を担当します。 CI / CDパイプラインは、テストの実行、コンテナーの自動構築(必要な場合)、および複数のソースコードファイルのパッケージ化を担当します。
- MLパイプライン –各ステップのソースコードとテストを開発したら、次のステップは別のルートフォルダーにSageMakerパイプラインを定義することです。 各MLパイプライン定義は、ハイパーパラメーター範囲などの入力パラメーター用の.pyファイルとJSONまたは.yamlファイルを含むサブフォルダーに配置されます。 MLパイプラインを説明するreadmeファイルが必要です。
- ノートブック –このフォルダーは、データサイエンティストが実験中に使用した元のノートブックをホストします。
デプロイメントリポジトリは、次のXNUMXつの主要部分で構成されています。
- 推論構成 –インスタンスタイプなど、開発環境ごとのリアルタイムエンドポイントまたはバッチ推論の構成が含まれます。
- アプリケーションインフラストラクチャ –必要に応じて、推論を実行するために必要なインフラストラクチャのソースコードをホストします。 これは、を介したトリガーメカニズムである可能性があります アマゾンイベントブリッジ, アマゾンAPIゲートウェイ, AWSラムダ 関数、またはSageMakerパイプライン。
- テスト –顧客のテスト方法に応じて、複数のサブフォルダーで構成されます。 最小限のテストセットとして、統合テスト(アプリケーションインフラストラクチャを含む推論のエンドツーエンドの実行)、ストレステスト(エッジケースの調査)、およびMLテスト(信頼スコアや確率の分布など)をお勧めします。
構築およびトレーニングリポジトリに変更をコミットすることにより、CI / CDパイプラインは、リポジトリ構造の検証、テストの実行、およびMLパイプラインのデプロイと実行を担当します。 別のCI/CDパイプラインがモデルのプロモートを担当します。これについては、次のセクションで説明します。
リポジトリの分岐とCI/CDの標準化
devアカウントのMLパイプラインの堅牢性を確保するために、マルチブランチリポジトリ戦略が提案されていますが、デプロイはCI/CDパイプラインのみを介して実行されます。 データサイエンティストは、機能ブランチを利用して新しい機能(ソースコード)を開発する必要があります。 対応するMLパイプラインをデプロイする準備ができたら、これを開発ブランチにプッシュできます。 このアプローチの代替手段は、機能ブランチごとにMLパイプラインをデプロイできるようにすることです。 詳細については、を参照してください。 AWSを使用したマルチブランチトレーニングMLOpsパイプラインでデータサイエンスワークフローを改善します.
次の図は、MLパイプラインとモデル構築のために開発環境で実行する分岐戦略と必要なCI/CDパイプラインステップを示しています。
マルチブランチアプローチのコード例は、 マルチブランチMLOpsトレーニングパイプライン。 機能ブランチベースのMLパイプラインによって生成されたモデルを別の機能モデルグループに保存し、メインブランチとのマージリクエスト中にそれらを廃止することができます。 メインモデルグループのモデルは、生産に昇格したモデルです。
データ構造の標準化
ソースコードの標準化にとって同様に重要なのは、データの構造の標準化です。これにより、データサイエンティストとMLエンジニアは、モデルとMLパイプラインの起源と履歴をデバッグ、監査、および監視できます。 次の図は、そのような例を示しています。
簡単にするために、入力履歴データが入力サブキーの下の開発アカウントのバケットにあると仮定します(通常、これはデータレイクにあります)。 MLのユースケースごとに、個別のサブキーを作成する必要があります。 新しいMLパイプラインをトリガーして実行するには、データサイエンティストはgit commit and pushを実行する必要があります。これにより、CI/CDパイプラインがトリガーされます。 次に、CI / CDパイプラインは、コードアーティファクトをコピーしてサブキーを作成します( code
サブキー)および入力データ( input
サブキー)ビルドIDのサブパーティションの下. 例として、ビルドID c日時とgitハッシュの組み合わせ、またはSageMakerパイプライン実行IDである必要があります。 この構造により、データサイエンティストは、過去の展開と実行を監査および照会できます。 この後、CI / CDパイプラインが展開され、MLパイプラインがトリガーされます。 MLパイプラインの実行中、各ステップは中間結果をにエクスポートします ml-pipeline-outputs
。 さまざまな機能ブランチがMLパイプラインの新しいインスタンスをデプロイして実行し、それぞれが新しいサブキーや標準化されたプレフィックスまたはサフィックスを含むさまざまなサブフォルダーに中間結果をエクスポートする必要があることを覚えておくことが重要です。機能ブランチID。
このアプローチは、すべての実験の完全な監査可能性をサポートします。 ただし、開発戦略のマルチブランチアプローチでは、大量のデータが生成されます。 したがって、データライフサイクル戦略が必要です。 プル/マージリクエストが成功するたびに、少なくとも各機能ブランチMLパイプラインのデータを削除することをお勧めします。 ただし、これは、ビジネスがサポートする必要のある運用モデルと監査の粒度によって異なります。 バッチ推論MLパイプラインでも同様のアプローチを使用できます
信頼できるフェーズ
複数のアカウントを使用してデータサイエンティスト、MLエンジニア、データエンジニアの間で関心の分離を最初に行った後、次のステップは、作成されたモデルをモデルレジストリから分離された環境に昇格させて推論を実行することです。 ただし、デプロイされたモデルの堅牢性を確保する必要があります。 したがって、本番環境のミラー環境にデプロイされたモデルのシミュレーション、つまり本番前(またはステージング)が必須です。
次の図は、このアーキテクチャを示しています。
実稼働前環境でのモデルとエンドポイントの展開のプロモーションは、モデルレジストリステータスの更新イベント(または展開リポジトリのgit push)を使用して実行されます。これにより、EventBridgeイベントを使用して個別のCI/CDパイプラインがトリガーされます。 CI / CDパイプラインの最初のステップでは、リードデータサイエンティスト(およびオプションで製品所有者、ビジネスアナリスト、またはその他のリードデータサイエンティスト)による手動承認を要求します。 承認者は、モデルのパフォーマンスKPIとデプロイメントリポジトリ内のコードのQAを検証する必要があります。 承認後、CI / CDパイプラインはテストコードを展開リポジトリに実行します(統合テスト、ストレステスト、MLテスト)。 モデルエンドポイントに加えて、CI / CDは、EventBridge、Lambda関数、APIGatewayなどのトリガーインフラストラクチャもテストします。 次の図は、この更新されたアーキテクチャを示しています。
テストが正常に実行された後、CI / CDパイプラインは、モデルを本番環境に昇格させる準備ができていることを新しい(または同じ)承認者に通知します。 この段階で、ビジネスアナリストは、モデルの結果に対していくつかの追加の統計的仮説検定を実行することをお勧めします。 承認後、モデルとトリガーインフラストラクチャが本番環境にデプロイされます。 青/緑、カナリア、A / Bテストなど、複数のデプロイ方法がSageMakerでサポートされています(詳細については、 展開ガードレール)。 CI / CDパイプラインに障害が発生した場合、ロールバックメカニズムはシステムを最新の堅牢な状態に戻します。
次の図は、モデルをプロモートするCI / CDパイプラインの主な手順と、APIゲートウェイ、Lambda関数、EventBridgeなどのモデルエンドポイントをトリガーするインフラストラクチャを示しています。
データレイクとMLOpsの統合
この時点で、開発段階またはアカウントごとのデータ要件と、MLOpsを一元化されたデータレイクに組み込む方法を理解することが重要です。 次の図は、MLOpsとデータレイクレイヤーを示しています。
データレイクでは、データエンジニアは、ETLを構築することにより、複数のデータソースを結合し、MLユースケースに対応するデータセット(たとえば、構造データの単一のテーブル、またはPDFファイルまたは画像を含む単一のフォルダー)を作成する責任があります。データサイエンティストによって定義されたパイプライン(探索データ分析フェーズ中)。 これらのデータセットは、履歴データと推論およびテスト用のデータに分割できます。 すべてのデータはカタログ化され(たとえば、AWS Glueデータカタログを使用)、LakeFormationをデータガバナンスレイヤー(構造化データ用)として使用することで、他のアカウントやユーザーと共有できます。 この記事の執筆時点では、LakeFormationはAthenaクエリ、AWS Glueジョブ、およびAmazonEMRとのみ互換性があります。
一方、MLOps環境では、dev、pre-prod、およびprodのローカルバケットにある特定のデータセットを使用してMLパイプラインを灌漑する必要があります。 開発環境は、データレイクからデータをプルするSageMakerパイプラインを使用して、オンデマンドでモデルを構築およびトレーニングする責任があります。 したがって、パイプラインの最初のステップとして、データのサンプリングとクエリのみが必要なAthenaステップ、またはより複雑な変換が必要な場合はAmazonEMRステップのいずれかを使用することをお勧めします。 または、コールバックステップを介してAWS Glueジョブを使用することもできますが、SageMakerパイプラインではまだネイティブステップとしては使用できません。
Pre-prodとprodは、リアルタイムおよびバッチ推論のテストまたは実行を担当します。 リアルタイム推論の場合、推論の入力がAPI Gatewayリクエストのペイロードに便乗する可能性があるため、MLOpspre-prodおよびprodアカウントにデータを送信する必要はありません。 バッチ推論(または大規模な入力データ)の場合、テストデータまたは推論用データのいずれかである必要なデータセットは、ローカルMLデータバケット(pre-prodまたはprod)に配置する必要があります。 データをpre-prodとprodに移動するには、AthenaまたはAmazon EMRをトリガーしてデータレイクからデータをプルするか、データレイクからそれらのMLOpsアカウントにデータをプッシュするかの3つのオプションがあります。 最初のオプションでは、MLOpsアカウントで追加のメカニズムを開発する必要があります。たとえば、スケジュールされたEventBridgeイベントを作成する(データレイクのデータが更新されているかどうかを知らない)、またはデータレイクのSXNUMXEventBridgeイベントにデータを到着させる(詳細については、を参照してください AmazonEventBridgeリソースポリシーによるクロスアカウントアクセスの簡素化)。 MLOps側でイベントをキャッチした後、AthenaクエリまたはAmazonEMRはローカルでデータをフェッチしてトリガーできます 非同期推論 or バッチ変換。 簡単にするために、これをSageMakerパイプラインにラップすることができます。 XNUMX番目のオプションは、ETLパイプラインの最後のステップで、データをMLOpsバケットにプッシュする機能を追加することです。 ただし、このアプローチでは責任が混在し(データレイクが推論をトリガーします)、MLOpsバケットに書き込むためにデータレイクへのアクセスを提供するためにレイクフォーメーションが必要になります。
最後のステップは、推論結果をデータレイクに戻すことです。 データをカタログ化して他のユーザーが利用できるようにするには、データを新しいデータソースとしてランディングバケットに戻す必要があります。
スケーラブルフェーズ
MLOps基盤の開発と、最初のMLユースケースのエンドツーエンドの本番化の後、dev、pre-prod、prod、リポジトリのインフラストラクチャ、CI / CDパイプライン、およびデータ構造がテストされ、完成しました。 。 次のステップは、新しいMLユースケースとチームをプラットフォームに導入することです。 価値実現のスピードを確保するために、SageMakerではカスタムSageMakerプロジェクトテンプレートを作成できます。これを使用して、テンプレートリポジトリとCI/CDパイプラインを自動的にインスタンス化できます。 このようなSageMakerプロジェクトテンプレートを使用すると、リードデータサイエンティストは新しいプロジェクトをインスタンス化し、新しいMLユースケースごとに専用チームを割り当てる責任があります。
次の図は、このプロセスを示しています。
さまざまなデータサイエンティストチーム(またはMLを生産する必要のある複数のビジネスユニット)がさまざまな機密データにアクセスでき、複数の製品所有者がモデルのトレーニング、展開、実行に対して個別の料金を支払う責任がある場合、問題はさらに複雑になります。 。 したがって、チームごとに個別のMLOpsアカウントのセット(実験、開発、事前生産、および生産)が必要です。 新しいMLOpsアカウントを簡単に作成できるようにするために、別のアカウントである高度な分析ガバナンスアカウントを導入します。これにより、ITメンバーはアクセスでき、オンデマンドでMLOpsアカウントをカタログ化、インスタンス化、または廃止できます。 具体的には、このアカウントは、MLOpsアカウントのインフラストラクチャコード(VPC、サブネット、エンドポイント、バケット、 AWS IDおよびアクセス管理 (IAM)役割とポリシー、 AWS CloudFormation スタック)、 AWSサービスカタログ インフラストラクチャのCloudFormationスタックをワンクリックで複数のアカウントに自動的にデプロイする製品。 Amazon DynamoDB アカウントの各セットを担当するチームなど、メタデータをカタログ化するためのテーブル。 この機能により、ITチームはオンデマンドでMLOpsアカウントをインスタンス化し、必要なユーザー、アカウントごとのデータアクセス、および一貫したセキュリティ制約を割り当てます。
このシナリオに基づいて、アカウントを一時的なものと永続的なものに分けます。 データレイクとツールは永続的なアカウントであり、それぞれデータとソースコードの信頼できる唯一の情報源の役割を果たします。 MLOpsアカウントはほとんどステートレスであり、オンデマンドでインスタンス化または廃止されるため、一時的なものになります。 MLOpsアカウントのセットが廃止された場合でも、ユーザーまたは監査人は、耐久性のある環境に保存されているため、過去の実験と結果を確認できます。
MLOpsにStudioUIを使用する場合は、次の図に示すように、ツールアカウントがdevアカウントの一部になります。
ユーザーがMLOpsにSagemakerStudioUIを使用したい場合、ツールアカウントは開発者の一部です
上の図のように説明します。 このMLOPsFoundationのソースコードの例は次の場所にあります。
CDKに基づく安全なマルチアカウントMLOps基盤.
Sagemakerは、CodeCommitとCodePipelineをGitHubやJenkinsなどの他のサードパーティ開発ツールに置き換える機能を提供していることに注意してください(詳細については、 AmazonSageMakerプロジェクトを作成する サードパーティのソース管理とJenkinsを使用する および AmazonSageMakerプロジェクトMLOps GitLabおよびGitLabパイプラインを含むテンプレート).
ペルソナ、運用、およびテクノロジの概要
MLOps成熟度モデルを使用すると、明確なアーキテクチャ設計と配信ロードマップを定義できます。 ただし、各ペルソナは、対話する主要なAWSアカウントとサービス、および実行する操作を明確に把握する必要があります。 次の図は、これらのカテゴリをまとめたものです。
まとめ
複数のペルソナとテクノロジー間の相互作用を明確に定義する堅牢なMLOps基盤は、価値実現のスピードを高め、コストを削減し、データサイエンティストがイノベーションに集中できるようにします。 この投稿では、このような基盤を段階的に構築する方法を示しました。これにより、ビジネスのMLOps成熟度モデルがスムーズになり、本番環境で複数のデータサイエンスチームとMLユースケースをサポートできるようになります。 複数のスキルと責任を持つ複数のペルソナで構成される運用モデルを定義しました。 最後に、コード開発(リポジトリとCI / CDパイプライン)、データの保存と共有、およびエンタープライズ環境向けのMLOpsセキュアインフラストラクチャプロビジョニングを標準化する方法の例を共有しました。 多くの企業顧客はこのアプローチを採用しており、MLソリューションを数か月ではなく数日で生産することができます。
コメントや質問がある場合は、コメントセクションに残してください。
著者について
ソクラティス・カルタキス博士 アマゾンウェブサービスのシニア機械学習スペシャリストソリューションアーキテクトです。 Sokratisは、AWSサービスを活用し、運用モデル(MLOps基盤)を形成し、ベスト開発プラクティスを活用した変革ロードマップを作成することで、企業のお客様が機械学習(ML)ソリューションを産業化できるようにすることに重点を置いています。 彼は、エネルギー、小売、健康、金融/銀行、モータースポーツなどの分野で革新的なエンドツーエンドの生産レベルのMLおよびモノのインターネット(IoT)ソリューションの発明、設計、主導、および実装に15年以上を費やしてきました。 Sokratisは、家族や友人と暇な時間を過ごしたり、バイクに乗ったりするのが好きです。
ゲオルギオス・シナス は、EMEA地域のAI/MLのスペシャリストソリューションアーキテクトです。 彼はロンドンを拠点とし、英国とアイルランドの顧客と緊密に協力しています。 Georgiosは、MLOpsの実践に特に関心を持ち、顧客が大規模な機械学習を実行できるようにすることで、顧客がAWSで本番環境に機械学習アプリケーションを設計およびデプロイするのを支援します。 余暇には、旅行、料理、友人や家族との時間を楽しんでいます。
ジュゼッペアンジェロポルチェッリ アマゾンウェブサービスのプリンシパル機械学習スペシャリストソリューションアーキテクトです。 MLのバックグラウンドをソフトウェアエンジニアリングする数年の経験を持つ彼は、あらゆる規模の顧客と協力して、ビジネスと技術のニーズを深く理解し、AWSクラウドとAmazonMachineLearningスタックを最大限に活用するAIと機械学習ソリューションを設計しています。 彼は、MLOps、Computer Vision、NLPなどのさまざまなドメインでプロジェクトに取り組み、幅広いAWSサービスを使用してきました。 自由時間には、ジュゼッペはサッカーを楽しんでいます。
シェルビーアイゲンブロード アマゾンウェブサービス(AWS)のプリンシパルAIおよび機械学習スペシャリストソリューションアーキテクトです。 彼女は24年間、複数の業界、テクノロジー、および役割にまたがるテクノロジーに携わってきました。 彼女は現在、DevOpsとMLのバックグラウンドをMLOpsのドメインに組み合わせて、顧客がMLワークロードを大規模に提供および管理できるようにすることに注力しています。 さまざまなテクノロジードメインで35を超える特許が付与されており、継続的なイノベーションとデータを使用してビジネスの成果を推進することに情熱を注いでいます。 Shelbeeは、Courseraの実用的なデータサイエンス専門分野の共同作成者およびインストラクターです。 彼女はまた、デンバー支部のビッグデータ(WiBD)の女性の共同ディレクターでもあります。 暇なときは、家族や友達、過激な犬と過ごすのが好きです。
- "
- 100
- a
- 能力
- 私たちについて
- 抽象
- 加速する
- アクセス
- アクセス可能な
- 対応する
- 達成する
- 越えて
- 添加
- NEW
- 養子縁組
- 高度な
- に対して
- AI
- アルゴリズム
- すべて
- ことができます
- 代替案
- Amazon
- Amazon Webサービス
- 間で
- 量
- 分析
- アナリスト
- 分析論
- 別の
- API
- 申し込み
- アプローチ
- 建築
- 監査
- 自動化する
- オートマチック
- 自動的に
- オートメーション
- 利用できます
- 回避
- AWS
- 背景
- ベースライン
- なぜなら
- になる
- 背後に
- 有益な
- BEST
- の間に
- ビッグデータ
- ビル
- ブースト
- ビルド
- 建物
- 内蔵
- ビジネス
- ビジネス
- 機能
- 場合
- 例
- 集中型の
- 挑戦
- 章
- 小切手
- クラシック
- クラウド
- コード
- 協力します
- 環境、テクノロジーを推奨
- コラム
- 組み合わせ
- 注釈
- コミット
- コマンドと
- 企業
- 互換性のあります
- コンプリート
- 複雑な
- コンプライアンス
- コンピュータ
- プロフェッショナルな方法で
- 導電性
- 信頼
- 接続
- 整合性のある
- コンテナ
- コンテナ
- 含まれています
- コントロール
- 複写
- 対応する
- 可能性
- カバー
- 作ります
- 作成した
- 作成します。
- 作成
- 創造
- 現在
- カスタム
- 顧客
- Customers
- データ
- データアクセス
- データ分析
- データプライバシー
- データサイエンス
- データサイエンティスト
- データストレージ
- 日
- 専用の
- 配達
- 需要
- デンバー
- によっては
- 依存
- 展開します
- 展開
- 展開する
- 展開
- 配備
- 配備する
- 説明する
- 設計
- 設計
- 細部
- 検出
- デベロッパー
- 開発する
- 開発
- 開発ツール
- 違い
- 異なります
- 話し合います
- ディストリビューション
- デッカー
- ドメイン
- ドメイン
- ドライブ
- ドリブン
- 間に
- 各
- エッジ(Edge)
- 排除する
- 受け入れる
- enable
- 可能
- 有効にする
- 端から端まで
- エンドポイント
- エネルギー
- エンジニアリング
- エンジニア
- Enterprise
- 企業
- 環境
- 等
- 評価する
- 評価
- イベント
- イベント
- 正確に
- 例
- 例
- 除外
- 実験
- エクスプロイト
- 探査
- 家族
- 特徴
- フィギュア
- 最後に
- 名
- フロー
- フォーカス
- 焦点を当てて
- 焦点
- フォロー中
- サッカー
- 形成
- 発見
- Foundation
- 財団
- フレームワーク
- フレームワーク
- 無料版
- から
- 機能性
- 機能
- さらに
- ゲートウェイ
- GDPR
- 生成された
- Gitの
- GitHubの
- 目標
- ガバナンス
- 付与された
- グループ
- ハンドリング
- ハッシュ
- 健康
- 助けます
- 助け
- ことができます
- ハイ
- 歴史的
- history
- 主催
- 認定条件
- How To
- しかしながら
- HTTPS
- 何百
- アイデンティティ
- 画像
- 実装する
- 実装
- 実装
- 重要
- 改善します
- 含ま
- 含めて
- 増える
- 産業
- 情報
- インフラ関連事業
- 革新的手法
- イノベーション
- 革新的な
- 統合
- 統合
- 相互作用
- 関心
- インタフェース
- インターネット
- モノのインターネット
- IOT
- アイルランド
- 分離
- IT
- ジョブ
- Jobs > Create New Job
- 参加
- ジョイン
- キープ
- キー
- 知識
- 大
- 最新の
- 層
- つながる
- 主要な
- LEARN
- 学習
- コメントを残す
- リーガルポリシー
- レベル
- 活用
- 図書館
- 負荷
- ローカル
- 局部的に
- ロンドン
- 機械
- 機械学習
- make
- 作成
- 管理します
- 管理
- 義務的な
- マニュアル
- 満期
- メカニズム
- メンバー
- マージ
- 方法論
- メソッド
- メトリック
- かもしれない
- マインド
- 最小
- ミラー
- ML
- モデル
- モニター
- ヶ月
- 他には?
- モータースポーツ
- 移動する
- の試合に
- すなわち
- 名
- 命名
- 必要
- ニーズ
- 次の
- 通常は
- 操作する
- オペレーティング
- 業務執行統括
- 最適化
- オプション
- オプション
- 注文
- 組織
- オリジナル
- その他
- 自分の
- 所有者
- 所有者
- 部
- 特定の
- パーティー
- 情熱
- 特許
- のワークプ
- パフォーマンス
- 実行
- 相
- プラットフォーム
- プレイ
- 再生
- お願いします
- ポイント
- ポリシー
- 準備
- 校長
- プライバシー
- 問題
- プロセス
- 処理
- 生産された
- プロダクト
- 生産
- 生産性
- プロジェクト
- プロジェクト(実績作品)
- 推進する
- プロモーション
- 提供します
- 提供
- は、大阪で
- 引き
- 品質
- RE
- への
- 減らします
- 縮小
- 地域
- 登録
- の関係
- 信頼性のある
- 倉庫
- 要求
- リクエスト
- の提出が必要です
- 要件
- 必要
- 研究
- リソースを追加する。
- リソース
- 責任
- 責任
- 結果
- 小売
- return
- 収益
- ロードマップ
- 丈夫
- 職種
- ルート
- ラン
- ランニング
- 同じ
- ド電源のデ
- 規模
- スケーリング
- 予定の
- 科学
- 科学者
- 科学者たち
- SDDK
- 安全に
- セキュリティ
- シリアル
- シリーズ
- サービス
- サービス
- セッションに
- いくつかの
- 形状
- shared
- シェアリング
- 表示する
- 同様の
- サイズ
- スキル
- ソフトウェア
- ソフトウェア工学
- 溶液
- ソリューション
- 解決する
- 一部
- ソースコード
- 専門家
- 特定の
- 特に
- スピード
- 過ごす
- 支出
- split
- スタック
- ステージ
- ステージ
- start
- 都道府県
- 統計的
- 統計
- Status:
- ストレージ利用料
- 店舗
- 店舗
- 戦略
- 流線
- ストレス
- 構造化された
- 研究
- 成功した
- サポート
- サポート
- サポート
- システム
- チーム
- チーム
- 技術的
- テクノロジー
- テクノロジー
- テンプレート
- test
- テスト
- テスト
- ソース
- 世界
- したがって、
- 物事
- サードパーティ
- 三
- 時間
- 一緒に
- 豊富なツール群
- トレーニング
- トレーニング
- 最適化の適用
- 変換
- 変換
- 旅行
- ui
- Uk
- 下
- わかる
- ユニット
- アップデイト
- つかいます
- users
- 活用する
- 値
- さまざまな
- 詳しく見る
- ビジョン
- ウェブ
- Webサービス
- while
- 以内
- 無し
- レディース
- 仕事
- 働いていました
- ワークフロー
- 作品
- 世界
- 書き込み
- 年
- あなたの