【ITニュース解説】My GPUs Run on Interruptible Capacity at 18% of On-Demand

ニュース記事は、クラウドサービスでGPU（グラフィックス処理ユニット）を利用する際のコストを大幅に削減できる「割り込み可能なインスタンス」という仕組みについて解説している。これは、通常のオンデマンド価格のわずか18%という驚くべき安さで高性能なGPUを使える可能性があるという話だ。

クラウドサービスでは、必要な時に必要なだけコンピューター資源を借りる「オンデマンド」が一般的だが、これには当然コストがかかる。特に高性能なGPUは、AIの学習や3Dグラフィックのレンダリングなどで大量に必要とされるため、料金も高くなりがちだ。しかし、この「割り込み可能なインスタンス」は、クラウドプロバイダーが余っている資源を非常に安い価格で提供する仕組みである。ただし、安さには理由があり、プロバイダーがその資源を他の顧客に回す必要が出た場合、予告なくインスタンスが停止させられる可能性がある。記事の筆者は、オンデマンドで1時間あたり約3ドルかかるシングルカードのGPUインスタンスが、割り込み可能なインスタンスでは55セントから70セントで利用できたと具体例を挙げている。これは、通常言われている「最大90%オフ」という宣伝文句が、特にGPUにおいては本当に実現できることを示している。

多くの解説記事では、CPUの割り込み可能なインスタンスの割引率は55%から75%程度とされているが、GPUの場合はさらに割引率が高く、80%オフに近い価格で利用できると筆者は指摘する。地域や特定の「アベイラビリティゾーン（AZ）」と呼ばれるデータセンターの物理的な区画によって価格は変動するが、筆者の調査ではオンデマンド価格がどの地域でも同じなのに対し、割り込み可能なインスタンスの価格はゾーンによって大きく異なり、最適なゾーンを選ぶことが重要だという。

しかし、この大幅な割引にはいくつかの代償が伴う。最もよく知られているのは、前述の通り「インスタンスが突然停止する可能性がある」ことだ。停止の2分前には通知があるが、その後すぐに使えなくなる。これは最もわかりやすい制約だが、システム設計で対処可能だと筆者は述べる。

次に重要なのは、「最も安いゾーンは安いなりの理由がある」という点だ。筆者の経験では、最も安価なゾーンはクラウドプロバイダー自身が容量が低いと評価しているゾーンであり、実際にこのゾーンでインスタンスが停止し、わずかなコスト削減のためにシステムが停止する事態に見舞われたという。つまり、価格の安さは中断のリスクという形で支払われる可能性があるのだ。

そして、最も筆者を悩ませたのは「割り込み可能なGPUインスタンスには利用可能な上限（クォータ）がある」という制約だ。このクォータはvCPU（仮想CPU）の数で決められており、筆者の場合、どの地域でも64vCPUに設定されていた。この上限は簡単に引き上げることができず、通常のリクエストフォームからでは承認されず、特別なアカウントチームを通じたレビュープロセスが必要になる場合もある。このクォータの存在は、システムの設計思想を根本から変えるほどの影響力を持つ。例えば、筆者の2枚GPUインスタンスは48vCPUを使うため、同じインスタンスを2つ起動すると96vCPUとなり、クォータの64vCPUを超えてしまう。そのため、「もう少し容量を追加する」といった柔軟なスケールアップができず、利用可能なクォータ内で最適な構成を選ぶ必要がある。さらに、通常のオンデマンドGPUインスタンスのクォータは割り込み可能なインスタンスとは別枠で設定されており、地域によって大きく異なるため、緊急時の代替手段が思ったより狭い場合があることにも注意が必要だ。

では、どのような場合に割り込み可能なインスタンスを使うべきなのだろうか。筆者は主に二つのケースを挙げている。一つは「バッチ処理」と呼ばれる、中断しても問題なく、後で再開できるような作業だ。AIのモデル学習（チェックポイントを保存しながら進めるもの）、オフラインでのレンダリング、評価の繰り返し、データの前処理などがこれに当たる。このような作業では、中断されても再試行する仕組みさえあれば、80%オフの恩恵を最大限に受けられる。もう一つは、ユーザーがリアルタイムで操作している「ライブセッション」のような場合だが、この場合は中断をユーザーに気づかせないための高度なエンジニアリングが必要になる。割引で得たコスト削減分を、このエンジニアリングの費用に充てるイメージだ。

