Spot instancesを使えばコンピュートコストを最大90%削減できます。本記事では、Spot instancesとは何か、なぜ・いつ使うべきかを解説します。
コンピュートコストを20〜80%削減でき、結果としてアプリケーションの耐障害性向上にもつながるにもかかわらず、Spot instances(Google CloudではSpot VMs)は本来活用_すべき_水準ほどには使われていないのが実情です。
理由は、価格や可用性が読みにくいこと、workloadsが中断されることへの不安、設定・管理の複雑さなどさまざまですが、多くの方がSpot instancesを敬遠する最大の理由は、単純に「よく知らないから」です。
しかし、こうした「ハードルに見える要素」の乗り越え方を理解すれば、これまで手つかずだったコンピュートコストの削減余地を引き出せます。
全2回シリーズの本記事では、Spot instancesを最大限に活用するために必要な知識を一通り解説します。
パート1では、Spot instancesとは何か、なぜ使うべきか、そして_いつ_使うべきかを取り上げます。パート2では、Auto ScalingグループによるSpot instancesの利用最適化と、Spot Scalingでコスト削減を最大化する方法を解説します。
Spot instancesとは?
Spot instancesは、直前のキャンセルや売れ残りで生まれる「当日格安航空券」のようなものです。航空会社は離陸前に空席を埋めるため、価格を大幅に下げて売り切ろうとします。
コンピュートインスタンスでも同じことが起きています。クラウドプロバイダーは余剰キャパシティを有効活用するため、未使用のオンデマンドリソースをオンデマンド価格より大幅に安く(最大90%オフで)提供しているのです。
仕組みはシンプルです。Spot instanceに対して入札価格(1時間あたりに支払ってもよい上限額)を設定するだけ。Spot価格(スポット市場の現在価格)が入札価格を下回っていれば、インスタンスが起動します。
ただし、通常価格のオンデマンドインスタンスへの需要が高まると、クラウドプロバイダーはわずか2分前の通知でSpot instancesを回収することがあり、アプリケーションが中断される可能性があります。
Spot instancesと航空券は、どちらも「何か(Spot instancesなら計算リソース、航空券なら座席)」を割安に手に入れるチャンスをくれます。一方で、不確実性とリスクもつきものです。市場価格が入札額を上回ればSpot instancesは回収されますし、直前の航空券も他の人に先に買われればもう手に入りません。
中断が発生しやすいのは、主に次の2つのケースです。
- オンデマンドインスタンスやリザーブドインスタンスへの需要が急増したとき
- Spot価格が入札額を上回ったとき(現在ではあまり起こりません)
Spot instancesを使うべき理由(コスト削減だけではありません)
EC2で最大80%にも及ぶコスト削減効果は、Spot instancesの代表的なメリットとしてよく語られますが、利点はそれだけではありません。
Spot instancesを導入すること自体がアプリケーションの耐障害性を高めてくれるわけではありませんが、Spot instances特有の中断にうまく対応するには、アプリケーションが_あらかじめ_一定の耐障害性を備えていることが求められます。
たとえば、Spot instances上で動かすアプリケーションは、中断を適切にハンドリングできる設計が理想です。チェックポイントや自動保存、複数インスタンスへのworkloads分散といった仕組みを、あらかじめ組み込んでおく必要があります。
こうした設計を経たインフラには、次のような特性が備わります。
- 負荷変動への対応力が高い
- ピーク時もパフォーマンスを維持できる
- 中断や障害に伴うリスクを軽減できる
ピーク時にはSpot instancesを組み込んで需要増を吸収することで、トラフィックやworkloadsが変動してもパフォーマンスを落とさずに対応できます。
また、安価なインスタンスを使えるぶん、冗長化やフェイルオーバーの仕組みにより多くのリソースを割り当てたり、workloadsを多くのインスタンスに分散させたりできます。
あるインスタンスが中断されても、他のインスタンスがworkloadsの一部を処理し続けるため、単一障害の影響を最小限に抑えられます。これにより、大きなコスト負担なしにworkloadsを別のインスタンスへシームレスに移せるのです。
EC2インスタンスプールを理解する
AWSのSpot instancesを最大限に活用するには、まずEC2インスタンスプールの考え方を押さえることが重要です。EC2インスタンスプールとは、特定リージョンにおける、あるインスタンスタイプ(例:m5.xlarge)の総キャパシティを指します。
このインスタンスプールに未使用のキャパシティがある場合、その余剰分はSpot Capacity poolと呼ばれます。
インスタンスファミリー、インスタンスサイズ、アベイラビリティゾーン、リージョンの組み合わせごとに、独立したEC2インスタンスプール、ひいてはSpot capacity poolが存在します。
だからこそ、「ひとつのカゴにすべての卵を盛る」ような使い方は禁物です。利用するプールを増やすほど、選択肢となるインスタンスの幅が広がり、アプリケーションで使えるSpot instancesが見つからないリスクを最小化できます。
Spot instancesを使うべきタイミング
一般に、Spot instancesは次のようなworkloadsに適しています。
- 柔軟性がある
- 厳密な時間要件がない
- 分散可能で、並列タスクに分割できる
- 中断を許容できる
具体的なユースケースは後ほど紹介しますが、まず自分のworkloadsがSpot instancesに向いているかを見極めるための3つの問いを挙げます。
- workloadsはフォールトトレラントですか?
Spot instancesは中断される可能性があるため、workloadsは中断されても致命的な障害やデータ損失につながらない設計でなければなりません。フォールトトレラントなworkloadsであれば、インスタンスが中断・終了しても処理を継続でき、あるいはすばやく復旧できます。 2. workloadsを2分以内に停止できますか? データ損失や障害を防ぐため、workloadsは短い猶予期間内に停止できる必要があります。2分以内に停止できれば、Spot instancesの中断にも対応しやすくなります。この観点で、セッションデータを保持しないステートレスなアプリケーションはSpot instancesに非常に向いています。機能やデータを失うことなくインスタンス間をシームレスに移行でき、中断にも強いと言えます。 3. インスタンスタイプやアベイラビリティゾーンを柔軟に選べますか? workloadsを複数のインスタンスとアベイラビリティゾーンに分散させれば、リスクが分散され、中断の影響を受けにくくなります。キャパシティはSpot instanceプールごとの属性であることを思い出してください。アベイラビリティゾーンが違えば、同じインスタンスタイプでも別のプールです。複数のプールを使えるようにしておけば、_すべての_プールで同時に中断が起きるリスクは、単一プールで中断が起きるリスクよりはるかに低くなります。複数アベイラビリティゾーンへの分散は単一プールへの依存を下げ、あるゾーンでキャパシティ制約や価格高騰が発生しても処理を継続できます。
より具体的には、次のような場面でSpot instancesの利用を検討するとよいでしょう。
テスト環境とCI/CD
テスト・開発環境やCI/CDタスクは、特定機能の開発や変更検証のために断続的に使われるため、常時稼働は基本的に必要ありません。加えて、開発・テストタスクは再起動が可能で、(あらかじめ設計しておけば)一時停止と再開も行えるため、重要なデータを失わずに済み、中断への耐性があります。
これらのworkloadsはリソース要件の面でも柔軟で、作業内容に支障をきたすことなく異なるインスタンスタイプやアベイラビリティゾーンに切り替えられます。
バッチ処理タスク
バッチ処理やETLジョブは時間的にシビアでないことが多く、その柔軟性からSpot instancesと非常に相性が良いと言えます。
こうしたタスクは小さく独立した単位に分割し、複数のインスタンスに分散して実行できるため、いずれかのインスタンスが中断されても影響は限定的です。
このように、ひとつのインスタンスが中断されてもworkloadsを稼働中の他インスタンスに振り分けられるため、ジョブ全体の完了が妨げられることはありません。利用可能なインスタンスが見つからない場合でも、中間状態を保存しておけば、中断後に最後のチェックポイントから再開できる構造にすることが可能です。
ハイパフォーマンスコンピューティング(HPC)とビッグデータ処理
HPCタスクは、膨大なデータの処理と分析を伴います。こうしたタスクは複数インスタンスへの分散が容易で、スケールアップ・スケールダウンも柔軟に行えるため、Spot instancesと相性が良い領域です。
大規模データセットの処理には多くの計算リソースが必要となるため、こうしたタスクは通常コストがかさみがちです。しかしSpot instancesを使えば1インスタンスあたりのコストが大きく下がり、数千インスタンス規模になればその差は無視できない金額になります。
Webサーバー
Webサーバーは通常_ステートレス_であるため、Spot instancesの有力な候補です。データをローカルに保存したり、過去のセッション情報に依存したりすることが少なく、中断されても大きな影響を受けにくい性質があります。
Webサーバーでは多くの場合、各リクエストは保存されたセッション情報に依存せず、独立して処理されます。
コンテナ化されたworkloads / Kubernetes
コンテナ化されたアプリケーションはステートレスに設計されることが多く、Spot instancesと好相性です。
コンテナはセッション固有のデータを保持しないのが一般的なため、新しいコンテナを起動したり停止したりしてもシステム全体には影響しません。
また、コンテナはアプリケーションを小さく独立した単位に分割するため、コンテナ化されたworkloadsはさまざまなインスタンスタイプやアベイラビリティゾーンに容易に対応できます。この柔軟性は、変動の大きいSpot instancesの性質と非常にうまくかみ合います。
ここまで、Spot instancesの基本概念から、そのメリットを効果的に引き出す方法、メリットを最大化できるユースケースまで、押さえておきたいポイントを一通り解説しました。
シリーズのパート2では、Spotの中断に対応し利用率を最適化するAuto Scalingグループ(ASG)と、ASGの設定・管理を簡素化してSpotによるコスト削減とアプリケーション可用性を最大化するSpot Scalingについて解説します。