カスタム AMI を使用して Amazon EMR クラスター設定の柔軟性を高める
Amazon EMR 5.7.0 以降を使用する場合は、Amazon EMR 用のデフォルトの Amazon Linux AMI ではなく、カスタム Amazon Linux AMI を指定できます。カスタム AMI は、以下を実行する場合に役立ちます。
-
ブートストラップアクションを使用する代わりにアプリケーションを事前インストールして他のカスタマイズを行う。これにより、クラスターの起動時間を短縮し、スタートアップのワークフローを合理化できます。詳細と例については、「事前設定したインスタンスからのカスタム Amazon Linux AMI の作成」を参照してください。
-
ブートストラップアクションが許可する以上の高度なクラスターおよびノード設定を実装する。
-
5.24.0 より低い Amazon EMR バージョンを使用している場合、クラスターの EC2 インスタンスの EBS ルートデバイスボリューム (ブートボリューム) を暗号化します。デフォルトの AMI と同様に、カスタム AMI の最小ルートボリュームサイズは、Amazon EMR リリース 6.9 以前で 10 GiB、Amazon EMR リリース 6.10 以降で 15 GiB です。詳細については、「暗号化された Amazon EBS ルートデバイスボリュームを使用したカスタム AMI の作成」を参照してください。
注記
Amazon EMR バージョン 5.24.0 から、AWS KMS をキープロバイダーとして指定している場合、セキュリティ設定オプションを使用して EBS ルートデバイスとストレージボリュームを暗号化できます。詳細については、「ローカルディスク暗号化」を参照してください。
カスタム AMI が存在する AWS リージョンとクラスターを作成するリージョンは同じであることが必要です。EC2 インスタンスアーキテクチャにも一致する必要があります。例えば、m5.xlarge インスタンスには x86_64 アーキテクチャがあります。したがって、カスタム AMI を使用して m5.xlarge をプロビジョニングするには、カスタム AMI にも x86_64 アーキテクチャが必要です。同様に、arm64 アーキテクチャを持つ m6g.xlarge インスタンスをプロビジョニングするには、カスタム AMI に arm64 アーキテクチャが必要です。ご利用のインスタンスタイプに適した Linux AMI の特定の詳細については、「Amazon EC2 ユーザーガイド」の「AMI の検索」を参照してください。
重要
Amazon Linux または Amazon Linux 2 Amazon マシンイメージ (AMI) を実行する EMR クラスターは、デフォルトの Amazon Linux 動作を使用します。再起動が必要な重要かつクリティカルなカーネル更新が自動的にダウンロードされてインストールされることはありません。これは、デフォルトの Amazon Linux AMI を実行している他の Amazon EC2 インスタンスと同じ動作です。Amazon EMR リリースが利用可能になった後に、再起動が必要な新しい Amazon Linux ソフトウェアアップデート (カーネル、NVIDIA、CUDA のアップデートなど) が使用可能になった場合、デフォルトの AMI を実行する EMR クラスターインスタンスで、それらの更新が自動的にダウンロードされてインストールされることはありません。カーネルの更新を取得するには、Amazon EMR AMI をカスタマイズして、最新の Amazon Linux AMI を使用できるようにします。
事前設定したインスタンスからのカスタム Amazon Linux AMI の作成
Amazon EMR のカスタム Amazon Linux AMI を作成するためにソフトウェアを事前インストールして他の設定を行う基本的な手順は、次のとおりです。
-
ベース Amazon Linux AMI からインスタンスを起動します。
-
インスタンスに接続してソフトウェアをインストールし、他のカスタマイズを行います。
-
設定したインスタンスの新しいイメージ (AMI スナップショット) を作成します。
カスタマイズ済みのインスタンスに基づいてイメージを作成したら、そのイメージを暗号化されたターゲットにコピーできます (「暗号化された Amazon EBS ルートデバイスボリュームを使用したカスタム AMI の作成」を参照)。
チュートリアル: カスタムソフトウェアがインストールされたインスタンスから AMI を作成する
最新の Amazon Linux AMI に基づいて EC2 インスタンスを起動するには
-
AWS CLI を使用して次のコマンドを実行し、既存の AMI からインスタンスを作成します。
をインスタンス接続時に使用したキーペアおよび適切な Amazon Linux AMI の ID のMyKeyName
MyAmiId
で置き換えます。最新の AMI ID に関しては、Amazon Linux AMIを参照してください。 注記
読みやすくするために、Linux 行連続文字 (\) が含まれています。Linux コマンドでは、これらは削除することも、使用することもできます。Windows の場合、削除するか、キャレット (^) に置き換えてください。
aws ec2 run-instances --image-id
MyAmiID
\ --count 1 --instance-typem5.xlarge
\ --key-nameMyKeyName
--regionus-west-2
InstanceId
出力値は、次のステップで
として使用します。MyInstanceId
-
次のコマンドを実行します。
aws ec2 describe-instances --instance-ids
MyInstanceId
PublicDnsName
出力値は、次のステップでインスタンスに接続するために使用します。
インスタンスに接続してソフトウェアをインストールするには
-
SSH 接続を使用して Linux インスタンスでシェルコマンドを実行します。詳細については、「Amazon EC2 ユーザーガイド」の「SSH クライアントを使用して Linux インスタンスに接続する」を参照してください。
-
必要なカスタマイズを行います。例:
sudo yum install
MySoftwarePackage
sudo pip installMySoftwarePackage
カスタマイズしたイメージからスナップショットを作成するには
-
インスタンスをカスタマイズしたら、
create-image
コマンドを使用してインスタンスから AMI を作成します。aws ec2 create-image --no-dry-run --instance-id
MyInstanceId
--nameMyEmrCustomAmi
imageID
出力値は、クラスターの起動時または暗号化されたスナップショットの作成時に使用します。詳細については、EMR クラスターで単一のカスタム AMI を使用するおよび暗号化された Amazon EBS ルートデバイスボリュームを使用したカスタム AMI の作成を参照してください。
Amazon EMR クラスターでカスタム AMI を使用する方法
カスタム AMI を使用して Amazon EMR クラスターをプロビジョニングするには、次の 2 つの方法があります。
-
クラスターのすべての EC2 インスタンスに対して 1 つのカスタム AMI を使用する。
-
クラスターで使用されるさまざまな EC2 インスタンスタイプに異なるカスタム AMI を使用する。
EMR クラスターのプロビジョニングには、2 つのオプションのうち 1 つしか使用できず、クラスターの起動後に変更することはできません。
考慮事項 | 単一のカスタム AMI | 複数のカスタム AMI |
---|---|---|
同じクラスターの複数のカスタム AMI で x86 プロセッサと Graviton2 プロセッサの両方を使用する |
|
|
AMI カスタマイズがインスタンスタイプによって異なる |
|
|
実行中のクラスターに新しいタスクインスタンスグループ/フリートを追加するときに、カスタム AMI を変更する 注意: 既存のインスタンスグループ/フリートのカスタム AMI を変更することはできません。 |
|
|
AWS コンソールを使用してクラスターを起動する |
|
|
AWS CloudFormation を使用してクラスターを起動する |
|
|
EMR クラスターで単一のカスタム AMI を使用する
クラスターの作成時にカスタム AMI ID を指定するには、次のいずれかを使用します。
-
AWS Management Console
-
AWS CLI
-
Amazon EMR SDK
-
Amazon EMR API RunJobFlow
-
AWS CloudFormation(Cluster InstanceGroupConfig、Cluster InstanceTypeConfig、Resource InstanceGroupConfig、または Resource InstanceFleetConfig-InstanceTypeConfig の
CustomAmiID
プロパティを参照してください)
Amazon EMR クラスターで複数のカスタム AMI を使用する
複数のカスタム AMI を使用してクラスターを作成するには、次のいずれかを使用します。
-
AWS CLI バージョン 1.20.21 以降
-
AWS SDK
-
「Amazon EMR API リファレンス」の Amazon EMR RunJobFlow
-
AWS CloudFormation(Cluster InstanceGroupConfig、Cluster InstanceTypeConfig、Resource InstanceGroupConfig、または Resource InstanceFleetConfig-InstanceTypeConfig の
CustomAmiID
プロパティを参照してください)
AWS マネジメントコンソールでは、現在、複数のカスタム AMI を使用したクラスターの作成をサポートしていません。
例 - AWS CLI を使用して、複数のカスタム AMI を使用するインスタンスグループクラスターを作成する
AWS CLI バージョン 1.20.21 以降を使用して、クラスター全体に単一のカスタム AMI を割り当てたり、クラスター内のすべてのインスタンスノードに複数のカスタム AMI を割り当てたりすることができます。
次の例は、各ノードタイプ (プライマリ、コア、タスク) にわたって 2 つのインスタンスタイプ (m5.xlarge) を使用して作成された均一インスタンスグループクラスターを示します。各ノードには複数のカスタム AMI があります。この例は、複数のカスタム AMI 設定のいくつかの機能を示しています。
-
クラスターレベルで割り当てられているカスタム AMI はありません。これは、クラスターの起動が失敗する原因となる、複数のカスタム AMI と単一のカスタム AMI の間の競合を回避するためです。
-
クラスターは、プライマリ、コア、および個々のタスクノードにまたがる複数のカスタム AMI を持つことができます。これにより、プリインストールされたアプリケーション、高度なクラスター設定、暗号化された Amazon EBS ルートデバイスボリュームなど、個々の AMI のカスタマイズが可能になります。
-
インスタンスグループコアノードは、1 つのインスタンスタイプと、対応するカスタム AMI のみを持つことができます。同様に、プライマリノードは、1 つのインスタンスタイプと、対応するカスタム AMI のみを持つことができます。
-
クラスターは、複数のタスクノードを持つことができます。
aws emr create-cluster --instance-groups InstanceGroupType=PRIMARY,InstanceType=
m5.xlarge
,InstanceCount=1
,CustomAmiId=ami-123456
InstanceGroupType=CORE,InstanceType=m5.xlarge
,InstanceCount=1
,CustomAmiId=ami-234567
InstanceGroupType=TASK,InstanceType=m6g.xlarge
,InstanceCount=1
,CustomAmiId=ami-345678
InstanceGroupType=TASK,InstanceType=m5.xlarge
,InstanceCount=1
,CustomAmiId=ami-456789
例 - AWS CLI バージョン 1.20.21 以降を使用して、複数のインスタンスタイプと複数のカスタム AMI を持つ実行中のインスタンスグループクラスターにタスクノードを追加する
AWS CLI バージョン 1.20.21 以降を使用して、実行中のクラスターに追加するインスタンスグループに複数のカスタム AMI を追加できます。次の例に示すように、CustomAmiId
引数を add-instance-groups
コマンドとともに使用できます。複数のノードで同じ複数のカスタム AMI ID (ami-123456) が使用されていることに注意してください。
aws emr create-cluster --instance-groups InstanceGroupType=PRIMARY,InstanceType=m5.xlarge,InstanceCount=1,CustomAmiId=ami-123456 InstanceGroupType=CORE,InstanceType=m5.xlarge,InstanceCount=1,CustomAmiId=ami-123456 InstanceGroupType=TASK,InstanceType=m5.xlarge,InstanceCount=1,CustomAmiId=ami-234567 { "ClusterId": "j-123456", ... } aws emr add-instance-groups --cluster-id j-123456 --instance-groups InstanceGroupType=Task,InstanceType=m6g.xlarge,InstanceCount=1,CustomAmiId=ami-345678
例 - AWS CLI バージョン 1.20.21 以降を使用して、インスタンスフリートクラスター、複数のカスタム AMI、複数のインスタンスタイプ、オンデマンドプライマリ、オンデマンドコア、複数のコアおよびタスクノードを作成する
aws emr create-cluster --instance-fleets InstanceFleetType=PRIMARY,TargetOnDemandCapacity=1,InstanceTypeConfigs=['{InstanceType=m5.xlarge, CustomAmiId=ami-123456}'] InstanceFleetType=CORE,TargetOnDemandCapacity=1,InstanceTypeConfigs=['{InstanceType=m5.xlarge,CustomAmiId=ami-234567},{InstanceType=m6g.xlarge, CustomAmiId=ami-345678}'] InstanceFleetType=TASK,TargetSpotCapacity=1,InstanceTypeConfigs=['{InstanceType=m5.xlarge,CustomAmiId=ami-456789},{InstanceType=m6g.xlarge, CustomAmiId=ami-567890}']
例 - AWS CLI バージョン 1.20.21 以降を使用して、複数のインスタンスタイプと複数のカスタム AMI を持つ実行中のクラスターにタスクノードを追加する
aws emr create-cluster --instance-fleets InstanceFleetType=PRIMARY,TargetOnDemandCapacity=1,InstanceTypeConfigs=['{InstanceType=m5.xlarge, CustomAmiId=ami-123456}'] InstanceFleetType=CORE,TargetOnDemandCapacity=1,InstanceTypeConfigs=['{InstanceType=m5.xlarge,CustomAmiId=ami-234567},{InstanceType=m6g.xlarge, CustomAmiId=ami-345678}'] { "ClusterId": "j-123456", ... } aws emr add-instance-fleet --cluster-id j-123456 --instance-fleet InstanceFleetType=TASK,TargetSpotCapacity=1,InstanceTypeConfigs=['{InstanceType=m5.xlarge,CustomAmiId=ami-234567},{InstanceType=m6g.xlarge, CustomAmiId=ami-345678}']
AMI パッケージリポジトリの更新の管理
デフォルトでは、Amazon Linux AMI は最初の起動時にパッケージリポジトリに接続し、他のサービスが起動する前にセキュリティ更新をインストールします。Amazon EMR のカスタム AMI の指定時に、必要に応じて、これらの更新を無効にすることを選択できます。この機能を無効にするオプションは、カスタム AMI を使用する場合にのみ使用できます。デフォルトでは、Amazon Linux カーネル更新および再起動を必要とするその他のソフトウェアパッケージは更新されません。ネットワーク設定では、Simple Storage Service (Amazon S3) の Amazon Linux リポジトリへの HTTP および HTTPS の出力が許可されている必要があります。そうしないと、セキュリティ更新は成功しません。
警告
カスタム AMI を指定するときに、すべてのインストールされているパッケージを再起動時に更新することを選択するようお勧めします。パッケージを更新しないことを選択すると、他のセキュリティリスクが生じます。
AWS Management Consoleでは、[カスタム AMI] を選択するときに更新を無効にするオプションを選択できます。
AWS CLI では、create-cluster コマンドを使用するときに --repo-upgrade-on-boot NONE
を --custom-ami-id
と共に指定できます。
Amazon EMR API を使用して、RepoUpgradeOnBoot パラメータに NONE
を指定できます。
暗号化された Amazon EBS ルートデバイスボリュームを使用したカスタム AMI の作成
Amazon EMR で Amazon Linux AMI の Amazon EBS ルートデバイスボリュームを暗号化するには、暗号化されていない AMI から暗号化されたターゲットにスナップショットイメージをコピーします。暗号化された EBS ボリュームの作成の詳細については、「Amazon EC2 ユーザーガイド」の 「Amazon EBS 暗号化」を参照してください。スナップショットのソース AMI としてベース Amazon Linux AMI を使用できます。または、カスタマイズしたベース Amazon Linux AMI から派生した AMI からスナップショットをコピーできます。
注記
Amazon EMR バージョン 5.24.0 から、AWS KMS をキープロバイダーとして指定している場合、セキュリティ設定オプションを使用して EBS ルートデバイスとストレージボリュームを暗号化できます。詳細については、「ローカルディスク暗号化」を参照してください。
EBS ルートボリュームの暗号化には、外部キープロバイダーまたは AWS KMS キーを使用できます。Amazon EMR で使用するサービスロール (通常はデフォルトの EMR_DefaultRole
) に対しては、Amazon EMR で AMI を使用してクラスターを作成するために、少なくともボリュームの暗号化と復号を許可する必要があります。AWS KMS をキープロバイダーとして使用する場合、以下のアクションを許可する必要があります。
-
kms:encrypt
-
kms:decrypt
-
kms:ReEncrypt*
-
kms:CreateGrant
-
kms:GenerateDataKeyWithoutPlaintext"
-
kms:DescribeKey"
これを行う最も簡単な方法としては、次のチュートリアルで説明するように、キーユーザーとしてロールを追加します。以下のポリシーステートメントの例は、ロールのポリシーをカスタマイズする必要がある場合に使用してください。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "EmrDiskEncryptionPolicy", "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:CreateGrant", "kms:GenerateDataKeyWithoutPlaintext", "kms:DescribeKey" ], "Resource": [ "*" ] } ] }
チュートリアル: KMS キーを使用した、暗号化されたルートデバイスボリュームを持つカスタム AMI の作成
この例の最初のステップでは、KMS キーの ARN を検索するか、新規作成します。キーの作成の詳細については、「AWS Key Management Service デベロッパーガイド」の「キーの作成」を参照してください。次の手順では、デフォルトのサービスロール EMR_DefaultRole
をキーユーザーとしてキーポリシーに追加する方法を示します。作成または編集するキーの ARN 値を書き留めます。AMI を作成するときに、より高い ARN を使用します。
コンソールを使用して Amazon EC2 のサービスロールを暗号化キーユーザーのリストに追加するには
-
AWS Management Console にサインインし、AWS Key Management Service (AWS KMS) コンソール (https://console.aws.amazon.com/kms
) を開きます。 -
AWS リージョン を変更するには、ページの右上隅にあるリージョンセレクターを使用します。
-
使用する KMS キーのエイリアスを選択します。
-
[Key Users] のキーの詳細ページで、[Add] を選択します。
-
[アタッチ] ダイアログボックスで Amazon EMR サービスロールを選択します。デフォルトロールの名前は
EMR_DefaultRole
です。 -
添付を選択します。
AWS CLI を使用して暗号化された AMI を作成するには
-
AWS CLI の
aws ec2 copy-image
コマンドを使用して暗号化された EBS ルートデバイスボリュームとユーザーが変更したキーを持つ AMI を作成します。指定された--kms-key-id
値を、ユーザーが作成またはより低く変更したキーの完全な ARN に置き換えます。注記
読みやすくするために、Linux 行連続文字 (\) が含まれています。Linux コマンドでは、これらは削除することも、使用することもできます。Windows の場合、削除するか、キャレット (^) に置き換えてください。
aws ec2 copy-image --source-image-id
MyAmiId
\ --source-regionus-west-2
--nameMyEncryptedEMRAmi
\ --encrypted --kms-key-idarn:aws:kms:us-west-2:12345678910:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
コマンドの出力として、作成した AMI の ID が提供されます。この ID をクラスターの作成時に指定できます。詳細については、「EMR クラスターで単一のカスタム AMI を使用する」を参照してください。また、ソフトウェアをインストールし、他の設定を行うことにより、この AMI をカスタマイズすることもできます。詳細については、「事前設定したインスタンスからのカスタム Amazon Linux AMI の作成」を参照してください。
ベストプラクティスと考慮事項
Amazon EMR のカスタム AMI を作成する場合は、以下の点を考慮してください。
-
Amazon EMR 7.x シリーズは、Amazon Linux 2023 に基づいています。これらの Amazon EMR バージョンでカスタム AMI を作成する場合は、Amazon Linux 2023 に基づくイメージを使用する必要があります。基本カスタム AMI を見つけるには、「Linux AMI の検索」を参照してください。
-
7.x より低い Amazon EMR バージョンでは、Amazon Linux 2023 AMI はサポートされません。
-
Amazon EMR 5.30.0 以降、および Amazon EMR 6.x シリーズは、Amazon Linux 2 に基づいています。これらの Amazon EMR バージョンでカスタム AMI を作成する場合は、Amazon Linux 2 に基づくイメージを使用する必要があります。基本カスタム AMI を見つけるには、「Linux AMI の検索」を参照してください。
-
5.30.0 および 6.x より低い Amazon EMR バージョンでは、Amazon Linux 2 AMI はサポートされません。
-
64 ビットの Amazon Linux AMI を使用する必要があります。32 ビット AMI はサポートされていません。
-
複数の Amazon EBS ボリュームを持つ Amazon Linux AMI はサポートされていません。
-
最新の EBS-backed Amazon Linux AMI
に基づいてカスタマイズします。Amazon Linux AMI および対応する AMI ID のリストについては、Amazon Linux AMI を参照してください。 -
カスタム AMI を作成する際に、既存の Amazon EMR インスタンスのスナップショットをコピーしないでください。これを行うと、エラーになります。
-
Amazon EMR と互換性がある HVM 仮想化タイプおよびインスタンスのみがサポートされます。必ず Amazon EMR と互換性がある HVM イメージおよびインスタンスタイプを選択して、AMI のカスタマイズプロセスを進めてください。互換性のあるインスタンスおよび仮想化タイプについては、「Amazon EMR でサポートされているインスタンスタイプ」を参照してください。
-
サービスロールには AMI での起動許可が必要であるため、AMI はパブリックであるか、ユーザーが AMI の所有者であるか、AMI を所有者と共有している必要があります。
-
AMI で作成するユーザーをアプリケーションと同じ名前 (
hadoop
、hdfs
、yarn
、spark
など) にすると、エラーが発生します。 -
/tmp
、/var
、および/emr
のコンテンツ (AMI に存在する場合) は起動時にそれぞれ/mnt/tmp
、/mnt/var
、および/mnt/emr
に移動されます。ファイルは保持されますが、大量のデータがあると、スタートアップに予想以上の時間がかかる場合があります。 作成日が 2018-08-11 の Amazon Linux AMI に基づくカスタム Amazon Linux AMI を使用すると、Oozie サーバーの起動に失敗します。Oozie を使用する場合は、作成日が異なる Amazon Linux AMI ID に基づいてカスタム AMI を作成します。次の AWS CLI コマンドを使用して、2018.03 バージョンのすべての HVM Amazon Linux AMI のイメージ ID とリリース日のリストを返し、ベースとして適切な Amazon Linux AMI を選択できます。MyRegion はリージョン ID (us-west-2 など) に置き換えます。
aws ec2 --region
MyRegion
describe-images --owner amazon --query 'Images[?Name!=`null`]|[?starts_with(Name, `amzn-ami-hvm-2018.03`) == `true`].[CreationDate,ImageId,Name]' --output text | sort -rk1-
非標準ドメイン名と AmazonProvidedDNS を持つ VPC を使用する場合は、オペレーティングシステムの DNS 設定 で
rotate
オプションを使用しないでください。
詳細については、「Amazon EC2 ユーザーガイド」の「Amazon EBS-backed Linux AMI を作成する」を参照してください。