この運用事例は、SRE（サイト信頼性エンジニアリング）の国際イベント「SREcon25 Europe/Middle East/Africa」において、Maerskのソフトウェアエンジニアであるヘルス氏が紹介したものだ。対象のシステムは、ログ集約ツール「Grafana Loki」、データ可視化ツール「Grafana」、分散トレーシングシステム「Grafana Tempo」、メトリクス（指標）保管ツール「Grafana Mimir」といったツール群を、コンテナオーケストレーションツール「Kubernetes」で稼働させている。

　スポットインスタンスを利用する上での最大の制約は、クラウドベンダーのコンピューティングリソースの空き状況によって、わずかな猶予時間で突然インスタンスが回収される「エビクション」（強制終了）が発生することだ。安定稼働と費用削減という、相反する目的を両立させるために、ヘルス氏のチームは大規模運用を通じて主に3つの実践的な教訓を得た。

　第1の教訓は、「稼働しているワークロード（実行中の処理）は、いかなるときも適切な終了処理（Graceful termination）を経なければならない」ことだ。突然のインフラ喪失に対し、システムがデータ損失を起こさず、適切に処理を引き継ぐ仕組みが欠かせない。

　「Microsoft Azure」のシステム構成を例にとると、インスタンスが強制終了される最低30秒前に、インフラ側から「Preempt」（先取り）という中断の予兆シグナルが送信される。ヘルス氏のチームはこの仕組みを前提に、Microsoft Azureのサーバの状態変化を通知する機能「Scheduled Events」を通じて、エビクションの予告を事前に検出するアーキテクチャを構築した。

　具体的な動作手順としては、専用のハンドラー（特定のイベントを処理するプログラム）が終了予告を検出すると、対象ノードを即座に「Cordon」状態に移行させる。これは新規のポッド割り当てを停止する設定だ。その後、そのノードで稼働している各ポッドに対して一斉に終了要求を送り、安全にプロセスを停止させる。これによって、強制終了による通信エラーやシステム全体への悪影響を最小限に抑え込むことに成功した。

　第2の教訓は、「インスタンスの頻繁な入れ替わりがもたらす危険性」だ。単発のエビクションであれば先述の終了手順で対処可能だが、複数の要因が同時に重なると事態は一気に深刻化する。例えば、エンドユーザーからのトラフィックが急増している最中に連続してエビクションが発生したり、クラスタの更新作業とエビクションが重なったりするケースだ。

　このような過酷な条件では、代替ノードの起動やポッドの再配置が追い付かず、システムの処理能力が一時的に大幅に低下する。最悪の場合はサービス維持が困難になる。インフラ費用の削減のみを追求し、全てのインフラをスポットインスタンスで構成してしまうと、こうした連鎖的な障害の復旧作業に追われ、運用チームは終わりのない苦痛を味わうことになる。

　第3の教訓は、「コンテナイメージのタグに『:latest』（最新版）を絶対に使用しないこと」だ。インスタンスの入れ替わりに伴ってポッドが別ノードで再作成される際、このタグを使用していると、開発者の意図に反してその時点の最新バージョンが取得されてしまうからだ。これによって、同一システム内で仕様の異なる複数バージョンのアプリケーションが混在することになり、原因究明が極めて困難な不具合を引き起こす。使用するバージョンは、特定の識別子を用いて厳密に固定しなければならない。

　クラウドインフラの費用と運用負荷は、明確なトレードオフの関係にある。ヘルス氏の経験が示唆しているのは、自社のシステムの特性と運用チームの許容負荷を冷静に見極めることだ。その上で、インフラの一部のみにスポットインスタンスを導入するといった、現実的で適応力の高い戦略を選択することが重要だと言える。スポットインスタンスは強力な費用削減の手段だが、それを扱うための堅牢（けんろう）な設計と、障害を前提とした運用体制が伴って初めて、ビジネスに真の恩恵をもたらす。

本稿は、USENIXが2025年11月12日に公開した動画「SREcon25 Europe/Middle East/Africa - What I Wish I Knew Before Choosing Spot Instances」を基に作成しました。