ステップ 6. パイプラインの拡大 - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ステップ 6. パイプラインの拡大

このガイドでは、具体的なアーキテクチャを使用して で ML パイプライン AWS をすばやく構築する方法について説明します。パイプラインを完成させるためには、メタデータの管理、実験の追跡、モニタリングなど、他にも考慮すべき点があります。これらは、このガイドの対象外である重要なトピックです。以下のセクションでは、パイプライン管理のもう 1 つの側面であるパイプラインの自動化について説明します。

さまざまな自動化レベル

SageMaker AI コンソールでトレーニングパイプラインを手動で設定できますが、実際には、ML トレーニングパイプラインのデプロイにおける手動のタッチポイントを最小限に抑えて、ML モデルが一貫して繰り返しデプロイされるようにすることをお勧めします。要件と対応するビジネス上の問題に応じて、半自動、完全自動、完全管理の 3 つのレベルでデプロイ戦略を決定し、実施することができます。

  • 半自動 - 前のセクションで説明した手順は、 AWS CloudFormation テンプレートを使用してトレーニングと推論のパイプラインをデプロイするため、デフォルトでは半自動のアプローチを採用しています。これはパイプラインの再現性を確保し、変更や更新を容易にするのに役立ちます。

  • 完全自動 - より高度なオプションは、開発環境、ステージング環境、本番環境への継続的インテグレーションと継続的デプロイ (CI/CD) を使用することです。トレーニングパイプラインのデプロイに CI/CD のプラクティスを組み込むことで、自動化にトレーサビリティと品質ゲートを確実に含めることができます。

  • 完全マネージド型 – 最終的には、一連のシンプルなマニフェストを使用して ML トレーニングパイプラインをデプロイし、必要な AWS サービスを自己設定して調整できるように、完全マネージド型システムを開発できます。

このガイドでは、具体的なアーキテクチャを紹介することにしました。ただし、検討できる代替技術もあります。次の 2 つのセクションでは、プラットフォームとオーケストレーションエンジンのいくつかの代替案について説明します。

ML ワークロード用のさまざまなプラットフォーム

Amazon SageMaker AI は、ML モデルのトレーニングと提供のための AWS マネージドサービスです。多くのユーザーは、ML ワークロードを実行するための幅広い組み込み機能と、多数のオプションを高く評価しています。SageMaker AI は、クラウドでの ML の実装を始めたばかりの場合に特に役立ちます。SageMaker AI の主な機能は次のとおりです。

  • 組み込みのトレーサビリティ (ラベル付け、トレーニング、モデルトラッキング、最適化、推論を含む)。

  • Python と ML の経験が最小限で済むトレーニングと推論のためのワンクリックオプションが組み込まれています。

  • 高度なハイパーパラメータチューニング。

  • すべての主要な人工知能と機械学習 (ML/AI) フレームワークとカスタム Docker コンテナのサポート。

  • 内蔵モニタリング機能。

  • トレーニングジョブ、処理ジョブ、バッチ変換ジョブ、モデル、エンドポイント、検索性を含む履歴の追跡機能を内蔵。トレーニング、処理、バッチ変換など、一部の履歴は不変で、追記のみです。

SageMaker AI を使用する代替手段の 1 つは ですAWS Batch。 AWS Batch は、環境のコンピューティングとオーケストレーションをより低レベルの制御を提供しますが、機械学習用にカスタム構築されていません。いくつかの主な特徴は以下のとおりです。

  • ワークロードに基づくコンピュートリソースのすぐに使える自動スケーリング。

  • すぐにサポートできるジョブ優先度、リトライ、ジョブ依存性。

  • リカレントジョブやオンデマンドジョブの構築をサポートするキューベースのアプローチ。

  • CPU と GPU のワークロードのサポート。GPU は、特にディープラーニングモデルの場合、トレーニングプロセスを大幅にスピードアップできるため、ML モデルの構築に GPU を使用できることが不可欠です。

  • コンピューティング環境用のカスタム Amazon マシンイメージ (AMI) を定義できる能力。

パイプラインオーケストレーション用のさまざまなエンジン

2 番目の主なコンポーネントはパイプラインオーケストレーションレイヤーです。 は、フルマネージドオーケストレーションエクスペリエンスのために Step Functions AWS を提供します。ステップ関数の代わりによく使われるのが、Apache Airflow です。この 2 つのいずれかを選択するには、以下の点を考慮してください。

  • 必要なインフラストラクチャ – AWS Step Functions はフルマネージドサービスでサーバーレスですが、Airflow は独自のインフラストラクチャを管理し、オープンソースソフトウェアに基づいています。その結果、ステップ関数は設定なしですぐに高可用性を実現できますが、Apache Airflow の管理には追加の手順が必要です。

  • スケジューリング機能 - ステップ関数も Airflow も同等の機能を備えています。

  • 視覚化機能と UI - ステップ関数も Airflow も同等の機能を備えています。

  • 計算グラフ内での変数の受け渡し – Step Functions は AWS Lambda 関数を使用するための機能が制限されていますが、Airflow は XCom インターフェイスを提供します。

  • 使用状況 – Step Functions は AWS 顧客の間で非常に人気があり、Airflow はデータエンジニアリングコミュニティによって広く採用されています。