ゼファーネットのロゴ

AWS と Amazon SageMaker で Kubeflow を使用して、柔軟でスケーラブルな分散トレーニング アーキテクチャを構築する

日付:

この投稿では、その方法を示します AWSでのKubeflow (Kubeflow の AWS 固有のディストリビューション) で使用 AWS深層学習コンテナ & AmazonElasticファイルシステム (Amazon EFS) は、コラボレーションを簡素化し、両方で深層学習モデルを大規模にトレーニングする際の柔軟性を提供します Amazon Elastic Kubernetesサービス (Amazon EKS) および アマゾンセージメーカー ハイブリッド アーキテクチャ アプローチを採用しています。

機械学習 (ML) の開発は、複雑で継続的に進化するオープンソース フレームワークとツールキット、および複雑で継続的に進化するハードウェア エコシステムに依存しています。 これは、ML 開発をクラスターにスケールアウトする際に課題となります。 コンテナーは、トレーニング コードだけでなく、ハードウェア ライブラリまでの依存関係スタック全体を完全にカプセル化できるため、ソリューションを提供します。 これにより、一貫性があり移植可能な ML 環境が保証され、トレーニング クラスターの個々のノードでトレーニング環境の再現性が促進されます。

Kubernetes は、インフラストラクチャの展開、リソースのスケーリング、およびこれらのコンテナー化されたアプリケーションの管理を自動化するために広く採用されているシステムです。 ただし、Kubernetes は ML を念頭に置いて構築されていないため、YAML 仕様ファイルに大きく依存しているため、データ サイエンティストには直感に反するように感じる可能性があります。 Jupyter エクスペリエンスはなく、ワークフロー管理やパイプラインなどの ML 固有の機能や、ハイパーパラメーターの調整、モデルのホスティングなど、ML の専門家が期待するその他の機能も多くありません。 このような機能を構築することはできますが、Kubernetes はこれを主な目的として行うようには設計されていません。

オープンソース コミュニティが注目し、Kubeflow と呼ばれる Kubernetes の上にレイヤーを開発しました。 Kubeflow は、Kubernetes でのエンド ツー エンドの ML ワークフローのデプロイを、シンプルで、移植可能で、スケーラブルにすることを目的としています。 Kubeflow を使用して、ML 用の最善の組み合わせのオープンソース システムをさまざまなインフラストラクチャにデプロイできます。

Kubeflow と Kubernetes は、データ サイエンティスト チームに柔軟性と制御を提供します。 ただし、運用オーバーヘッドを削減しながら、大規模に実行されているトレーニング クラスターの高い使用率を確保することは、依然として困難です。

この投稿では、オンプレミスの制限または既存の Kubernetes への投資があるお客様が、AWS で Amazon EKS と Kubeflow を使用してセルフマネージド型アプローチに基づく分散トレーニング用の ML パイプラインを実装し、フルマネージド型の SageMaker を使用してこの課題に対処する方法を示します。コストが最適化され、完全に管理された、本番規模のトレーニング インフラストラクチャ。 これには、ハイブリッド分散トレーニング アーキテクチャの段階的な実装が含まれます。これにより、実行時に XNUMX つのアプローチから選択できるようになり、デプロイメントの厳しいニーズに合わせて最大限の制御と柔軟性が得られます。 深層学習トレーニング スクリプトでオープンソース ライブラリを引き続き使用し、プラットフォームに依存しない方法で Kubernetes と SageMaker の両方で実行できるように互換性を維持する方法がわかります。

Kubeflow on AWS と SageMaker はどのように役立ちますか?

TensorFlow、PyTorch、MXNet などのディープ ラーニング フレームワークで構築されたニューラル ネットワーク モデルは、特にコンピューター ビジョンや自然言語処理のユース ケースで、非常に大きなトレーニング データセットを使用することで、はるかに高い精度を提供します。 ただし、大規模なトレーニング データセットを使用すると、ディープ ラーニング モデルのトレーニングに時間がかかり、最終的に市場投入までの時間が遅くなります。 クラスターをスケールアウトして、モデルのトレーニング時間を数週間から数日または数時間に短縮できれば、生産性とビジネスの速度に大きな影響を与える可能性があります。

Amazon EKS は、マネージド Kubernetes コントロール プレーンのプロビジョニングを支援します。 Amazon EKS を使用して CPU と GPU インスタンスを備えた大規模なトレーニング クラスターを作成し、Kubeflow ツールキットを使用して ML フレンドリーなオープンソース ツールを提供し、Kubeflow Pipelines を使用して移植可能でスケーラブルな ML ワークフローを運用化して、チームの生産性と市場投入までの時間を短縮します。

ただし、このアプローチにはいくつかの課題がある可能性があります。

  • データ サイエンス チーム全体でクラスターを最大限に活用できるようにします。 たとえば、GPU インスタンスをオンデマンドでプロビジョニングし、ディープ ラーニング トレーニングなどの要求の厳しい実稼働規模のタスクには高い使用率を確保し、データの前処理などの要求の少ないタスクには CPU インスタンスを使用する必要があります。
  • Kubernetes クラスター ワーカー ノードにデプロイされる、データベース、ストレージ、認証などの重量級の Kubeflow インフラストラクチャ コンポーネントの高可用性を確保します。 たとえば、Kubeflow コントロール プレーンは、時間の経過とともに増大し、継続的な監視機能を備えたサイズ変更可能なストレージ ボリュームを必要とするアーティファクト (MySQL インスタンス、ポッド ログ、または MinIO ストレージなど) を生成します。
  • 開発者、トレーニング クラスター、およびプロジェクト間でトレーニング データセット、コード、およびコンピューティング環境を共有することは困難です。 たとえば、独自のライブラリ セットに取り組んでいて、それらのライブラリに強い相互依存関係がある場合、同じチームのデータ サイエンティスト間で同じコードを共有して実行するのは非常に困難です。 また、トレーニングを実行するたびに、トレーニング データセットをダウンロードし、新しいコードを変更してトレーニング イメージをビルドする必要があります。

