考慮事項とベストプラクティス
複数のプライマリノードを持つ Amazon EMR クラスターの制限事項
-
インスタンスフリートを持つ複数のプライマリノードを持つ Amazon EMR クラスターは使用できません。複数のプライマリノードで機能する Amazon EMR 機能の詳細については、「サポートされるアプリケーションと機能」を参照してください。
-
2 つのプライマリノードで同時に障害が発生した場合、Amazon EMR はクラスターを回復することができません。
-
複数のプライマリノードを持つ Amazon EMR クラスターは、アベイラビリティーゾーンの障害に対して耐性がありません。アベイラビリティーゾーンが停止した場合、EMR クラスターへのアクセスは失われます。
-
Amazon EMR では、「複数のプライマリノードを持つ Amazon EMR クラスターでサポートされているアプリケーション」で指定されているものを除き、オープンソースアプリケーションの高可用性機能は保証されません。
-
Amazon EMR リリース 5.23.0 から 5.30.1 では、3 つのプライマリノードのうちの 2 つだけが HDFS NameNode を実行します。
サブネット設定の考慮事項:
-
複数のプライマリノードを持つ Amazon EMR クラスターは、1 つのアベイラビリティーゾーンまたはサブネットにのみ存在できます。フェイルオーバーの際にサブネットが完全に利用されている、またはオーバーサブスクライブされている場合、Amazon EMR は障害が発生したプライマリノードを置き換えることができません。このシナリオを回避するには、サブネット全体を Amazon EMR クラスター専用にすることをお勧めします。さらに、サブネットで利用できる十分なプライベート IP アドレスがあることを確認します。
コアノード設定の考慮事項:
-
コアノードのインスタンスグループの高可用性も維持するには、少なくとも 4 つのコアノードを起動することをお勧めします。3 つ以下のコアノードを持つ、より小さいクラスターの起動を決定した場合は、HDFS の
dfs.replication parameter
を少なくとも2
に設定して、十分な DFS レプリケーションになるようにします。詳細については、「HDFS 構成」を参照してください。
警告
-
ノードが 4 つ未満のクラスターで
dfs.replication
を 1 に設定すると、単一ノードがダウンした場合に HDFS データが失われる可能性があります。本番環境のワークロードには、少なくとも 4 つのコアノードを持つクラスターを使用することをお勧めします。 -
Amazon EMR では、クラスターはコアノードを
dfs.replication
未満にスケールすることはできません。例えば、dfs.replication = 2
の場合、コアノードの最小数は 2 です。 -
マネージドスケーリングや自動スケーリングを使用する場合や、クラスターのサイズを手動で変更する場合は、
dfs.replication
を 2 以上に設定することをお勧めします。
メトリクスでのアラーム設定の考慮事項:
-
Amazon EMR は HDFS または YARN に関するアプリケーション固有のメトリクスを提供していません。アラームを設定して、プライマリノードのインスタンス数をモニタリングすることをお勧めします。アラームは、次の Amazon CloudWatch メトリクスを使用して設定できます:
MultiMasterInstanceGroupNodesRunning
、MultiMasterInstanceGroupNodesRunningPercentage
、MultiMasterInstanceGroupNodesRequested
。プライマリノードの障害と置換が発生した場合は CloudWatch により通知されます。-
MultiMasterInstanceGroupNodesRunningPercentage
が 0.5 より大きく 1.0 より小さい場合、クラスターでプライマリノードが失われた可能性があります。このような状況では、Amazon EMR はプライマリノードの置換を試みます。 -
MultiMasterInstanceGroupNodesRunningPercentage
が 0.5 を下回った場合、2 つのプライマリノードで障害が発生した可能性があります。このような状況では、クォーラムは失われており、クラスターを回復することはできません。このクラスターからデータを手動で移行する必要があります。
詳細については、「メトリクスでアラームを設定する」を参照してください。
-