More than 1 year has passed since last update.

ネットアップ合同会社Advent Calendar 2022

@yasuoohno(Yasuo Ono)in

ネットアップ合同会社

Spotインスタンスをもっと活用してみよう

Last updated at 2022-12-06Posted at 2022-12-03

こんにちは。NetAppの大野です。NetAppアドベントカレンダー4日目の記事になります。

アドベントカレンダーのお題には、「データ管理について」とありますが、
ちょっと方向を変えて AWSの Spotインスタンスの活用について書きたいと思います。

個人でリザーブドインスタンス／セービングプランとかは金額的にも、ちょっと無理ですが¹、
Spotインスタンスは、再起動がたまに入るのが気にならないサーバ用途で個人的に使っていたりします。

ここで「でも、SpotインスタンスだとInterrupt入ったときにサーバ上のデータ消えちゃうでしょ？」と思った方には、是非読んでもらえればと思います。

はじめに

記事の内容は以下となっており、2022/12/01時点の情報で記載しています。

AWS EC2 Spotインタンスについて
EC2の OnDemandインスタンスの代わりに、Spotインスタンスを使う事の検討
実際にStateful Nodesを使ってみる

ちょうど re:Invent等もあり、AWSが提供するサービス変更の影響を受ける記事のため、
出来るだけ正確にと気を付けてはいるのですが、最新の情報についてはドキュメント等も適宜ご参照いただければと思います。

AWS EC2 Spotインタンスについて

Spot インスタンスって何だろう

2022/12/02の時点でAWS EC2 スポットインスタンスのページには以下の様に書かれています。

Amazon EC2 スポットインスタンスを使うと、AWS クラウド内の使用されていない EC2 キャパシティーを活用できます。
スポットインスタンスは、オンデマンド料金に比べ最大 90% の割引料金でご利用いただけます。
スポットインスタンスは、ステートレス、耐障害性、または柔軟性を備えたさまざまなアプリケーションでご利用いただけます。

1,2 から「AWSの中で余ってるリソースを、割引価格で使える」となっていて、気軽に個人でも使えますし結構魅力的に思います。
ただ、3を見ると、その上で走らせるのは何でも良いというわけではなく、何やら条件が並んでいます。

ステートレス－ステートを持たないアプリケーション（Stateless）
耐障害性を備えた－突然落ちても大丈夫なアプリケーション（Fault-Tolerant）
柔軟性を備えた－？

柔軟性が具体的に何をさすかはさておき、これには以下の様なワークロードが含まれるとあります。

ビッグデータ
コンテナ化されたワークロード
CI/CD
ウェブサービス
ハイパフォーマンスコンピューティング (HPC)
テストおよび開発

まとめると、「インスタンスが中断されても、再実行・再開可能なワークロード」が Spot インスタンスの対象となる、かと思います。

なぜ中断が前提に？

Spot インスタンスは先に示した「AWS クラウド内の使用されていない EC2 キャパシティーを活用」とある通りで、AWSクラウド内の余ったリソースで提供されています。

このため、AWSクラウド側でリソースが不足してきた時等²は、AWSからの要求により、Spotインスタンスを止めてリソースを返却する必要があります。

この返却はいつ起こるかわかりません³。このため、「中断されてもやり直しが出来る」事がワークロードに求められる事になります。

Spotの中断=Interruptionと、Spot インスタンスの返し方

突然「返して」と言われたときの返し方は、三つから選べます。

終了（Terminate/再開不可-デフォルト）
停止（Stop/再開可能）
休止（Hibernate/再開可能）

"終了"ではなく、"停止" か "休止" を選べば一時的に止まりはするものの、再開可能な形となります⁴。

ただ「いつ止まるかわからない」に加えて、Spotインスタンスを再び起動できるキャパシティや価格が、いつ回復するか分かりません。業務等になるべく影響を与えない様にするには何等かの工夫が必要になりそうです。

EC2の OnDemandインスタンスの代わりに、Spotインスタンスを使う事の検討

価格的なメリットが大きいSpotインスタンスですが、ここまでのお話では、単体では少し使いにくい様に思います。

このため AWS EC2 では EC2 Fleet/ EC2 Spot Fleetを使って、インスタンスを複数のプールから取り出してグループとしてまとめて利用する事が出来るようになっています。

ただ、Fleetでは一般的にステートレスであったり、フォールトトレラントなアプリケーションが対象になるかと思います。これはデータの入った EBSボリューム等を含めた、永続的なリソースの管理がやりにくい（出来ればやりたくない）事等が理由としてあげられるかと思います⁵。

