インスタンス購入方式の選定 — スポットに載せてよい処理の見極め

スポットインスタンスは通常価格の60〜90%引きで調達できるケースがあり、コスト削減の選択肢として有力に見える。しかし購入方式の選定を「単価の安さ」だけで進めると、中断発生時に処理が途中停止したまま復旧設計から作り直す事態を招く。何をスポットに乗せてよいか、どの範囲をリザーブドで固めるべきか——その判断軸を購入前に明確にすることが、設計の手戻りを防ぐ核心になる。

安さで選んで途中停止に耐えられず作り直す構造

コスト試算だけで終わらせた選定の末路

スポットインスタンスの単価試算を見て「同じ処理を3分の1以下のコストで動かせる」と判断し、アーキテクチャの検証なしにワークロードを移行するケースがある。この段階では中断の発生頻度やタイミングが設計に織り込まれていないため、実際に中断が起きた際に処理の再開手順がなく、手動介入を前提とした運用が常態化する。数十台規模のバッチ処理環境でスポットへの一括移行を試みた現場では、月単位でのコスト削減効果が確認できた一方、週に数回の中断ごとにエンジニアが手動で再投入する手順が固定化してしまったという話をよく聞く。コスト試算と中断対策の設計は同時に進めなければ意味をなさず、試算だけで選定を完結させることがアンチパターンの入口になる。

中断耐性の設計を後付けにした場合のコスト

購入方式の選定後にアーキテクチャを見直すと、チェックポイント機構やジョブキューの導入、フォールバック先の整備など、本来は設計フェーズで決めるべき要素を後から差し込む工数が発生する。中断耐性の設計がないまま稼働させた環境に後付けで対応しようとすると、コードの修正だけでなくインフラ構成全体を再設計する必要が生じることがある。工数ベースで見ると、設計フェーズで盛り込んだ場合の2〜3倍の作業量になるケースが少なくない。後付けの設計修正はテストやステージング環境の再整備も伴うため、実際の手戻りはさらに大きくなりがちである。

作り直しが起きる典型的なパターン

作り直しが発生する典型例は「スポットで動かしてみたが中断率が予想以上に高かった」という状況よりも、「中断を想定せずに設計したワークロードをスポットに乗せてしまった」という構造的な問題に起因することが多い。中断そのものがまれにしか起きない環境であっても、一度でも発生したときの影響が大きければ設計を根本から見直す判断を迫られる。購入方式の選定は調達コストを下げる手段ではなく、ワークロードの再実行可能性を問う設計判断だという認識を出発点に置くことで、選定と設計を分けて考えることで起きる根本的な問題を避けられる。

中断されても困らない処理と困る処理の判断

中断耐性が高い処理の構造的な特徴

スポットに適したワークロードは「冪等性を持ち、途中からの再実行が可能で、処理単位が分割しやすい」という構造を備えている。機械学習の訓練ジョブ、画像・動画の変換バッチ、ログ集計処理、大規模データのETL処理がその典型で、いずれも処理の進捗をチェックポイントとして外部ストレージに書き出せるため中断後の再実行が成立しやすい。CI/CDのビルドジョブも、ビルド単位を再実行できる前提があればスポットへの親和性が高い。一方、状態をインスタンス内で完結させている設計では再実行のたびに最初からやり直す必要があり、スポットとの相性は悪い。

スポットに乗せてはいけない処理の見分け方

処理の中断可否を判断する際にまず確認すべきは、ユーザーやシステムとのリアルタイムなやり取りが発生するかどうかという点である。Webアプリケーションのフロントエンドサーバー、APIゲートウェイ、データベースのプライマリノードなど、リクエストを受け付けて即時応答することを求められる処理は、中断が即座にサービス断に直結する。さらに「停止してよい時間帯が事前に決まっていない」処理——たとえばユーザーセッションを保持しながら継続するもの、分散トランザクションの中核を担うもの——も候補から外すべきである。処理の「止まり方」が設計されていない処理は、すべてスポット不向きと判断するのが安全である。

ステートの持ち方が判断の分岐点になる

同種の処理であっても、ステートをどこで持つかによってスポット適性が変わる。キューから取り出したメッセージを処理する構成では、中断されても未処理メッセージはキューに残るため別のインスタンスがそのまま引き継げる。一方、キューを使わずインスタンス起動時にタスクを割り当てる方式だと、中断時のタスクを誰が引き取るかを別途設計しなければならない。分散ジョブスケジューラを使っている環境ではこの引き継ぎが仕組みとして組み込まれていることが多いが、自前構成の場合は別途対応が必要になる。ステートをインスタンスの外に切り出せているかどうかが、スポット適性の実質的な分岐点になる。

