MLアプリケーション・パッケージとしてのMLユース・ケースの実装

新しいMLアプリケーション実装を開発するプロバイダは、実装に対応する新しいアプリケーション・パッケージを作成する必要があります。

アプリケーション・パッケージを使用すると、環境に依存しないリージョンに依存しない方法でML機能の標準パッケージ化が可能になります。これにより、任意のテナンシ、リージョンまたは環境で使用できるポータブル・ソリューションになります。アップロード・プロセス中に、リージョンまたは環境に固有のインフラストラクチャ依存性(VCNやログOCIDsなど)がパッケージ引数として提供されます。

パッケージには、コンポーネントやアプリケーション・コンポーネントなどのTerraform、実装バージョン情報を含む記述子、構成スキーマなど、MLアプリケーションのすべての実装詳細が含まれます。これらのパッケージは、既存のMLアプリケーション実装リソースにアップロードまたはデプロイでき、パッケージの新しいバージョンがアップロードされると、MLアプリケーション・サービスによって新しいMLアプリケーション実装バージョンが自動的に作成され、パッケージを使用するすべてのMLアプリケーション・インスタンスのアップグレードが開始されます。

すべてのアプリケーション・コンポーネントのTerraform構成は、アプリケーション・パッケージのapplication_componentsディレクトリ内にあります。同様に、すべてのインスタンス・コンポーネントのTerraformは、instance_componentsディレクトリに存在します。

この例では、MLジョブはアプリケーション・コンポーネントで、MLジョブを作成するためのTerraform構成はアプリケーション・パッケージのapplication_componentsディレクトリの一部です。実際のトレーニングが消費者データに対して行われると、MLアプリケーション実装の新しいMLアプリケーション・インスタンスがプロビジョニングされたときにトレーニングがトリガーされます。新しいMLアプリケーション・インスタンスが作成されると、新しいジョブ実行が作成され、トリガーされます。これにより、コンシューマ・オブジェクト・ストレージ・バケットからプロバイダ・オブジェクト・ストレージ・バケットにデータがロードされ、モデルがトレーニングされ、モデルがモデル・カタログに格納されてから、モデルがデプロイされます。新しいジョブ実行は、すべてのインスタンス(顧客)に対して作成する必要があります。ジョブ実行はインスタンス・コンポーネントです。また、ターゲット・オブジェクト・ストレージ・バケットはインスタンスごとに作成されるため、インスタンス・コンポーネントになります。同様に、モデル・デプロイメントもインスタンス・コンポーネントです。

アプリケーション・コンポーネントとインスタンス・コンポーネントの両方のTerraform構成をパラメータ化できます。MLアプリケーションおよびMLアプリケーション・インスタンスのプロビジョニングに必要なすべてのパラメータは、descriptor.yamlファイルで指定できます。たとえば、ジョブ実行で使用するdockerイメージはパラメータ化できます。ジョブを作成する必要があるデータ・サイエンス・プロジェクトをパラメータ化できます。アプリケーション・コンポーネントに属し、新しい実装のプロビジョニング時に必要なすべてのパラメータは、descriptor.yamlファイルのpackageArgumentsで指定できます。一般に、packageArgumentsを使用して、インフラストラクチャOCIDsや環境固有のスケーリング値などの環境固有の値を指定できます。

同様に、MLアプリケーション・インスタンスの作成時に(コンシューマ・テナンシから)ソースOSバケットの名前が必要で、インスタンスごとに(コンシューマからコンシューマまで)異なる場合があります。そのため、これは、MLアプリケーション・インスタンスの作成時にコンシューマによって値が提供されるパラメータである場合があります。このようなすべてのパラメータは、descriptor.yamlファイルのconfigurationSchemaで定義できます。

したがって、アプリケーション・パッケージ・ディレクトリの最終構造は次のようになります。

• <ml-app-package-name>-<version>.zip
  • application_components: すべてのアプリケーション・コンポーネント定義を含むディレクトリ。
  • instance_components: すべてのインスタンス・コンポーネント定義を含むディレクトリ。
  • descriptor.yaml: パッケージのディスクリプタ・ファイル。
  • *.trigger.yaml: トリガー定義ファイル。

アプリケーション・パッケージ構造に関する重要な注意事項:

• アプリケーション・コンポーネントとインスタンス・コンポーネントの両方を対応するディレクトリに定義する必要があります。
• application_componentsおよびinstance_componentsディレクトリはオプションです。application_componentsまたはinstance_componentsディレクトリのないアプリケーション・パッケージは有効です。
• ディレクトリの名前は、application_componentsおよびinstance_componentsと正確(小文字)にする必要があります。
• Terraform構成がapplication_componentsディレクトリに存在しないコンポーネントは、アプリケーション・コンポーネントとはみなされません。
• Terraform構成がinstance_componentsディレクトリに存在しないコンポーネントは、インスタンス・コンポーネントとはみなされません。
• 現時点では、すべてのOCIリソースがアプリケーション・コンポーネントまたはインスタンス・コンポーネントとしてサポートされているわけではありません。
• データ・サイエンス・ジョブはサポートされているアプリケーション・コンポーネントですが、データ・サイエンス・モデル、モデル・デプロイメント、ジョブ実行、オブジェクト・ストレージ・バケットおよびオブジェクトはサポートされているインスタンス・コンポーネントです。

次のセクションでは、パッケージ記述子ファイルのスキーマについて詳しく説明します。