Amazon Web Services ブログ

Amazon SageMaker から Amazon EMR クラスタを作成・管理し、Spark と ML のインタラクティブな ワークロードを実行する – Part2

この記事は、“Create and manage Amazon EMR Clusters from SageMaker Studio to run interactive Spark and ML workloads – Part 2” を翻訳したものです。

本連載のPart 1 では、シングルアカウントで Amazon SageMaker Studio から Amazon EMR クラスタを作成、接続、停止、デバッグする方法をステップバイステップで説明しました。

この記事では、同じ機能をエンタープライズ規模にも対応するためにマルチアカウントセットアップで使用する方法について DiveDeep します。AWS Well-Architected Framework で説明されているように、アカウント間でワークロードを分離することで、環境を分離しながら共通のガードレールを設定することができます。これは、プロジェクトやチーム間のコストの管理を簡素化するだけでなく、特定のセキュリティ要件にも有用です。

ソリューションの概要

この記事では、以下のアーキテクチャを実現するためのプロセスを説明します。データワーカーには Part 1 で見たものと同じシンプルなインターフェースを提供し、必要のない場合はマルチアカウントの詳細を日々のワークフローから抽象化します。

まず、SageMaker Studio から Amazon EMR に接続するために、クロスアカウントネットワークを設定する方法を説明します。始めに、いくつかの前提条件が正しく設定されていることを確認する必要があります。この例では、DevOps 管理者は、プライベート VPC に Elastic Network Interface を持つ Amazon SageMaker ドメインを設定し、アタッチするセキュリティグループ ID を指定する必要があります。

ネットワークのセットアップ

SageMaker Studio のドメインを設定した後、アカウント間の通信を可能にするためにネットワークの設定を行う必要があります。

VPC ピアリング

まず、アカウント間の VPC ピアリングを行い、トラフィックのやり取りを容易にします。

  1. スタジオアカウントから、Amazon Virtual Private Cloud (Amazon VPC) コンソールで、Peering connectionsを選択します。Create peering connection を選択します。
  2. Amazon EMR アカウントの VPC 内に Studio VPC をピアリングするリクエストを作成します。

ピアリングリクエストを行った後、管理者は2番目のアカウントからこのリクエストを受け入れることができます。

プライベートサブネットをピアリングする場合、VPC ピアリング接続レベルでプライベート IP の DNS 解決を有効にする必要があります。

ルートテーブル

ピアリング接続を確立した後、両方のアカウントのプライベートサブネットのルートテーブルにルートを手動で追加して、トラフィックの流れを有効にする必要があります。これは、SageMaker Studio のアカウントからリモートアカウントのプライベートサブネットへの EMR クラスタの作成と接続を可能にするために行います。

これらのルートは、ピアリングされた VPC のプライベートサブネットの IP アドレス範囲を指し、サブネットページにあるRoute Tables タブで設定されます。ここで、各アカウントの管理者はルートを編集することができます。

次のSageMaker Studio 用のサブネットのルートテーブルは、SageMaker Studio アカウントからピアリング接続を介して 2.0.1.0/24 のトラフィックをアウトバウンドしていることを示しています。

Amazon EMR 用のサブネットの次のルートテーブルは、ピアリング接続を介して 10.0.20.0/24 のAmazon EMR アカウントからスタジオへのアウトバウンドトラフィックを示しています。

セキュリティグループ

最後に、SageMaker Studio のドメインに所属するセキュリティグループはアウトバウンドトラフィックを許可し、Amazon EMR プライマリノードのセキュリティグループはスタジオインスタンスのセキュリティグループからのインバウンド TCP トラフィックを許可する必要があります。

次のスクリーンショットは、SageMaker アカウントでのインバウンドルールの設定です。

次のスクリーンショットは、Amazon EMR アカウントのインバウンドルールの設定を示しています。

権限の設定

セカンダリの Amazon EMR アカウントに、Part 1 で見たものと同じ Amazon EMR の読み取り権限を持つ AWS Identity and Access Management（IAM）ロールを作成する必要があります。

次のコードは、IAM ロールの具体的なパーミッションを示しています。Part 1と同じですが、次のようなポリシーが含まれています。
AllowRoleAssumptionForCrossAccountDiscovery:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPresignedUrl",
            "Effect": "Allow",
            "Action": [
                "elasticmapreduce:DescribeCluster",
                "elasticmapreduce:ListInstanceGroups",
                "elasticmapreduce:CreatePersistentAppUI",
                "elasticmapreduce:DescribePersistentAppUI",
                "elasticmapreduce:GetPersistentAppUIPresignedURL",
                "elasticmapreduce:GetOnClusterAppUIPresignedURL"
            ],
            "Resource": [
                "arn:aws:elasticmapreduce:<region>:<account-id>:cluster/*"
            ]
        },
        {
            "Sid": "AllowClusterDetailsDiscovery",
            "Effect": "Allow",
            "Action": [
                "elasticmapreduce:DescribeCluster",
                "elasticmapreduce:ListInstanceGroups"
            ],
            "Resource": [
                "arn:aws:elasticmapreduce:<region>:<account-id>:cluster/*"
            ]
        },
        {
            "Sid": "AllowClusterDiscovery",
            "Effect": "Allow",
            "Action": [
                "elasticmapreduce:ListClusters"
            ],
            "Resource": "*"
        },
        { 
            "Sid": "AllowRoleAssumptionForCrossAccountDiscovery", 
            "Effect": "Allow", 
            "Action": "sts:AssumeRole", 
            "Resource": ["arn:aws:iam::<cross-account>:role/<studio-execution-role>" ]
        },
        {
            "Sid": "AllowEMRTemplateDiscovery",
            "Effect": "Allow",
            "Action": [
              "servicecatalog:SearchProducts"
            ],
            "Resource": "*"
        }
    ]
}

