この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
コンバンハ、千葉（幸）です。
Amazon EMR に新たなスケーリングオプションが追加されました！細かいことは指定せずによしなにやってくれる EMR マネージドスケーリングです！
- Amazon EMR now supports Managed Scaling – automatically resizing clusters to lower cost
- Introducing Amazon EMR Managed Scaling – Automatically Resize Clusters to Lower Cost | AWS Big Data Blog
これまでのスケーリング設定がハードルが高くて手が出せなかったという方には朗報ですね！コストを減らしていきましょう！
目次
何が変わったのか
マネジメントコンソールの画面ベースで見てみましょう。
簡単に言うと、従来のスケーリング方式では ここ と ここ でそれぞれ……
これらをすべて設定する必要があったのが……
これだけ設定すれば良くなりました！
やりましたね！
Amazon EMR の構成要素
今回の追加されたスケーリング方式について理解を深めるために、そもそも EMR はどういった要素から構成されるかを確認しておきましょう。
クラスターとノード
EMR における最上位のコンポーネントはクラスターであり、クラスターは以下のノードから構成されます。
- マスターノード
- クラスターを管理するノード
- 他のノード間でのデータやタスクの分散を調整する
- クラスターを構成する上で必須
- 1台か、マルチマスターノード構成による 3 台のいずれか
- マスターノード 1 台だけで他のノードを持たないクラスターも構成可能
- コアノード
- タスクを実行するノード
- クラスター上のHadoop Distributed File System (HDFS) にデータを保存するソフトウェアコンポーネントを持つ
- マルチノードクラスターでは 1台以上必要
- タスクノード
- タスクを実行するのみで、 HDFS にデータを保存しないノード
- 省略可能
これらを表したイメージが以下です。
https://d1.awsstatic.com/webinars/jp/pdf/services/20191023_AWS-Blackbelt_EMR.pdf より。以下同様。
AWS ドキュメントは以下を参照してください。
インスタンスフリートまたはインスタンスグループ
クラスター内のノードは、役割ごとにグループもしくはフリートを構成します。
グループは正確にはユニフォームインスタンスグループと呼ばれます。以下からクラスターが構成されることになります。
- マスターインスタンスグループ
- グループ内のノードの追加不可
- グループの追加不可
- コアインスタンスグループ
- グループ内のノードの追加可能
- グループの追加不可
- タスクインスタンスグループ
- グループ内のノードの追加可能
- グループの追加可能
同一のグループ内のインスタンスは、以下の設定についてすべて同じものが採用されます。
- 購入オプション（オンデマンドかスポットか）
- インスタンスタイプ（メモリ、CPU）
- EBSストレージ
それに対して相対的に新しい概念が、インスタンスフリートです。
ノードのタイプごとにフリートが構成されるのは同様ですが、同一のフリート内でインスタンスタイプや購入オプションを組み合わせることができます。
希望する容量を満たすように、オンデマンドやスポット、インスタンスタイプを組み合わせながら EMR がノードをプロビジョニングしてくれるものです。
これらの詳細は以下ドキュメントを参照してください。
インスタンスフリートまたはユニフォームインスタンスグループでクラスターを作成する - Amazon EMR
Amazon EMR におけるスケーリング方式
クラスターやノード、グループやフリートについて理解を深めたところで、新旧のスケーリング方式を比較しましょう。
先に述べておくと、どちらの方式でもマスターノードのスケーリングには対応していません。スケーリングにより増減できるのはコアノードとタスクノードのみです。
比較内容についてはこちらのドキュメントの表をそのまま引用します。
| EMR マネージドスケーリング | カスタム自動スケーリング | |
|---|---|---|
| スケーリングポリシーとルール | ポリシーは必要ありません。EMR は、クラスターメトリクスを継続的に評価し、最適化されたスケーリング決定を行うことにより、自動スケーリングアクティビティを管理します。 | スケーリングアクティビティ、評価期間、クールダウン期間をトリガーする特定条件など、自動スケーリングポリシーとルールを定義および管理する必要があります。 |
| サポートされている EMR リリースバージョン | Amazon EMR バージョン 5.30.0 以降 (Amazon EMR バージョン 6.0.0 を除く) | Amazon EMR バージョン 4.0.0 以降 |
| サポートされているクラスター構成 | インスタンスグループまたはインスタンスフリート | インスタンスグループのみ |
| スケーリング制限の設定 | スケーリング制限は、クラスター全体に対して設定されます。 | スケーリング制限は、各インスタンスグループに対してのみ設定できます。 |
| メトリクス評価頻度 | 5 ～ 10秒ごと。メトリクスの評価を頻繁に行うことで、EMR によるスケーリング決定の精度が高くなります。 | 評価期間は 5 分単位でのみ定義できます。 |
| サポートされているアプリケーション | Spark、Hadoop、Hive、Flink などの YARN アプリケーションのみがサポートされています。Presto などの他のアプリケーションは現在サポートされていません。 | 自動スケーリングルールを定義するときに、サポート対象とするアプリケーションを選択できます。 |
ざっくり言うと以下のような特徴があります。
- ポリシーをユーザー側で定義する必要がなく、取得したメトリクスから最適なスケーリングを実行する
- インスタンスフリートにも適用できる
- リリースバージョンやアプリケーションなどいくつか制限あり
ポリシーを指定しなくて済むことがどのくらい楽なことかは、冒頭で載せた画面からも分かるでしょう。条件に合致するのであれば、マネージドスケーリングを使っていきたいですね。
EMR マネージドスケーリングのパラメータ
EMR マネージドスケーリングのパラメータとして以下の 4 つがあります。たったの 4 つです。しかもうち 2 つはオプションのため、指定しなくても大丈夫です。これはもう勝ったも同然ですね。
- Minimum (
MinimumCapacityUnits)- コアノードとタスクノードの合計の最小値
- Maximum (
MaximumCapacityUnits)- コアノードとタスクノードの合計の最大値
- On-Demand limit (
MaximumOnDemandCapacityUnits) （オプション）- オンデマンドで稼働するノードの最大値
- つまりこれを超えた分はスポットで稼働する
- Maximum core nodes (
MaximumCoreCapacityUnits) （オプション）- コアノードの最大数
- つまりこれを超えた分はタスクノードとして起動する
ここでは「ノード」と書きましたが、正確にはカウント対象となるのはユニットです。ユニットは、インスタンスグループとインスタンスフリートで考え方が異なります。
- インスタンスグループ
- インスタンス数もしくは vCPU コア数
- インスタンスフリート
- ユニット数
- 1 インスタンスあたり何ユニットかを定義する
これらの詳細については以下を参照してください。
Using EMR Managed Scaling in Amazon EMR - Amazon EMR
各パラメータを例えば以下のように設定すると、10ユニットまではオンデマンドでコアノードが立ち上がり、そこから残りの90ユニットはスポットでタスクノードが立ち上がる、といった設定となります。
コアノードは HDFS を持つことから、スポットによって途中で終了すると差し支えがあり、オンデマンドで稼働させることがベストプラクティスとされています。
https://aws.amazon.com/jp/blogs/big-data/introducing-amazon-emr-managed-scaling-automatically-resize-clusters-to-lower-cost/ より
こういったノード割り当てのシナリオについては以下を参照してください。
Understanding Node Allocation Strategy and Scenarios - Amazon EMR
やってみた
ここまでもろもろを確認してきたので、早速実際に EMR マネージドスケーリングを設定したクラスターを作成してみます。
とはいえ実際にスケーリングさせるところまではハードルが高そうなため、クラスターを作成するところまでをゴールとします。
クイックオプション
クラスターの作成オプションとして、クイックオプションと詳細オプションが用意されています。クイックオプションはいくつかのパラメータを決め打ちにすることでサクッと作成できるものです。
クイックオプションの場合デプロイ先のサブネットを選択できないため今回は採用しないのですが、どのように設定できるかだけ確認してみます。
[ Cluster Scaling ] にチェックを入れると、自動的にマネージドスケーリングが採用されます。ここでは 4 つのパラメータのうち、必須の 2 つだけが選択できるようになっています。
クイックですね。デフォルト VPC が無事であれば私もクイックオプションを使用したかもしれません。
詳細オプション
詳細オプションによるクラスターの作成は 4 ステップからなります。
ステップ 1 は特に変更を加えず次に進みます。
ステップ 2 ではハードウェアに関する設定を行います。グループかフリートかはここで選択できるのですが、今回はフリートを選択してみます。
ノードの設定をします。今回はコアノードに 2 オンデマンドユニットを指定してみました。（後から気付いたのですが、各インスタンスのカウント単位が 4 ユニットになっています。普通はここより低い数字は入れないですね。。）
[ Cluster Scaling ] にチェックを入れると、今回はフリートを選択したため、EMR マネージドスケーリングのみが表示されます。パラメータを適宜入力し、次へ進みます。（ここでたまたま Maximum を 4 ユニットにしていたので、事なきを得ました。）
ステップ 3 ではクラスター全般の設定を行います。ここは特に何もせず次に進みます。
ちなみにここで指定できるログの暗号化は、つい先日のアップデートでサポートされました。アップデートし過ぎじゃないですかね。
ステップ 4 はセキュリティに関する設定です。もちろん何も指定せず [ クラスターを作成 ] を力強く押します。
クラスターの作成が開始され、各ノードのプロビジョニングやブートストラップが行われます。一通り落ち着くと、このように見えます。
コアノードが 4 ユニットで実行されていることや、マネージドスケーリングが設定されていることが見てとれます。
[ ハードウェア ] タブでは、各ノードの詳細やスケーリングポリシーの確認、編集などができます。
EC2 インスタンスの画面からもそれぞれ確認できます。マスターノード、コアノードそれぞれ 1 台ずつ立ち上がっていました。 EMR により起動テンプレートが自動で生成され、それに基づいてインスタンスが作成されるようです。
スケーリング動作の確認はできないものの、ひとまずマネージドスケーリングを設定した EMR クラスターを作成できました！
終わりに
Amazon EMR で新たに使用できるようになったマネージドスケーリングについて確認しました。
従来のカスタム Auto Scaling は 2016年の11月に発表された機能のようで、そこから苦節 3 年半の時を経て新たな方式が誕生しました。これまでスケーリングを敬遠していた、インスタンスフリートを採用していたため使えなかった、という方はありがたく使っていきましょう。
冒頭のブログを機械翻訳したものですが、ユースケースによってはスケーリングなしの場合と比べてコストが大きく削減されるようですよ！
例を挙げて説明すると、EMRマネージドスケーリングを使用してEMRクラスターを構成し、ノードあたり16 VCPUで1から20ノードにスケーリングしました。（TPC-DSベンチマークからの）複数の並列Sparkジョブを30分間隔でクラスターに送信しました。EMRクラスター設定をデフォルトに設定し、EMR管理スケーリングをオンにしました。次のAmazon CloudWatchダッシュボードは、EMR Managed Scalingがクラスターをクラスター負荷に合わせてサイズ設定し、ピーク時にそれをスケールアップし、アイドル時にスケールダウンする方法を示しています。このユースケースでEMRマネージドスケーリングを有効にすると、固定サイズのクラスターと比較してコストが60％削減されました。
以上、千葉（幸）がお送りしました。
14
