Amazon Web Services ブログ

Amazon EMR Managed Scaling のご紹介 – クラスターを自動的にサイズ変更してコストを削減する

AWS は、Amazon EMR マネージドスケーリングをリリースすることを発表します。これは、可能な限り低いコストで最高のパフォーマンスを得るためにクラスターのサイズを自動的に変更する新機能です。EMR マネージドスケーリングにより、クラスターの最小および最大のコンピューティング制限を指定し、Amazon EMR はそれらを自動的にサイズ変更して、最高のパフォーマンスとリソース使用率を実現します。EMR マネージドスケーリングは、クラスターで実行されているワークロードに関連する主要なメトリクスを継続的にサンプリングしています。EMR マネージドスケーリングは、Amazon EMR バージョン 5.30.1 以降の Apache Spark、Apache Hive、YARN ベースのワークロードでサポートされています。*

ユースケースとメリット

EMR マネージドスケーリングがリリースされる前は、ワークロードパターンを事前に予測するか、アプリケーションフレームワーク (Apache Spark や Apache Hive など) の深い理解に依存するカスタム Auto Scaling ルールを作成する必要がありました。ワークロードを予測したり、カスタムルールを作成したりするのは難しく、エラーが発生しやすくなります。クラスターリソースの不適切なサイジングは、多くの場合、SLA の未達成または予測できないパフォーマンス、またはリソースの不十分な活用とコスト超過の原因となる可能性があります。

EMR マネージドスケーリングは、ワークロードに基づいてクラスターリソースのサイズを自動的に決定することでこの問題を解決し、最高のパフォーマンスと最小のコストを実現します。クラスターをスケーリングするために、ワークロードパターンを予測したり、カスタムロジックを記述したりする必要はありません。EMR マネージドスケーリングは、ワークロードに基づいて主要なメトリクスを常にモニタリングし、クラスターのサイズを最適化して、リソースの使用率を最適化します。Amazon EMR は、ピーク時にクラスターをスケールアップし、アイドル期間中に適切にクラスターをスケールダウンして、コストを削減し、クラスターの容量を最適化して最高のパフォーマンスを実現できます。数回クリックするだけで、クラスターのコンピューティング制限を設定でき、残りは Amazon EMR が管理します。EMR マネージドスケーリングを使用すると、Amazon EMR は 1 分の粒度で高解像度のメトリクスも生成します。これにより、Amazon EMR マネージドスケーリングが受信ワークロードにどのように反応するかを視覚化できます。詳細については、「マネージドスケーリングのメトリクスを理解する」を参照してください。

例を挙げて説明するため、EMR マネージドスケーリングを使用して EMR クラスターを設定し、1 ~ 20 の間のノードにスケーリングしました (ノードあたり 16 VCPU)。(TPC-DS ベンチマークからの) 複数の並列 Spark ジョブを 30 分間隔でクラスターに送信しました。EMR クラスター設定をデフォルトに設定し、EMR マネージドスケーリングをオンにしました。次の Amazon CloudWatch ダッシュボードは、EMR マネージドスケーリングがクラスターをクラスター負荷に合わせてサイズ設定し、ピーク時にそれをスケールアップし、アイドル時にスケールダウンする方法を示しています。このユースケースで EMR マネージドスケーリングを有効にすることで、固定サイズのクラスターと比較してコストが 60% 削減されました。

EMR マネージドスケーリングとAuto Scaling の比較

Amazon EMR は、クラスターをスケーリングするのに 2 つの方法を提供します。その方法とは、2016 年にリリースされた Auto Scaling への Amazon EMR のサポートを使用するか、または EMR マネージドスケーリングを使用する方法です。Apache Spark、Apache Hive、または YARN ベースのアプリケーションを実行していて、完全マネージド型のエクスペリエンスが必要な場合は、EMR マネージドスケーリングの使用をお勧めします。クラスターで実行されているアプリケーションのカスタムメトリクスを含むカスタムルールを定義する必要がある場合は、Auto Scaling を使用する必要があります。次の表は、これらの方法の違いをまとめたものです。

