翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ステップ 2. ランタイムスクリプトを作成する
このステップでは、ステップ 1 で開発したモデルとそれに関連するヘルパーコードを ML プラットフォームに統合して、本番環境ですぐに使えるトレーニングと推論を行います。具体的には、モデルを SageMaker AI に組み込むためのランタイムスクリプトの開発が含まれます。これらのスタンドアロン Python スクリプトには、定義済みの SageMaker AI コールバック関数と環境変数が含まれています。これらは Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでホストされている SageMaker AI コンテナ内で実行されます。[Amazon SageMaker AI Python SDK ドキュメントには](https://sagemaker.readthedocs.io/en/stable/index.html)、これらのコールバックと補助セットアップがどのように連携してトレーニングと推論を行うかについての詳細な情報が記載されています。以下のセクションでは、 AWS お客様と協働した経験に基づいて ML ランタイムスクリプトを開発する際のその他の推奨事項を説明します。
## 処理ジョブを使用する
SageMaker AI には、バッチモードでのモデル推論を実行するための 2 つのオプションがあります。SageMaker AI *処理ジョブ*または*バッチ変換ジョブ*を使用できます。各オプションにはメリットとデメリットがあります。
処理ジョブは、SageMaker AI コンテナ内で実行される Python ファイルで構成されます。処理ジョブは、Python ファイルに入力したすべてのロジックで構成されます。これには次のような利点があります。
+ トレーニングジョブの基本的なロジックを理解していれば、処理ジョブは簡単に設定でき、理解しやすくなります。これらはトレーニングジョブと同じ抽象概念を共有しています (たとえば、インスタンス数やデータ分散のチューニング)。
+ データサイエンティストと ML エンジニアは、データ操作オプションを完全に制御できます。
+ データサイエンティストは、使い慣れた読み取り/書き込み機能以外は I/O コンポーネントのロジックを管理する必要がありません。
+ SageMaker AI 以外の環境でファイルを実行する方がいくらか簡単であり、迅速な開発とローカルテストに役立ちます。
+ エラーが発生した場合、スクリプトが失敗すると同時に処理ジョブも失敗し、予期せぬ再試行待ちが発生することはありません。
一方、バッチ変換ジョブは SageMaker AI エンドポイントの概念を拡張したものです。ランタイムに、これらのジョブはコールバック関数をインポートし、その I/O を処理してデータの読み取り、モデルの読み込み、予測を行います。バッチ変換ジョブには次の利点があります。
+ トレーニングジョブで使用される抽象化とは異なるデータ分散抽象化を使用します。
+ バッチ推論とリアルタイム推論の両方に同じコアファイルと関数構造を使用しているため、便利です。
+ リトライベースのフォールトトレランスメカニズムが組み込まれています。たとえば、レコードのバッチでエラーが発生した場合、ジョブは失敗として終了する前に複数回リトライします。
その透明性、複数の環境での使いやすさ、トレーニングジョブとの抽象化が共通していることから、このガイドで説明するリファレンスアーキテクチャのバッチ変換ジョブの代わりに処理ジョブを使用することにしました。
Python ランタイムスクリプトは、クラウドにデプロイする前にローカルで実行する必要があります。具体的には、Python スクリプトを構造化してユニットテストを行う際には、メインのガード節 (guard clause) を使用することをおすすめします。
## メインガード説を使用する
モジュールのインポートをサポートし、Python スクリプトを実行するには、メインガード節を使用してください。Python スクリプトを個別に実行すると、ML パイプラインの問題をデバッグして切り分けるのに役立ちます。次のステップを推奨します。
+ Python 処理ファイル内の引数パーサーを使用して、入出力ファイルとその場所を指定します。
+ 各 Python ファイルのメインガイドとテスト関数を提供します。
+ Python ファイルをテストしたら、 AWS Step Functions モデルを使用しているか SageMaker AI 処理ジョブを使用しているかにかかわらず、ML パイプラインのさまざまなステージに組み込みます。
+ テストとデバッグを容易にするために、スクリプトの重要なセクションには **Assert** ステートメントを使用してください。たとえば、**アサート**ステートメントを使用すると、読み込み後にデータセット特徴量の数が一定になるようにすることができます。
## ユニットテスト
パイプライン用に作成されたランタイムスクリプトのユニットテストは、ML パイプライン開発ではしばしば無視される重要なタスクです。これは、機械学習とデータサイエンスは比較的新しい分野であり、ユニットテストなどの確立されたソフトウェアエンジニアリング手法を採用するのが遅れているためです。ML パイプラインは運用環境で使用されるため、ML モデルを実際のアプリケーションに適用する前に、パイプラインコードをテストすることが不可欠です。
ランタイムスクリプトをユニットテストすることには、ML モデルに次のような独自の利点もあります。
+ これにより、予期しないデータ変換が防止されます。ほとんどの ML パイプラインには多数のデータ変換が含まれるため、これらの変換が期待どおりに実行されることが不可欠です。
+ これにより、コードの再現性を検証します。コード内のランダム性は、さまざまなユースケースでユニットテストを行うことで検出できます。
+ コードのモジュール性が強化されます。ユニットテストは通常、特定のテストスイート (テストケースの集まり) がプログラムのソースコードをどの程度実行するかを示すテストカバレッジ指標と関連付けられます。大量のコードを関数やクラスに分解しないとユニットテストを書くのは難しいので、高いテストカバレッジを実現するために、開発者はコードをモジュール化します。
+ これにより、品質の低いコードやエラーが本番環境に導入されるのを防ぐことができます。
ユニットテストケースを書くために、[pytest](https://docs.pytest.org/en/stable/) のような成熟したユニットテストフレームワークを使うことを推奨します。フレームワークの中で広範囲なユニットテストを管理する方が簡単だからです。
**重要**
ユニットテストでは、すべてのコーナーケースがテストされることを保証することはできませんが、モデルをデプロイする前にミスを未然に防ぐのに役立ちます。優れた運用性を確保するため、デプロイ後もモデルをモニタリングすることをお勧めします。