購入方式別の特性比較

購入方式	向いている処理の特徴	コスト感（目安）	中断リスク	コミット条件
オンデマンド	本番フロント・API・予測困難な突発需要・短期の検証環境	基準価格（割引なし）	なし	なし（時間単位の従量）
リザーブド・長期割引	常時稼働するベースライン処理・DBサーバー・監視基盤・永続ミドルウェア	30〜60%割引（期間・前払い方式で変動）	なし	1〜3年のコミットが必要
スポット・プリエンプティブル	バッチ・ML訓練・画像変換・ETL・CIビルド・冪等性のある非同期処理	60〜90%割引（需給で変動）	あり（数秒〜2分前通知で回収）	なし（随時調達・解放）

表のコスト感はあくまで目安であり、クラウドプロバイダー・リージョン・インスタンスタイプ・期間によって大きく変動する。設計判断の材料として参照し、採用前に各プロバイダーの最新情報を確認することが必要になる。

中断通知を受けて処理を逃がす仕組みの組み方

通知の受け取り方と伝播の設計

AWS・GCP・Azureいずれも、スポットインスタンスが回収される前にメタデータエンドポイント経由で中断通知を提供している。この通知をポーリングで検知し、実行中のプロセスに停止シグナルを送る仕組みを事前に組み込んでおくことが前提になる。通知から実際の回収までに与えられる時間は概ね2分程度のことが多く、シグナルを受けたプロセスがチェックポイントを書き出してから終了するまでをこの猶予に収める必要がある。ポーリング間隔を長く設定すると通知を見逃すリスクがあるため、5〜10秒程度の間隔が一般的な設計の目安になる。

チェックポイント設計の粒度を決める

チェックポイントを細かく取るほど中断後のやり直し量は減るが、書き出し処理そのものが全体のオーバーヘッドになる。機械学習の訓練では数エポックごと、ETL処理では一定件数ごとという粒度を処理の性質に合わせて決める。10万件のデータ変換処理で1万件ごとにチェックポイントを書き出す設計にすれば、中断後のやり直しは最大1万件に抑えられる。保存先はインスタンスが消えても残る外部ストレージ（オブジェクトストレージや分散キャッシュなど）を使うことが前提であり、チェックポイントの書き出し時間が2分の猶予を超えるようであれば粒度を調整するか保存先のI/O性能を改善する必要がある。

フォールバック先をどこに置くか

スポットが調達できない状況や中断頻度が設計の許容範囲を超えた場合のフォールバック先を設計に含めておくことが、スポット活用の安定運用につながる。フォールバック先としてオンデマンドインスタンスを自動起動する構成が多く使われるが、切り替わるまでの遅延と切り替え後のコストを設計時に見積もっておく必要がある。スポットが入手しやすい別のインスタンスタイプや別のアベイラビリティゾーンを優先順位付きで指定できるマネージドサービス（スポットフリート・プリエンプティブルVMグループなど）を活用することで、単一タイプへの依存を減らす選択もある。スポット枯渇が長期化するケースに備え、フォールバック後の最大継続時間と切り戻し条件も事前に決めておくことが望ましい。

長期契約で固定する範囲をどこまでにするか

ベースライン需要の見積もりから始める

リザーブドインスタンスや長期割引（GCPのCommitted Use Discount・AzureのReserved VM Instancesなど）は、継続的に一定水準の需要が見込める処理に対して有効で、コミット期間は1〜3年が一般的である。ベースライン需要の見積もりは、過去3〜6か月分の利用実績から「ほぼ常時稼働しているインスタンス数」を算出するところから始める。常時稼働率が80%を超えているインスタンス群は、リザーブドへの切り替えを検討する候補として挙げられる。逆に利用率が日中に集中し夜間は落ち込むワークロードは、コミット量を必要以上に積むとコスト効率が悪化するため、稼働の谷の深さも確認する必要がある。

コミットメント量の決め方

コミット量の目安として「常時稼働するインスタンス数の70〜80%程度をリザーブドでカバーし、残余をオンデマンドやスポットで調達する」という考え方がある。全量をリザーブドでコミットすると、需要が想定より下振れした際に未使用コミットが固定費として残る。逆にコミットを絞りすぎると需要の底の部分までオンデマンドで調達することになり、割引恩恵を受けられる範囲が狭まる。コミット期間についても1年と3年の割引率の差を確認したうえで、プロジェクトのロードマップや技術的な移行計画と照合して決めることが重要になる。環境の役割や規模が大きく変わる可能性があるなら、1年単位の更新を選ぶ方が柔軟性を保てる。

