すべてのプロダクト
Search
ドキュメントセンター

E-MapReduce:ハードウェアとネットワーク

最終更新日:Jun 25, 2026

Alibaba Cloud EMR クラスターを作成する際、適切なハードウェア構成とネットワーク環境の設計は、クラスターのパフォーマンス、コスト効率、信頼性を確保する上で鍵となります。このトピックでは、ビッグデータ処理の要件に基づいて、高可用性サービス、ノード仕様、ネットワーク構成ソリューションを選択する方法について説明します。

高可用性サービスの選択

ビジネスシナリオと実際の要件に基づいて、高可用性機能を有効にするかどうかを選択できます。高可用性サービスを有効にすると、クラスターはマルチマスターノードモードを使用してシングルノードの障害リスクを排除し、分散およびフェールオーバーメカニズムによってサービスの継続性を確保します。

観点

シングルマスターノードクラスター

マルチマスターノードクラスター

シナリオ

  • テスト環境

  • 高可用性の要件が低い場合

  • 本番環境

  • 高可用性の要件が高い場合

主な機能

シングルノードアーキテクチャで、デプロイが簡単です。一方で、シングルノードの障害リスクがあります。

  • シングルノードの障害リスクを排除:マルチノードのクラスターアーキテクチャにより、他の利用可能なマスターノード へ切り替えることでサービスの継続性を確保します。

  • クラスターの高い信頼性:HDFS NameNode や YARN ResourceManager などのコアコンポーネントに対する高可用性構成をサポートします。

  • ハードウェア分離ECS デプロイメントセット を使用して、複数のマスターノードを別々の物理ハードウェアに分散配置します。これにより、基盤となるハードウェアに障害が発生した場合でも、複数のマスターノードが同時に障害となることを防止します。

障害復旧

自動復旧なし:トラブルシューティングと再起動には手動介入が必要です。

自動復旧:EMR サービスが、障害が発生したマスターノードを自動的に置換します。元のノードと同じ環境およびブートストラップアクションを構成します。

コスト

低コスト:構成が必要なマスターノードは 1 台のみです。

高コスト:マスターノードを 3 台構成する必要があります。これらのノードは分散システムのコンセンサスアルゴリズムによって多数決の意思決定メカニズムを実装し、オープンソースコンポーネント (ZooKeeper や HDFS など) の強整合性要件を満たし、シングルノードの障害を許容するとともに、スプリットブレインを回避します。

ノード仕様の選択

クラスター構成の手順は次のとおりです:

  1. ビジネスシナリオの決定:シナリオに基づいて選択します (例:データレイク、データ分析、リアルタイムデータストリーム、データサービス、またはカスタムクラスターシナリオ)。

  2. ストレージアーキテクチャの選択:シナリオに基づいて、コンピューティングとストレージの結合 (HDFS) を選択するか、コンピューティングとストレージの分離 (OSS-HDFS/OSS) アーキテクチャを選択するかを決定します。

  3. ノード仕様とディスクサイズの構成:

    1. ノード仕様の構成:選択したストレージアーキテクチャ、クラスター規模、ビジネス特性などの要因に基づいて、ノードタイプ (マスター、コア、タスクなど) ごとに適切な ECS インスタンスタイプ (汎用インスタンス、コンピューティング最適化インスタンス、メモリ最適化インスタンス、ビッグデータインスタンスファミリーなど) を選択します。

    2. ディスクサイズの構成:ストレージ容量を計算し、データ量と増加見込みに基づいて適切なディスクサイズを構成します。

データレイクシナリオ

コンピューティングとストレージの結合 (HDFS)

ノードタイプ

推奨仕様

マスター

クラスターを管理し、タスクを調整します。
デプロイされるサービス:NameNode、ResourceManager、HiveServer、HiveMetastore、SparkHistoryServer。
  • 通常:汎用インスタンスを使用し、クラウドディスクを選択します。

  • 小規模クラスター (≤ 8 インスタンス):8 コア、32 GiB。

  • 中規模から大規模クラスター:16 コア、64 GiB 以上。

  • HDFS ファイル数が非常に多い場合 (≥ 1,000 万):仕様は NameNode のメモリ要件を満たす必要があります。

コア

コンピューティング能力とストレージリソースを提供します。
デプロイされるサービス:DataNode、NodeManager。