Kubeflow on AWS は、これらの課題に対処するのに役立ち、エンタープライズ グレードのセミマネージド Kubeflow 製品を提供します。 Kubeflow on AWS を使用すると、データベース、ストレージ、モニタリング、ユーザー管理などの一部の Kubeflow コントロール プレーン サービスを、AWS マネージド サービスなどに置き換えることができます。 Amazon リレーショナル データベース サービス (Amazon RDS)、 Amazon シンプル ストレージ サービス (Amazon S3)、 AmazonElasticファイルシステム (Amazon EFS)、 アマゾンFSx, アマゾンクラウドウォッチ, アマゾンコグニート.

これらの Kubeflow コンポーネントを置き換えることで、Kubeflow コントロール プレーンの重要な部分を Kubernetes から分離し、安全で、スケーラブルで、回復力があり、コストが最適化された設計を提供します。 このアプローチは、分散モデル トレーニングやユーザー ノートブック サーバーなどのアプリケーションで必要になる可能性がある、EKS データ プレーンからストレージとコンピューティング リソースも解放します。 Kubeflow on AWS は、Jupyter ノートブックとディープ ラーニング コンテナー (DLC) イメージとのネイティブ統合も提供します。これは、PyTorch や TensorFlow などの AWS に最適化されたディープ ラーニング フレームワークで事前にパッケージ化および事前構成されているため、トレーニング コードをすぐに書き始めることができます。依存関係の解決とフレームワークの最適化。 また、Amazon EFS とトレーニング クラスターおよび開発環境の統合により、コードと処理されたトレーニング データセットを共有できるため、コード変更のたびにコンテナ イメージを構築して巨大なデータセットをロードする必要がなくなります。 これらの Kubeflow on AWS との統合により、モデルの構築とトレーニングの時間を短縮し、データとコードの共有を容易にしてコラボレーションを改善できます。

Kubeflow on AWS は、可用性が高く堅牢な ML プラットフォームの構築に役立ちます。 このプラットフォームは、ディープ ラーニング モデルを構築およびトレーニングするための柔軟性を提供し、多くのオープンソース ツールキット、ログへの洞察、および実験用の対話型デバッグへのアクセスを提供します。 ただし、何百もの GPU でディープ ラーニング モデルをトレーニングしながらインフラストラクチャ リソースを最大限に活用するには、依然として多くの運用上のオーバーヘッドが伴います。 これは、要求されたときにのみプロビジョニングされ、必要に応じてスケーリングされ、ジョブが完了すると自動的にシャットダウンされる、パフォーマンスとコストが最適化されたトレーニング クラスターを処理するために設計および最適化されたフルマネージド サービスである SageMaker を使用することで対処できます。 % リソースの活用。 マネージド SageMaker コンポーネントを使用して、SageMaker を Kubeflow Pipelines と統合できます。 これにより、ML ワークフローを Kubeflow パイプラインの一部として運用できるようになり、ローカル トレーニングには Kubernetes を使用し、ハイブリッド アーキテクチャでの製品規模のトレーニングには SageMaker を使用できます。

ソリューションの概要

次のアーキテクチャは、Kubeflow Pipelines を使用して移植可能でスケーラブルなエンドツーエンドの ML ワークフローを構築およびデプロイし、ランタイム パラメータに基づいて Kubeflow トレーニングまたは SageMaker を使用して Kubernetes で分散トレーニングを条件付きで実行する方法を示しています。

Kubeflow トレーニングは、Kubeflow に TensorFlow、PyTorch などのさまざまなフレームワークを使用した ML モデルの分散トレーニングのサポートを追加する Kubernetes オペレーターのグループです。 pytorch-operator Kubernetes の Kubeflow 実装です。 カスタム リソース (PyTorchJob) を使用して、分散された PyTorch トレーニング ジョブを Kubernetes で実行します。

Kubeflow パイプラインの一部として PyTorchJob Launcher コンポーネントを使用して、インタラクティブなデバッグと分析のために柔軟性とすべての基礎となるリソースへのアクセスが必要な実験段階で PyTorch 分散トレーニングを実行します。

また、Kubeflow Pipelines 用の SageMaker コンポーネントを使用して、実稼働規模でモデル トレーニングを実行しています。 これにより、フルマネージド サービス、最大の GPU 使用率での分散トレーニング ジョブ、費用対効果の高いトレーニングなどの強力な SageMaker 機能を利用できます。 アマゾン エラスティック コンピューティング クラウド (Amazon EC2)スポットインスタンス。