EMR マネージドスケーリング Auto Scaling
スケーリングルールの管理 Amazon EMR マネージドアルゴリズムは、ワークロードに基づいて主要なメトリクスを常にモニタリングし、クラスターのサイズを最適化して、リソースを最大限に活用します。 カスタムメトリクスを選択し、スケーリングルールを適用できます。
サポートされているクラスタータイプ インスタンスグループとインスタンスフリート インスタンスグループのみ
設定の粒度 クラスターレベルの最小/最大制約 インスタンスグループレベルの設定
Amazon EMR の最小リリースバージョン 5.30+ 4.0+
スケーリングの決定を支援するメトリクス収集頻度 1 ~ 5 秒ごと 5 分ごと
評価頻度 5 ~ 10 秒ごと 5 分ごと
スケーリングアルゴリズム

設定は必要ありません。Amazon EMR は動的スケーリング戦略に従い、実際のクラスターのリソース要件を計算し、正しいスケールに直接到達します。これは、スケールアップとスケールダウンの両方のユースケースで発生します。Amazon EMR は、特定のクールダウン期間なしでスケールアップまたはスケールダウンの必要性を自動的に検出します。

 

Auto Scaling を使用すると、条件に違反した場合に追加または削除するインスタンスの固定数を定義できます。
サイズ変更間のクールダウン 連続してサイズを変更する間に独自のクールダウン期間を定義することを選択できます
カスタムメトリクスに基づくスケーリング カスタムアプリケーションまたはインフラストラクチャメトリクスを定義することを選択できます。カスタムスケーリングアクションとしきい値を定義することもできます。

 

EMR マネージドスケーリングが EMR インスタンスフリートをサポートするようになりました

スポットインスタンスは、AWS クラウドの予備の Amazon Elastic Compute Cloud (Amazon EC2) コンピューティングキャパシティで、オンデマンド料金と比較して最大 90% 節約して利用できます。Amazon EC2 は、容量を戻す必要がある場合、2 分間の通知でスポットインスタンスを中断できます。Spark やその他の YARN ベースのワークロードにはフォールトトレラントな性質があるため、一般的なユースケースは、スポットインスタンスを使用して Amazon EMR でデータ処理ワークロードを実行することです。詳細については、「Amazon EMR で Amazon EC2 スポットインスタンスを使用して、Apache Spark アプリケーションを実行するベストプラクティス」を参照してください。

EMR マネージドスケーリングでは、Amazon EMR インスタンスフリートのサポートも導入しています。スポットインスタンス、オンデマンドインスタンス、Savings Plan の一部であるインスタンスをすべて同じクラスター内でシームレスにスケーリングできます。

複数のインスタンスファミリーとサイズにまたがる複数のスポット容量プール (アベイラビリティーゾーン内の EC2 インスタンスタイプの組み合わせ) の容量を組み合わせると、スポット容量が中断されたり使用できなかったりした場合のワークロードへの影響が減少します。これをスポットの多様化と呼びます。Amazon EMR は、インスタンスフリートを設定できるようにすることで、この戦略を自動化します。Amazon EMR で大規模なデータ処理ワークロードを実行していて、ワークロードに耐障害性がある場合、スポットインスタンスを使用する推奨される方法は、スポットインスタンスでタスクフリートを使用してスケーリングすることです。さらに、Spark ドライバーや HDFS ノードなど、クラスターの非フォールトトレラント部分向けのコアフリートでオンデマンドインスタンスを使用することです。

EMR マネージドスケーリングでは、この設定パターンが自動的にサポートされます。そして Amazon EMR がスケールアウトアクティビティの必要性を検出すると、タスクフリートをスケーリングすることを選択します。これは実質的に、クラスターのコンピューティングキャパシティを増やすための安価なスケールアウトオプションを選択したことになります。インスタンスフリートでは、クラスター内のオンデマンドインスタンスとスポットインスタンスのターゲット容量を指定します。Amazon EMR がターゲットを満たすときに使用するフリートごとに最大 5 つの EC2 インスタンスタイプを指定できます。異なるアベイラビリティーゾーンに対して複数のサブネットを選択することもできます。クラスターが起動すると、Amazon EMR はターゲットが満たされるまでインスタンスをプロビジョニングします。Amazon EMR がクラスターを起動すると、提供されたサブネット、アベイラビリティーゾーン、インスタンスファミリー、およびサイズ全体を調べて、中断される可能性が最も低いクラスター容量を最小のコストでプロビジョニングします。EMR マネージドスケーリングを使用すると、インスタンスフリートのサイズを変更し、各インスタンスフリートにオンデマンドとスポットの制限を設定することもできます。詳細については、「インスタンスフリートの設定」を参照してください。