コアノードのインスタンス仕様は、リソース要件に基づいて決定します。

  • ビジネスタイプの適合:Yarn タスクに必要な CPU とメモリの比率の要件に基づいてインスタンスタイプを選択します。

    • デフォルトシナリオ:汎用インスタンス。

    • CPU 集約型タスク (AI 推論トレーニングなど):コンピューティング最適化インスタンス。

    • メモリ集約型タスク (オフラインレポート分析など):メモリ最適化インスタンス。

  • HDFS のストレージ要件 (> 10 TB/ノード):ビッグデータインスタンスファミリー。このインスタンスタイプはローカルディスクをストレージとして使用するためストレージコストを削減できますが、ローカルディスクは自己管理が必要です。

  • メモリ容量の制約:ノードのメモリ仕様 > Yarn タスクの単一コンテナーのピークメモリ。

タスク

コンピューティング能力のみを提供し、データは保存しません。主に、コアノードのCPUとメモリを補うために使用します。
デプロイされるサービス:NodeManager。

ピーク時とオフピーク時があるシナリオでの推奨事項:

  • オフピーク時のコンピューティング要件に基づいて、固定のコアノード仕様を構成します。

  • ピーク需要に対応するため、弾力的なスケーリングを行うタスクノードの仕様はコアノードの仕様以上にします。

コンピューティングとストレージの分離 (OSS-HDFS/OSS)

ノードタイプ

推奨仕様

マスター

クラスターを管理し、タスクを調整します。
デプロイされるサービス:ResourceManager、HiveServer、HiveMetastore、SparkHistoryServer。

  • 通常:汎用インスタンスを使用し、クラウドディスクを選択します。

  • 小規模クラスター (≤ 8 インスタンス):8 コア、32 GiB。

  • 中規模から大規模クラスター:16 コア、64 GiB 以上。

コア

タスクノードと同様の機能で、データは保存しません。
デプロイされるサービス:NodeManager。

コアノードは弾力的なスケーリング機能をサポートしていません。コアノードは構成せず、タスクノードのみを使用することを推奨します。

タスク

コンピューティング能力を提供します。
デプロイされるサービス:NodeManager。
  • ビジネスタイプの適合:Yarn タスクに必要な CPU とメモリの比率に基づいてインスタンスタイプを選択します。

    • デフォルトシナリオ:汎用インスタンス。

    • CPU 集約型タスク (AI 推論トレーニングなど):コンピューティング最適化インスタンス。

    • メモリ集約型タスク (オフラインレポート分析など):メモリ最適化インスタンス。

  • メモリ容量の制約:ノードのメモリ仕様 > Yarn タスクの単一コンテナーのピークメモリ。

データ分析シナリオ

コンピューティングとストレージの結合

ノードタイプ

推奨仕様

マスター

クラスターを管理し、タスクを調整します。
デプロイされるサービス:StarRocks FE、Doris FE、Zookeeper。
  • 通常のシナリオ:汎用インスタンスを使用し、クラウドディスクを選択します。

  • 小規模クラスター (≤ 8 インスタンス):8 コア、32 GiB。

  • 中規模から大規模クラスター:16 コア、64 GiB 以上。

コア

コンピューティング能力とストレージリソースを提供します。
デプロイされるサービス:StarRocks BE、Doris BE、ClickhouseKeeper、ClickhouseServer。

コアノードのインスタンス仕様は、ビジネスのコンピューティング要件とデータストレージ量に関連します。

  • ストレージ量 ≤ 10 TB/ノード:インスタンス仕様は実際のビジネスのコンピューティング要件に関連します。

    • デフォルト:汎用インスタンスを使用し、クラウドディスクを選択します。

    • CPU 集約型タスク (計算処理が多い場合):コンピューティング最適化インスタンス。

    • メモリ集約型タスク (より大きなキャッシュが必要で、パフォーマンスを向上させたい場合):メモリ最適化インスタンス。

  • ストレージ量 > 10 TB/ノード:ビッグデータインスタンスファミリー。このインスタンスタイプはローカルディスクをストレージとして使用するためストレージコストを削減できますが、ローカルディスクは自己管理が必要です。

タスク

コンピューティング能力を提供します。
デプロイされるサービス:StarRocks CN。