ワークフロー作成プロセスの一環として、次の手順を完了して (前の図に示すように)、このパイプラインを作成します。

  1. Kubeflow マニフェスト ファイルを使用して Kubeflow ダッシュボードを作成し、Kubeflow 中央ダッシュボードから Jupyter ノートブックにアクセスします。
  2. Kubeflow パイプライン SDK を使用して、Python コードを使用して Kubeflow パイプラインを作成およびコンパイルします。 パイプライン コンパイルは、Python 関数を、Argo 互換の YAML 形式であるワークフロー リソースに変換します。
  3. Kubeflow Pipelines SDK クライアントを使用してパイプライン サービス エンドポイントを呼び出し、パイプラインを実行します。
  4. パイプラインは条件付きランタイム変数を評価し、ターゲット実行環境として SageMaker または Kubernetes を決定します。
  5. Kubeflow PyTorch Launcher コンポーネントを使用してネイティブ Kubernetes 環境で分散トレーニングを実行するか、SageMaker コンポーネントを使用して SageMaker マネージド プラットフォームでトレーニングを送信します。

次の図は、アーキテクチャに含まれる Kubeflow Pipelines コンポーネントを示しています。これにより、Kubernetes または SageMaker 分散環境を柔軟に選択できます。

Kubeflow パイプライン コンポーネント

ユースケースのワークフロー

次の段階的なアプローチを使用して、AWS で Kubeflow を使用して、Amazon EKS と SageMaker を使用した分散トレーニングのユースケースをインストールして実行します。

前提条件

このチュートリアルでは、次の前提条件を満たしている必要があります。

  • An AWSアカウント.
  • Docker と AWSコマンドラインインターフェイス (AWS CLI) がインストールされています。
  • オプションで、 AWS クラウド9は、Web ブラウザーからすべての作業を完了できるクラウドベースの統合開発環境 (IDE) です。 セットアップ手順については、を参照してください。 Cloud9 IDE のセットアップ. Cloud9 環境からプラス記号を選択し、新しいターミナルを開きます。
  • 役割を作成する 名前で sagemakerrole. 管理ポリシーを追加する AmazonSageMakerFullAccess & AmazonS3FullAccess SageMaker に S3 バケットへのアクセスを許可します。 このロールは、Kubeflow Pipelines ステップの一部として送信された SageMaker ジョブによって使用されます。
  • アカウントに SageMaker Training リソースタイプの制限があることを確認してください ml.p3.2xlarge を使用して 2 に増加 サービス クォータ コンソール

1.AWS に Amazon EKS と Kubeflow をインストールする

いくつかの異なるアプローチを使用して、Kubernetes クラスターを構築し、Kubeflow をデプロイできます。 この記事では、プロセスをシンプルにするアプローチに焦点を当てます。 まず、EKS クラスターを作成し、次に Kubeflow on AWS v1.5 をデプロイします。 これらのタスクのそれぞれについて、私たちは対応するオープンソース プロジェクトを使用します。 フレームワークを行う. タスクごとに一連の前提条件をインストールするのではなく、必要なすべてのツールを備えた Docker コンテナーを構築し、コンテナー内からタスクを実行します。

この投稿では Do フレームワークを使用します。これは、Amazon EFS をアドオンとして Kubeflow のデプロイを自動化します。 本番環境へのデプロイのための公式の Kubeflow on AWS デプロイ オプションについては、以下を参照してください。 展開.

現在の作業ディレクトリと AWS CLI を構成する

作業ディレクトリを構成して、次の手順の開始点として参照できるようにします。

export working_dir=$PWD

AWS CLI プロファイルも設定します。 そのためには、アクセス キー ID とシークレット アクセス キーが必要です。 AWS IDおよびアクセス管理 (わたし) user 管理者権限 (既存の管理ポリシーをアタッチ) とプログラムによるアクセスを持つアカウント。 次のコードを参照してください。

aws configure --profile=kubeflow
AWS Access Key ID [None]: 
AWS Secret Access Key [None]: 
Default region name [None]: us-west-2
Default output format [None]: json

# (In Cloud9, select “Cancel” and “Permanently disable” when the AWS managed temporary credentials dialog pops up)

export AWS_PROFILE=kubeflow

1.1 EKS クラスターを作成する

利用可能な EKS クラスターが既にある場合は、次のセクションにスキップできます。 この記事では、 aws-do-eks プロジェクト クラスターを作成します。

  1. 最初に作業ディレクトリにプロジェクトのクローンを作成します
    cd ${working_dir}
    git clone https://github.com/aws-samples/aws-do-eks
    cd aws-do-eks/

  2. 次に、ビルドして実行します aws-do-eks 容器:
    ./build.sh
    ./run.sh

      build.sh script は、EKS クラスターのプロビジョニングと操作に必要なすべてのツールとスクリプトを含む Docker コンテナー イメージを作成します。 の run.sh スクリプトは、作成された Docker イメージを使用してコンテナーを開始し、それを維持するため、EKS 管理環境として使用できます。 自分のステータスを見るには aws-do-eks コンテナ、実行できます ./status.sh. コンテナが終了ステータスの場合は、 ./start.sh スクリプトを実行してコンテナを起動したり、コンテナを再起動したりできます。 ./stop.sh 続い ./run.sh.

  3. 実行中のシェルを開く aws-do-eks 容器:
  4. KubeFlow デプロイの EKS クラスター構成を確認するには、次のコマンドを実行します。
    vi ./eks-kubeflow.yaml

    デフォルトでは、この構成により、次の名前のクラスターが作成されます。 eks-kubeflow セクションに us-west-2 5 つの mXNUMX.xlarge ノードがあるリージョン。 また、EBS ボリュームの暗号化はデフォルトでは有効になっていません。 追加することで有効にできます "volumeEncrypted: true" ノードグループに追加すると、デフォルトのキーを使用して暗号化されます。 必要に応じて、他の構成設定を変更します。

  5. クラスターを作成するには、次のコマンドを実行します。
    export AWS_PROFILE=kubeflow
    eksctl create cluster -f ./eks-kubeflow.yaml

    クラスターのプロビジョニング プロセスには、最大 30 分かかる場合があります。

  6. クラスターが正常に作成されたことを確認するには、次のコマンドを実行します。
    kubectl get nodes

    正常に作成されたクラスターの前のコマンドからの出力は、次のコードのようになります。

    root@cdf4ecbebf62:/eks# kubectl get nodes
    NAME                                           STATUS   ROLES    AGE   VERSION
    ip-192-168-0-166.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
    ip-192-168-13-28.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
    ip-192-168-45-240.us-west-2.compute.internal   Ready       23m   v1.21.14-eks-ba74326
    ip-192-168-63-84.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
    ip-192-168-75-56.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
    ip-192-168-85-226.us-west-2.compute.internal   Ready       23m   v1.21.14-eks-ba74326

