複数のプライマリノードを持つ Amazon EMR クラスターを作成する際の考慮事項とベストプラクティス - Amazon EMR

複数のプライマリノードを持つ Amazon EMR クラスターを作成する際の考慮事項とベストプラクティス

複数のプライマリノードを持つ Amazon EMR クラスターを作成する場合は、以下の事項を考慮します。

重要

複数のプライマリノードを持つ高可用性 EMR クラスターを起動するには、最新の Amazon EMR リリースを使用することを強くお勧めします。これにより、高可用性クラスターで最高レベルの耐障害性と安定性を得ることができます。

  • インスタンスフリートの高可用性は、Amazon EMR リリース 5.36.1、5.36.2、6.8.1、6.9.1、6.10.1、6.11.1、6.12.0、およびそれ以降でサポートされています。インスタンスグループの場合、Amazon EMR リリース 5.23.0 以降で高可用性がサポートされています。詳細については、「Amazon EMR リリースについて」を参照してください。

  • 高可用性クラスターでは、Amazon EMR はオンデマンドインスタンスを備えたプライマリノードの起動のみをサポートします。これにより、クラスターの可用性を最大限に高めることができます。

  • プライマリフリートには引き続き複数のインスタンスタイプを指定できますが、高可用性クラスターのすべてのプライマリノードは、異常のあるプライマリノードの代替を含め、同じインスタンスタイプで起動されます。

  • 運用を継続するには、複数のプライマリノードがある高可用性クラスターの 3 つのプライマリノードのうちの 2 つが正常である必要があります。そのため、2 つのプライマリノードで同時に障害が発生した場合、EMR クラスターは機能しません。

  • 高可用性クラスターを含むすべての EMR クラスターは、単一の可用性ゾーンで起動します。そのため、可用性ゾーンの障害に対する耐性がありません。可用性ゾーンが停止した場合、クラスターへのアクセスは失われます。

  • インスタンスフリート内でクラスターを起動するときにカスタムサービスロールまたはポリシーを使用している場合は、Amazon EMR がサポートされていないアベイラビリティーゾーン (AZ) を除外できるように ec2:DescribeInstanceTypeOfferings アクセス許可を追加できます。Amazon EMR がプライマリノードのインスタンスタイプをサポートしていない AZ をフィルタリングすると、Amazon EMR はサポートされていないプライマリインスタンスタイプが原因でクラスターの起動が失敗するのを防ぎます。詳細については、「Instance type not supported」を参照してください。

  • Amazon EMR では、複数のプライマリノードを持つ Amazon EMR クラスターでサポートされているアプリケーション で指定されているものを除き、オープンソースアプリケーションの高可用性は保証していません。

  • Amazon EMR リリース 5.23.0 から 5.36.2 では、1 つのインスタンスグループクラスターの 3 つのプライマリノードのうち 2 つだけが HDFS NameNode を実行します。

  • Amazon EMR リリース 6.x 以降では、インスタンスグループの 3 つのプライマリノードすべてが HDFS NameNode を実行します。

サブネット設定の考慮事項:

  • 複数のプライマリノードを持つ Amazon EMR クラスターは、1 つのアベイラビリティーゾーンまたはサブネットにのみ存在できます。フェイルオーバーの際にサブネットが完全に利用されている、またはオーバーサブスクライブされている場合、Amazon EMR は障害が発生したプライマリノードを置き換えることができません。このシナリオを回避するには、サブネット全体を Amazon EMR クラスター専用にすることをお勧めします。さらに、サブネットで利用できる十分なプライベート IP アドレスがあることを確認します。

コアノード設定の考慮事項:

  • コアノードの高可用性も維持するには、少なくとも 4 つのコアノードを起動することをお勧めします。3 つ以下のコアノードを持つ、より小さいクラスターの起動を決定した場合は、HDFS の dfs.replication parameter を少なくとも 2 に設定して、十分な DFS レプリケーションになるようにします。詳細については、「HDFS 構成」を参照してください。

警告

  1. ノードが 4 つ未満のクラスターで dfs.replication を 1 に設定すると、単一ノードがダウンした場合に HDFS データが失われる可能性があります。本番環境のワークロードには、少なくとも 4 つのコアノードを持つクラスターを使用することをお勧めします。

  2. Amazon EMR では、クラスターはコアノードを dfs.replication 未満にスケールすることはできません。例えば、dfs.replication = 2 の場合、コアノードの最小数は 2 です。

  3. マネージドスケーリングや自動スケーリングを使用する場合や、クラスターのサイズを手動で変更する場合は、dfs.replication を 2 以上に設定することをお勧めします。

メトリクスでのアラーム設定の考慮事項:

  • Amazon EMR は HDFS または YARN に関するアプリケーション固有のメトリクスを提供していません。アラームを設定して、プライマリノードのインスタンス数をモニタリングすることをお勧めします。アラームは、次の Amazon CloudWatch メトリクスを使用して設定できます: MultiMasterInstanceGroupNodesRunning、MultiMasterInstanceGroupNodesRunningPercentage、MultiMasterInstanceGroupNodesRequested。プライマリノードの障害と置換が発生した場合は CloudWatch により通知されます。

    • MultiMasterInstanceGroupNodesRunningPercentage が 0.5 より大きく 1.0 より小さい場合、クラスターでプライマリノードが失われた可能性があります。このような状況では、Amazon EMR はプライマリノードの置換を試みます。

    • MultiMasterInstanceGroupNodesRunningPercentage が 0.5 を下回った場合、2 つのプライマリノードで障害が発生した可能性があります。このような状況では、クォーラムは失われており、クラスターを回復することはできません。このクラスターからデータを手動で移行する必要があります。

    詳細については、「メトリクスでアラームを設定する」を参照してください。