StarRocks Compute Node のみがタスクノードへのデプロイをサポートします。StarRocks コンポーネントを使用しない場合、タスクノードを使用する必要はありません。

ピーク時とオフピーク時があるシナリオでの推奨事項:

  • オフピーク時のコンピューティング要件に基づいて、固定のコアノード仕様を構成します。

  • ピーク需要に対応するため、弾力的なスケーリングを行うタスクノードの仕様はコアノードの仕様以上にします。

コンピューティングとストレージの分離

コンピューティングとストレージの分離をサポートするのは StarRocks 3.x バージョンのみです。

ノードタイプ

推奨仕様

マスター

クラスターを管理し、タスクを調整します。
デプロイされるサービス:StarRocks FE、Zookeeper。
  • 通常のシナリオ:汎用インスタンスを使用し、クラウドディスクを選択します。

  • 小規模クラスター (≤ 8 インスタンス):8 コア、32 GiB。

  • 中規模から大規模クラスター:16 コア、64 GiB 以上。

タスク

コンピューティング能力を提供します。
デプロイされるサービス:StarRocks CN。

StarRocks のコンピューティングとストレージの分離アーキテクチャでは、コアノードはなく、タスクノードのみです。

  • デフォルト:汎用インスタンスを使用し、クラウドディスクを選択します。

  • CPU 集約型タスク (計算処理が多い場合):コンピューティング最適化インスタンス。

  • メモリ集約型タスク (より大きなキャッシュが必要で、パフォーマンスを向上させたい場合):メモリ最適化インスタンス。

インスタンス仕様は実際のビジネスのコンピューティング要件に基づいて決定し、一般的に 16 コア 64 GiB 以上を選択します。ノード数はビジネス要件に応じて弾力的にスケーリングできます。

リアルタイムデータストリームシナリオ

コンピューティングとストレージの結合 (HDFS)

ノードタイプ

推奨仕様

マスター

クラスターを管理し、タスクを調整します。
デプロイされるサービス:NameNode、ResourceManager、FlinkHistoryServer、Zookeeper。
  • 通常:汎用インスタンスを使用し、クラウドディスクを選択します。

  • 小規模クラスター (≤ 8 インスタンス):8 コア、32 GiB。

  • 中規模から大規模クラスター:16 コア、64 GiB 以上。

  • HDFS ファイル数が非常に多い場合 (≥ 100 万):仕様は NameNode のメモリ要件を満たす必要があります。

コア

コンピューティング能力とストレージリソースを提供します。
デプロイされるサービス:DataNode、NodeManager。

コアノードのインスタンス仕様は、ビジネスタイプとリソース要件に関連します。

  • ビジネスタイプの適合:Flink タスクに必要な CPU とメモリの比率に基づいてインスタンスタイプを選択します。

    • デフォルト:汎用インスタンス。

    • CPU 集約型タスク:コンピューティング最適化インスタンス。

    • メモリ集約型タスク:メモリ最適化インスタンス。

  • HDFS のストレージ要件 (> 10 TB/ノード):ビッグデータインスタンスファミリー。このインスタンスタイプはローカルディスクをストレージとして使用するためストレージコストを削減できますが、ローカルディスクは自己管理が必要です。

  • メモリ容量の制約:ノードのメモリ仕様 > Flink タスクにおける単一の JobManager または TaskManager のピークメモリ。

タスク

コンピューティング能力のみを提供し、データは保存しません。主に、コアノードのCPUとメモリを補うために使用します。
デプロイされるサービス:NodeManager。

ピーク時とオフピーク時があるシナリオでの推奨事項:

  • オフピーク時のコンピューティング要件に基づいて、固定のコアノード仕様を構成します。

  • ピーク需要に対応するため、弾力的なスケーリングを行うタスクノードの仕様はコアノードの仕様以上にします。

コンピューティングとストレージの分離 (OSS-HDFS/OSS)

ノードタイプ

推奨仕様

マスター

クラスターを管理し、タスクを調整します。
デプロイされるサービス:ResourceManager、FlinkHistoryServer、Zookeeper。
  • 通常:汎用インスタンスを使用し、クラウドディスクを選択します。

  • 小規模クラスター (≤ 8 インスタンス):8 コア、32 GiB。

  • 中規模から大規模クラスター:16 コア、64 GiB 以上。