SageMaker トレーニングジョブ用の EFS ボリュームを作成する

このユースケースでは、Amazon EFS にすでに保存されているデータから深層学習モデルをトレーニングすることで、SageMaker トレーニングジョブを高速化します。 この選択には、データ移動を必要とせずに Amazon EFS のデータからトレーニング ジョブを直接起動できるという利点があり、トレーニングの開始時間が短縮されます。

EFS ボリュームを作成し、EFS Container Storage Interface (CSI) ドライバーをデプロイします。 これは、次の場所にある展開スクリプトによって実現されます。 /eks/deployment/csi/efs 中で aws-do-eks コンテナ。

このスクリプトは、アカウントに XNUMX つの EKS クラスターがあることを前提としています。 設定 CLUSTER_NAME= 複数の EKS クラスターがある場合。

cd /eks/deployment/csi/efs
./deploy.sh

このスクリプトは、EFS ボリュームをプロビジョニングし、クラスター VPC のサブネットのマウント ターゲットを作成します。 次に、EFS CSI ドライバーを展開し、 efs-sc ストレージクラスと efs-pv EKS クラスターの永続ボリューム。

スクリプトが正常に完了すると、次のような出力が表示されます。

Generating efs-sc.yaml ...

Applying efs-sc.yaml ...
storageclass.storage.k8s.io/efs-sc created
NAME            PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
efs-sc          efs.csi.aws.com         Delete          Immediate              false                  1s
gp2 (default)   kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  36m

Generating efs-pv.yaml ...
Applying efs-pv.yaml ...
persistentvolume/efs-pv created
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
efs-pv   5Gi        RWX            Retain           Available           efs-sc                  10s

Done ...

Amazon S3 VPC エンドポイントを作成する

SageMaker トレーニングジョブと EFS ファイルシステムがアクセスできるプライベート VPC を使用します。 SageMaker トレーニング クラスターがプライベート VPC から S3 バケットにアクセスできるようにするには、VPC エンドポイントを作成します。

cd /eks/vpc 
export CLUSTER_NAME= 
export REGION= 
./vpc-endpoint-create.sh

これで終了できます aws-do-eks コンテナ シェルに進み、次のセクションに進みます。

exit

root@cdf4ecbebf62:/eks/deployment/csi/efs# exit
exit
TeamRole:~/environment/aws-do-eks (main) $

1.2 Amazon EKS で AWS に Kubeflow をデプロイする

Kubeflow を Amazon EKS にデプロイするには、 aws-do-kubeflow プロジェクト.

  1. 次のコマンドを使用してリポジトリをクローンします。
    cd ${working_dir}
    git clone https://github.com/aws-samples/aws-do-kubeflow
    cd aws-do-kubeflow

  2. 次に、プロジェクトを構成します。
    ./config.sh

    このスクリプトは、プロジェクト構成ファイルをテキスト エディターで開きます。 それは重要です AWS_REGION クラスターが存在するリージョンに設定するだけでなく、 AWS_CLUSTER_NAME 前に作成したクラスターの名前と一致するようにします。 デフォルトでは、構成はすでに適切に設定されているため、変更を加える必要がない場合は、エディターを閉じてください。

    ./build.sh
    ./run.sh
    ./exec.sh

      build.sh スクリプトは、既存の Kubernetes クラスターで Kubeflow をデプロイおよび管理するために必要なすべてのツールを備えた Docker コンテナー イメージを作成します。 の run.sh スクリプトは Docker イメージを使用してコンテナーを開始し、exec.sh スクリプトはコマンド シェルをコンテナーに開きます。これを Kubeflow 管理環境として使用できます。 を使用できます。 ./status.sh かどうかを確認するスクリプト aws-do-kubeflow コンテナが稼働中であり、 ./stop.sh & ./run.sh スクリプトを使用して、必要に応じて再起動します。

  3. でシェルを開いた後、 aws-do-eks コンテナーで、構成されたクラスター コンテキストが期待どおりであることを確認できます。
    root@ip-172-31-43-155:/kubeflow# kubectx
    kubeflow@eks-kubeflow.us-west-2.eksctl.io

  4. Kubeflow を EKS クラスターにデプロイするには、次のコマンドを実行します。 deploy.sh スクリプト:
    ./kubeflow-deploy.sh

    kubeflow 名前空間のすべてのポッドが Running 状態になると、デプロイは成功です。 一般的な出力は、次のコードのようになります。

    Waiting for all Kubeflow pods to start Running ...
    
    Waiting for all Kubeflow pods to start Running ...
    
    Restarting central dashboard ...
    pod "centraldashboard-79f489b55-vr6lp" deleted
    /kubeflow/deploy/distro/aws/kubeflow-manifests /kubeflow/deploy/distro/aws
    /kubeflow/deploy/distro/aws
    
    Kubeflow deployment succeeded
    Granting cluster access to kubeflow profile user ...
    Argument not provided, assuming default user namespace kubeflow-user-example-com ...
    clusterrolebinding.rbac.authorization.k8s.io/kubeflow-user-example-com-cluster-admin-binding created
    Setting up access to Kubeflow Pipelines ...
    Argument not provided, assuming default user namespace kubeflow-user-example-com ...
    
    Creating pod-default for namespace kubeflow-user-example-com ...
    poddefault.kubeflow.org/access-ml-pipeline created

  5. 別のウィンドウで KubeFlow ポッドの状態を監視するには、次のコマンドを使用できます。
    watch kubectl -n kubeflow get pods

  6. イベント Ctrlキー+ C すべてのポッドが実行中の場合、次のコマンドを実行して Kubeflow ダッシュボードをクラスター外に公開します。
    ./kubeflow-expose.sh

