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

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

最終更新日:Jun 10, 2025

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

高可用性サービスの選択

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

ディメンション

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

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

シナリオ

  • テスト環境

  • 低可用性のニーズ

  • 本番環境

  • 高可用性のニーズ

コア機能

シングルノードアーキテクチャ、シンプルなデプロイメント。シングルノードの障害リスク。

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

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

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

フェイルバック

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

自動フェイルバック:EMR サービスは、障害が発生したマスターノードを自動的に置き換えます。元のノードと同じ環境とブートストラップ操作を構成します。

コスト

低コスト:構成が必要なマスターノードは 1 つだけです。

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

ノード仕様の選択

クラスタの構成プロセスは次のとおりです。

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

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

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

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

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

データレイクシナリオ

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

ノードタイプ

推奨仕様

Master

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

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

  • 中規模から大規模クラスタ:≥ 16 コアおよび 64 GiB。

  • HDFS ファイル数が膨大(≥ 1,000 万):仕様は NameNode のメモリ要件を満たしている必要があります。

Core

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

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

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

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

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

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

  • HDFS ストレージ要件(> 10 TB/ノード):ビッグデータインスタンスファミリ。このインスタンスタイプは、ストレージにローカルディスクを使用するため、ストレージコストが削減されますが、ローカルディスクのセルフメンテナンスが必要です。

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

Task

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

ピークバレーシナリオの推奨事項:

  • 低いバレーコンピューティング要件に基づいて固定 Core ノード仕様を構成します。

  • ピーク需要に対応するために、Elastic Task ノード仕様 ≥ Core ノード仕様。

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

ノードタイプ

推奨仕様

Master

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

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

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

  • 中規模から大規模クラスタ:≥ 16 コアおよび 64 GiB。

Core

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

Core ノードは、弾性スケーリング機能をサポートしていません。Task ノードのみを使用し、Core ノードを構成しないことをお勧めします。

Task

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

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

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

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

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

データ分析シナリオ

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

ノードタイプ

推奨仕様

Master

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

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

  • 中規模から大規模クラスタ:≥ 16 コアおよび 64 GiB。

Core

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

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

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

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

    • CPU 集約型タスク(多くの計算操作を含む):コンピューティング最適化インスタンス。

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

  • ストレージ容量 > 10 TB/ノード:ビッグデータインスタンスファミリ。このインスタンスタイプは、ストレージにローカルディスクを使用するため、ストレージコストが削減されますが、ローカルディスクのセルフメンテナンスが必要です。

Task

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

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

ピークバレーシナリオの推奨事項:

  • 低いバレーコンピューティング要件に基づいて固定 Core ノード仕様を構成します。

  • ピーク需要に対応するために、Elastic Task ノード仕様 ≥ Core ノード仕様。

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

StarRocks 3.x バージョンのみが、分離ストレージとコンピューティングをサポートしています。

ノードタイプ

推奨仕様

Master

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

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

  • 中規模から大規模クラスタ:≥ 16 コアおよび 64 GiB。

Task

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

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

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

  • CPU 集約型タスク(多くの計算操作を含む):コンピューティング最適化インスタンス。

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

インスタンスの仕様は、実際のビジネスコンピューティング要件に基づいて評価する必要があり、通常は ≥16 コア 64 GiB を選択します。ノードの数は、ビジネス要件に応じて弾力的にスケーリングできます。

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

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

ノードタイプ

推奨仕様

Master

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

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

  • 中規模から大規模クラスタ:≥ 16 コアおよび 64 GiB。

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

Core

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

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

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

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

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

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

  • HDFS ストレージ要件(> 10 TB/ノード):ビッグデータインスタンスファミリ。このインスタンスタイプは、ストレージにローカルディスクを使用するため、ストレージコストが削減されますが、ローカルディスクのセルフメンテナンスが必要です。

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

Task

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

ピークバレーの推奨事項:

  • 低いバレーコンピューティング要件に基づいて固定 Core ノード仕様を構成します。

  • ピーク需要に対応するために、Elastic Task ノード仕様 ≥ Core ノード仕様。

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

ノードタイプ

推奨仕様

Master

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

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

  • 中規模から大規模クラスタ:≥ 16 コアおよび 64 GiB。

Core

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

Core ノードは、弾性スケーリング機能をサポートしていません。Task ノードのみを使用し、Core ノードを構成しないことをお勧めします。