コア

タスクノードと同様の機能で、データは保存しません。
デプロイされるサービス:NodeManager。

コアノードは弾力的なスケーリング機能をサポートしていません。コアノードは構成せず、タスクノードのみを使用することを推奨します。

タスク

コンピューティング能力を提供します。
デプロイされるサービス:NodeManager。
  • ビジネスタイプの適合:Flink タスクに必要な CPU とメモリの比率に基づいてインスタンスタイプを選択します。

    • デフォルト:汎用インスタンス。

    • CPU 集約型タスク:コンピューティング最適化インスタンス。

    • メモリ集約型タスク:メモリ最適化インスタンス。

  • メモリ容量の制約:ノードのメモリ仕様 > Flink タスクにおける単一の JobManager または TaskManager のピークメモリ。

データサービスシナリオ

コンピューティングとストレージの結合 (HDFS)

ノードタイプ

推奨仕様

マスター

クラスターを管理し、タスクを調整します。
デプロイされるサービス:NameNode、HMaster、Zookeeper。
  • 通常:汎用インスタンスを使用し、クラウドディスクを選択します。

  • 小規模から中規模クラスター (≤ 16 インスタンス):8 コア、32 GiB。

  • 大規模クラスター:16 コア、64 GiB 以上。

  • HDFS ファイル数が非常に多い場合 (≥ 1,000 万):仕様は NameNode のメモリ要件を満たす必要があります。

コア

コンピューティング能力とストレージリソースを提供します。
デプロイされるサービス:DataNode、HRegionServer。

コアノードのインスタンス仕様は、ビジネスのリクエスト量とストレージ量に関連します。

  • ビジネスのリクエスト量:汎用インスタンスを使用し、クラウドディスクを選択します。

    • 小規模クラスター (≤ 8 インスタンス):8 コア、メモリ 32 GiB。各ノードの QPS は 10,000 以下です。

    • 中規模から大規模クラスター:16 コア 64 GiB 以上。コアノード数は実際の状況に基づいて決定します。

  • HDFS のストレージ量 (> 10 TB/ノード):ビッグデータインスタンスファミリー。このインスタンスタイプはローカルディスクをストレージとして使用するためストレージコストを削減できますが、ローカルディスクは自己管理が必要です。

タスク

コンピューティング能力のみを提供し、データは保存しません。主に、コアノードのCPUとメモリを補うために使用します。
デプロイされるサービス:HRegionServer。

データサービスでは、データはコアノードに保存されるため、データローカリティを確保する観点から、通常はタスクノードは推奨されません。

コンピューティングとストレージの分離 (OSS-HDFS/OSS)

ノードタイプ

推奨仕様

マスター

クラスターを管理し、タスクを調整します。
デプロイされるサービス:NameNode、HMaster、Zookeeper。
  • 通常:汎用インスタンスを使用し、クラウドディスクを選択します。

  • 小規模から中規模クラスター (≤ 16 インスタンス):8 コア、32 GiB。

  • 大規模クラスター:16 コア、64 GiB 以上。

コア

コンピューティング能力とストレージリソースを提供します。
デプロイされるサービス:DataNode、HRegionServer。

OSS-HDFS/OSS を使用して HBase HLog を保存すると、書き込みパフォーマンスに大きな影響を及ぼします。HBase HLog は HDFS に保存することを推奨します。

コアノードのインスタンス仕様はビジネスのリクエスト量に関連します。汎用インスタンスを推奨し、ディスク容量は 500 GiB 以上としてください。

  • 小規模クラスター (≤ 8 インスタンス):8 コア、メモリ 32 GiB。各ノードの QPS は 10,000 以下です。

  • 中規模から大規模クラスター:16 コア 64 GiB 以上。コアノード数は実際の状況に基づいて決定します。

タスク

コンピューティング能力を提供します。
デプロイされるサービス:HRegionServer。

ピーク時とオフピーク時があるシナリオでの推奨事項:

  • 固定のコアノード + 弾力的なスケーリングを行うタスクノードの構成。

  • タスクノードの仕様はコアノードの仕様と一致させてください。

カスタムクラスターシナリオ