次のコードのような出力が表示されます。

root@ip-172-31-43-155:/kubeflow# ./kubeflow-expose.sh
root@ip-172-31-43-155:/kubeflow# Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080

このコマンドは、Istio イングレス ゲートウェイ サービスをクラスターからローカル ポート 8080 にポート転送します。Kubeflow ダッシュボードにアクセスするには、 http://localhost:8080 デフォルトのユーザー認証情報を使用してログインします (user@example.com/12341234)。 あなたが実行している場合 aws-do-kubeflow AWS Cloud9 のコンテナである場合は、選択できます プレビュー、を選択します 実行中のアプリケーションのプレビュー. Docker デスクトップで実行している場合は、 ./kubeflow-expose.sh 外部のスクリプト aws-do-kubeflow コンテナ。

2. Kubeflow on AWS 環境をセットアップする

Kubeflow on AWS 環境をセットアップするには、EFS ボリュームと Jupyter ノートブックを作成します。

2.1 EFS ボリュームの作成

EFS ボリュームを作成するには、次の手順を実行します。

  • Kubeflow ダッシュボードで、 ボリューム ナビゲーションペインに表示されます。
  • 選んだ 新巻.
  • 名前 、 入る efs-sc-claim.
  • ボリュームサイズ、 入る 10.
  • ストレージクラス、選択する efs-sc.
  • アクセスモード、選択する リードライトワンス.
  • 選択する 創造する.

2.2 Jupyter ノートブックを作成する

新しいノートブックを作成するには、次の手順を実行します。

  • Kubeflow ダッシュボードで、 ノートブック ナビゲーションペインに表示されます。
  • 選択する 新しいノート.
  • 名前 、 入る aws-hybrid-nb.
  • Jupyter ドケット イメージ、画像を選択 c9e4w0g3/notebook-servers/jupyter-pytorch:1.11.0-cpu-py38-ubuntu20.04-e3-v1.1 (入手可能な最新の jupyter-pytorch DLC イメージ)。
  • CPU、 入る 1.
  • メモリ、 入る 5.
  • GPU、そのままにしておく なし.
  • に変更を加えないでください ワークスペース ボリューム のセクションから無料でダウンロードできます。
  • データ量 セクションでは、選択 既存のボリュームをアタッチ 既存のボリュームセクションを展開します
  • 名前 、選択する efs-sc-claim.
  • マウント パス、 入る /home/jovyan/efs-sc-claim.
    これにより、EFS ボリュームが Jupyter ノートブック ポッドにマウントされ、フォルダーが表示されます。 efs-sc-claim Jupyter ラボのインターフェースで。 トレーニング データセットとトレーニング コードをこのフォルダーに保存して、テスト用にコンテナー イメージを再構築しなくてもトレーニング クラスターがアクセスできるようにします。
  • 選択 Kubeflow Pipelines へのアクセスを許可する 構成セクションで。
  • 選択する 起動する.
    ノートブックが正常に作成されたことを確認します (数分かかる場合があります)。
  • ソフトウェア設定ページで、下図のように ノートブック ページ、選択 お問合せ JupyterLab 環境にログインします。
  • ソフトウェア設定ページで、下図のように Gitの メニュー、選択 リポジトリのクローンを作成する.
  • レポをクローンする、 入る https://github.com/aws-samples/aws-do-kubeflow.

3. 分散トレーニングを実行する

Jupyter ノートブックをセットアップしたら、フォルダーから次の高レベルの手順を使用して、デモ全体を実行できます。 aws-do-kubeflow/workshop クローンされたリポジトリで:

  • PyTorch 分散データ並列 (DDP) トレーニング スクリプト: PyTorch DDP トレーニング スクリプト cifar10-distributed-gpu-final.py を参照してください。これには、サンプルの畳み込みニューラル ネットワークとロジックが含まれており、マルチノード CPU および GPU クラスターでトレーニングを分散します。 (詳細は 3.1 参照)
  • ライブラリをインストールします。 ノートブックを実行する 0_initialize_dependencies.ipynb すべての依存関係を初期化します。 (詳細は 3.2 参照)
  • Kubernetes で分散 PyTorch ジョブ トレーニングを実行します。 ノートブックを実行する 1_submit_pytorchdist_k8s.ipynb Python コードを使用して、Kubernetes カスタム リソース PyTorchJob YAML ファイルを使用して、XNUMX つのプライマリ コンテナーと XNUMX つのワーカー コンテナーで分散トレーニングを作成して送信します。 (詳細は 3.3 参照)
  • ハイブリッド Kubeflow パイプラインを作成します。 ノートブックを実行する 2_create_pipeline_k8s_sagemaker.ipynb ランタイム変数を使用して、SageMaker または Amazon EKS で分散トレーニングを実行するハイブリッド Kubeflow パイプラインを作成する training_runtime. (詳細は 3.4 参照)

