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

# 複数のプライマリノードを持つ Amazon EMR クラスターを作成する際の考慮事項とベストプラクティス
<a name="emr-plan-ha-considerations"></a>

複数のプライマリノードを持つ 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 リリースについて](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-components.html)」を参照してください。
+ 高可用性クラスターでは、Amazon EMR はオンデマンドインスタンスを備えたプライマリノードの起動のみをサポートします。これにより、クラスターの可用性を最大限に高めることができます。
+ プライマリフリートには引き続き複数のインスタンスタイプを指定できますが、高可用性クラスターのすべてのプライマリノードは、異常のあるプライマリノードの代替を含め、同じインスタンスタイプで起動されます。
+ 運用を継続するには、複数のプライマリノードがある高可用性クラスターの 3 つのプライマリノードのうちの 2 つが正常である必要があります。そのため、2 つのプライマリノードで同時に障害が発生した場合、EMR クラスターは機能しません。
+ 高可用性クラスターを含むすべての EMR クラスターは、単一の可用性ゾーンで起動します。そのため、可用性ゾーンの障害に対する耐性がありません。可用性ゾーンが停止した場合、クラスターへのアクセスは失われます。
+ インスタンスフリート内でクラスターを起動するときにカスタムサービスロールまたはポリシーを使用している場合は、Amazon EMR がサポートされていないアベイラビリティーゾーン (AZ) を除外できるように `ec2:DescribeInstanceTypeOfferings` アクセス許可を追加できます。Amazon EMR がプライマリノードのインスタンスタイプをサポートしていない AZ をフィルタリングすると、Amazon EMR はサポートされていないプライマリインスタンスタイプが原因でクラスターの起動が失敗するのを防ぎます。詳細については、「[Instance type not supported](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-INSTANCE_TYPE_NOT_SUPPORTED-error.html)」を参照してください。
+ Amazon EMR では、[複数のプライマリノードを持つ Amazon EMR クラスターでサポートされているアプリケーション](emr-plan-ha-applications.md#emr-plan-ha-applications-list) で指定されているものを除き、オープンソースアプリケーションの高可用性は保証していません。
+ 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 構成](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html)」を参照してください。

**警告**  
ノードが 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` が 50% より大きく 100% より小さい場合、クラスターでプライマリノードが失われた可能性があります。このような状況では、Amazon EMR はプライマリノードの置換を試みます。
  + `MultiMasterInstanceGroupNodesRunningPercentage` が 50% を下回った場合、2 つのプライマリノードで障害が発生した可能性があります。このような状況では、クォーラムは失われており、クラスターを回復することはできません。このクラスターからデータを手動で移行する必要があります。

  詳細については、「[メトリクスでアラームを設定する](https://docs.aws.amazon.com/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html#UsingEMR_ViewingMetrics_Alarm)」を参照してください。