ビジネスに、オフライン ETL、リアルタイム ETL、複雑な集計分析、同時実行性の高いクエリサービスなど、複数の混在シナリオが含まれる場合:

  • 推奨アプローチ:複数のクラスタータイプを組み合わせるソリューション。特性の異なるクラスター (オフラインバッチ処理クラスター、リアルタイムストリーム処理クラスター、分析クラスター、クエリ高速化クラスターなど) を個別にデプロイすることで、リソース分離とシナリオ適合を実現できます。これにより、各タスクのパフォーマンスと安定性を確保します。

  • ビジネス規模が小さく、シナリオ間でリソース競合がない場合は、カスタムクラスターを選択します:柔軟な構成によりデプロイの複雑さを低減し、リソース使用率を向上させます。

コンピューティングとストレージの結合 (HDFS)

ノードタイプ

推奨仕様

マスター

クラスターの管理とタスクの調整を担当します。
  • 小規模クラスター (≤ 8 インスタンス):汎用インスタンス (8 コア、32 GiB) を使用し、クラウドディスクを選択します。

  • HDFS ファイル数が多い場合 (≥ 100 万):仕様は NameNode のメモリ要件を満たす必要があります。

コア

コンピューティング能力とストレージリソースを提供します。

コアノードのインスタンス仕様は、ビジネスタイプとリソース要件に関連します。

  • ビジネスタイプの適合:クラスタータスクに必要な CPU とメモリの比率に基づいてインスタンスタイプを選択します。

    • デフォルトシナリオ:汎用インスタンス。

    • CPU 集約型タスク:コンピューティング最適化インスタンス。

    • メモリ集約型タスク:メモリ最適化インスタンス。

  • ストレージ要件 (> 10 TB/ノード):ビッグデータインスタンスファミリー。このインスタンスタイプはローカルディスクをストレージとして使用するためストレージコストを削減できますが、ローカルディスクは自己管理が必要です。

  • メモリ容量の制約:ノードのメモリ仕様 > Max(Yarn タスクの単一コンテナーのピークメモリ、Flink タスクの単一 JobManager または TaskManager のピークメモリ)。

タスク

コンピューティング能力のみを提供し、データは保存しません。主に、コアノードのCPUとメモリを補うために使用します。

ピーク時とオフピーク時があるシナリオでの推奨事項:

  • オフピーク時のコンピューティング要件に基づいて、固定のコアノード仕様を構成します。

  • ピーク需要に対応するため、弾力的なスケーリングを行うタスクノードの仕様はコアノードの仕様以上にします。

コンピューティングとストレージの分離 (OSS-HDFS/OSS)

ノードタイプ

推奨仕様

マスター

クラスターを管理し、タスクを調整します。

小規模クラスター (≤ 8 インスタンス):汎用インスタンス (8 コア、32 GiB) を使用し、クラウドディスクを選択します。

コア

タスクノードと同様の機能で、データは保存しません。
  • データストレージが不要な場合は、弾力的なスケーリングを行うタスクノードのみを使用し、コアノードは構成しないことを推奨します。

  • HBase サービスが必要な場合:

    • 書き込みパフォーマンスを確保するため、HBase HLog は HDFS に保存することを推奨します。

    • 仕様:汎用インスタンス (16 コア、64 GiB)、ディスク容量 500 GiB 以上。

タスク

コンピューティング能力を提供します。

タスクノードのみを構成する場合:

  • ビジネスタイプの適合:Flink タスクに必要な CPU とメモリの比率に基づいてインスタンスタイプを選択します。

    • デフォルト:汎用インスタンス。

    • CPU 集約型タスク:コンピューティング最適化インスタンス。

    • メモリ集約型タスク:メモリ最適化インスタンス。

  • メモリ容量の制約:ノードのメモリ仕様 > Max(Yarn タスクの単一コンテナーのピークメモリ、Flink タスクの単一 JobManager または TaskManager のピークメモリ)。

コアノードとタスクノードの両方を構成する場合は、ピーク時とオフピーク時があるシナリオを考慮する必要があります:

  • 固定のコアノード + 弾力的なスケーリングを行うタスクノードの構成。

  • タスクノードの仕様はコアノードの仕様と一致させてください。

ネットワーク構成の推奨事項

項目

構成の推奨事項