ノートブックを実行したことを確認してください 1_submit_pytorchdist_k8s.ipynb ノートブックを始める前に 2_create_pipeline_k8s_sagemaker.ipynb.

以降のセクションでは、これらの各手順について詳しく説明します。

3.1 PyTorch 分散データ並列 (DDP) トレーニング スクリプト

分散トレーニングの一環として、CIFAR10 データセットで動作する単純な畳み込みニューラル ネットワークによって作成された分類モデルをトレーニングします。 トレーニング スクリプト cifar10-distributed-gpu-final.py オープンソース ライブラリのみが含まれており、GPU デバイスまたは CPU インスタンスのいずれかで、Kubernetes と SageMaker トレーニング クラスターの両方で実行できる互換性があります。 ノートブックの例を実行する前に、トレーニング スクリプトのいくつかの重要な側面を見てみましょう。

私たちは、使用 torch.distributed モジュールには、クラスター内のノード間のマルチプロセス並列処理のための PyTorch サポートと通信プリミティブが含まれています。

...
import torch
import torch.distributed as dist
import torch.nn as nn
import torch.nn.functional as F
import torch.optim as optim
import torch.utils.data
import torch.utils.data.distributed
import torchvision
from torchvision import datasets, transforms
...

モデル トレーニングのフォワード パスで relu 活性化関数が適用される、畳み込み層、最大プーリング層、および線形層の組み合わせを使用して、単純な画像分類モデルを作成します。

# Define models
class Net(nn.Module):
def __init__(self):
super(Net, self).__init__()
self.conv1 = nn.Conv2d(3, 6, 5)
self.pool = nn.MaxPool2d(2, 2)
self.conv2 = nn.Conv2d(6, 16, 5)
self.fc1 = nn.Linear(16 * 5 * 5, 120)
self.fc2 = nn.Linear(120, 84)
self.fc3 = nn.Linear(84, 10)

def forward(self, x):
x = self.pool(F.relu(self.conv1(x)))
x = self.pool(F.relu(self.conv2(x)))
x = x.view(-1, 16 * 5 * 5)
x = F.relu(self.fc1(x))
x = F.relu(self.fc2(x))
x = self.fc3(x)
return x

データセットと DistributedSampler (を使用して、データのサブセットを分散方式でロードします。 torch.nn.parallel.DistributedDataParallel)、データに対して単一プロセスまたは複数プロセスの反復子を提供します。

# Define data loader for training dataset
def _get_train_data_loader(batch_size, training_dir, is_distributed):
logger.info("Get train data loader")

train_set = torchvision.datasets.CIFAR10(root=training_dir,
train=True,
download=False,
transform=_get_transforms())

train_sampler = (
torch.utils.data.distributed.DistributedSampler(train_set) if is_distributed else None
)

return torch.utils.data.DataLoader(
train_set,
batch_size=batch_size,
shuffle=train_sampler is None,
sampler=train_sampler)
...

トレーニング クラスターに GPU がある場合、スクリプトは CUDA デバイスでトレーニングを実行し、デバイス変数はデフォルトの CUDA デバイスを保持します。

device = "cuda" if torch.cuda.is_available() else "cpu"
...

PyTorch を使用して分散トレーニングを実行する前に DistributedDataParallel 複数のノードで分散処理を実行するには、呼び出して分散環境を初期化する必要があります init_process_group. これは、トレーニング クラスターの各マシンで初期化されます。

dist.init_process_group(backend=args.backend, rank=host_rank, world_size=world_size)
...

分類子モデルをインスタンス化し、モデルをターゲット デバイスにコピーします。 分散トレーニングが複数のノードで実行できるようになっている場合、 DistributedDataParallel クラスは、モデル オブジェクトのラッパー オブジェクトとして使用されます。これにより、複数のマシンにまたがる同期分散トレーニングが可能になります。 入力データはバッチ ディメンションで分割され、モデルのレプリカが各マシンと各デバイスに配置されます。

model = Net().to(device)

if is_distributed:
model = torch.nn.parallel.DistributedDataParallel(model)

...

3.2 ライブラリのインストール

PyTorch 分散トレーニング サンプルを実行するために必要なすべてのライブラリをインストールします。 これには、Kubeflow Pipelines SDK、Training Operator Python SDK、Kubernetes 用の Python クライアント、および Amazon SageMaker Python SDK が含まれます。

#Please run the below commands to install necessary libraries

!pip install kfp==1.8.4

!pip install kubeflow-training

!pip install kubernetes

!pip install sagemaker

3.3 Kubernetes で分散 PyTorch ジョブ トレーニングを実行する

ノート 1_submit_pytorchdist_k8s.ipynb Kubeflow トレーニングと Kubernetes クライアント Python SDK を使用して、Kubernetes カスタム リソース PyTorchJob YAML ファイルを作成します。 以下は、このノートブックの重要な抜粋です。

次のコードに示すように、プライマリ コンテナーとワーカー コンテナーを使用して PyTorchJob YAML を作成します。

