翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # アプリケーションの設定 アプリケーションのデフォルトの設定を上書きするために、設定オブジェクトを指定できます。短縮構文を使用して設定を指定するか、JSON ファイルの設定オブジェクトを参照することができます。設定オブジェクトは、分類、プロパティ、オプションの入れ子になっている設定で構成されます。プロパティは、変更するアプリケーション設定に対応します。単一の JSON オブジェクトで、複数のアプリケーションに複数の分類を指定できます。 **警告** Amazon EMR の Describe API オペレーションと List API オペレーションにより、Amazon EMR ジョブフローの一部として使用するカスタム設定と構成可能な設定がプレーンテキストで出力されます。こうした設定でパスワードなどの機密情報を指定する方法については、「 AWS Secrets Manager」の「[機密の設定データを保存する](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/storing-sensitive-data.html)」を参照してください。 Amazon EMR リリースバージョンによって使用可能な設定分類は異なります。特定のリリースバージョンでサポートされている設定分類のリストについては、「[Amazon EMR リリースについて](emr-release-components.md)」にあるそのリリースバージョンのページを参照してください。 設定の一覧の JSON ファイル例を次に示します。 ``` [ { "Classification": "core-site", "Properties": { "hadoop.security.groups.cache.secs": "250" } }, { "Classification": "mapred-site", "Properties": { "mapred.tasktracker.map.tasks.maximum": "2", "mapreduce.map.sort.spill.percent": "0.90", "mapreduce.tasktracker.reduce.tasks.maximum": "5" } } ] ``` 設定分類は、多くの場合アプリケーション固有の設定ファイルにマップします。たとえば、`hive-site` 分類は Hive の `hive-site.xml` 設定ファイルの設定にマッピングされます。この例外には、`--namenode-heap-size` のような環境パラメータの設定に使用される、サポートされなくなったブートストラップアクション `configure-daemons` があります。このようなオプションはそれ自身の下位エクスポート分類とともに、`hadoop-env` および `yarn-env` 分類の中に入れ子になっています。`env` で終わる分類には、下位エクスポート分類を使用してください。 もう 1 つの例外として `s3get` があり、これはクライアント側の暗号化で使用するために、クラスター内の各ノードに顧客の `EncryptionMaterialsProvider` オブジェクトを配置するのに使用されます。この用途には、`emrfs-site` 分類にオプションが追加されています。 `hadoop-env` 分類の例を次に示します。 ``` [ { "Classification": "hadoop-env", "Properties": { }, "Configurations": [ { "Classification": "export", "Properties": { "HADOOP_DATANODE_HEAPSIZE": "2048", "HADOOP_NAMENODE_OPTS": "-XX:GCTimeRatio=19" }, "Configurations": [ ] } ] } ] ``` yarn-env 分類の例を次に示します。 ``` [ { "Classification": "yarn-env", "Properties": { }, "Configurations": [ { "Classification": "export", "Properties": { "YARN_RESOURCEMANAGER_OPTS": "-Xdebug -Xrunjdwp:transport=dt_socket" }, "Configurations": [ ] } ] } ] ``` 次の設定は設定ファイルに属しませんが、ユーザーに代わって複数の設定を構成できるようにするために Amazon EMR が使用します。 **Amazon EMR-によって選別された設定** | アプリケーション | リリースラベルの分類 | 有効なプロパティ | どのようなときに使うか | | --- | --- | --- | --- | | Spark | spark | maximizeResourceAllocation | 各ノードの最大リソースを利用するようにエグゼキューターを設定します。 | **Topics** + [クラスターの作成時のアプリケーションの設定](emr-configure-apps-create-cluster.md) + [実行中のクラスター内のインスタンスグループの再設定](emr-configure-apps-running-cluster.md) + [に機密設定データを保存する AWS Secrets Manager](storing-sensitive-data.md) + [特定の Java 仮想マシンを使用するようにアプリケーションを設定](configuring-java8.md) # クラスターの作成時のアプリケーションの設定 クラスターを作成するときは、Amazon EMR コンソール、 AWS Command Line Interface (AWS CLI)、または AWS SDK を使用して、アプリケーションのデフォルト設定を上書きできます。 アプリケーションのデフォルト設定をオーバーライドするには、設定分類でカスタム値を指定します。設定分類は、アプリケーションを設定する XML ファイル (`hive-site.xml` など) に対応しています。 設定分類は、Amazon EMR のリリースバージョンによって異なります。特定のリリースバージョンで利用可能な設定分類のリストについては、「[Amazon EMR リリース 6.4.0](emr-640-release.md#emr-640-class)」などのリリース詳細ページを参照してください。 ## クラスター作成時にコンソールで設定を指定する 設定を指定するには、**[クラスターの作成]** ページに移動して **[ソフトウェア設定]** を展開します。コンソールで JSON またはシャドウテキストに倣った短縮構文を使用して、設定を直接入力できます。それ以外の方法として、JSON の `Configurations` オブジェクトとしてファイルの Amazon S3 URI を指定することもできます。 インスタンスグループの設定を指定するには、クラスターのリストでクラスターを選択し、**[設定]** タブを選択します。**[インスタンスグループの設定]** テーブルで、編集するインスタンスグループを選択し、**[再設定]** を選択します。 ## クラスターの作成 AWS CLI 時に を使用して設定を指定する ローカルまたは Amazon S3 に保存された JSON ファイルのパスを指定することで、**create-cluster** に対して設定を指定できます。次の例は、Amazon EMR にデフォルトのロールを使用していて、そのロールが作成されていることを前提としています。ロールを作成する必要がある場合は、最初に `aws emr create-default-roles` を実行します。 設定がローカルディレクトリにある場合は、次のコマンド例を使用できます。 ``` aws emr create-cluster --use-default-roles --release-label emr-7.12.0 --applications Name=Hive \ --instance-type m5.xlarge --instance-count 3 --configurations file://./configurations.json ``` 設定が Amazon S3 パスに含まれている場合は、次の次善策を設定した後に、Amazon S3 `create-cluster` パスをコマンドに渡す必要があります。 ``` #!/bin/sh # Assume the ConfigurationS3Path is not public, and its present in the same AWS account as the EMR cluster ConfigurationS3Path="s3://amzn-s3-demo-bucket/config.json" # Get a presigned HTTP URL for the s3Path ConfigurationURL=`aws s3 presign $ConfigurationS3Path --expires-in 300` # Fetch the presigned URL, and minify the JSON so that it spans only a single line Configurations=`curl $ConfigurationURL | jq -c .` aws emr create-cluster --use-default-roles --release-label emr-5.34.0 --instance-type m5.xlarge --instance-count 2 --applications Name=Hadoop Name=Spark --configurations $Configurations ``` ## クラスター作成時に Java SDK を使用して設定を指定する AWS SDK for Javaを使用して設定を指定する方法を次のプログラム抜粋に示します。 ``` Application hive = new Application().withName("Hive"); Map hiveProperties = new HashMap(); hiveProperties.put("hive.join.emit.interval","1000"); hiveProperties.put("hive.merge.mapfiles","true"); Configuration myHiveConfig = new Configuration() .withClassification("hive-site") .withProperties(hiveProperties); RunJobFlowRequest request = new RunJobFlowRequest() .withName("Create cluster with ReleaseLabel") .withReleaseLabel("emr-5.20.0") .withApplications(hive) .withConfigurations(myHiveConfig) .withServiceRole("EMR_DefaultRole") .withJobFlowRole("EMR_EC2_DefaultRole") .withInstances(new JobFlowInstancesConfig() .withEc2KeyName("myEc2Key") .withInstanceCount(3) .withKeepJobFlowAliveWhenNoSteps(true) .withMasterInstanceType("m4.large") .withSlaveInstanceType("m4.large") ); ``` # 実行中のクラスター内のインスタンスグループの再設定 Amazon EMR バージョン 5.21.0 以降では、実行中のクラスター内のインスタンスグループごとに、クラスターアプリケーションを再設定して追加の設定分類を指定できます。そのためには、Amazon EMR コンソール、 AWS Command Line Interface (AWS CLI)、または SDK AWS を使用できます。 新しい Amazon EMR コンソールでインスタンスグループのアプリケーション設定を更新すると、新規設定と既存の設定がマージされ、有効な新規設定が作成されます。Amazon EMR が設定をマージできないという稀なケースでは、コンソールに警告が表示されます。 インスタンスグループの再設定リクエストを送信すると、Amazon EMR が新しい設定仕様にバージョン番号を割り当てます。CloudWatch イベントを表示することで、設定のバージョン番号やインスタンスグループの状態を追跡できます。詳細については、「[CloudWatch イベントのモニタリング](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-cloudwatch-events.html)」を参照してください。 **注記** クラスターの作成時に指定したクラスター設定に対して実行できるのは上書きのみであり、削除はできません。既存の設定と指定したファイルに差異がある場合、Amazon EMR は SSH を使用してクラスターに接続中に変更した設定などの手動で変更された設定を、指定したインスタンスグループのクラスターのデフォルト値にリセットします。 ## インスタンスグループの再設定時の考慮事項 **再設定アクション** Amazon EMR コンソール、 AWS Command Line Interface (AWS CLI)、または AWS SDK を使用して再設定リクエストを送信すると、Amazon EMR は既存のクラスター上の設定ファイルをチェックします。既存の設定と指定したファイルに差異がある場合、Amazon EMR は再設定アクションを開始し、いくつかのアプリケーションを再起動し、SSH を使用してクラスターに接続中に変更した設定などの手動で変更された設定を、指定したインスタンスグループのクラスターのデフォルト値にリセットします。 Amazon EMR は、インスタンスグループの再設定ごとに、デフォルトのアクションをいくつか実行します。これらのデフォルトのアクションが、ユーザーが行ったクラスターのカスタマイズと競合して、再設定に失敗することがあります。再設定失敗のトラブルシューティング方法については、[インスタンスグループの再設定のトラブルシューティング](#emr-configure-apps-running-cluster-troubleshoot)を参照してください。 Amazon EMR は、リクエストで指定した設定分類に対する再設定アクションも開始します。これらのアクションの詳細なリストについては、使用している Amazon EMR のバージョンの「設定分類」セクションを参照してください。例えば、[6.2.0 の設定分類](emr-620-release.md#emr-620-class)です。 Amazon EMR リリースガイドには、Amazon EMR バージョン 5.32.0 および 6.2.0 以降の再設定アクションのみが記載されています。 **サービスの中断** Amazon EMR では、ローリングプロセスに従って、タスクインスタンスグループとコアインスタンスグループのインスタンスの再設定を行います。インスタンスグループ内のインスタンスのうち、一度に変更および再起動されるのはわずか 10% です。このプロセスは完了するまでに時間がかかりますが、実行中のクラスターでアプリケーションが失敗する可能性は低くなります。 YARN の再起動中に YARN ジョブを実行するには、複数のマスターノードを持つ Amazon EMR クラスターを作成するか、`yarn-site` 設定分類で `yarn.resourcemanager.recovery.enabled` を `true` に設定します。複数のマスターノードの使用方法については、[高可用性 YARN ResourceManager](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-applications.html#emr-plan-ha-applications-YARN) を参照してください。 **アプリケーションの検証** Amazon EMR は、再設定の再起動プロセスの後に、クラスター上の各アプリケーションが実行中であることを確認します。使用できないアプリケーションがある場合、再設定操作全体が失敗します。再設定操作に失敗した場合、Amazon EMR は、設定パラメータを前に機能していたバージョンに戻します。 再設定の失敗を回避するため、クラスターに使用する予定のアプリケーションのみをインストールすることをお勧めします。再設定リクエストを送信する前に、すべてのクラスターアプリケーションが正常に稼働していることを確認することもお勧めします。 **再設定のタイプ** インスタンスグループは、2 つの方法のいずれかで再設定できます。 + **上書き**: デフォルトの再設定方法です。5.35.0 および 6.6.0 より前の Amazon EMR リリースでは、この方法のみ使用できます。この方法で再設定すると、クラスター上のすべてのファイルが、新しく送信した設定セットで強制的に上書きされます。この方法では、再設定 API 以外で行った設定ファイル変更がすべて消去されます。 + **マージ**: Amazon EMR リリース 5.35.0 および 6.6.0 以降でサポートされる再設定の方法です。ただし、バージョンに関係なく、Amazon EMR コンソールでは、この再設定は行えません。この方法で再設定すると、新しく送信した設定が、クラスターに既に存在する設定と統合されます。このオプションでは、送信した新しい設定のみが追加または変更されます。既存の設定は保持されます。 Amazon EMR では、適切なサービス稼働に必要な Hadoop 設定の一部が継続的に上書きされます。 **制限事項** 実行中のクラスターのインスタンスグループを再設定するときは、次の制限を考慮してください。 + 非 Yarn アプリケーションでは、アプリケーションが適切に設定されていない場合は特に、再起動中の失敗やクラスターの問題が発生する可能性があります。メモリや CPU 使用率が最大に近づいているクラスターは、再起動プロセス後に問題が発生する可能性があります。これは、マスターインスタンスグループに対して特にあてはまります。 + インスタンスグループのサイズ変更中は、再設定リクエストを送信できません。インスタンスグループのサイズ変更中に再設定を開始した場合、インスタンスグループのサイズ変更が完了するまで再設定を開始することはできません。再設定中にサイズ変更を行う場合も同様です。 + インスタンスグループを再設定後、Amazon EMR は、新しい設定を反映するためにアプリケーションを再起動します。再設定中にアプリケーションが使用されていると、ジョブが失敗したり、アプリケーションで予期しない動作が発生したりする可能性があります。 + インスタンスグループの再設定に失敗した場合、Amazon EMR は、設定パラメータを前に機能していたバージョンに戻します。バージョンを戻せなかった場合は、新しい `ModifyInstanceGroup` リクエストを送信して、インスタンスグループを `SUSPENDED` 状態から復旧させる必要があります。 + Phoenix 設定分類の再設定リクエストは、Amazon EMR バージョン 5.23.0 以降でのみサポートされていて、Amazon EMR バージョン 5.21.0 や 5.22.0 ではサポートされていません。 + HBase 設定分類の再設定リクエストは、Amazon EMR バージョン 5.30.0 以降でのみサポートされていて、Amazon EMR バージョン 5.23.0 から 5.29.0 ではサポートされていません。 + Amazon EMR バージョン 5.27.0 以降でのみ、複数のプライマリノードを持つ EMR クラスターでのアプリケーション再設定リクエストがサポートされています。 + `hdfs-encryption-zones` 分類または Hadoop KMS 設定分類の再設定は、複数のプライマリノードを持つ Amazon EMR クラスターではサポートされていません。 + Amazon EMR では現在、YARN ResourceManager の再起動を必要とする Capacity Scheduler の特定の再設定リクエストをサポートしていません。例えば、キューを完全に削除することはできません。 ## コンソールでのインスタンスグループの再設定 **注記** Amazon EMR コンソールでは、**マージ**タイプの再設定がサポートされていません。 1. [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) で Amazon EMR コンソールを開きます。 1. **[名前]** の下のクラスター一覧で、再設定するアクティブなクラスターを選択します。 1. クラスターのクラスター詳細ページを開き、**[設定]** タブに移動します。 1. [**フィルタ**] ドロップダウンリストで、再設定するインスタンスグループを選択します。 1. **[再設定]** ドロップダウンメニューで、**[テーブルで編集する]** と **[JSON ファイルで編集する]** のいずれかを選択します。 + **テーブルで編集する** -- 設定分類テーブルで、既存の設定のプロパティと値を編集するか、**[設定の追加]** を選択して追加の設定分類を指定します。 + **JSON ファイルで編集する** -- JSON に直接設定を入力するか、短縮構文 (シャドウテキストで示されている) を使用します。それ以外の方法として、JSON の `Configurations` オブジェクトとしてファイルの Amazon S3 URI を指定します。 **注記** 設定分類テーブルの **[ソース]** 列は、クラスター作成時と、このインスタンスグループ用の追加設定の指定時のどちらで設定を指定するかを示しています。インスタンスグループの設定は、両方のソースから編集することができます。最初のクラスター設定を削除することはできませんが、インスタンスグループの設定は上書きすることができます。 また、ネストされた設定分類は、テーブルで直接追加または編集することもできます。たとえば、`export` の追加の `hadoop-env` サブ分類を指定するには、テーブルで `hadoop.export` 設定分類を追加します。次に、この分類の特定のプロパティおよび値を指定します。 1. (オプション) [**Apply this configuration to all active instance groups (この設定をすべてのアクティブインスタンスグループに適用する)**] を選択します。 1. 変更を保存します。 ## CLI を使用したインスタンスグループの再設定 **modify-instance-groups** コマンドを使用して、実行中のクラスター内のインスタンスグループに新しい設定を指定します。 **注記** 次の例では、** をクラスター ID に、** をインスタンスグループ ID に置き換えてください。 **Example - インスタンスグループの設定を置き換える** 次の例では、`instanceGroups.json` という名前の設定 JSON ファイルを参照して、インスタンスグループの YARN NodeManager ディスクヘルスチェッカーのプロパティを編集します。 1. 設定分類を準備し、コマンドを実行するのと同じディレクトリに `instanceGroups.json` として保存します。 ``` [ { "InstanceGroupId":"", "Configurations":[ { "Classification":"yarn-site", "Properties":{ "yarn.nodemanager.disk-health-checker.enable":"true", "yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage":"100.0" }, "Configurations":[] } ] } ] ``` 1. 以下のコマンドを実行してください。 ``` aws emr modify-instance-groups --cluster-id \ --instance-groups file://instanceGroups.json ``` **Example - インスタンスグループに設定を追加する** インスタンスグループに設定を追加する場合は、そのインスタンスグループに対して前に指定した設定すべてを新しい `ModifyInstanceGroup` リクエストに含める必要があります。含めない場合、前に指定した設定が削除されます。 次の例では、YARN NodeManager 仮想メモリチェッカーのプロパティを追加します。設定には、値が上書きされないように YARN NodeManager ディスクヘルスチェッカーに対して前に指定した値も含められています。 1. `instanceGroups.json` に次の内容を準備し、コマンドを実行するのと同じディレクトリに保存します。 ``` [ { "InstanceGroupId":"", "Configurations":[ { "Classification":"yarn-site", "Properties":{ "yarn.nodemanager.disk-health-checker.enable":"true", "yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage":"100.0", "yarn.nodemanager.vmem-check-enabled":"true", "yarn.nodemanager.vmem-pmem-ratio":"3.0" }, "Configurations":[] } ] } ] ``` 1. 以下のコマンドを実行してください。 ``` aws emr modify-instance-groups --cluster-id \ --instance-groups file://instanceGroups.json ``` **Example — **マージタイプの再設定を使用してインスタンスグループに設定を追加する**** デフォルトの**上書き**再設定によってインスタンスグループに設定を追加する場合は、そのインスタンスグループに以前指定したすべての設定を、新しい `ModifyInstanceGroup` リクエストに含める必要があります。そうしない場合、**上書き**によって、以前指定した設定が削除されます。**マージ**の再設定では、この操作は不要です。ただし、リクエストでは、新しい設定のみ指定する必要があります。 次の例では、YARN NodeManager 仮想メモリチェッカーのプロパティを追加します。これは、**マージ**タイプの再設定であるため、YARN NodeManager ディスクヘルスチェッカーに以前指定した値は上書きされません。 1. `instanceGroups.json` に次の内容を準備し、コマンドを実行するのと同じディレクトリに保存します。 ``` [ {"InstanceGroupId":"", "ReconfigurationType" :"MERGE", "Configurations":[ {"Classification":"yarn-site", "Properties":{ "yarn.nodemanager.vmem-check-enabled":"true", "yarn.nodemanager.vmem-pmem-ratio":"3.0" }, "Configurations":[] } ] } ] ``` 1. 以下のコマンドを実行してください。 ``` aws emr modify-instance-groups --cluster-id \ --instance-groups file://instanceGroups.json ``` **Example - インスタンスグループの設定を削除する** インスタンスグループの設定を削除するには、前の設定を除外する新しい再設定リクエストを送信します。 最初の*クラスター*設定に対して実行できるのは上書きのみです。この設定を削除することはできません。 例えば、前の例から YARN NodeManager ディスクヘルスチェッカーの設定を削除するには、次の内容の新しい `instanceGroups.json` を送信します。 ``` [ { "InstanceGroupId":"", "Configurations":[ { "Classification":"yarn-site", "Properties":{ "yarn.nodemanager.vmem-check-enabled":"true", "yarn.nodemanager.vmem-pmem-ratio":"3.0" }, "Configurations":[] } ] } ] ``` 最後の再設定リクエストに含まれる設定をすべて削除するには、空の設定の配列を指定して再設定リクエストを送信します。例: ``` [ { "InstanceGroupId":"", "Configurations":[] } ] ``` **Example — 1 つのリクエストでインスタンスグループの再設定とサイズ変更を実行する** 同じリクエストでインスタンスグループの再設定とサイズ変更を行う方法を次の JSON 例に示します。 ``` [ { "InstanceGroupId":"", "InstanceCount":5, "EC2InstanceIdsToTerminate":["i-123"], "ForceShutdown":true, "ShrinkPolicy":{ "DecommissionTimeout":10, "InstanceResizePolicy":{ "InstancesToTerminate":["i-123"], "InstancesToProtect":["i-345"], "InstanceTerminationTimeout":20 } }, "Configurations":[ { "Classification":"yarn-site", "Configurations":[], "Properties":{ "yarn.nodemanager.disk-health-checker.enable":"true", "yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage":"100.0" } } ] } ] ``` ## Java SDK を使用したインスタンスグループの再設定 **注記** 次の例では、** をクラスター ID に、** をインスタンスグループ ID に置き換えてください。 次のコードスニペットでは、 AWS SDK for Javaを使用して、インスタンスグループに対する新しい設定を指定します。 ``` AWSCredentials credentials = new BasicAWSCredentials("access-key", "secret-key"); AmazonElasticMapReduce emr = new AmazonElasticMapReduceClient(credentials); Map hiveProperties = new HashMap(); hiveProperties.put("hive.join.emit.interval","1000"); hiveProperties.put("hive.merge.mapfiles","true"); Configuration configuration = new Configuration() .withClassification("hive-site") .withProperties(hiveProperties); InstanceGroupModifyConfig igConfig = new InstanceGroupModifyConfig() .withInstanceGroupId("") .withReconfigurationType("MERGE"); .withConfigurations(configuration); ModifyInstanceGroupsRequest migRequest = new ModifyInstanceGroupsRequest() .withClusterId("") .withInstanceGroups(igConfig); emr.modifyInstanceGroups(migRequest); ``` 次のコードスニペットでは、空の設定の配列を指定して、インスタンスグループに対して前に指定した設定を削除します。 ``` List configurations = new ArrayList(); InstanceGroupModifyConfig igConfig = new InstanceGroupModifyConfig() .withInstanceGroupId("") .withConfigurations(configurations); ModifyInstanceGroupsRequest migRequest = new ModifyInstanceGroupsRequest() .withClusterId("") .withInstanceGroups(igConfig); emr.modifyInstanceGroups(migRequest); ``` ## インスタンスグループの再設定のトラブルシューティング インスタンスグループの再設定プロセスが失敗した場合、Amazon EMR は再設定を元に戻し、Amazon CloudWatch イベントを使用して失敗メッセージをログに記録します。イベントには、再設定失敗の簡単な概要が記載されます。ここに、再構成が失敗したインスタンスと、対応する失敗メッセージがリストされます。失敗メッセージの例を次に示します。 ``` The reconfiguration operation for instance group ig-1xxxxxxx9 in Amazon EMR cluster j-2AL4XXXXXX5T9 (ExampleClusterName) failed at 2021-01-01 00:00 UTC and took 2 minutes to fail. Failed configuration version is example12345. Failure message: Instance i-xxxxxxx1, i-xxxxxxx2, i-xxxxxxx3 failed with message "This is an example failure message". ``` 再設定失敗に関する詳細データを収集するには、ノードのプロビジョニングログを確認します。これは、次のようなメッセージを受信したときに特に有用です。 ``` i-xxxxxxx1 failed with message “Unable to complete transaction and some changes were applied.” ``` ------ #### [ On the node ] **ノードに接続してノードのプロビジョニングログにアクセスする** 1. SSH を使用して、再設定が失敗したノードに接続します。手順については、*Amazon EC2* *Linux インスタンス用ユーザーガイド*の [Linux インスタンスへの接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html)を参照してください。 1. ノードのプロビジョニングログファイルが含まれる次のディレクトリに移動します。 ``` /mnt/var/log/provision-node/ ``` 1. `reports` サブディレクトリを開き、再設定のノードのプロビジョニングレポートを検索します。`reports` ディレクトリでは、再設定のバージョン番号、Universally Unique Identifier (UUID)、Amazon EC2 インスタンスの IP アドレス、およびタイムスタンプによってログが整理されます。各レポートは、再設定プロセスに関する詳細情報が含まれる圧縮された YAML ファイルです。 レポートファイルの名前とパスの例を次に示します。 ``` /reports/2/ca598xxx-cxxx-4xxx-bxxx-6dbxxxxxxxxx/ip-10-73-xxx-xxx.ec2.internal/202104061715.yaml.gz ``` 1. レポートは、次の例に示すように、`zless` などのファイルビューワーを使用して確認できます。 ``` zless 202104061715.yaml.gz ``` ------ #### [ Amazon S3 ] **Amazon S3 を使用してノードのプロビジョニングログにアクセスするには** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) で Amazon S3 コンソールを開きます。 1. ログファイルをアーカイブするようにクラスターを設定したときに指定した Amazon S3 バケットを開きます。 1. ノードのプロビジョニングログファイルが含まれる次のフォルダに移動します。 ``` amzn-s3-demo-bucket/elasticmapreduce//node//provision-node/ ``` 1. `reports` フォルダを開き、再設定のノードのプロビジョニングレポートを検索します。`reports` フォルダでは、再設定のバージョン番号、Universally Unique Identifier (UUID)、Amazon EC2 インスタンスの IP アドレス、およびタイムスタンプによってログが整理されます。各レポートは、再設定プロセスに関する詳細情報が含まれる圧縮された YAML ファイルです。 レポートファイルの名前とパスの例を次に示します。 ``` /reports/2/ca598xxx-cxxx-4xxx-bxxx-6dbxxxxxxxxx/ip-10-73-xxx-xxx.ec2.internal/202104061715.yaml.gz ``` 1. ログファイルを表示するには、Amazon S3 からローカルマシンにログファイルをテキストファイルとしてダウンロードします。手順については、「[オブジェクトのダウンロード](https://docs.aws.amazon.com/AmazonS3/latest/userguide/download-objects.html)」を参照してください。 ------ 各ログファイルには、関連する再設定に関する詳細なプロビジョニングレポートが含まれています。エラーメッセージ情報を検索するには、レポートの `err` ログレベルを検索します。レポートの形式は、クラスターの Amazon EMR のバージョンによって異なります。 5.32.0 および 6.2.0 より前の Amazon EMR リリースバージョンのエラー情報を次の例に示します。 ``` - !ruby/object:Puppet::Util::Log level: !ruby/sym err tags: - err message: "Example detailed error message." source: Puppet time: 2021-01-01 00:00:00.000000 +00:00 ``` Amazon EMR リリースバージョン 5.32.0 および 6.2.0 以降では、代わりに次の形式が使用されます。 ``` - level: err message: 'Example detailed error message.' source: Puppet tags: - err time: '2021-01-01 00:00:00.000000 +00:00' file: line: ``` # に機密設定データを保存する AWS Secrets Manager Amazon EMR では、カスタム設定データ (`DescribeCluster` や `ListInstanceGroups` など) を発行する API オペレーションをプレーンテキストで記述して一覧表示できます。Amazon EMR は と統合 AWS Secrets Manager されているため、データを Secrets Manager に保存し、設定でシークレット ARN を使用できます。この方法を取ると、機密性の高い設定データをプレーンテキストで Amazon EMR に渡して外部 API に公開しなくても済みます。キーと値のペアに Secrets Manager に保存されているシークレットの ARN が含まれていることを示すと、Amazon EMR は設定データをクラスターに送信するときにこのシークレットを取得し、そのシークレット ARN が取得されます。Amazon EMR は、外部 API を使用して設定を表示する場合、そのアノテーションを送信されません。 ## シークレットを作成する シークレットを作成するには、「*AWS Secrets Manager ユーザーガイド*」の「[Create an AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)」の手順に従います。**ステップ 3** では、**[プレーンテキスト]** フィールドを選択して機密値を入力する必要があります。 Secrets Manager では、最大 65536 バイトをシークレットで指定できますが、Amazon EMR では、プロパティキー (アノテーションを除く) と取得するシークレット値を合わせた長さが 1024 文字に制限されていることに注意してください。 ## Amazon EMR にアクセス権を付与してシークレットを取得する Amazon EMR では、IAM サービスロールを使用してクラスターをプロビジョニングおよび管理します。Amazon EMR に許可するアクションは Amazon EMR のサービスロールによって定義します。これにより、リソースをプロビジョニングすると共に、クラスター内で稼働している Amazon EC2 インスタンスのコンテキスト上、実行されないサービスレベルのタスクを実行できます。サービスロールの詳細については、「[Amazon EMR のサービスロール (EMR ロール)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-iam-role.html)」と「[IAM ロールのカスタマイズ](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-iam-roles-custom.html)」を参照してください。 Amazon EMR が Secrets Manager からシークレット値を取得できるようにするには、クラスターを起動するときに Amazon EMR ロールに次のポリシーステートメントを追加します。 ``` { "Sid":"AllowSecretsRetrieval", "Effect":"Allow", "Action":"secretsmanager:GetSecretValue", "Resource":[ "arn:aws:secretsmanager:::secret:" ] } ``` カスタマーマネージドでシークレットを作成する場合は AWS KMS key、使用するキーの Amazon EMR ロールにも`kms:Decrypt`アクセス許可を追加する必要があります。詳細については、*AWS Secrets Manager ユーザーガイド*の「[AWS Secrets Managerに対する認証とアクセスコントロール](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html)」を参照してください。 ## シークレットを設定分類で使用する `EMR.secret@` アノテーションを任意の設定プロパティに追加して、そのキーと値のペアに、Secrets Manager に保存しているシークレットの ARN が含まれていることを示すことができます。 次の例は、設定分類でシークレット ARN を指定する方法を示しています。 ``` { "Classification":"core-site", "Properties":{ "presto.s3.access-key":"", "EMR.secret@presto.s3.secret-key":"arn:aws:secretsmanager:::secret:" } } ``` クラスターの作成時にアノテーション付きの設定を送信すると、Amazon EMR によって設定プロパティが検証されます。設定が有効な場合、Amazon EMR は、設定からアノテーションを削除し、Secrets Manager からシークレットを取得します。これによって、実際の設定を作成し、クラスターに適用します。 ``` { "Classification":"core-site", "Properties":{ "presto.s3.access-key":"", "presto.s3.secret-key":"" } } ``` `DescribeCluster` などのアクションを呼び出すと、Amazon EMR から、クラスターで現在稼働しているアプリケーションの設定が返ります。アプリケーション設定プロパティにシークレット ARN が含まれるとマークしている場合、`DescribeCluster` 呼び出しによって返るアプリケーション設定には、シークレット値ではなく ARN が含まれています。これにより、クラスター上でのみシークレット値を目視できるようになります。 ``` { "Classification":"core-site", "Properties":{ "presto.s3.access-key":"", "presto.s3.secret-key":"arn:aws:secretsmanager:::secret:" } } ``` ## シークレット値を更新する Amazon EMR は、アタッチされたインスタンスグループが起動、再設定、またはサイズ変更されるたびに、アノテーション付きの設定からシークレット値を取得します。稼働中のクラスターの設定で使用するシークレット値は、Secrets Manager を使用すると変更できます。その場合、更新済みの値を受け取りたい各インスタンスグループに、再設定リクエストを送信できます。インスタンスグループを再設定する方法と、その際に考慮すべき点の詳細については、「[実行中のクラスター内のインスタンスグループの再設定](emr-configure-apps-running-cluster.md)」を参照してください。 # 特定の Java 仮想マシンを使用するようにアプリケーションを設定 Amazon EMR は、リリースごとに、デフォルトの Java 仮想マシン (JVM) のバージョンが異なります。このページでは、さまざまなリリースやアプリケーションに対する JVM サポートについて説明します。 ## 考慮事項 アプリケーションでサポートされている Java バージョンについては、[Amazon EMR リリースガイド](emr-release-components.md)のアプリケーションのページを参照してください。 + Amazon EMR のクラスター内で実行可能なランタイムバージョンは 1 つのみであり、同じクラスターで、異なるランタイムバージョンを実行し、異なるノードまたはアプリケーションを稼働させることはできません。 + Amazon EMR 7.x の場合、Apache Livy を除く、Java 17 をサポートするアプリケーションのデフォルトの Java 仮想マシン (JVM) は Java 17 です。アプリケーションでサポートされている JDK バージョンの詳細については、Amazon EMR リリースガイドの対応するリリースページを参照してください。 + Amazon EMR 7.1.0 以降、Flink は Java 17 をサポートし、デフォルトで Java 17 に設定されています。別のバージョンの Java ランタイムを使用するには、`flink-conf` の設定を上書きします。Java 8 または Java 11 を使用するように Flink を設定する方法の詳細については、「[Configure Flink to run with Java 11](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/flink-configure.html#flink-configure-java11)」を参照してください。 + Amazon EMR 5.x および 6.x の場合、デフォルトの Java 仮想マシン (JVM) は Java 8 です。 + Amazon EMR リリース 6.12.0 以降の場合、一部のアプリケーションも Java 11 と 17 をサポートしています。 + Amazon EMR リリース 6.9.0 以降の場合、Trino はデフォルトで Java 17 をサポートしています。Java 17 と Trino の詳細については、Trino のブログ、「[Trino updates to Java 17](https://trino.io/blog/2022/07/14/trino-updates-to-java-17.html)」を参照してください。 ランタイムバージョンを選択する際には、次に示すアプリケーション固有の考慮事項に留意してください。 **Java 設定に関する、アプリケーション固有の注意点** | アプリケーション | Java の設定に関する注意点 | | --- | --- | | Spark | Spark をデフォルト以外の Java バージョンで稼働させるには、Spark と Hadoop の両方を設定する必要があります。例については「[JVM をオーバーライドする](#configuring-java8-override)」を参照してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ReleaseGuide/configuring-java8.html) | | Spark RAPIDS | Spark 用に設定されている Java バージョンで RAPIDS を実行できます。 | | Iceberg | Iceberg は、それを使用するアプリケーションの設定済み Java バージョンで稼働させることができます。 | | Delta | Delta は、それを使用するアプリケーションの設定済み Java バージョンで稼働させることができます。 | | Hudi | Hudi は、それを使用するアプリケーションの設定済み Java バージョンで稼働させることができます。 | | Hadoop | Hadoop の JVM を更新するには、`hadoop-env` を変更します。例については「[JVM をオーバーライドする](#configuring-java8-override)」を参照してください。 | | [Hive] | Hive の Java バージョンを 11 または 17 に設定するには、Hadoop の JVM 設定で、使用する Java バージョンを指定します。 | | HBase | HBase の JVM を更新するには、`hbase-env` を変更します。デフォルトの場合、Amazon EMR では、Hadoop の JVM 設定に基づいて HBase の JVM が設定されます。ただし、`hbase-env` の設定をオーバーライドした場合を除きます。例については「[JVM をオーバーライドする](#configuring-java8-override)」を参照してください。 | | Flink | Flink の JVM を更新するには、`flink-conf` を変更します。デフォルトの場合、Amazon EMR では、Hadoop の JVM 設定に基づいて Flink の JVM が設定されます。ただし、`flink-conf` の設定をオーバーライドした場合を除きます。詳細については、「[Flink が Java 11 で実行されるよう設定する](flink-configure.md#flink-configure-java11)」を参照してください。 | | Oozie | Oozie が Java 11 または 17 で稼働するように構成するには、Oozie サーバーと Oozie LauncherAM ランチャー AM の設定を行い、クライアント側の実行ファイルとジョブ設定を変更します。`EmbeddedOozieServer` を設定して、Java 17 で稼働させることもできます。詳細については、「[Oozie 用の Java バージョンの設定](oozie-java.md)」を参照してください。 | | Pig | Pig は Java 8 のみをサポートしています。Hadoop で Java 11 または 17 を使用し、それと同じクラスターで Pig を稼働させることはできません。 | ## JVM をオーバーライドする Amazon EMR リリースの JVM 設定をオーバーライドするには (例えば、Amazon EMR リリース 6.12.0 を使用するクラスターで Java 17 を使用するなど)、`JAVA_HOME` をその環境分類に設定します。この場合の環境分類は `application-env` であり、Flink を除くすべてのアプリケーションに適用されます。Flink の環境分類は `flink-conf` です。Flink の Java ランタイムを設定する手順については、「[Flink が Java 11 で実行されるよう設定する](flink-configure.md#flink-configure-java11)」を参照してください。 **Topics** + [JVM 設定をオーバーライドし Apache Spark を使用する](#configuring-java8-override-spark) + [JVM 設定をオーバーライドし Apache HBase を使用する](#configuring-java8-override-hbase) + [JVM 設定をオーバーライドし Apache Hadoop と Hive を使用する](#configuring-java8-override-hadoop) ### JVM 設定をオーバーライドし Apache Spark を使用する Amazon EMR リリース 6.12 以上で Spark を使用し、エグゼキューターが Java 11 または 17 を使用するよう環境を設定できます。Amazon EMR リリース 5.x より前のリリースで Spark を使用し、クラスターモードで送信するドライバーを作成すると、ドライバーは Java 7 を使用しますが、エグゼキューターが Java 8 を使用するよう環境を設定できます。 Spark の JVM を上書きするには、Spark 分類設定を設定します。このサンプルでは、Hadoop 用の Java バージョンは同じですが、必須ではありません。 ``` [ { "Classification": "hadoop-env", "Configurations": [ { "Classification": "export", "Configurations": [], "Properties": { "JAVA_HOME": "/usr/lib/jvm/java-1.8.0" } } ], "Properties": {} }, { "Classification": "spark-env", "Configurations": [ { "Classification": "export", "Configurations": [], "Properties": { "JAVA_HOME": "/usr/lib/jvm/java-1.8.0" } } ], "Properties": {} } ] ``` Amazon EMR の Hadoop では、JVM バージョンがすべての Hadoop コンポーネントで一貫していることをお勧めします。 次の例は、EMR 7.0.0 以上に必要な設定パラメータを追加して、すべてのコンポーネントで一貫した Java バージョンの使用を確保する方法を示しています。 ``` [ { "Classification": "spark-defaults", "Properties": { "spark.executorEnv.JAVA_HOME": "/usr/lib/jvm/java-1.8.0", "spark.yarn.appMasterEnv.JAVA_HOME": "/usr/lib/jvm/java-1.8.0" } }, { "Classification": "hadoop-env", "Configurations": [ { "Classification": "export", "Configurations": [], "Properties": { "JAVA_HOME": "/usr/lib/jvm/java-1.8.0" } } ], "Properties": {} }, { "Classification": "spark-env", "Configurations": [ { "Classification": "export", "Configurations": [], "Properties": { "JAVA_HOME": "/usr/lib/jvm/java-1.8.0" } } ], "Properties": {} } ] ``` ### JVM 設定をオーバーライドし Apache HBase を使用する HBase で Java 11 が使用されるように設定するには、クラスターの起動時に次の設定を行います。 ``` [ { "Classification": "hbase-env", "Properties": {}, "Configurations": [ { "Classification": "export", "Properties": { "JAVA_HOME": "/usr/lib/jvm/jre-11", "HBASE_OPTS": "-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -Dsun.net.inetaddr.ttl=5" }, "Configurations": [] } ] } ] ``` ### JVM 設定をオーバーライドし Apache Hadoop と Hive を使用する 次の例は、JVM をバージョン 17 に設定し、Hadoop と Hive を利用可能にする方法を示しています。 ``` [ { "Classification": "hadoop-env", "Configurations": [ { "Classification": "export", "Configurations": [], "Properties": { "JAVA_HOME": "/usr/lib/jvm/jre-17" } } ], "Properties": {} } ] ``` ## サービスポート 以下は YARN および HDFS サービスポートです。これらの設定には、Hadoop のデフォルトが反映されます。特に文言化されていない限り、他のアプリケーションサービスはデフォルトのポートでホストされます。詳細については、アプリケーションのプロジェクトドキュメントを参照してください。 **YARN と HDFS のポート設定** | 設定 | ホスト名 / ポート | | --- | --- | | `fs.default.name` | デフォルト (`hdfs://emrDeterminedIP:8020`) | | `dfs.datanode.address` | デフォルト (`0.0.0.0:50010`) | | `dfs.datanode.http.address` | デフォルト (`0.0.0.0:50075`) | | `dfs.datanode.https.address` | デフォルト (`0.0.0.0:50475`) | | `dfs.datanode.ipc.address` | デフォルト (`0.0.0.0:50020`) | | `dfs.http.address` | デフォルト (`0.0.0.0:50070`) | | `dfs.https.address` | デフォルト (`0.0.0.0:50470`) | | `dfs.secondary.http.address` | デフォルト (`0.0.0.0:50090`) | | `yarn.nodemanager.address` | デフォルト (`${yarn.nodemanager.hostname}:0`) | | `yarn.nodemanager.localizer.address` | デフォルト (`${yarn.nodemanager.hostname}:8040`) | | `yarn.nodemanager.webapp.address` | デフォルト (`${yarn.nodemanager.hostname}:8042`) | | `yarn.resourcemanager.address` | デフォルト (`${yarn.resourcemanager.hostname}:8032`) | | `yarn.resourcemanager.admin.address` | デフォルト (`${yarn.resourcemanager.hostname}:8033`) | | `yarn.resourcemanager.resource-tracker.address` | デフォルト (`${yarn.resourcemanager.hostname}:8031`) | | `yarn.resourcemanager.scheduler.address` | デフォルト (`${yarn.resourcemanager.hostname}:8030`) | | `yarn.resourcemanager.webapp.address` | デフォルト (`${yarn.resourcemanager.hostname}:8088`) | | `yarn.web-proxy.address` | デフォルト (`no-value`) | | `yarn.resourcemanager.hostname` | `emrDeterminedIP` | **注記** *emrDeterminedIP* とは、Amazon EMR コントロールプレーンで生成された IP アドレスのことです。新しいバージョンでは、この規則は削除されています ( `yarn.resourcemanager.hostname` および `fs.default.name` 設定は除く)。 ## アプリケーションユーザー アプリケーションでは、プロセスを独自のユーザーとして実行します。たとえば、Hive JVM はユーザー `hive` として、MapReduce JVM は `mapred` として実行されます。これを、次のプロセスステータスの例に示します。 ``` USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND hive 6452 0.2 0.7 853684 218520 ? Sl 16:32 0:13 /usr/lib/jvm/java-openjdk/bin/java -Xmx256m -Dhive.log.dir=/var/log/hive -Dhive.log.file=hive-metastore.log -Dhive.log.threshold=INFO -Dhadoop.log.dir=/usr/lib/hadoop hive 6557 0.2 0.6 849508 202396 ? Sl 16:32 0:09 /usr/lib/jvm/java-openjdk/bin/java -Xmx256m -Dhive.log.dir=/var/log/hive -Dhive.log.file=hive-server2.log -Dhive.log.threshold=INFO -Dhadoop.log.dir=/usr/lib/hadoop/l hbase 6716 0.1 1.0 1755516 336600 ? Sl Jun21 2:20 /usr/lib/jvm/java-openjdk/bin/java -Dproc_master -XX:OnOutOfMemoryError=kill -9 %p -Xmx1024m -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -Dhbase.log.dir=/var/ hbase 6871 0.0 0.7 1672196 237648 ? Sl Jun21 0:46 /usr/lib/jvm/java-openjdk/bin/java -Dproc_thrift -XX:OnOutOfMemoryError=kill -9 %p -Xmx1024m -ea -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -Dhbase.log.dir=/var/ hdfs 7491 0.4 1.0 1719476 309820 ? Sl 16:32 0:22 /usr/lib/jvm/java-openjdk/bin/java -Dproc_namenode -Xmx1000m -Dhadoop.log.dir=/var/log/hadoop-hdfs -Dhadoop.log.file=hadoop-hdfs-namenode-ip-10-71-203-213.log -Dhadoo yarn 8524 0.1 0.6 1626164 211300 ? Sl 16:33 0:05 /usr/lib/jvm/java-openjdk/bin/java -Dproc_proxyserver -Xmx1000m -Dhadoop.log.dir=/var/log/hadoop-yarn -Dyarn.log.dir=/var/log/hadoop-yarn -Dhadoop.log.file=yarn-yarn- yarn 8646 1.0 1.2 1876916 385308 ? Sl 16:33 0:46 /usr/lib/jvm/java-openjdk/bin/java -Dproc_resourcemanager -Xmx1000m -Dhadoop.log.dir=/var/log/hadoop-yarn -Dyarn.log.dir=/var/log/hadoop-yarn -Dhadoop.log.file=yarn-y mapred 9265 0.2 0.8 1666628 260484 ? Sl 16:33 0:12 /usr/lib/jvm/java-openjdk/bin/java -Dproc_historyserver -Xmx1000m -Dhadoop.log.dir=/usr/lib/hadoop/logs -Dhadoop.log.file=hadoop.log -Dhadoop.home.dir=/usr/lib/hadoop ```