長期固定とスポット・オンデマンドの比率設計

理想的な比率設計は「ベースラインをリザーブド、変動分の上限をスポット、スポット調達失敗時のバッファをオンデマンド」という3層構造になる。この比率は固定ではなく、半期ごとに利用実績と照合して見直すサイクルを設けることが多い。比率を固めるタイミングは新規環境の立ち上げ直後ではなく、3〜6か月程度の実稼働データが揃った後にするほうがコミット量のズレが小さくなる。一度確定した比率をそのまま維持し続けることは、スポットの調達難易度の変化やワークロードの増減を反映できなくなるため、定期的な見直しを仕組みとして組み込むことが求められる。

値引き狙いで本番の可用性を削る境界

可用性要件とスポット比率の突き合わせ

本番環境でスポットを混在させる場合、可用性要件とスポットの中断リスクを照合する工程が必要になる。可用性99.9%——月あたり約43分のダウンタイム許容——を求められる環境でスポット比率を高めると、単一アベイラビリティゾーンのスポットが一斉回収されたときにその許容時間を一瞬で使い切る可能性がある。スポットの中断は個別インスタンス単位だけでなく、リソースひっ迫時にゾーン内の複数インスタンスが同時に回収されるケースもあり、この点を設計に織り込まなければならない。単一AZへのスポット依存は、ゾーン障害と回収が重なる最悪ケースを想定した設計に直接影響する。

本番ワークロードへのスポット混在が招く設計負債

本番のフロント層やAPI層にスポットを混在させた構成は、表面上のコスト効率が高く見える一方、中断対策のコードパス・モニタリング・アラートの整備が必須になる。整えないままスポット比率を上げると中断のたびに人的対応が発生し、オンコール対応の工数が増える。構築を任されたある担当者の事例では、本番APIサーバーの40%をスポットで賄う構成を取ったところ、中断発生時のヘルスチェック外れとオートスケールの競合が原因で一時的なレスポンスタイムの悪化が常態化した。可用性を守る仕組みの整備コストも含めて「スポット混在の実際のコスト」を算出することが、判断の前提になる。

組織のリスク許容度と判断の先送りを避ける

スポット混在の比率は、インフラチームだけでなくサービスオーナーや開発チームのリスク許容度と合わせて決める必要がある。「コストを下げたいのか、可用性を守りたいのか」という問いを先送りにしたまま構成を進めると、中断が起きたときに責任の所在が曖昧になる。インフラ構築の担当者が事前に判断軸を明示し、「どこまでをスポットで許容するか」を関係者と合意した状態で設計を固めることが、後の作り直しを防ぐ出発点になる。この合意を文書として残し、設計変更のたびに照合できる形にしておくことが長期的な運用安定につながる。

購入方式選定チェックリスト

以下のチェックリストを、ワークロードごとの購入方式を選定する際の判断フローとして活用する。各項目に対して「はい」が揃った購入方式が、そのワークロードに適した候補になる。

1. 処理の冪等性を確認する — 同じ処理を複数回実行しても結果が変わらないか。変わる場合はスポットを使う前に冪等化の設計を検討する。
2. 途中からの再実行が設計されているか — チェックポイントを外部ストレージに書き出せるか。再実行時に最初からやり直す処理はスポット不向きと判断する。
3. リアルタイム応答が不要か — ユーザーやシステムからの即時応答を必要としないか。必要な場合はスポット単独での稼働を避ける。
4. ステートが外部化されているか — 処理状態がインスタンス内に閉じていないか。キューや外部DBに切り出せているかを確認する。
5. 可用性要件と照合しているか — SLA・SLOの許容ダウンタイムを把握しているか。スポットの中断リスクと突き合わせているか。
6. フォールバック先を設計しているか — スポット調達失敗時にオンデマンドへ自動切り替えできるか。切り替え時間とコストを見積もっているか。
7. 常時稼働率を把握しているか — 過去3〜6か月の実績から常時稼働率を算出しているか。80%超ならリザーブドの検討対象になる。
8. コミット量を実稼働データに基づいて決めているか — 立ち上げ直後のコミットを避け、実績データが揃った後に量を決めているか。
9. リスク許容度を合意しているか — インフラチーム以外のステークホルダーと「どこまでスポットを使うか」を明示的に合意しているか。
10. 比率の見直しサイクルを設けているか — リザーブド・スポット・オンデマンドの比率を半期ごとなど定期的に見直す仕組みがあるか。