Alibaba Cloud EMR クラスターを作成する際、適切なハードウェア構成とネットワーク環境の設計は、クラスターのパフォーマンス、コスト効率、信頼性を確保する上で鍵となります。このトピックでは、ビッグデータ処理の要件に基づいて、高可用性サービス、ノード仕様、ネットワーク構成ソリューションを選択する方法について説明します。
高可用性サービスの選択
ビジネスシナリオと実際の要件に基づいて、高可用性機能を有効にするかどうかを選択できます。高可用性サービスを有効にすると、クラスターはマルチマスターノードモードを使用してシングルノードの障害リスクを排除し、分散およびフェールオーバーメカニズムによってサービスの継続性を確保します。
観点 | シングルマスターノードクラスター | マルチマスターノードクラスター |
シナリオ |
|
|
主な機能 | シングルノードアーキテクチャで、デプロイが簡単です。一方で、シングルノードの障害リスクがあります。 |
|
障害復旧 | 自動復旧なし:トラブルシューティングと再起動には手動介入が必要です。 | 自動復旧:EMR サービスが、障害が発生したマスターノードを自動的に置換します。元のノードと同じ環境およびブートストラップアクションを構成します。 |
コスト | 低コスト:構成が必要なマスターノードは 1 台のみです。 | 高コスト:マスターノードを 3 台構成する必要があります。これらのノードは分散システムのコンセンサスアルゴリズムによって多数決の意思決定メカニズムを実装し、オープンソースコンポーネント (ZooKeeper や HDFS など) の強整合性要件を満たし、シングルノードの障害を許容するとともに、スプリットブレインを回避します。 |
ノード仕様の選択
クラスター構成の手順は次のとおりです:
ビジネスシナリオの決定:シナリオに基づいて選択します (例:データレイク、データ分析、リアルタイムデータストリーム、データサービス、またはカスタムクラスターシナリオ)。
ストレージアーキテクチャの選択:シナリオに基づいて、コンピューティングとストレージの結合 (HDFS) を選択するか、コンピューティングとストレージの分離 (OSS-HDFS/OSS) アーキテクチャを選択するかを決定します。
ノード仕様とディスクサイズの構成:
ノード仕様の構成:選択したストレージアーキテクチャ、クラスター規模、ビジネス特性などの要因に基づいて、ノードタイプ (マスター、コア、タスクなど) ごとに適切な ECS インスタンスタイプ (汎用インスタンス、コンピューティング最適化インスタンス、メモリ最適化インスタンス、ビッグデータインスタンスファミリーなど) を選択します。
ディスクサイズの構成:ストレージ容量を計算し、データ量と増加見込みに基づいて適切なディスクサイズを構成します。
データレイクシナリオ
コンピューティングとストレージの結合 (HDFS)
ノードタイプ | 推奨仕様 |
マスター クラスターを管理し、タスクを調整します。 デプロイされるサービス:NameNode、ResourceManager、HiveServer、HiveMetastore、SparkHistoryServer。 |
|
コア コンピューティング能力とストレージリソースを提供します。 デプロイされるサービス:DataNode、NodeManager。 | コアノードのインスタンス仕様は、リソース要件に基づいて決定します。
|
タスク コンピューティング能力のみを提供し、データは保存しません。主に、コアノードのCPUとメモリを補うために使用します。 デプロイされるサービス:NodeManager。 | ピーク時とオフピーク時があるシナリオでの推奨事項:
|
コンピューティングとストレージの分離 (OSS-HDFS/OSS)
ノードタイプ | 推奨仕様 |
マスター クラスターを管理し、タスクを調整します。 デプロイされるサービス:ResourceManager、HiveServer、HiveMetastore、SparkHistoryServer。 |
|
コア タスクノードと同様の機能で、データは保存しません。 デプロイされるサービス:NodeManager。 | コアノードは弾力的なスケーリング機能をサポートしていません。コアノードは構成せず、タスクノードのみを使用することを推奨します。 |
タスク コンピューティング能力を提供します。 デプロイされるサービス:NodeManager。 |
|
データ分析シナリオ
コンピューティングとストレージの結合
ノードタイプ | 推奨仕様 |
マスター クラスターを管理し、タスクを調整します。 デプロイされるサービス:StarRocks FE、Doris FE、Zookeeper。 |
|
コア コンピューティング能力とストレージリソースを提供します。 デプロイされるサービス:StarRocks BE、Doris BE、ClickhouseKeeper、ClickhouseServer。 | コアノードのインスタンス仕様は、ビジネスのコンピューティング要件とデータストレージ量に関連します。
|
タスク コンピューティング能力を提供します。 デプロイされるサービス:StarRocks CN。 | StarRocks Compute Node のみがタスクノードへのデプロイをサポートします。StarRocks コンポーネントを使用しない場合、タスクノードを使用する必要はありません。 ピーク時とオフピーク時があるシナリオでの推奨事項:
|
コンピューティングとストレージの分離
コンピューティングとストレージの分離をサポートするのは StarRocks 3.x バージョンのみです。
ノードタイプ | 推奨仕様 |
マスター クラスターを管理し、タスクを調整します。 デプロイされるサービス:StarRocks FE、Zookeeper。 |
|
タスク コンピューティング能力を提供します。 デプロイされるサービス:StarRocks CN。 | StarRocks のコンピューティングとストレージの分離アーキテクチャでは、コアノードはなく、タスクノードのみです。
インスタンス仕様は実際のビジネスのコンピューティング要件に基づいて決定し、一般的に 16 コア 64 GiB 以上を選択します。ノード数はビジネス要件に応じて弾力的にスケーリングできます。 |
リアルタイムデータストリームシナリオ
コンピューティングとストレージの結合 (HDFS)
ノードタイプ | 推奨仕様 |
マスター クラスターを管理し、タスクを調整します。 デプロイされるサービス:NameNode、ResourceManager、FlinkHistoryServer、Zookeeper。 |
|
コア コンピューティング能力とストレージリソースを提供します。 デプロイされるサービス:DataNode、NodeManager。 | コアノードのインスタンス仕様は、ビジネスタイプとリソース要件に関連します。
|
タスク コンピューティング能力のみを提供し、データは保存しません。主に、コアノードのCPUとメモリを補うために使用します。 デプロイされるサービス:NodeManager。 | ピーク時とオフピーク時があるシナリオでの推奨事項:
|
コンピューティングとストレージの分離 (OSS-HDFS/OSS)
ノードタイプ | 推奨仕様 |
マスター クラスターを管理し、タスクを調整します。 デプロイされるサービス:ResourceManager、FlinkHistoryServer、Zookeeper。 |
|
コア タスクノードと同様の機能で、データは保存しません。 デプロイされるサービス:NodeManager。 | コアノードは弾力的なスケーリング機能をサポートしていません。コアノードは構成せず、タスクノードのみを使用することを推奨します。 |
タスク コンピューティング能力を提供します。 デプロイされるサービス:NodeManager。 |
|
データサービスシナリオ
コンピューティングとストレージの結合 (HDFS)
ノードタイプ | 推奨仕様 |
マスター クラスターを管理し、タスクを調整します。 デプロイされるサービス:NameNode、HMaster、Zookeeper。 |
|
コア コンピューティング能力とストレージリソースを提供します。 デプロイされるサービス:DataNode、HRegionServer。 |
コアノードのインスタンス仕様は、ビジネスのリクエスト量とストレージ量に関連します。
|
タスク コンピューティング能力のみを提供し、データは保存しません。主に、コアノードのCPUとメモリを補うために使用します。 デプロイされるサービス:HRegionServer。 | データサービスでは、データはコアノードに保存されるため、データローカリティを確保する観点から、通常はタスクノードは推奨されません。 |
コンピューティングとストレージの分離 (OSS-HDFS/OSS)
ノードタイプ | 推奨仕様 |
マスター クラスターを管理し、タスクを調整します。 デプロイされるサービス:NameNode、HMaster、Zookeeper。 |
|
コア コンピューティング能力とストレージリソースを提供します。 デプロイされるサービス:DataNode、HRegionServer。 |
OSS-HDFS/OSS を使用して HBase HLog を保存すると、書き込みパフォーマンスに大きな影響を及ぼします。HBase HLog は HDFS に保存することを推奨します。 コアノードのインスタンス仕様はビジネスのリクエスト量に関連します。汎用インスタンスを推奨し、ディスク容量は 500 GiB 以上としてください。
|
タスク コンピューティング能力を提供します。 デプロイされるサービス:HRegionServer。 | ピーク時とオフピーク時があるシナリオでの推奨事項:
|
カスタムクラスターシナリオ
ビジネスに、オフライン ETL、リアルタイム ETL、複雑な集計分析、同時実行性の高いクエリサービスなど、複数の混在シナリオが含まれる場合:
推奨アプローチ:複数のクラスタータイプを組み合わせるソリューション。特性の異なるクラスター (オフラインバッチ処理クラスター、リアルタイムストリーム処理クラスター、分析クラスター、クエリ高速化クラスターなど) を個別にデプロイすることで、リソース分離とシナリオ適合を実現できます。これにより、各タスクのパフォーマンスと安定性を確保します。
ビジネス規模が小さく、シナリオ間でリソース競合がない場合は、カスタムクラスターを選択します:柔軟な構成によりデプロイの複雑さを低減し、リソース使用率を向上させます。
コンピューティングとストレージの結合 (HDFS)
ノードタイプ | 推奨仕様 |
マスター クラスターの管理とタスクの調整を担当します。 |
|
コア コンピューティング能力とストレージリソースを提供します。 | コアノードのインスタンス仕様は、ビジネスタイプとリソース要件に関連します。
|
タスク コンピューティング能力のみを提供し、データは保存しません。主に、コアノードのCPUとメモリを補うために使用します。 | ピーク時とオフピーク時があるシナリオでの推奨事項:
|
コンピューティングとストレージの分離 (OSS-HDFS/OSS)
ノードタイプ | 推奨仕様 |
マスター クラスターを管理し、タスクを調整します。 | 小規模クラスター (≤ 8 インスタンス):汎用インスタンス (8 コア、32 GiB) を使用し、クラウドディスクを選択します。 |
コア タスクノードと同様の機能で、データは保存しません。 |
|
タスク コンピューティング能力を提供します。 | タスクノードのみを構成する場合:
コアノードとタスクノードの両方を構成する場合は、ピーク時とオフピーク時があるシナリオを考慮する必要があります:
|
ネットワーク構成の推奨事項
項目 | 構成の推奨事項 |
VPC ネットワーク構成 |
|
セキュリティグループ構成 |
|
ネットワーク接続性の構成 |
|
付録: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 を共有するインスタンスタイプです。大きな計算負荷に対して十分な安定性はなく、入門レベルの学習用途にのみ適しています。エンタープライズのお客様には推奨しません。このインスタンスタイプはタスクノードでのみ使用できます。 |