翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ステップ 3. パイプラインを定義する
このステップでは、パイプラインが実行するアクションの順序とロジックを定義します。これには、個別のステップだけでなく、それらのロジカルな入力と出力も含まれます。たとえば、パイプライン開始時のデータの状態はどうなっているのでしょうか。データは細分性の異なる複数のファイルから取得されるのか、それとも 1 つのフラットファイルからのものなのでしょうか。データが複数のファイルからのものである場合、前処理ロジックを定義するために、すべてのファイルに対して 1 つのステップが必要なのか、それともファイルごとに別々のステップが必要なのか。決定は、データソースの複雑さと前処理の範囲によって異なります。
今回のリファレンス実装では、サーバーレス関数オーケストレーターである [AWS Step Functions](https://aws.amazon.com/step-functions/) を使用してワークフローステップを定義します。ただし、[ML Max フレームワーク](https://github.com/awslabs/mlmax)は Apache AirFlow (「[パイプラインオーケストレーション用のさまざまなエンジン](step6.md#engines)」セクションを参照) などの他のパイプラインシステムやステートマシンシステムもサポートしており、ML パイプラインの開発とデプロイを推進します。
## Step Functions SDK を使用する
ML パイプラインを定義するには、まず[AWS Step Functions データサイエンス SDK](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-python-sdk.html) (Step Functions SDK) が提供する高レベルの Python API を使用して、パイプラインの 2 つの主要コンポーネントであるステップとデータを定義します。パイプラインを有向非循環グラフ (DAG) と考えると、ステップはグラフ上のノードを表し、データは 1 つのノード (ステップ) を次のノード (ステップ) に接続する有向エッジとして表示されます。ML ステップの一般的な例には、前処理、トレーニング、評価などがあります。Step Functions SDK には、使用できる組み込みステップ ([TrainingStep](https://aws-step-functions-data-science-sdk.readthedocs.io/en/stable/sagemaker.html#stepfunctions.steps.sagemaker.TrainingStep) など) が多数用意されています。データの例としては、入力、出力、パイプラインのいくつかのステップによって生成される多くの中間データセットなどがあります。ML パイプラインを設計する場合、データ項目の具体的な値はわかりません。データ項目名とプリミティブデータ型のみを含むテンプレートとして機能するデータプレースホルダーを定義できます(関数パラメーターと同様)。この方法では、グラフ上を移動するデータの具体的な値を事前に知らなくても、完全なパイプラインブループリントを設計できます。この目的のために、Step Functions SDK のプレースホルダークラスを使用して、これらのデータテンプレートを明示的にモデル化できます。
ML パイプラインには、各 ML ステップの動作をきめ細かく制御するための設定パラメーターも必要です。このような特別なデータプレースホルダーはパラメータープレースホルダーと呼ばれます。パイプラインを定義する時点では、その値の多くは不明です。パラメータプレースホルダーの例としては、パイプライン設計中に定義するインフラストラクチャ関連のパラメータ ( AWS リージョン コンテナイメージ URL など) や、パイプラインの実行時に定義する ML モデリング関連のパラメータ (ハイパーパラメータなど) などがあります。
## Step Functions SDK の拡張
リファレンス実装における要件の 1 つは、特定のパラメータ設定を使用して ML パイプライン定義を具体的な ML パイプラインの作成とデプロイから分離することでした。ただし、Step Functions SDK の組み込みステップの中には、これらすべてのプレースホルダーパラメーターを渡すことができないものもありました。その代わり、パラメータ値は、パイプライン設計時に SageMaker AI 設定 API 呼び出しを通じて直接取得されることが想定されていました。これは SageMaker AI の設計時環境が SageMaker AI ランタイム環境と同一であれば問題なく動作しますが、実際の設定ではそうなることはほとんどありません。パイプライン設計時間とランタイムがこれほど密結合していることと、ML プラットフォームインフラストラクチャが一定に保たれるという前提は、設計されたパイプラインの適用性を著しく妨げています。実際、ML パイプラインは、基盤となるデプロイプラットフォームに少しでも変更が加えられるとすぐに機能しなくなります。
この課題を克服し、堅牢な ML パイプライン (一度設計すればどこでも実行したい) を作成するために、**TrainingStep**、**ModelStep**、**TransformerStep** などの組み込みステップを拡張して、独自のカスタムステップを実装しました。これらの拡張は [ML Max プロジェクト](https://github.com/awslabs/mlmax)で提供されています。これらのカスタムステップのインターフェースは、パイプラインの作成時やパイプラインの実行時に具体的な値を入力できるパラメータプレースホルダーをはるかに多くサポートしています。