こちらはフロムスクラッチ Advent Calendar 2017の3日目の記事です。
EEEEEEEEEEEEEEEEEEEE MMMMMMMM MMMMMMMM RRRRRRRRRRRRRR
E::::::::::::::::::E M:::::::M M:::::::M R::::::::::::::R
EE:::::EEEEEEEEE:::E M::::::::M M::::::::M R:::::RRRRRR:::::R
E::::E EEEEE M:::::::::M M:::::::::M RR::::R R::::R
E::::E M::::::M:::M M:::M::::::M R:::R R::::R
E:::::EEEEEEEEEE M:::::M M:::M:::M M:::::M R:::RRRRRR:::::R
E::::::::::::::E M:::::M M:::::M M:::::M R:::::::::::RR
E:::::EEEEEEEEEE M:::::M M:::M M:::::M R:::RRRRRR::::R
E::::E M:::::M MMM M:::::M R:::R R::::R
E::::E EEEEE M:::::M M:::::M R:::R R::::R
EE:::::EEEEEEEE::::E M:::::M M:::::M R:::R R::::R
E::::::::::::::::::E M:::::M M:::::M RR::::R R::::R
EEEEEEEEEEEEEEEEEEEE MMMMMMM MMMMMMM RRRRRRR RRRRRR
当記事に興味を持っていただきありがとうございます。
この記事では、AWS EMR利用者向けにスポットインスタンスを使いつつも、それら安定的に稼働させることを目指して私が取り組んでいることを紹介する記事です。
AWS EMRが何モノで、何をすることできるのか、ということは知っていることを前提として記載していますので、ご了承ください。（その辺を知りたい方は、記事末尾にリンクくっつけときますのでどうぞ。）
そもそもスポットインスタンスとは何なのか
この辺りの紹介記事は星の数ほどありますが、改めて紹介しておきます。
AWS EMRを特に何も考えずに採用すると、オンデマンドと呼ばれる課金形態で構築され、インスタンスサイズごとに定義されている固定額（以下、オンデマンド価格）が利用時間に応じて課金されていきます。
価格表を見ると、1時間単位での課金額が記載されていますが、実際には秒単位での課金となるようです。（最近変わったそうです：AWSの方からの情報）
一方でスポットインスタンスは、AWS EMRに限らずAmazon EC2などのサービスででも使用できる利用形態のオプションの1つで、AWSの余剰インスタンスを入札制で安価に利用できるというものです。
その値引率は・・・オンデマンド比で最大で90%にもなります。
ものすごい割引率ですが、Amazonからすると、余剰リソースを腐らせておくぐらいだったら、安くてもいいから使ってもらったほうがいい、ということなのでしょう。
スポットインスタンスの設定方法
ここではAWSコンソール上から設定する方法について述べます。
-
スポットインスタンスはEMRクラスター作成時に、クイックオプションでは選択することができないため、作成フォーム上部の「詳細オプション」を選択します。
-
「ステップ2：ハードウェア」の項目で、EMRクラスターの各ノードに対して「スポット」を選択します。
-
あとはよしなに作ります。
-
作成した後に確認する場合はスポットの詳細画面を開き、「ハードウェア」タブを選択することで確認できます。
スポットインスタンスのデメリット
メリットは前述の通り安価であることです。が、しかしデメリットもあります。それは安定性です。
スポットインスタンスは前述の通り、余剰リソースに対する入札制であるため、需給のバランスによって課金額（以下、スポット価格）が増減します。
価格決定のロジックは以下のようになっているようです。（公式ドキュメント、及びAWSの方からの情報）
- AWS全体で抱えているリソースの中から、オンデマンドに割り当てられていないものを、入札額が高い人から順に割り当てる。
- 実際に割り当てられた人の中でもっとも入札額が低い人の入札額が、その時点での価格となる。（図の例では$2.50を入札額に設定していた人であっても、実際には$0.03が課金される。）
[価格決定のロジック例]
なお、上図でも表現しているのですが、オンデマンドとスポットは同じリソースプールを共有するため、スポット価格はオンデマンドを使っているユーザーが増加した場合でもスポット価格は上昇します。
この価格決定のロジックによって、このスポット価格がオンデマンド価格を超えてしまう（最大でオンデマンド価格の10倍程度まで上昇する）こともあるのです。（キャプチャ参照）
[スポットインスタンス価格変動状況例]
しかし、キャプチャから見てみたいただいても分かる通り、一時的に高騰することもあるものの、総じて言えば安価で稼働させていくことができます。
スポット価格高騰時の振る舞い
では、このスポット価格が入札額を超えるとどうなるか、ですが、
【起動時に、スポット価格が設定されている入札額を超えている】
EMRインスタンスは起動中の状態となり、各ノード（マスター・コア・タスク）はスポット価格が入札額以下になるまでプロビジョニング状態で待機する。
【起動後に、スポット価格が設定されている入札額を超えた】
入札額を超えてから、2分後にEMRインスタンスは強制的に停止する。
という振る舞いになります。
Amazon EC2とEMRのスポットインスタンス特性の違い
冒頭でAmazon EC2でもスポットインスタンスがあるよ、と述べましたが、EMRとEC2のスポットインスタンスは同じなのか、それとも違うのか・・・
結論から述べれば"ほぼ"同じです。なぜなら、EMRはAmazon EC2の上で稼働するサービスだからです。結局のところ、スポットインスタンスの入札という名の札束での殴り合いは、EC2のリソースを奪い合っているのとほぼ同義だと言えます。
唯一異なるのはEC2はそれ単独のインスタンスで存在するのに対し、EMRは複数のEC2インスタンスによって構成されるということです。なので、前述のようにスポットインスタンスの価格が高騰して落ちるパターンにも、一部だけ落ちるなどいくつかのパターンが考えられます。
そして、そのパターンによってEMRクラスタのその後の振る舞いが異なります。
以下がそれを端的にまとめた表です。
| マスターノード | コアノード | タスクノード | 振る舞い |
|---|---|---|---|
| ◯ | ◯ | × | タスクノードの再起動を試みる |
| ◯ | × | ◯ | コアノードの再起動を試みる |
| ◯ | × | × | タスクノードとコアノードの再起動を試みる |
| × | * | * | EMRクラスタは終了する |
◯：生存 ×:死亡 *：生死問わず
EMRの場合、いずれかのクラスタが価格高騰で落ちたとしても、マスターノードさえ生存していればマスターノードは落ちているクラスタを再始動しようと頑張ってくれます。
この再始動の時の条件はオリジナルのルールに則るので、同じ条件でスポットインスタンスに入札を行い、価格が最高入札価格を下回るとそのノードが立ち上がります。
もっとも、価格が高騰して落ちているので、なかなか立ち上がらないのが常ではあるのですが・・・
まとめ
スポットインスタンスは安価にEMRを使うことができるので良いのですが、その反面、突然落ちてしまったりすることもあるので、安定性の面では難があります。成功するまでリトライすれば良いものであれば良いのですが・・・、ある日時までにできていなければならないなど、一定安定性をもって使うことが求められる場合にはスポットインスタンスは諦めるしかないのだろうか？
いやいや、諦めたら試合終了だよ？ということで、次回から本格的に対策を説いていきます。
明日のフロムスクラッチ Advent Calendar 2017の4日目は@nrk_babyさんです。
参考文献
EMR
・EMR: AWS上のマネージド型のHadoopフレームワークhttps://qiita.com/uenohara/items/36aadaa8884359b8674b
・AWS EMR（公式）
https://aws.amazon.com/jp/emr/details/
・Amazon EMR 料金（公式）
https://aws.amazon.com/jp/emr/pricing/
・AWS CLI Command Reference - create-cluster （公式：英語）
http://docs.aws.amazon.com/cli/latest/reference/emr/create-cluster.html
EC2スポットインスタンス
・Amazon EC2 スポットインスタンス（公式）
https://aws.amazon.com/jp/ec2/spot/
・スポットインスタンスを安定して利用するための取り組みhttps://qiita.com/megadreams14/items/766ce04ca6cb418e95ca