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

Amazon EMR クラスターの高可用性をサポートする機能と、オープンソースアプリケーションとの連携方法

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

高可用性 HDFS

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

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 の高可用性」を参照してください。

複数のプライマリノードを持つ 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 の設定」を参照してください。

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 の 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」を参照してください。

複数のプライマリノードを含む 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 メタストアが必要です。AWS Glue Data Catalog とともに Presto を使用するか、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 つまたは 3 つのプライマリノードで実行されます。ただし、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 の機能は、複数のプライマリノードを持つ 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 での透過的暗号化」を参照してください。