View a markdown version of this page

ステップ 6。パイプラインの拡大 - AWS 規範ガイダンス
さまざまな自動化レベルML ワークロード用のさまざまなプラットフォームパイプラインオーケストレーション用のさまざまなエンジン

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

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

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

さまざまな自動化レベル

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

  • 半自動 - 前のセクションで説明した手順は、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 つ目の主要コンポーネントは、パイプラインオーケストレーションレイヤーです。AWS は完全に管理されたオーケストレーション体験のための Step Functions を提供します。Step Functions の代わりによく使われるのが、Apache Airflow です。この 2 つのいずれかを選択するには、以下の点を考慮してください。

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

  • スケジューリング機能 - Step Functions も Airflow も同等の機能を備えています。

  • 視覚化機能と UI - Step Functions も Airflow も同等の機能を備えています。

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

  • 使い方 - Step Functions は AWS カスタマーの間で非常に人気があり、Airflow はデータエンジニアリングコミュニティで広く採用されています。