この点を改善するために、Spot by NetApp には Stateful Nodes という機能が提供されています。
これは Spotインスタンスを使っているのですが、以下の様な管理機能を実現しています。

通常のオンデマンドインスタンスを Spotインスタンスに変換する
Spotインスタンスが中断された時の自動的な再リクエストによる再起動
希望する Spotインスタンスが利用できない場合に OnDemandインスタンスへの切り替え
OnDemandインスタンスからSpotインスタンスへの切り戻し
Private IP/Public IP(Elastic IP)、EBS ルート／データボリュームの永続化

Stateful Nodesが永続化するリソース

ステートフルアプリケーションを Spot インスタンスで実行した場合、中断の前後で変わって欲しくない、永続的に利用したいリソースは以下かと思います。

ルートボリューム
データボリューム(EBS)
Private/Public IP(EIP)アドレス

普通に考えるとブートボリュームを EBSにして Spotインスタンスの終了時の状態で残しておけばよさそうです。

ただ、Spot インスタンスの設定で回収時に "終了" とした場合、
ルートボリュームを残しておくことができず、終了タイミングで削除されてしまいます。

休止や停止の場合、インスタンスタイプ等を変えなければ継続利用できない場合に、支障が出てしまいそうです。

Stateful Nodes では、これらの永続化したいリソースを自動的に管理して、Spotインスタンスの中断前後での接続性、データの維持を行ってくれます。

Stateful NodesによるSpotインスタンス中断後の回復

AWSにより Spotインスタンスを終了されてしまったという事は、AWS側のリソースが足りない、
もしくは望む金額では Spotインスタンスを利用できない事になったのかと思います。

同じ条件で Spotインスタンスを使おうとして、リクエストを出しても多分使えません。
となると、回復させるためには

先ほどの永続化条件＝同じルート／データボリューム／IPアドレスを使いながら

条件の違う Spot インスタンスをリクエストする
OnDemand インスタンスを使う

といった事を実現する必要があります。

どちらを行ったにせよ、価格が上昇してしまいますので、どこかで

リソースが空いたら、また安いSpotインスタンスに戻す

も必要な機能になります。

こういった切り戻しまで含めて Stateful Nodes では自動管理する事が可能です。

実際にStateful Nodesを使ってみる

こういった特徴がありますので、ここでは、実際に OnDemandインスタンスで動いている
WebサーバをSpot インスタンスに変更してみたいと思います。

準備1. Webサーバの準備をする

まずは移行対象のサーバをAWS上にたてておきます。

2022-12-04 00_44_12-My First Post __ My Web Site.png

Public IPはインスタンス間で固定的に付け直す必要があるため、Elastic IPにしておく必要があります。
EBSは必要ならつけておきましょう。

準備2. Spot.ioのアカウントを作る

まずは Spot.io に行ってアカウントを作成します。

右上のSign Inボタン（見当たらなければバーガーボタンの中にあります）をポチっとした後

左下、または中央の下にある "Don't have an account yet? Sign Up" のリンクをクリック

続くアカウント作成画面でフルネーム、emailアドレス、パスワードを入れて Sign Upをすると確認用メールが届きます。
メール内の確認リンクをクリックすればアカウント作成完了です。

準備3. Spot.ioにクラウドプロバイダの登録

アカウントが作成出来たら、次に Spot.ioとクラウドプロバイダを接続してやる必要があります。
これにより Spot.io側から、クラウドのリソースを制御する事ができるようになります。

ここではAWSに Cloud Formationを使って追加する手順を簡単に書いておきます。

※ この前にOrganization登録があったように思うのですが、スクリーンショットの取得を忘れてしまいました! すいません🙇

ここではAWSを選択
Linked Accountを選択
CloudFormationを使ってリンクするので Automaticallyを選択
GovCloudか中国のユーザかと聞かれるので、Noで答える
Run Templateのボタンを押すとAWS Consoleに飛びます
Cloud Formationのスタックのクイック作成画面が出てきます。一番下にある、機能の □ AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。 にチェックを入れてから、［スタックの作成］をクリックします。
作成が終わるとSpot.io側のダッシュボードに "Your account has been successfully connected!"と表示されたら接続完了です。

OnDemandインスタンスを Spotインスタンス＝Stateful Nodeに変換する

準備が出来ましたので実際に変換（Import）してみます。

