保存を240分ごとにすると、24時間の仕事が37.4時間かかりました。12.9時間ぶんを捨てています。
中断前の通知で保存できるようにすると、同じ240分ごとのまま24.3時間で終わりました。
貸してもらっていた資源を返す仕組みです。返す側の都合で起きるので、こちらでは止められません。
プリエンプションは、使っていた計算資源を取り上げられる仕組みです。安く借りる代わりに、必要になったら返します。
どれも借りる側では制御できません。出典もスポットインスタンスが中断される可能性は常にあると明記しています。
取り上げられたあとの扱いは、要求のときに指定できます。終了・停止・休止のどれかです。
休止を選べばメモリの内容が保たれるので、再開が速くなります。使える条件は限られるので、確かめてから選びます。
止められない以上、止まったあとにどこから再開するかを先に決めます。決め方は2通りです。
次の節で、この2つを実際に走らせて比べます。スポットインスタンスの記事では、1番目だけを使ったときの間隔の決め方を測っています。
It is always possible that your Spot Instance might be interrupted.原文AWS「Spot Instance interruptions」(Amazon EC2 ユーザーガイド) この内容の有効期限2027-02-18
中断の直前に保存できれば、定期保存の間隔はほとんど効かなくなります。捨てる計算が消えるためです。
プリエンプションの前に通知が来る場合、その間に保存できます。どれだけ効くのかを実際に走らせて測りました。
本来24時間の仕事に、平均6時間ごとの中断を入れます。通知は2分前です。通知の長さより書き込みが短ければ保存できるものとしました。
保存の間隔 受け方 実時間 捨てた計算 実時間の増え 15分 通知を使わない 25.8h 0.6h 7.4% 15分 通知で保存する(30秒) 25.1h 0.0h 4.6% 15分 通知で保存する(3分) 29.7h 0.6h 23.7% 60分 通知を使わない 27.0h 2.5h 12.7% 60分 通知で保存する(30秒) 24.5h 0.0h 2.0% 60分 通知で保存する(3分) 27.9h 2.4h 16.2% 240分 通知を使わない 37.4h 12.9h 55.8% 240分 通知で保存する(30秒) 24.3h 0.0h 1.4% 240分 通知で保存する(3分) 37.5h 12.8h 56.4%
通知を使わない場合、保存を240分ごとにすると実時間が37.4時間まで延びます。捨てた計算が12.9時間あるためです。
通知で保存できるようにすると、同じ240分ごとのまま24.3時間で終わります。捨てた計算は0.0時間です。
通知ありの行を縦に見てください。15分ごとで25.1時間、60分ごとで24.5時間、240分ごとで24.3時間です。
粗いほうが速くなっています。捨てる計算が0なので、残るのは書き込みの回数だけだからです。
取り上げられたあとの扱いも、この差に効きます。出典は中断のとき、スポット要求の作成時に指定した中断時の動作に応じて、終了・停止・休止のいずれかになると説明しています。
通知で保存できると、間隔を粗くしても延びない。
When Amazon EC2 interrupts a Spot Instance, it either terminates, stops, or hibernates the instance, depending on the interruption behavior that you specified when you created the Spot request.原文AWS「Spot Instance interruptions」(Amazon EC2 ユーザーガイド) この内容の有効期限2027-02-18
通知は時間の余裕でしかありません。その中で書き切れなければ、あってもなくても結果は変わりません。
プリエンプションの通知に頼る設計で外しやすいのが、書き込みの時間を測っていないことです。同じ計測の3行目を見てください。
保存の間隔 受け方 実時間 捨てた計算 実時間の増え 240分 通知を使わない 37.4h 12.9h 55.8% 240分 通知で保存する(3分) 37.5h 12.8h 56.4%
書き込みが3分かかると、2分の通知には収まりません。捨てた計算は12.8時間で、通知を使わない場合とほとんど同じです。
実時間はむしろ0.1時間延びています。定期保存のほうも1回3分かかるようになったためです。
15分ごとの行では差がもっと開きます。通知なしの25.8時間に対し、書き込み3分は29.7時間です。
24時間で96回書くので、書き込みだけで4.8時間かかります。保存を厚くしたことが、そのまま損になっています。
中断の回数そのものを増やしてしまう設定もあります。出典はただし上限価格を指定した場合、指定しない場合よりも頻繁に中断されると述べています。
費用の上振れを止めたい気持ちは分かります。中断が増えれば実時間が延びるので、総額では逆に増えることがあります。
通知が来ない止まり方もあります。通知は定期保存の代わりではなく、上乗せです。
通知に収まらない書き込みは、無いのと同じ。
通知の扱いは「通知より書き込みが短ければ保存できる」という単純な置き方にしています。実際には通知の受け取りから書き出し開始までにも時間がかかり、余裕はもっと少なくなります。ここで見せているのは、書き込みが通知に収まるかどうかで結果が二分されるという関係です。
However, if you specify a maximum price, your instances will be interrupted more frequently than if you do not specify it.原文AWS「Spot Instance interruptions」(Amazon EC2 ユーザーガイド) この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る