中断に耐えるシステムを構築するために、筆者は以下の4つの仕組みを導入したと説明している。

1. コントローラ: 特定の物理マシンやゾーンに依存せず、「サービスが必要とする正常なスロット数」を管理する。これにより、どのゾーンやマシンが使われるかは結果として決まり、特定の場所に縛られない柔軟な運用が可能になる。
2. 段階的なフォールバック: まずは最もコスト効率の良い2枚GPUの割り込み可能なインスタンスを試す。それが利用できない場合は1枚GPUの割り込み可能なインスタンスを試す。それも無理なら、一時的かつ意図的に高価なオンデマンドインスタンスに切り替えてサービスを維持する。このオンデマンドインスタンスは、プライマリの地域にこだわる必要はなく、オンデマンドクォータが利用可能な任意の地域で起動すべきだと筆者は指摘する。
3. 価格ウォッチャー: ゾーンごとの価格を常に監視し、現在の支払い額と代替案のコストを比較して、より安価なオプションがある場合に通知する。ゾーンの価格は変動するため、継続的な監視が重要だ。
4. バックオフ付きリトライ: インスタンスの確保に失敗した場合、すぐに再試行するのではなく、試行間隔を徐々に長くしていく（30分、60分、120分など）。これは、短期間の資源不足を長期的なものに変えないための重要な仕組みだ。安易にリトライ間隔を短くすると、失敗したリクエストが割り当てられた時間を無駄にしてしまい、かえって資源不足を悪化させる可能性がある。

筆者は、これらの仕組みが実際に稼働している最中にシステムが中断された経験を語っている。その際、システムは自動的にマシンを交換し、サービスを復旧させるまでに約30分かかったが、誰も気づかないうちに処理が完了したという。

ただし、このような自動化されたシステムには落とし穴がある。筆者は、自身の構築した監視システムが3度も「成功」を報告しながら、実際には問題を見落としていた経験を共有している。 一つ目は「価格ウォッチャーが自身の地域内のゾーン価格差を見落としていた」ことだ。異なる地域間の価格比較はできていたが、同じ地域内の異なるゾーン間での価格差は考慮されていなかったため、月91ドルも高価なゾーンを使い続けていたにもかかわらず、アラートは緑のままだった。 二つ目は「アラート通知先に誰も登録されていなかった」ことだ。システムはイベントを律儀に発行していたが、それを聞いている人が誰もいなかった。システムにとっては「正常に配信された」としか報告されず、誰も問題に気づかなかった。 三つ目は「計画的な置き換えの際に古いマシンがシャットダウンされないバグ」だ。これは、意図的にマシンをロールアウトしたときに古いインスタンスが残ってしまう問題で、特定の地域でしか動作しないジョブが原因だった。このバグは、実際の割り込みが発生した場合にはAWS側が古いマシンをシャットダウンしてくれるため、むしろ「問題がなかった時」にしか表面化しなかったという。

これらの経験から筆者が学んだのは、中断自体に対処する技術的な側面だけでなく、システムが自己申告する情報がいかに信頼できないかという点だ。ハードウェアとユーザーの間に複雑なシステムが介在する場合、ハードウェアの状態はシステムの自己報告を通じてしか見えず、その自己報告は「静かに」失敗する可能性があることを理解する必要がある。

システムエンジニアを目指す初心者へのアドバイスとして、筆者は次の点を強調している。割り込み可能なインスタンスの割引は本当に大きく、特にGPUにおいてはガイドが示唆するよりも大きい。しかし、最も安価なゾーンは中断によってコストを請求する可能性があるため、まず容量の安定性を考慮し、次に価格を見るべきだ。設計を始める前に、割り込み可能なインスタンスと、緊急時のフォールバックとして使うオンデマンドインスタンスの両方のクォータを別々に確認しておくことが極めて重要だ。そして、何よりも「ハッピーパス」（問題なく動作するケース）のコードを書く前に、中断や失敗を処理するリトライのロジックを先に設計すべきだ。さらに、構築した監視や防御の仕組みは、実際に意図的に失敗させて動作確認することが不可欠である。筆者の経験のように、システムが「正常」を報告していても、実際には機能していないケースは少なくないからだ。インフラストラクチャが監視対象をまったく検出できない場合に、どのような情報を報告するのかを、常に意識して設計に取り組むことが求められる。