デフォルトでは、Cloud Data Fusion はコンピューティング プロファイルとして Autoscale を使用します。ワークロードに最適なクラスタ ワーカー（ノード）の数を見積もることは困難であり、パイプライン全体で単一のクラスタサイズを使用することは多くの場合、理想的ではありません。Dataproc 自動スケーリングは、クラスタ リソースの管理を自動化するメカニズムを提供し、クラスタ ワーカー VM の自動スケーリングを実現します。詳細については、自動スケーリングをご覧ください。
プロファイルのリストが表示されているアプリケーションの [Compute config] ページに、[Total cores] 列があります。この列には、プロファイルのスケールアップが可能な最大 vCPU（例: Up to 84）が表示されています。
Dataproc コンピューティング プロファイルを使用する場合は、パイプライン サイズに基づいてクラスタサイズを管理できます。
マスターノード
マスターノードは、クラスタで実行されているパイプライン数または追加アプリケーションの数に比例してリソースを使用します。エフェメラル クラスタでパイプラインを実行する場合は、マスターノードに 2 つの CPU と 8 GB のメモリを使用します。永続クラスタを使用している場合、ワークフローに追いつくために、より大きなマスターノードが必要になる場合があります。より大きなマスターノードが必要なかどうかを把握するには、ノードのメモリと CPU の使用状況をモニタリングします。ワーカーノードのサイズは、2 つ以上の CPU と 8 GB のメモリにすることをおすすめします。より多くのメモリを使用するようにパイプラインを構成した場合は、より大きなワーカーを使用する必要があります。
実行時間を最小限に抑えるには、クラスタに、できるだけ多くの並列処理が可能なノードが十分にあることを確認してください。
ワーカー
以降のセクションでは、ワーカーノードのサイズ設定について説明します。
CPU とメモリ
ワーカーノードのサイズは、少なくとも 2 つの CPU と 8 GB のメモリにすることをおすすめします。より多くのメモリを使用するようにパイプラインを構成した場合は、より大きなワーカーを使用します。たとえば、4 CPU 15 GB のワーカーノードの場合、各ワーカーには YARN コンテナの実行に 4 CPU と 12 GB が使用されます。パイプラインが 1 CPU、8 GB のエグゼキュータを実行するように構成されている場合、YARN はワーカーノードごとに複数のコンテナを実行できません。各ワーカーノードには、何も実行できないため、3 個の CPU と 4 GB が余分になります。クラスタのリソース使用率を最大化するには、YARN メモリと CPU を Spark エクゼキュータごとに必要な量の正確な倍数にする必要があります。YARN の yarn.nodemanager.resource.memory-mb プロパティを確認すると、各ワーカーが YARN 用に予約したメモリ量を確認できます。
Dataproc を使用している場合、YARN コンテナで使用できるメモリは VM メモリの約 75% になります。最小 YARN コンテナサイズも、ワーカー VM のサイズに応じて調整されます。一般的なワーカーサイズとそれに対応する YARN 設定を次の表に示します。
| ワーカー CPU | ワーカーのメモリ（GB） | YARN ノードのメモリ（GB） | YARN の最小割り当てメモリ（MB） |
|---|---|---|---|
| 1 | 4 | 3 | 256 |
| 2 | 8 | 6 | 512 |
| 4 | 16 | 12 | 1024 |
| 8 | 32 | 24 | 1024 |
| 16 | 64 | 51 | 1024 |
Spark は、パイプラインに設定されたエグゼキュータのメモリよりも多くのメモリをリクエストし、YARN はそのリクエストされた量を切り上げます。たとえば、エグゼキュータのメモリを 2,048 MB に設定し、spark.yarn.executor.memoryOverhead の値を指定していない場合、デフォルトの 384 MB が使用されます。つまり、Spark はエグゼキュータごとに 2, 048 MB + 384 MB をリクエストします。これは、YARN の最小割り当ての正確な倍数に切り上げられます。8 GB ワーカーノードで実行する場合、YARN の最小割り当てが 512 MB であるため、2.5 GB に切り上げられます。つまり、各ワーカーは 2 つのコンテナを実行でき、使用可能なすべての CPU を使用しますが、1 GB の YARN メモリ（6 GB - 2.5 GB - 2.5 GB）は使用されません。つまり、ワーカーノードのサイズを実際に少し小さくしたり、エグゼキュータに少しメモリを割り当てたりできます。16 GB ワーカーノードで実行する場合、YARN の最小割り当てが 1,024 MB であるため、2,048 MB + 1,024 MB は 3 GB に切り上げられます。つまり、各ワーカーノードは、すべての CPU と YARN メモリを使用して 4 つのコンテナを実行できます。
次の表に、一般的なエグゼキュータのサイズに基づく推奨されるワーカーのサイズを示します。
| Executor CPU | エグゼキュータのメモリ（MB） | ワーカー CPU | ワーカーのメモリ（GB） |
|---|---|---|---|
| 1 | 2048 | 4 | 15 |
| 1 | 3072 | 4 | 21 |
| 1 | 4096 | 4 | 26 |
| 2 | 8192 | 4 | 26 |
たとえば、26 GB のワーカーノードは、YARN コンテナの実行に使用できる 20 GB のメモリに変換されます。エグゼキュータのメモリが 4 GB に設定されている場合、オーバーヘッドとして 1 GB が追加されます。つまり、エグゼキュータごとに 5 GB の YARN コンテナが使用されます。つまり、ワーカーは追加のリソースを残さずに 4 つのコンテナを実行できます。ワーカーのサイズを増やすこともできます。たとえば、エグゼキュータのメモリが 4,096 GB に設定されている場合、8 個の CPU と 52 GB のメモリを備えたワーカーでも適切に機能します。Compute Engine VM では、コア数に基づいて VM に割り当てることができるメモリ量が制限されます。たとえば、4 コアの VM には、7.25 GB 以上のメモリと 26 GB 以下のメモリが必要です。つまり、1 つの CPU と 8 GB のメモリを使用するように設定されたエグゼキュータは、VM で 2 つの CPU と 26 GB のメモリを使用します。代わりに、エグゼキュータが 2 つの CPU と 8 GB のメモリを使用するように構成されている場合、すべての CPU が使用されます。
ディスク
ディスクは一部のパイプラインでは重要ですが、すべてのパイプラインで重要というわけではありません。パイプラインにシャッフルが含まれていない場合、ディスクは Spark のメモリが不足し、データをディスクにスピルする必要がある場合にのみ使用されます。このようなタイプのパイプラインでは、通常、ディスクのサイズとタイプはパフォーマンスに大きな影響を与えません。パイプラインが大量のデータをシャッフルしている場合は、ディスク パフォーマンスが重要になります。Dataproc を使用している場合は、ディスクサイズがディスクサイズに応じてスケールアップされるため、少なくとも 1 TB のディスクサイズを使用することをおすすめします。ディスク パフォーマンスの詳細については、パフォーマンス要件を満たすようにディスクを構成するをご覧ください。
ワーカーの数
実行時間を最小限に抑えるには、できるだけ多くの処理を並列で実行できるように、クラスタが十分な大きさであることを確認してください。たとえば、パイプライン ソースが 100 個の分割を使用してデータを読み取る場合は、100 個のエグゼキュータを一度に実行できる十分な大きさのクラスタが必要です。
クラスタのサイズが小さすぎるかどうかを確認する最も簡単な方法は、YARN の保留中メモリの経時的な変化を確認することです。Dataproc を使用している場合、グラフはクラスタの詳細ページにあります。
保留中のメモリが長時間高くなっている場合は、ワーカーの数を増やして、その分の容量をクラスタに追加できます。上記の例では、最大レベルの並列処理を実現するために、クラスタを 28 GB 程度増やす必要があります。
高度な柔軟性モード（EFM）
EFM を使用すると、データのシャッフルにプライマリ ワーカーノードのみを使用するように指定できます。セカンダリ ワーカーは中間シャッフル データの責任を負わなくなったため、クラスタから削除されても、Spark ジョブで遅延やエラーが発生することはありません。プライマリ ワーカーはスケールダウンされないため、クラスタはより安定して効率的にスケールダウンされます。静的クラスタでシャッフルを含むパイプラインを実行する場合は、EFM を使用することをおすすめします。
EFM の詳細については、Dataproc の高度な柔軟性モードをご覧ください。