翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EMR クラスターの高可用性をサポートする機能と、オープンソースアプリケーションとの連携方法
このトピックでは、Amazon EMR クラスター内の HDFS NameNode および YARN ResourceManager の Hadoop 高可用性機能に関する情報と、この高可用性機能がオープンソースアプリケーションや他の Amazon EMR 機能と連携する仕組みについて説明します。
## 高可用性 HDFS
複数のプライマリノードを持つ Amazon EMR クラスターにより、Hadoop 内の HDFS NameNode 高可用性機能が有効になります。詳細については、「[HDFS High Availability](https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html)」を参照してください。
Amazon EMR クラスターでは、2 つ以上の個別のノードが NameNode として設定されます。1 つの NameNode は `active` 状態で、その他の NameNode は `standby` 状態です。`active` NameNode を持つノードに障害が発生した場合、Amazon EMR は自動 HDFS フェイルオーバープロセスを開始します。`standby` NameNode を持つノードが `active` になり、クラスターのすべてのクライアントオペレーションを引き継ぎます。Amazon EMR は障害が発生したノードを新しいノードで置き換え、`standby` として再結合します。
**注記**
Amazon EMR バージョン 5.23.0 から 5.36.2 までで、HDFS NameNode を実行するのは 3 つのプライマリノードのうちの 2 つだけです。
Amazon EMR バージョン 6.x 以上では、3 つのプライマリノードすべてが HDFS NameNode を実行します。
どの NameNode が `active` であるか確認する必要がある場合は、SSH を使用してクラスターのいずれかのプライマリノードに接続し、次のコマンドを実行します。
```
hdfs haadmin -getAllServiceState
```
出力では、NameNode がインストールされたノードと、そのステータスが表示されます。例えば、
```
ip-##-#-#-##1.ec2.internal:8020 active
ip-##-#-#-##2.ec2.internal:8020 standby
ip-##-#-#-##3.ec2.internal:8020 standby
```
## 高可用性 YARN ResourceManager
複数のプライマリノードを持つ Amazon EMR クラスターにより、Hadoop で YARN ResourceManager の高可用性機能が有効になります。詳細については、「[ResourceManager の高可用性](https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html)」を参照してください。
複数のプライマリノードを持つ Amazon EMR クラスターでは、YARN ResourceManager は 3 つすべてのプライマリノードで実行されます。1 つの ResourceManager は `active` 状態で、もう 2 つは `standby` 状態です。`active` ResourceManager を持つプライマリノードで障害が発生した場合、Amazon EMR は自動フェイルオーバープロセスを開始します。`standby` ResourceManager を持つプライマリノードが、すべてのオペレーションを引き継ぎます。Amazon EMR は障害が発生したプライマリノードを新しいプライマリノードで置き換え、ResourceManager クォーラムを `standby` として再結合します。
どのプライマリノードについても、「http://*master-public-dns-name*:8088/cluster」に接続できます。これにより、自動的に `active` リソースマネージャーに接続されます。どのリソースマネージャーが `active` であるかを確認するには、SSH を使用して、クラスターのいずれかのプライマリノードに接続します。続いて、次のコマンドを実行して 3 つのプライマリノードとそのステータスのリストを取得します。
```
yarn rmadmin -getAllServiceState
```
## 複数のプライマリノードを持つ Amazon EMR クラスターでサポートされているアプリケーション
複数のプライマリノードを持つ Amazon EMR クラスターには、次のアプリケーションをインストールして実行できます。アプリケーションごとに、プライマリノードのフェイルオーバープロセスは異なります。
| アプリケーション | プライマリノードのフェイルオーバー中の可用性 | 注意事項 |
| --- | --- | --- |
| Flink | プライマリノードのフェイルオーバーによって影響を受けない可用性 | Amazon EMR での Flink ジョブは YARN アプリケーションとして実行されます。Flink の JobManager はコアノードで YARN の ApplicationMaster として実行されます。JobManager は、プライマリノードのフェイルオーバープロセスによる影響を受けません。 Amazon EMR バージョン 5.27.0 以前を使用している場合、JobManager は単一障害点です。JobManager に障害が発生すると、すべてのジョブ状態が失われ、実行中のジョブは再開されません。アプリケーションの試行回数およびチェックポイントを設定し、ZooKeeper を Flink のステートストレージとして有効にすることで、JobManager の高可用性を有効にできます。詳細については、「[複数のプライマリノードがある Amazon EMR クラスターでの Flink の設定](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/flink-configure.html#flink-multi-master)」を参照してください。 Amazon EMR バージョン 5.28.0 以降、JobManager の高可用性を有効にするための手動設定は必要ありません。 |
| Ganglia | プライマリノードのフェイルオーバーによって影響を受けない可用性 | Ganglia はすべてのプライマリノードで利用できるため、Ganglia はプライマリノードのフェイルオーバープロセス中に継続して実行できます。 |
| Hadoop | 高可用性 | アクティブなプライマリノードで障害が発生した場合、HDFS NameNode および YARN ResourceManager は自動的にスタンバイノードにフェイルオーバーします。 |
| HBase | 高可用性 | アクティブなプライマリノードで障害が発生した場合、HBase は自動的にスタンバイノードにフェイルオーバーします。 REST または Thrift サーバーを通じて HBase に接続している場合、アクティブなプライマリノードに障害が発生したときは、別のプライマリノードに切り替える必要があります。 |
| HCatalog | プライマリノードのフェイルオーバーによって影響を受けない可用性 | HCatalog は、クラスター外部に存在する Hive メタストア上に構築されます。HCatalog は、プライマリノードのフェイルオーバープロセス中も引き続き利用可能です。 |
| JupyterHub | 高可用性 | JupyterHub は 3 つすべてのプライマリインスタンスにインストールされます。プライマリノードの障害時にノートブックが失われないように、ノートブックの永続性を設定することを強くお勧めします。詳細については、「[Simple Storage Service (Amazon S3) でノートブックの永続性を設定する](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-jupyterhub-s3.html)」を参照してください。 |
| Livy | 高可用性 | Livy は 3 つすべてのプライマリノードにインストールされます。アクティブなプライマリノードで障害が発生した場合、現在の Livy セッションへのアクセスは失われ、別のプライマリノードまたは新しい代替ノードで新しい Livy セッションを作成する必要があります。 |
| Mahout | プライマリノードのフェイルオーバーによって影響を受けない可用性 | Mahout にはデーモンがないため、プライマリノードのフェイルオーバープロセスによる影響を受けません。 |
| MXNet | プライマリノードのフェイルオーバーによって影響を受けない可用性 | MXNet にはデーモンがないため、プライマリノードのフェイルオーバープロセスによる影響を受けません。 |
| フェニックス | 高可用性 | Phoenix の QueryServer は、3 つのプライマリノードの 1 つでのみ実行されます。3 つすべてのマスター上の Phoenix は、Phoenix QueryServer を接続するように設定されています。`/etc/phoenix/conf/phoenix-env.sh` ファイルを使用して、Phoenix の QueryServer のプライベート IP を見つけることができます。 |
| Pig | プライマリノードのフェイルオーバーによって影響を受けない可用性 | Pig にはデーモンがないため、プライマリノードのフェイルオーバープロセスによる影響を受けません。 |
| Spark | 高可用性 | すべての Spark アプリケーションは YARN コンテナで実行され、高可用性 YARN 機能と同じ方法で、プライマリノードのフェイルオーバーに対応できます。 |
| Sqoop | 高可用性 | デフォルトでは、sqoop-job および sqoop-metastore は、コマンドを実行するマスターのローカルディスクにデータ (ジョブの説明) を保存します。外部データベースにメタストアデータを保存する場合は、Apache Sqoop ドキュメントを参照してください |
| Tez | 高可用性 | Tez コンテナは YARN で実行されるため、Tez はプライマリノードのフェイルオーバープロセス中は YARN と同じ方法で動作します。 |
| TensorFlow | プライマリノードのフェイルオーバーによって影響を受けない可用性 | TensorFlow にはデーモンがないため、プライマリノードのフェイルオーバープロセスによる影響を受けません。 |
| Zeppelin | 高可用性 | Zeppelin は 3 つすべてのプライマリノードにインストールされます。Zeppelin は、データの損失を防ぐために、デフォルトでノートとインタープリタの設定を HDFS に保存します。インタープリタセッションは、3 つすべてのプライマリインスタンス間で完全に分離されます。セッションデータは、マスターで障害が発生すると失われます。異なるプライマリインスタンスで同じノートを同時に変更しないことをお勧めします。 |
| ZooKeeper | 高可用性 | ZooKeeper は、HDFS の自動フェイルーバー機能の基礎です。ZooKeeper は調整データを維持するための高可用性サービスを提供し、そのデータの変更をクライアントに通知して、障害についてクライアントをモニタリングします。詳細については、「[HDFS Automatic Failover](https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html#Automatic_Failover)」を参照してください。 |
複数のプライマリノードを含む Amazon EMR クラスターで以下のアプリケーションを実行するには、外部データベースを設定する必要があります。外部データベースはクラスター外部に存在し、プライマリノードのフェイルオーバープロセス中にデータを永続的に保ちます。以下のアプリケーションでは、サービスコンポーネントはプライマリノードのフェイルオーバープロセス中に自動的に復旧されますが、アクティブなジョブは失敗し、再試行が必要になる場合があります。
| アプリケーション | プライマリノードのフェイルオーバー中の可用性 | 注意事項 |
| --- | --- | --- |
| [Hive] | サービスコンポーネントのみに対する高可用性 | Hive の外部メタストアが必要です。PostgreSQL はマルチマスタークラスターではサポートされていないため、これは MySQL の外部メタストアでなければなりません。詳細については、「[Hive の外部メタストアの設定](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html)」を参照してください。 |
| Hue | サービスコンポーネントのみに対する高可用性 | Hue の外部データベースが必要です。詳細については、「[Amazon RDS でのリモートデータベースと Hue の使用](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/hue-rds.html)」を参照してください。 |
| Oozie | サービスコンポーネントのみに対する高可用性 | Oozie の外部データベースが必要です。詳細については、「[Amazon RDS でのリモートデータベースと Oozie の使用](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/oozie-rds.html)」を参照してください。 oozie-server と oozie-client は 3 つのプライマリノードすべてにインストールされます。oozie-clients は、デフォルトで正しい oozie-server に接続するように設定されています。 |
| PrestoDB または PrestoSQL/Trino | サービスコンポーネントのみに対する高可用性 | PrestoDB (Amazon EMR 6.1.0-6.3.0 では PrestoSQL、Amazon EMR 6.4.0 以降では Trino) 用の外部 Hive メタストアが必要です。[Glue データカタログで Presto AWS](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-presto-glue.html)を使用するか[、Hive の外部 MySQL データベースを使用できます](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-external.html)。 Presto CLI は 3 つのプライマリノードすべてにインストールされるため、これを使用して、任意のプライマリノードから Presto コーディネーターにアクセスできます。Presto コーディネーターは 1 つのプライマリノードにのみインストールされます。Presto コーディネーターがインストールされているプライマリノードの DNS 名は、Amazon EMR `describe-cluster` API を呼び出し、レスポンス内の `MasterPublicDnsName` フィールドの戻り値を読み取ることで見つけることができます。 |
**注記**
プライマリノードで障害が発生した場合、Java Database Connectivity (JDBC) または Open Database Connectivity (ODBC) はプライマリノードへの接続を終了します。Hive メタストアデーモンはすべてのプライマリノードで実行されるため、残りのいずれかのプライマリノードに接続して作業を続行できます。または、障害が発生したプライマリノードが置き換えられるのを待つことができます。
## 複数プライマリノードを持つクラスターでの Amazon EMR 機能の動作の仕組み
### SSH を使用したプライマリノードへの接続
1 つのプライマリノードに接続するのと同じ方法で、SSH を使用して Amazon EMR クラスターで 3 つのプライマリノードのいずれかに接続できます。詳細については、「[SSH を使用してプライマリノードに接続する](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-connect-master-node-ssh.html)」を参照してください。
プライマリノードで障害が発生した場合、そのプライマリノードへの SSH 接続は終了します。作業を続行するには、2 つのプライマリノードのうち、もう 1 つのノードに接続できます。あるいは、障害が発生したプライマリノードを Amazon EMR が置き換えた後で、新しいプライマリノードにアクセスできます。
**注記**
代替プライマリノードのプライベート IP アドレスは、前のノードと同じままになります。代替プライマリノードのパブリック IP アドレスは変更される場合があります。新しい IP アドレスはコンソールで取得するか、 AWS CLI の `describe-cluster` コマンドを使用して取得できます。
NameNode は 2 つまたは 3 つのプライマリノードで実行されます。ただし、`hdfs` CLI コマンドを実行し、ジョブを運用して 3 つすべてのプライマリノードで HDFS にアクセスできます。
### 複数のプライマリノードを持つ Amazon EMR クラスターでのステップの操作
1 つのプライマリノードを持つクラスターでステップを操作するのと同じ方法で、複数のプライマリノードを持つ Amazon EMR クラスターにステップを送信できます。詳細については、「[クラスターへの作業の送信](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-work-with-steps.html)」を参照してください。
以下に、複数のプライマリノードを持つ Amazon EMR クラスターでステップを操作する際の考慮事項を示します。
+ プライマリノードで障害が発生した場合、プライマリノードで実行中のステップは FAILED とマークされます。ローカルに書き込まれたデータはすべて失われます。ただし、FAILED ステータスがステップの実際の状態を反映しているとは限りません。
+ プライマリノードで障害が発生したときに実行中のステップが YARN アプリケーションを開始した場合、プライマリノードの自動フェイルオーバーにより、ステップは続行して成功できます。
+ ジョブの出力を参照して、ステップのステータスを確認することをお勧めします。たとえば、MapReduce ジョブは `_SUCCESS` ファイルを使用して、ジョブが正常に完了したかどうか判断します。
+ ActionOnFailure パラメータを TERMINATE\$1JOB\$1FLOW または TERMINATE\$1CLUSTER ではなく、CONTINUE または CANCEL\$1AND\$1WAIT に設定することをお勧めします。
### 自動終了保護
Amazon EMR は、複数のプライマリノードを持つすべてのクラスターに対して終了保護を自動的に有効にし、クラスターの作成時に指定したステップ実行設定をオーバーライドします。クラスターの起動後に、終了保護を無効にできます。「[実行中のクラスターに対する終了保護の設定](UsingEMR_TerminationProtection.md#emr-termination-protection-running-cluster)」を参照してください。複数のプライマリノードを持つクラスターをシャットダウンするには、まずクラスター属性を変更して、終了保護を無効にする必要があります。手順については、「[複数のプライマリノードを持つ Amazon EMR クラスターの終了](emr-plan-ha-launch.md#emr-plan-ha-launch-terminate)」を参照してください。
終了保護の詳細については、「[Amazon EMR クラスターを誤ったシャットダウンから保護するための終了保護の使用](UsingEMR_TerminationProtection.md)」を参照してください。
### 複数のプライマリノードを持つ Amazon EMR クラスターでサポートされていない機能
現在、次の Amazon EMR の機能は、複数のプライマリノードを持つ Amazon EMR クラスターで使用できません。
+ EMR Notebooks
+ 永続 Spark 履歴サーバーへのワンクリックアクセス
+ 永続アプリケーションユーザーインターフェイス
+ 永続アプリケーションユーザーインターフェイスへのワンクリックアクセスは現在、複数のプライマリノードを持つ Amazon EMR クラスターや AWS Lake Formation と統合された Amazon EMR クラスターでは使用できません。
+ ランタイムロールベースのアクセスコントロール。詳細については、「[Amazon EMR ステップのランタイムロール](emr-steps-runtime-roles.md)」の [その他の考慮事項](emr-steps-runtime-roles.md#emr-steps-runtime-roles-considerations) を参照してください。
+ Amazon EMR と AWS IAM アイデンティティセンター (信頼できる ID の伝播) の統合。詳細については、「[Amazon EMR を と統合する AWS IAM アイデンティティセンター](emr-idc.md)」を参照してください。
**注記**
クラスターで Kerberos 認証を使用するには、外部 KDC を設定する必要があります。
Amazon EMR バージョン 5.27.0 以降では、複数のプライマリノードを持つ Amazon EMR クラスターに HDFS 透過的暗号化を設定することができます。詳細については、「[Amazon EMR における HDFS での透過的暗号化](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html)」を参照してください。