# Define PyTorchJob custom resource manifest
pytorchjob = V1PyTorchJob(
api_version="kubeflow.org/v1",
kind="PyTorchJob",
metadata=V1ObjectMeta(name=pytorch_distributed_jobname,namespace=user_namespace),
spec=V1PyTorchJobSpec(
run_policy=V1RunPolicy(clean_pod_policy="None"),
pytorch_replica_specs={"Master": master,
"Worker": worker}
)
)

これは、次を使用して Kubernetes コントロール プレーンに送信されます。 PyTorchJobClient:

# Creates and Submits PyTorchJob custom resource file to Kubernetes
pytorchjob_client = PyTorchJobClient()

pytorch_job_manifest=pytorchjob_client.create(pytorchjob):

Kubernetes トレーニング ログを表示する

トレーニング ログは、Python コードを使用して同じ Jupyter ノートブックから、または Kubernetes クライアント シェルから表示できます。

3.4 ハイブリッド Kubeflow パイプラインを作成する

ノート 2_create_pipeline_k8s_sagemaker.ipynb 条件付きランタイム変数に基づいてハイブリッド Kubeflow パイプラインを作成します training_runtime、次のコードに示すように。 ノートブックは、 KubeflowパイプラインSDK また、ML ワークフロー パイプラインを指定して実行するための一連の Python パッケージが提供されています。 この SDK の一部として、次のパッケージを使用します。

  • ドメイン固有言語 (DSL) パッケージ デコレーター dsl.pipeline、パイプラインを返すように Python 関数を装飾します
  •   dsl.Condition パッケージは、特定の条件が満たされた場合にのみ実行される操作のグループを表します。 training_runtime としての値 sagemaker or kubernetes

次のコードを参照してください。

# Define your training runtime value with either 'sagemaker' or 'kubernetes'
training_runtime='sagemaker'

# Create Hybrid Pipeline using Kubeflow PyTorch Training Operators and Amazon SageMaker Service
@dsl.pipeline(name="PyTorch Training pipeline", description="Sample training job test")
def pytorch_cnn_pipeline():

# Pipeline Step 1: to evaluate the condition. You can enter any logic here. For demonstration we are checking if GPU is needed for training
condition_result = check_condition_op(training_runtime)

# Pipeline Step 2: to run training on Kuberentes using PyTorch Training Operators. This will be executed if gpus are not needed
with dsl.Condition(condition_result.output == 'kubernetes', name="PyTorch_Comp"):
train_task = pytorch_job_op(
name=training_job_name,
namespace=user_namespace,
master_spec=json.dumps(master_spec_loaded), # Please refer file at pipeline_yaml_specifications/pipeline_master_spec.yml
worker_spec=json.dumps(worker_spec_loaded), # Please refer file at pipeline_yaml_specifications/pipeline_worker_spec.yml
delete_after_done=False
).after(condition_result)

# Pipeline Step 3: to run training on SageMaker using SageMaker Components for Pipeline. This will be executed if gpus are needed
with dsl.Condition(condition_result.output == 'sagemaker', name="SageMaker_Comp"):
training = sagemaker_train_op(
region=region,
image=train_image,
job_name=training_job_name,
training_input_mode=training_input_mode,
hyperparameters='{ 
"backend": "'+str(pytorch_backend)+'", 
"batch-size": "64", 
"epochs": "3", 
"lr": "'+str(learning_rate)+'", 
"model-type": "custom", 
"sagemaker_container_log_level": "20", 
"sagemaker_program": "cifar10-distributed-gpu-final.py", 
"sagemaker_region": "us-west-2", 
"sagemaker_submit_directory": "'+source_s3+'" 
}',
channels=channels,
instance_type=instance_type,
instance_count=instance_count,
volume_size=volume_size,
max_run_time=max_run_time,
model_artifact_path=f's3://{bucket_name}/jobs',
network_isolation=network_isolation,
traffic_encryption=traffic_encryption,
role=role,
vpc_subnets=subnet_id,
vpc_security_group_ids=security_group_id
).after(condition_result)

3.2 つの ml.pXNUMXxlarge インスタンスを使用して SageMaker 分散トレーニングを構成します。

パイプラインを定義したら、Kubeflow Pipelines SDK を使用してパイプラインを Argo YAML 仕様にコンパイルできます。 kfp.compiler パッケージ。 このパイプラインは、Kubeflow Pipeline SDK クライアントを使用して実行できます。このクライアントは、Pipelines サービス エンドポイントを呼び出し、適切な認証ヘッダーをノートブックから直接渡します。 次のコードを参照してください。

# DSL Compiler that compiles pipeline functions into workflow yaml.
kfp.compiler.Compiler().compile(pytorch_cnn_pipeline, "pytorch_cnn_pipeline.yaml")

# Connect to Kubeflow Pipelines using the Kubeflow Pipelines SDK client
client = kfp.Client()

experiment = client.create_experiment(name="kubeflow")

# Run a specified pipeline
my_run = client.run_pipeline(experiment.id, "pytorch_cnn_pipeline", "pytorch_cnn_pipeline.yaml")

# Please click “Run details” link generated below this cell to view your pipeline. You can click every pipeline step to see logs.

あなたが sagemaker import エラーが発生した場合は、!pip install sagemaker を実行し、カーネルを再起動します ( カーネル メニュー、選択 カーネルを再起動する).

選択する 実行の詳細 最後のセルの下にあるリンクをクリックして、Kubeflow パイプラインを表示します。