左のサービス一覧からElastigroupを選択します。
左のメニューからStateful Nodesを選択し、右のペインにある［New Node］のボタンを押します。
"Create a new stateful node from an existing instance"を選択し、変換するインスタンスのリージョンと対象のOnDemandeインスタンスのIDを入力します。
ここで Private IP を引き継ごうとした場合、インスタンスが終了(Terminate)されてしまいます 。
念のため、ここではまだ、元からあったインスタンスを終了させたくないので、[Use a new private IP]をチェックして、Private IPの変更を許容しています。
設定が終わったら［Select］ボタンを押してインスタンスの情報をインポートします。
構成がインポートされるので構成を確認し、［Create］を押します。
Stateful Nodeが作成されます。
最初は状態が Pausedですが、数分待つと状態が Importingに変わってインポート処理が走ります。
ステータスが Importingから Activeになるのを待ちます。
Activeになっても Health Check Statusが EC2で警告になるはずですが先に進めます。
AWS Consoleから元になった OnDemandインスタンスを停止して、Elastic IPの関連付けを解除します。
Elastic IPが自動的に Spot Instance側に関連付けられてサービスが再開となります。
特にOnDemandと変わらずアクセスできますので、確認してみてください。

実験：Spotインスタンスの中断が発生したらどうなるか試してみる

ここで、中断が発生しても特に問題無くSpotインスタンス間でデータが引き継がれる事を確認してみます。

この引継ぎ処理は EBSのつけかえ等の処理が入るため、それなりに時間がかかります。インスタンスの構成や状況にもよりますが、10分ぐらいはかかると思いますので少しのんびり結果を待っていただければと思います。

EBS等のデータがちゃんと引き継がれるのを確認するため、念のためサーバ上のコンテンツに変更を加えます
Spot.ioのコンソールから、Stateful Nodesの Recycleを実行します
確認のため Recycle と入力して［Recycle］ボタンを押します。
Recycleの終了を待ちます

Spotインスタンスが一度終了し、その後新しいSpotインスタンスが起動してきます。
その後、問題無くサービスが継続されている事が確認してみてください。

なお、Spotのインスタンスが変更のタイミングで、SSHのホストキーが変更になります。このため、EIPめがけてSSH接続をかけると、ホストキーが変更になった事による警告を受ける事になりますので注意してください（ssh-keygen -R 等で一旦削除する必要があります）。

終わりに

無事、Spotインスタンスを単体のステートフルアプリケーションでも使える事が確認できたでしょうか？

もちろん単体サーバなので Spotの中断時にダウンタイムがあり、多数のユーザが使う本番系で使うには考慮が必要かと思いますが、ちょっとしたサーバの管理等には利用できるのではないかと思います。

Spotのコンソールで確認すると、OnDemandインスタンスから Spotインスタンスにしたことによるコスト効果が表示されています。気持ち良く割引が効いている事が確認できます（以下は立ち上げたばかりで、金額としては微々たるものですが70%オフ！）。

でも、Spot.ioを使うのにお金かかるんでしょ？と思われた方がいると思うのですが、実は現在は20インスタンスまで無料だったりしますので、是非体験活用をしてみていただければと思います。

なお、Spot by NetAppには今回紹介した仕組みを利用⁶してよりかしこくスケールアウト型のアプリケーションを管理できる Elastigroup という製品があり、どちらかと言えばこちらが本命です。

また、これを Kubernetes Clusterの自動管理に応用した Ocean、更に Kubernetesの上で Apache Sparkを動かすOcean for Apache Spark等もラインナップされていて、これらは本番系で使う事を意識したサービスになっていますので、ご興味のある方は是非 Spot.ioをチェックしてみていただければと思います！

こういった技術が必要とされる背景に、企業がクラウドのコストをどうやってコントロールしていくのか？クラウドサービスの複雑な課金体系を理解し、削減する努力を、今後どうやって継続していくのか？といった悩みがあるかと思います。ネットアップは、そういったクラウドを使っていく上での悩みに対応するソリューションをSpotブランドで提供しておりますので、困ったときには思い出していただけば幸いに思います。

こういう猛者もいるのでしょうか……？ ↩
中断の理由 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/interruption-reasons.html ↩
いつおこるかは分かりませんが、中断リスクが高まった場合の推奨シグナルと、中断2分前の通知があります。このため、いきなりバッツンと落ちてしまうのではなく、ある程度対処する事が可能です。ただし、推奨シグナルについては、いつ来るのについて、決まった答えが無いようです。 ↩
これは永続的リクエストの条件でもあります。 ↩
このために外部のRDBやRedisといった物に、ステートを全て逃がしてやる事も重要です。 ↩
正確にはElastigroupを、Single Node専用にしたのが Stateful Nodesなので、Elastigroupの仕組みを利用した製品がStateful Nodes、という言い方が正しい。はず。 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up