Amazon EMR クラスター容量の見積り

Amazon EMR はサイズ変更可能なプラットフォームですが、クラスターのサイズを適切に設定することが重要です。適切なサイズを設定することで、クラスターのサイズが小さければクラスターが遅くなり、大きすぎればコストが高くなるのを防ぐことができます。ワークロードに必要なノードの数とタイプを計算すると、このような問題を予測できます。

プライマリノード

このタイプのノードは、データやプロセスの分散を調整する役割を担っています。前述のように、プライマリノードの計算要件は少ないです。単一のプライマリノードを使用して Amazon EMR クラスターを管理できます。ただし、単一障害点を避けるために最大 3 つのプライマリノードを使用できます。1 つのプライマリ ノードに障害が発生した場合、Amazon EMR は他の 2 つのプライマリ ノードのいずれかにフェイルオーバーします。

コアノードとタスクノード

コアノードとタスクノードの違いは、タスクノードがデータを保存しないことです。タスクノードは並列計算タスクを実行する能力のみを提供します。

コアノードとタスクノードの数を計算するには、データのサイズとおおよそのメモリ使用量を把握しておく必要があります。

コアノード

コアノードは、データを処理するタスクを実行し、Hadoop 分散ファイルシステム (HDFS) にデータを保存する役割を担います。コアノードの容量を計算するには、コアノードの数を定義し、そのノードの数に各ノードの Amazon Elastic Block Store (Amazon EBS) ストレージを掛けます。

例えば、1 TiB のデータを処理するために 10 個のコアノードを定義し、64 GiB の Amazon EBS ストレージを備えた m5.xlarge インスタントタイプがある場合、10 nodes × 64 GiB、つまり 640 GiB の容量になります。HDFS の レプリケーション係数 3 に基づくと、データサイズはノードで 3 回複製されるため、1 TiB のデータには 3 TiB の容量が必要です。この例には 640 GiB しかないため、容量が 3 TiB になるまでノード数を増やすか、インスタンスタイプを変更する必要があります。

m5.4xlarge インスタンスタイプには 256 GiB のストレージがあります。m5.4xlarge インスタンスタイプに変更して 12 個のインスタンスを選択すると、十分な容量を確保できます。

12 instances × 256 GiB of storage = 3072 GiB = 3 TiB available

タスクノード

タスクノードはタスクのみを実行します。データは保存されません。タスクノードの数を計算するには、メモリ使用量の見積りが必要です。この容量は、コアノードとタスクノードに分けることができます。必要なタスクノードの数を計算するには、前のステップで計算したコアノードによって得られたメモリをメモリ使用量から差し引きます。

メモリの範囲を拡張するには、必要なメモリを 3 倍するのがベストプラクティスです。

20 GiB ずつのプロセスが 28 個あるとします。

3 × 28 processes × 20 GiB of memory = 1680 GiB of memory

この例では、コアノードには 64 GiB のメモリ (m5.4xlarge インスタンス) があります。コアノードは 64 GiB × 12 nodes = 768 GiB of memory を提供しますが、この例では十分ではありません。

不足分を特定するには、必要な合計メモリからコアノードのメモリを差し引きます。

1680 GiB – 768 GiB core node memory = 912 GiB memory shortage.

タスクノードは残りの 912 GiB のメモリを提供できます。この例では、タスクノードには 32 GiB のメモリ (m5.2xlarge インスタンス) があります。必要なタスクノードの数を求めるには、不足しているメモリをインスタンスタイプのメモリで割ります。

912 GiB/32 GiB = 28.5 task nodes

タスクノードには端数を取ることができないため、29 個のタスクノードを切り上げる必要があります。