EMR マネージドスケーリングの設定

EMR マネージドスケーリングの設定は簡単です。EMR マネージドスケーリングを有効にし、クラスターノードのインスタンス数、または VCPU (インスタンスグループの場合) またはキャパシティーユニット (インスタンスフリートの場合) の最小および最大値の制限を設定するだけです。実行中のクラスターで、またはクラスターのプロビジョニング時に、マネージドスケーリングを有効にできます。詳細については、「Amazon EMR での EMR マネージドスケーリングの使用」を参照してください。

ノード割り当て戦略

EMR マネージドスケーリングでは、クラスターがスケールアップできる最小および最大容量を制御できます。これを制御できるパラメータは次のとおりです。

  • MinimumCapacityUnits – クラスターサイズの下限
  • MaximumCapacityUnits – クラスターサイズの上限
  • MaximumCoreCapacityUnits – コアノードグループの上限
  • MaximumOnDemandCapacityUnits – オンデマンドマーケットからプロビジョニングされる容量の上限

最後の 2 つのパラメータでは、コアノードまたはタスクノード (MaximumCoreCapacityUnits) をスケーリングするか、オンデマンドまたはスポットマーケット (MaximumOnDemandCapacityUnits) のインスタンスを使用するかを選択できます。これらのパラメータを使用して、コアとタスク、およびオンデマンドまたはスポット間で容量を分割できます。その点について考えるより簡単な方法は、線上のスライダーについて考えることです。

コアノードのみのスケーリング

このユースケースでは、クラスターに最小 5 ノード、最大 100 ノードがあります。最大コアノードを最大容量に、最大オンデマンドノードを最大に設定することで、コアノードのみをオンデマンドでのみスケーリングするように EMR マネージドスケーリングを指示します。次の図は、この設定を示しています。

タスクノードのみのスケーリング (オンデマンド)

最大コアを最小値に変更すると、タスクインスタンスを使用してノードをスケーリングするだけになります。このユースケースでは、クラスターはタスクノードとオンデマンドのみをスケーリングします。次の図は、この設定を示しています。

タスクノードのみのスケーリング (スポットインスタンス)

オンデマンドの最大容量を最小に変更すると、スポットノードを使用して、最小容量と最大容量の間でクラスターをスケーリングできます。最大コアもクラスターの最小サイズに設定されているため、スケーリングはタスクノードを使用した場合にのみ発生します。次の図は、この設定を示しています。

ベストプラクティス: コアノードをオンデマンドでスケーリングし、タスクノードをスポットでスケーリングする

ベストプラクティスとして、コアノード (HDFS があるため) をオンデマンドで使用し、タスクインスタンスをスポットインスタンスで使用することをお勧めします。コアノードには HDFS が含まれているため、ノードが突然失われると、ジョブのパフォーマンスが低下したり、データが失われたりする可能性があります。次の図は、クラスターがオンデマンドマーケットを使用してコアノードを最大コア容量にスケールアップし、残りをスポットマーケットのタスクノードを使用してスケールアップしているところを示しています。

まとめ

この記事では、EMR マネージドスケーリングについて説明しました。これにより、可能な限り低いコストで最高のパフォーマンスが得られるようにクラスターのサイズが自動的に変更されます。詳細については、「Amazon EMR での EMR マネージドスケーリングの使用」を参照するか、EMR マネージドスケーリングのデモをご覧ください。

*EMR 6.0 では EMR マネージドスケーリングをサポートしていませんが、後続のリリース 6.1+ でサポートします

 


著者について

Abhishek Sinha は、アマゾン ウェブ サービスのプリンシパルプロダクトマネージャーです。

 

 

 

 

 

Joseph Marques はアマゾン ウェブ サービスの EMR プリンシパルエンジニアです

 

 

 

 

 

Srinivas Addanki は、アマゾン ウェブ サービスのソフトウェア開発マネージャーです。

 

 

 

 

 

Vishal Vyas は、アマゾン ウェブ サービスのソフトウェア開発エンジニアです。