激安「スポットインスタンス」全面導入の代償 痛みから学んだ3つの教訓：Kubernetesを激安インフラで運用できるのか

格安でクラウドインフラを利用できる「スポットインスタンス」は、ベンダーの都合で突然サーバが停止するリスクがある。大規模システムをスポットインスタンスだけで構築したエンジニアが経験した「痛み」とは。

[TechTargetジャパン]

　クラウドインフラの費用最適化は企業にとって喫緊の課題だ。その強力な手段として、クラウドベンダーの余剰コンピューティングリソースを通常よりも低価格で利用できる「スポットインスタンス」という仕組みがある。これはデータセンターで余っているコンピューティングリソースを利用する代わりに、サーバの利用料金が大幅に割り引かれるものだ。

　海運大手A.P. Moller - Maersk（以下、Maersk）が運用するオブザーバビリティシステムは、約8000個のポッド（処理の最小単位）が、330台のノード（サーバ）に配置され、5つのクラスタ（複数のノードを束ねた運用単位）またがって稼働するという、極めて大規模な構成だ。

　このシステムの運用管理を担当するラッセ・カント・ヘルス氏のチームは、システム立ち上げから最初の3年間、インフラを完全にスポットインスタンスのみで稼働させる大胆な手法を採った。その結果、浮いた費用でチーム全員に高級スポーツカーを買い与えたり、民間宇宙旅行に行けたりするほどの、圧倒的な費用削減を実現したという。

　しかし、こうしたメリットの裏には、運用チームを日々悩ませる深刻な「痛み」が潜んでいた。膨大な費用削減と引き換えに彼らが直面したインフラの不安定さと、それを乗り越えるために実装した工夫を明らかにする。

「安いから」だけで選んではいけないスポットインスタンス3つの教訓

併せて読みたいお薦め記事

クラウド料金をどう抑えるか

• クラウド料金が「高過ぎる現実」を前に払うしかない企業の本音
• クラウドの“いつの間にか高くなる”「エグレス料金」を全力で抑える3つの方法

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

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