パイプラインの作成手順を繰り返します training_runtime='kubernetes' Kubernetes 環境で実行されるパイプラインをテストします。 の training_runtime 変数は、運用シナリオの CI/CD パイプラインで渡すこともできます。

SageMaker コンポーネントの Kubeflow パイプライン実行ログを表示する

次のスクリーンショットは、SageMaker コンポーネントのパイプラインの詳細を示しています。

トレーニング ジョブ ステップを選択し、 ログ タブで、CloudWatch ログリンクを選択して SageMaker ログにアクセスします。

次のスクリーンショットは、3.2 つの ml.pXNUMXxlarge インスタンスのそれぞれの CloudWatch ログを示しています。

ログを表示するには、いずれかのグループを選択します。

Kubeflow PyTorchJob Launcher コンポーネントの Kubeflow パイプライン実行ログを表示する

次のスクリーンショットは、Kubeflow コンポーネントのパイプラインの詳細を示しています。

を使用して次のコマンドを実行します。 Kubectl Kubernetes クラスターに接続された Kubernetes クライアント シェルで、ログを表示します (名前空間とポッド名を置き換えてください)。

kubectl get pods -n kubeflow-user-example-com
kubectl logs  -n kubeflow-user-example-com -f

4.1 クリーンアップ

アカウントで作成したすべてのリソースをクリーンアップするには、それらを逆の順序で削除する必要があります。

  1. 実行して Kubeflow インストールを削除します。 ./kubeflow-remove.sh セクションに aws-do-kubeflow 容器。 コマンドの最初のセットはオプションであり、まだコマンド シェルがない場合に使用できます。 aws-do-kubeflow コンテナオープン。
    cd aws-do-kubeflow
    ./status.sh
    ./start.sh
    ./exec.sh
    
    ./kubeflow-remove.sh

  2. ノーザンダイバー社の aws-do-eks コンテナー フォルダーで、EFS ボリュームを削除します。 コマンドの最初のセットはオプションであり、まだコマンド シェルがない場合に使用できます。 aws-do-eks コンテナオープン。
    cd aws-do-eks
    ./status.sh
    ./start.sh
    ./exec.sh
    
    cd /eks/deployment/csi/efs
    ./delete.sh
    ./efs-delete.sh

    クラスター用に作成した VPC に関連付けられたネットワーク インターフェイスを解放するには、Amazon EFS を削除する必要があります。 EFS ボリュームを削除すると、そこに保存されているすべてのデータが破棄されることに注意してください。

  3. ノーザンダイバー社の aws-do-eks コンテナ、実行 eks-delete.sh スクリプトを使用して、VPC を含むクラスターとそれに関連付けられているその他のリソースを削除します。
    cd /eks
    ./eks-delete.sh

まとめ

この投稿では、分散モデル トレーニングと ML ワークフローの典型的な課題のいくつかについて説明しました。 Kubeflow on AWS ディストリビューションの概要を説明し、XNUMX つのオープンソース プロジェクトを共有しました (aws-do-eks & aws-do-kubeflow) インフラストラクチャのプロビジョニングとその上での Kubeflow の展開を簡素化します。 最後に、自己管理型の Kubernetes と完全管理型の SageMaker インフラストラクチャの間でワークロードをシームレスに移行できるようにするハイブリッド アーキテクチャについて説明し、デモを行いました。 このハイブリッド アーキテクチャを独自のユース ケースに使用することをお勧めします。

あなたは AWSLabsリポジトリ KubeflowへのすべてのAWSの貢献を追跡します。 また、で私たちを見つけることができます Kubeflow #AWS Slack チャンネル; そこでのフィードバックは、Kubeflowプロジェクトに貢献する次の機能に優先順位を付けるのに役立ちます。

この投稿の立ち上げをサポートしてくれた Sree Arasanagatta (ソフトウェア開発マネージャー AWS ML) と Suraj Kota (ソフトウェア開発エンジニア) に感謝します。


著者について

カンワルジット・クルミ アマゾンウェブサービスのAI/MLスペシャリストソリューションアーキテクトです。 彼はAWS製品、エンジニアリング、および顧客と協力して、AWSを使用する際のハイブリッドMLソリューションの価値を向上させるためのガイダンスと技術支援を提供しています。 Kanwaljitは、コンテナ化された機械学習アプリケーションで顧客を支援することを専門としています。

ゴータム・クマール AWS AI Deep Learning のソフトウェアエンジニアです。 AWS Deep Learning Containers と AWS Deep Learning AMI を開発しました。 彼は、AI 用のツールとシステムの構築に情熱を注いでいます。 余暇には、サイクリングと読書を楽しんでいます。

アレックス・イアンクルスキ は、フルスタックのソフトウェアおよびインフラストラクチャ アーキテクトであり、深く実践的な作業を行うのが好きです。 彼は現在、AWS で自己管理型機械学習のプリンシパル ソリューション アーキテクトを務めています。 彼の役割では、コンテナを利用した AWS サービスでの ML および AI ワークロードのコンテナ化とオーケストレーションで顧客を支援することに重点を置いています。 彼はオープンソースの作者でもあります フレームワークを行う 世界最大の課題を解決しながら、イノベーションのペースを加速するためにコンテナー テクノロジーを適用することを愛する Docker キャプテン。 過去 10 年間、Alex は気候変動との闘い、AI と ML の民主化、旅行の安全化、ヘルスケアの改善、エネルギーのスマート化に取り組んできました。

スポット画像

最新のインテリジェンス

スポット画像

私たちとチャット

やあ! どんな御用でしょうか?