サポートされるアプリケーションと機能 - Amazon EMR
高可用性 HDFS高可用性 YARN ResourceManager複数のプライマリノードを持つ Amazon EMR クラスターでサポートされているアプリケーション複数プライマリノードを持つクラスターでの Amazon EMR 機能の動作の仕組み

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

サポートされるアプリケーションと機能

このトピックでは、Amazon EMR クラスター ResourceManager 内の HDFS NameNode と YARN の Hadoop 高可用性機能、および高可用性機能がオープンソースアプリケーションやその他の Amazon EMR 機能とどのように連携するかについて説明します。

高可用性 HDFS

複数のプライマリノードを持つ Amazon EMR クラスターにより、Hadoop 内の HDFS NameNode 高可用性機能が有効になります。詳細については、「HDFS High Availability」を参照してください。

Amazon EMR クラスターでは、2 つ以上の個別のノードが として設定されます NameNodes。1 つは NameNode active状態、もう 1 つは standby状態です。を持つノードがactive NameNode 失敗すると、Amazon EMR は自動 HDFS フェイルオーバープロセスを開始します。を持つノードstandbyNameNode は になりactive、クラスター内のすべてのクライアントオペレーションを引き継ぎます。Amazon EMR は障害が発生したノードを新しいノードで置き換え、standby として再結合します。

注記

5.30.1 までの Amazon EMR バージョン 5.23.0 では、3 つのプライマリノードのうち HDFS を実行するのは 2 つだけです 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 「高可用性」を参照してください。

複数のプライマリノードを持つ Amazon EMR クラスターでは、YARN は 3 つのプライマリノードすべてで ResourceManager 実行されます。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 の は、コアノード ApplicationMasters で YARN の としてJobManagers 実行されます。JobManager は、プライマリノードのフェイルオーバープロセスの影響を受けません。

Amazon EMR バージョン 5.27.0 以前を使用している場合、 JobManager は単一障害点です。が JobManager 失敗すると、すべてのジョブ状態が失われ、実行中のジョブは再開されません。アプリケーションの試行回数、チェックポイント、Flink の状態ストレージ ZooKeeper として を有効にすることで、 JobManager 高可用性を有効にできます。詳細については、「複数のプライマリノードがある Amazon EMR クラスターでの Flink の設定」を参照してください。

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) でノートブックの永続性を設定する」を参照してください。
Livy

高可用性

Livy は 3 つすべてのプライマリノードにインストールされます。アクティブなプライマリノードで障害が発生した場合、現在の Livy セッションへのアクセスは失われ、別のプライマリノードまたは新しい代替ノードで新しい Livy セッションを作成する必要があります。
Mahout

プライマリノードのフェイルオーバーによって影響を受けない可用性

Mahout にはデーモンがないため、プライマリノードのフェイルオーバープロセスによる影響を受けません。
MXNet

プライマリノードのフェイルオーバーによって影響を受けない可用性

MXNet にはデーモンがないため、プライマリノードのフェイルオーバープロセスによる影響を受けません。
フェニックス

高可用性

Phoenix は、3 つのプライマリノードのいずれかでのみ QueryServer 実行されます。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」を参照してください。

複数のプライマリノードを含む Amazon EMR クラスターで以下のアプリケーションを実行するには、外部データベースを設定する必要があります。外部データベースはクラスター外部に存在し、プライマリノードのフェイルオーバープロセス中にデータを永続的に保ちます。以下のアプリケーションでは、サービスコンポーネントはプライマリノードのフェイルオーバープロセス中に自動的に復旧されますが、アクティブなジョブは失敗し、再試行が必要になる場合があります。

アプリケーション プライマリノードのフェイルオーバー中の可用性 メモ
[Hive]

サービスコンポーネントのみに対する高可用性

Hive の外部メタストアが必要です。PostgreSQL はマルチマスタークラスターではサポートされていないため、これは MySQL の外部メタストアでなければなりません。詳細については、「Hive の外部メタストアの設定」を参照してください。
Hue

サービスコンポーネントのみに対する高可用性

