こちらはフロムスクラッチ Advent Calendar 2017の5日目の記事です。
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】スポットインスタンスでの安定稼働を目指して（1/3）：スポットインスタンスとは
https://qiita.com/S_Haraguchi/items/92ee6d64a75242742da6
前回はスポットインスタンスについて紹介し、標準で選択されるオンデマンドと比較して、
・使用料金が需給バランスにもよるが、最大で90%の大幅割引になる
・リソースが必ずしも確保できるとは限らないので、安定性に難がある
という特徴があることを紹介しました。
今回はそんなスポットインスタンスを使って料金の割引を受けつつ、安定稼働を狙う仕組みとして私が有力視している「インスタンスフリート」を紹介したいと思います。
インスタンスフリートとは
インスタンスフリートとは、端的に言えばスポットインスタンスの拡張で複数のスポットインスタンス設定を組み合わせることができる、スポットインスタンスのオプションの1つです。
これまでの通常のスポットインスタンスの場合は、クラスタの種類とそれに対する入札上限額を1つ、例えば、
m4.large （入札上限額 $0.04）
のように設定し、この対象のクラスタの種類の価格が入札上限額を下回っていれば、インスタンスを割り当てられることができていました。
一方で、インスタンスフリートの場合はこの設定を複数個（最大5つまで）持たせることができます。すなわち、
m4.large （入札上限額 $0.04）
m4.xlarge （入札上限額 $0.08）
r4.large （入札上限額 $0.06）
のような具合です。
インスタンスフリートを使うと、この複数の設定の中のいずれか1つでも価格が入札上限額を下回っていれば、そのクラスタタイプのインスタンスが割り当てられます。もし、複数の設定が同時にその価格が入札上限額を下回っている時には、その中からもっともコストパフォーマンスが良いものが割り当てられるようです。
ここまではEC2でも同様の仕組みがありますので、割と馴染みのある方も多いかもしれませんね。
異なるのは、前回記事でも紹介した通り、EC2はインスタンス単体で動くのに対してEMRは複数のノード（マスター、コア、タスク）によって構成されます。そして、EMRのインスタンスフリートはこのノードタイプごとに設定することができる、という違いです。
ノードのうち一部だけが落ちた場合の振る舞いについては、スポットインスタンスの振る舞いと同じく、マスターノードが生きていればコアノードの復活も試みてくれます。ただし、復活のルールはインスタンスフリートのルールに従って行われるため、設定によっては再プロビジョニングした結果、これまでと違うクラスタタイプが割り当てられる、ということもあり得ます。
例えば、以下のような状態でEMRが立ち上がっていたとして、
m4.largeが高騰して、コアノードがダウンしたとします。マスターノードが落ちていないので、マスターノードはコアノードを生き返らせようとしますが、この時m4.largeがまだ高騰している場合は、別のサイズで立ち上がります。
同じように特定のタスクノードだけ落ちてしまった場合も、別のサイズで立ち上がる可能性もあるため、（当たり前ですが）インスタンスフリートの候補として入れるクラスタタイプはどれが選ばれても問題がないように、スペックを選ぶ必要があります。
なお、このインスタンスフリートのルールはいずれも立ち上げ時のみ有効であり、立ち上がった後は考慮されない（例：m4.xlargeで立ち上がった後によりコストパフォーマンスの高いm4.largeの設定が有効になったとしても切り替わらない）点は留意してください。
また、インスタンスフリートを用いると、オートスケールは使えなくなる点については注意が必要です。
インスタンスフリートのオプション
ここではインスタンスフリートで併用できる、有効なオプションをいくつか紹介します。
On demand vCPU
On demand vCPUはインスタンスフリートのオプションの1つです。これは何かというと、インスタンス数が複数あるノードについて、その一部をインスタンスフリートで、残りをオンデマンドで、といったように、インスタンスフリートとオンデマンドを併用して場合に使えるオプションです。
このオプションを使用することで最低限落ちないようにしつつ、インスタンスフリートで安価に得られそうなものがあればさらに性能を強化する、といったような使い方が可能です。
ただし、この設定はあくまでインスタンス単位での設定なので、上記のような使い方をしたければ、そのノードの最低必要インスタンス数は2つからとなります。
スポットブロック
スポットブロックはインスタンスフリートのオプションの1つで、インスタンスが割り当てられる時にそのインスタンスを一定期間は入札額不足によりダウンしないようにするためのオプションです。この時間は現在は1時間区切りで、かつ最大6時間まで設定することができます。
このオプションについては2つ注意すべき点があります。
・設定したスポットブロックの期間を越えると強制的に終了する
・設定したスポットブロックの期間によって、（長ければ長いほど）割引率が低下する
なお、このオプションはノードに対して設定できるものなので、例えば、m4.largeの時には3時間のスポットブロックを、m4.xlargeの時には2時間のスポットブロックを、というような、クラスタサイズによってブロックする時間を変動させるような使い方はできません。
プロビジョニングのタイムアウト
このオプションは、インスタンスフリート設定があるものの、そのいずれからもインスタンスを得られないような状態がxx分以上経過すると、スポットインスタンスのプロビジョニングを諦めてオンデマンドで立ち上げる、またはクラスタを終了するというオプションです。
スポットフリートを採用するだけでも、単純なスポットインスタンスと比較すればかなり安定性がましますが、このプロビジョニングのタイムアウトがあると、最後は必ずオンデマンドになるため安心して運用していくことができます。
次回はこれらの要素の考察と、どういう局面に適用していくのが良いのか。また、弊社内での取り組みについて実例を交えつつ紹介できればと思います。
参考文献
EMR
・新機能 - Amazon EMRインスタンスフリート（公式）
https://aws.amazon.com/jp/blogs/news/new-amazon-emr-instance-fleets/