Task

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

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

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

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

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

データサービスシナリオ

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

ノードタイプ

推奨仕様

Master

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

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

  • 大規模クラスタ:≥ 16 コアおよび 64 GiB。

  • HDFS ファイル数が膨大(≥ 1,000 万):仕様は NameNode のメモリ要件を満たしている必要があります。

Core

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

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

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

    • 小規模クラスタ(≤ 8 インスタンス):8 コア 32 GiB、Core ノードの数 ≤ 8、ノードあたりの QPS ≤ 10000。

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

  • HDFS ストレージ容量(> 10 TB/ノード):ビッグデータインスタンスファミリ。このインスタンスタイプは、ストレージにローカルディスクを使用するため、ストレージコストが削減されますが、ローカルディスクのセルフメンテナンスが必要です。

Task

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

データサービスでは、データは Core ノードに保存されるため、データの局所性を確保するために、通常は Task ノードは推奨されません。

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

ノードタイプ

推奨仕様

Master

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

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

  • 大規模クラスタ:≥ 16 コアおよび 64 GiB。

Core

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

OSS-HDFS/OSS を使用して HBase HLog を保存すると、書き込みパフォーマンスに大きな影響があります。HBase HLog は HDFS に保存することをお勧めします。

Core ノードインスタンスの仕様は、ビジネスリクエスト量に関連しています。汎用インスタンスをお勧めします。ディスク容量は ≥ 500 GiB です。

  • 小規模クラスタ(≤ 8 インスタンス):8 コア 32 GiB、Core ノードの数 ≤ 8、ノードあたりの QPS ≤ 10000。

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

Task

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

ピークバレーシナリオの推奨事項:

  • 固定 Core ノード + 弾性 Task ノードモード。

  • Task ノードの仕様は、Core ノードの仕様と一致する必要があります。

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

オフライン ETL、リアルタイム ETL、複雑な集計分析、高並列クエリサービスなど、複数の混合シナリオがビジネスに関係する場合:

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

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

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

ノードタイプ

推奨仕様

Master

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

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

コア

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

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

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

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

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

  • ストレージ要件 ( > 10 TB/ノード): ビッグデータインスタンスファミリ。このインスタンスタイプは、ストレージにローカルディスクを使用するため、ストレージコストが削減されますが、ローカルディスクのセルフメンテナンスが必要です。

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

タスク

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

ピークバレーシナリオの推奨事項:

  • 低いバレーコンピューティング要件に基づいて、固定コアノード仕様を構成します。

  • ピーク需要に対応するために、Elastic タスクノードの仕様 ≥ コアノードの仕様。

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

ノードタイプ

推奨仕様

Master

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

小規模クラスター(8 インスタンス以下):汎用インスタンス 8 コアおよび 32 GiB、クラウドディスクを選択。

コア

タスクノードと同様の機能で、データを保存しません。
  • データストレージが不要な場合は、コアノードを構成せずに、Elastic タスクノードのみを使用することをお勧めします。

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

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

    • 仕様: 汎用インスタンス 16 コアおよび 64 GiB、ディスク容量 ≥ 500 GiB。

タスク

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

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

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

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

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

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

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

コアノードとタスクノードの両方が構成されている場合は、ピークバレーシナリオを考慮する必要があります。

  • 固定コアノード + 弾性タスクノードモード。

  • タスクノードの仕様は、コアノードの仕様と一致している必要があります。

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

主要ディメンション

構成の推奨事項

VPC ネットワーク構成

  • 十分な IP アドレスリソースを確保する: 適切な VPC とスイッチを選択します。ネットワークセグメントを計画する際に拡張スペースを確保します。

  • ネットワーク接続性: 他のクラウドサービスとのネットワーク接続パスを計画します。

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

  • 最小権限の原則: セキュリティグループルールを合理的に構成します。必要なポートのみを開き、信頼できる IP アドレスまたはネットワークセグメントからのアクセスのみを許可するようにインバウンドルールを設定します。これは、暗号通貨マイニングなどの攻撃を防ぐためです。

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

ネットワーク接続構成

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

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

  • 外部アクセス制御: 外部アクセス機能が必要な場合は、NAT Gateway または 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 を共有するインスタンスタイプで、大きな計算負荷に対して十分に安定しておらず、エントリーレベルの学習にのみ適しています。企業のお客様にはお勧めしません。このインスタンスタイプはタスクノードでのみ使用できます。