VPC ネットワーク構成

  • 適切な VPC と [vSwitch] を選択し、将来の拡張に備えて十分な IP アドレスを確保できるように CIDR ブロックを計画してください。

  • [vSwitch] で利用可能な IP アドレス数を確認するには、VPC 管理コンソールにログインします。ナビゲーションペインで [vSwitch] を選択し、各 [vSwitch] の IPv4 CIDR ブロックと利用可能な IPv4 アドレス数を確認します。[vSwitch] の CIDR ブロックによって、利用可能な IP アドレス数が決まります。各 [vSwitch] では 5 つの IP アドレス (ネットワークアドレス、ゲートウェイアドレス、ブロードキャストアドレス、および Alibaba Cloud によって予約されたその他のアドレス) が予約されます。利用可能な IP アドレス数は 2^(32 - サブネットマスクのビット数) - 5 として計算されます。たとえば、/24 CIDR ブロックの IP アドレス総数は 256、利用可能数は 251 です。/20 CIDR ブロックの IP アドレス総数は 4,096、利用可能数は 4,091 です。

  • EMR クラスターを作成する前に、選択した [vSwitch] の利用可能な IP アドレス数が、デプロイ予定のノード数を上回っていることを確認してください。これにより、IP アドレスの枯渇によるエラスティックスケーリングの失敗を防止できます。[vSwitch] の CIDR ブロックは、作成後に変更できません。IP アドレス範囲を拡張するには、新しい [vSwitch] を作成し、クラスターを再作成する必要があります。

  • エラスティックノードの IP アドレス割り当て:タスクノードは ECS インスタンスです。スケーリング時に、システムは基盤となる ECS インスタンスを再作成し、VPC および [vSwitch] の CIDR ブロックから新しい IP アドレスを動的に割り当てます。新しい IP アドレスは以前と同一であることは保証されず、再利用される場合もあります。この動作は ECS の在庫状況とスケジューリングポリシーに依存します。

  • ネットワーク接続性:他のクラウドサービスとのネットワーク接続経路を計画してください。

セキュリティグループ構成

  • 最小権限の原則:セキュリティグループルールを適切に構成してください。必要なポートのみを開放し、インバウンドルールで信頼できる IP アドレスまたはネットワークセグメントからのアクセスのみを許可してください。これにより、クリプトマイニングなどの攻撃を防止できます。

  • 管理ポートの厳格な制御:SSH などの管理ポートに対して厳格なアクセス制御を設定し、クラスターのセキュリティを確保してください。

ネットワーク接続性の構成

  • ネットワークパフォーマンスの向上:データ量が多い場合は、内部帯域幅が大きいインスタンスの使用を検討してください。

  • ゾーン間トラフィックの削減:クラスターとデータソース間のネットワークトポロジを調整してください。

  • 外部アクセスの制御:外部アクセスが必要な場合は、NAT ゲートウェイまたは Elastic IP を使用してください。

付録:ECS インスタンスタイプ

利用可能な ECS インスタンスファミリーの特性、仕様、適用シナリオについては、インスタンスファミリーをご参照ください。EMR コンソールでノードインスタンスの仕様を構成する際の参考になります。

インスタンスタイプ

特徴

汎用

vCPU:メモリ = 1:4。略称は g シリーズです。

コンピューティング最適化

vCPU:メモリ = 1:2。より多くのコンピューティングリソースを提供します。略称は c シリーズです。

メモリ最適化

vCPU:メモリ = 1:8。より多くのメモリリソースを提供します。略称は r シリーズです。

ローカル SSD

vCPU:メモリ = 1:4。ローカル SSD ディスクを使用し、ランダム IOPS とスループットが高い一方で、データ損失のリスクがあります。このインスタンスタイプはマスターノードでは使用できません。略称は i シリーズです。

ビッグデータ

vCPU:メモリ = 1:4。ローカル SATA ディスクを使用し、ストレージのコスト効率が高く、大容量データ (TB レベルのデータ量) のシナリオで推奨されるインスタンスタイプです。略称は d シリーズです。

共有型

CPU を共有するインスタンスタイプです。大きな計算負荷に対して十分な安定性はなく、入門レベルの学習用途にのみ適しています。エンタープライズのお客様には推奨しません。このインスタンスタイプはタスクノードでのみ使用できます。