このassume が可能なロールには、SageMaker Studio アカウントとの信頼関係も必要です（アカウント ID を必ず修正してください）。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<account-id>:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

ユーザージャーニー

以下の図は、各種アカウントを接続した後の、統一的なノートブック体験を実現するためのユーザージャーニーを表しています。前回の記事と同様に、DevOps ペルソナはSageMaker Studio のアカウント内に AWS Service Catalog 製品とポートフォリオを作成し、それを基にデータワーカーはテンプレート化された EMR クラスタをプロビジョニングすることができます。

繰り返しになりますが、SageMaker Studio からデプロイ可能な AWS CloudFormation テンプレートを作成する際に、Amazon EMRのフルセットのプロパティを変更できることは重要なポイントです。これは、Service Catalog 製品を通じて、Spot、オートスケーリング、およびその他の一般的な構成を有効にできることを意味します。

エンドユーザーがワークロードに合わせてクラスタのさまざまな側面を変更できるように、EMR クラスタを作成するプリセット CloudFormation テンプレートにパラメータを設定することができます。たとえば、データサイエンティストやデータエンジニアは、クラスタのコアノード数を指定することができ、テンプレートの作成者は AllowedValues を指定してガードレールを設定することができます。

アカウントを跨いだ EMR クラスタの検出

アカウント間でクラスタ検出を可能にするには、以前に作成したリモート IAM ロールの ARN をSageMaker Studio 実行ロールに提供する必要があります。SageMaker Studio 実行ロールは、そのリモートロールを assume して、リモートアカウントの EMR クラスタを発見し、接続します。このassume が可能なクロスアカウントロールのARNは、起動時に SageMaker Studio のJupyter サーバーによって読み込まれ、クロスアカウントクラスタの検出に使用するロールが決定されます。これらのユーザー固有のARNを設定および変更するには、管理者はカーネルゲートウェイアプリではなく Jupyter サーバーに関連付けられたライフサイクル設定（ Lifecycle Configuration：LCC）を作成し、各ユーザーの Amazon Elastic File System（Amazon EFS）ホームディレクトリにロール ARN を書き込むことができます。この LCC は、ユーザーのセット全体に適用することもできますし、想定されるロールを通じてどのクラスタにアクセスできるかを細かく設定できるように、個人に固有のものにすることもできます。

Jupyter サーバの起動時には、設定ファイルに記述された ARN ロールを読み込む前に、ライフサイクル設定が実行されます。これにより、管理者は実行時にどのクロスアカウント ARN が使用されるかを上書きし、完全に制御することができます。LCC が実行され、ファイルが書き込まれた後、サーバーは、ファイル

/home/SageMaker-user/.cross-account-configuration-DO_NOT_DELETE/emr-discovery-iam-role-arns-DO_NOT_DELETE.json
を作成し、そのクロスアカウント ARN を保存します。以下は、LCC bash スクリプトの一例です。

# This script creates the file that informs SageMaker Studio that the role "arn:aws:iam::123456789012:role/ASSUMABLE-ROLE" in remote account "123456789012" must be assumed to list and describe EMR clusters in the remote account.

#!/bin/bash

set -eux

FILE_DIRECTORY="/home/sagemaker-user/.cross-account-configuration-DO_NOT_DELETE"
FILE_NAME="emr-discovery-iam-role-arns-DO_NOT_DELETE.json"
FILE="$FILE_DIRECTORY/$FILE_NAME"

mkdir -p $FILE_DIRECTORY

cat > "$FILE" <<- "EOF"
{
  "123456789012": "arn:aws:iam::123456789012:role/ASSUMABLE-ROLE"
}
EOF

この時点で、ユーザーが自分のアカウントにログインし、このファイルを修正することはできますが、管理者の ARN 指定には何の影響もありません。これは、この時点ですでに値が保存されており、Jupyter サーバーアプリが起動するたびに LCC が実行されるため、サーバーの再起動時にファイルが上書きされるからです。

この設定プロセスは、スタジオ内でクラスタを発見し接続するデータワーカーから完全に抽象化することができます。クロスアカウントクラスタで唯一明らかな違いは、browsing タブに、クラスタが収容されているアカウント ID の列があることです。

アカウントを跨いだ EMR クラスタの使用

クロスアカウントの可視性を確立した後は、クラスタの作成と停止のプロセスは Part 1 と同じです。クロスアカウントの CloudFormation スタックの例については、GitHub リポジトリを参照してください。

Service Catalog 製品をデプロイした後、エンドユーザーがクラスタをスピンアップするプロセスは変わりません。Clusters ページに移動し、Create cluster を選択するだけです。

クラスタ作成後、Studio Notebooks の Clusters グラフィカルインターフェイスを使用して、クラスタに接続します。これにより、自動入力されたマジックセルが作成され、単一アカウントの場合とほぼ同様に表示されますが、想定されるクロスアカウントの役割のパラメータが追加されています。

接続が完了したら、これまでと同じようにデモを進めていきます。GitHub のサンプルリポジトリをクローンして、Part 1 と同様に notebook のサンプルを実行することができます。

結論

本連載の最後となる Part 2 では、クロスアカウント設定において、SageMaker Studio ユーザーが EMR クラスタを作成、接続、デバッグ、停止する方法について紹介しました。ネットワークと権限を設定した後は、Part 1 で見たのと同じようにエンドユーザが使用できます。この SageMaker Studio の新機能を、マルチアカウントワークロードでぜひご活用ください。

翻訳はソリューションアーキテクト 深見 修平 が担当しました。原文はこちらです。