Hue の外部データベースが必要です。詳細については、「Amazon RDS でのリモートデータベースと Hue の使用」を参照してください。
Oozie

サービスコンポーネントのみに対する高可用性

Oozie の外部データベースが必要です。詳細については、「Amazon RDS でのリモートデータベースと Oozie の使用」を参照してください。

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 メタストアが必要です。Presto を AWS Glue データカタログで使用することも、Hive の外部 MySQL データベースを使用することもできます。

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 を使用してプライマリノードに接続する」を参照してください。

プライマリノードで障害が発生した場合、そのプライマリノードへの SSH 接続は終了します。作業を続行するには、2 つのプライマリノードのうち、もう 1 つのノードに接続できます。あるいは、障害が発生したプライマリノードを Amazon EMR が置き換えた後で、新しいプライマリノードにアクセスできます。

注記

代替プライマリノードのプライベート IP アドレスは、前のノードと同じままになります。代替プライマリノードのパブリック IP アドレスは変更される場合があります。新しい IP アドレスはコンソールで取得するか、 AWS CLI の describe-cluster コマンドを使用して取得できます。

NameNode は、2 つのプライマリノードでのみ実行されます。ただし、hdfs CLI コマンドを実行し、ジョブを運用して 3 つすべてのプライマリノードで HDFS にアクセスできます。

複数のプライマリノードを持つ Amazon EMR クラスターでのステップの操作

1 つのプライマリノードを持つクラスターでステップを操作するのと同じ方法で、複数のプライマリノードを持つ Amazon EMR クラスターにステップを送信できます。詳細については、「クラスターへの作業の送信」を参照してください。

以下に、複数のプライマリノードを持つ Amazon EMR クラスターでステップを操作する際の考慮事項を示します。

  • プライマリノードで障害が発生した場合、プライマリノードで実行中のステップは FAILED とマークされます。ローカルに書き込まれたデータはすべて失われます。ただし、FAILED ステータスがステップの実際の状態を反映しているとは限りません。

  • プライマリノードで障害が発生したときに実行中のステップが YARN アプリケーションを開始した場合、プライマリノードの自動フェイルオーバーにより、ステップは続行して成功できます。

  • ジョブの出力を参照して、ステップのステータスを確認することをお勧めします。例えば、 MapReduce ジョブは _SUCCESS ファイルを使用して、ジョブが正常に完了したかどうかを判断します。

  • ActionOnFailure TERMINATE_JOB_FLOW または TERMINATE_CLUSTER の代わりに、パラメータを CONTINUE または CANCEL_AND_WAIT に設定することをお勧めします。

自動終了保護

Amazon EMR は、複数のプライマリノードを持つすべてのクラスターに対して終了保護を自動的に有効にし、クラスターの作成時に指定したステップ実行設定をオーバーライドします。クラスターの起動後に、終了保護を無効にできます。実行中のクラスターに対する終了保護の設定 を参照してください。複数のプライマリノードを持つクラスターをシャットダウンするには、まずクラスター属性を変更して、終了保護を無効にする必要があります。手順については、「複数のプライマリノードを持つ Amazon EMR クラスターの終了」を参照してください。

終了保護の詳細については、「終了保護の使用」を参照してください。

複数のプライマリノードを持つ Amazon EMR クラスターでサポートされていない機能

現在、次の Amazon EMR の機能は、複数のプライマリノードを持つ Amazon EMR クラスターで使用できません。

  • EMR Notebooks

  • 永続 Spark 履歴サーバーへのワンクリックアクセス

  • 永続アプリケーションユーザーインターフェイス

  • 永続アプリケーションユーザーインターフェイスへのワンクリックアクセスは、現在、複数のプライマリノードを持つ Amazon EMR クラスターや AWS Lake Formation と統合された Amazon EMR クラスターでは使用できません。

注記

クラスターで Kerberos 認証を使用するには、外部 KDC を設定する必要があります。

Amazon EMR バージョン 5.27.0 以降では、複数のプライマリノードを持つ Amazon EMR クラスターに HDFS 透過的暗号化を設定することができます。詳細については、「Amazon EMR における HDFS での透過的暗号化」を参照してください。