Google Cloud Spot VM のユースケース トップ 5 についての説明とベスト プラクティス

※この投稿は米国時間 2022 年 6 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

クラウドは、アプリケーションの要求に応じて成長したり縮小したりする柔軟なインフラストラクチャを前提として構築されています。この弾力性のあるインフラストラクチャを活用し、アプリケーションの需要に応じて水平方向にスケールできるアプリケーションは、需要に応じてインフラストラクチャの費用の規模を増減させることができるため、競合他社に対して大きな優位性が得られます。

Google Cloud の Spot VM を使用すると、お客様は利用可能ならばいつでもどこでも Google のアイドル容量を最大限に活用できます。Spot VM は、正規価格から大幅に割引された価格で提供されており、コスト削減の最大化を促進します。また、お客様にはプリエンプションに対応できる柔軟でステートレスなワークロードが提供されます。Spot VM は、Google によって再利用されることもあります（30 秒前に通知）。Spot VM に適切なワークロードをデプロイすることで、Google が提供する最適な割引を活用しつつ、弾力性を維持できます。

このブログでは、お客様が Spot VM を利用する際の一般的なユースケースとデザイン パターンについていくつか説明し、これらのユースケースにおけるベスト プラクティスを紹介します。これは完全なリストではありませんが、このブログはお客様がアプリケーションとワークロードの目標を達成しながら Spot VM によるコスト削減効果を最大化するためのテンプレートとして役立ちます。

メディアのレンダリング

レンダリング ワークロード（2D や 3D 要素のレンダリングなど）には、多くのコンピューティングや時間が必要となり、レンダー ファームを管理するための熟練した IT 担当者も必要です。レンダー ファームの使用率が 100% になると、ジョブ管理はさらに難しくなります。Spot VM はフォールト トレラントなレンダリング ワークロードに理想的なリソースです。キューシステムと組み合わせることで、お客様はプリエンプション通知を統合してプリエンプトされたジョブを追跡できます。これにより、TCO を削減したレンダー ファームを構築できます。レンダラによって、進行中のレンダリングについて指定した間隔でスナップショットを取得している場合、これらのスナップショットを永続的なデータストア（Cloud Storage）に書き込むことで、Spot VM がプリエンプトされた場合の作業の損失を抑えることができます。後続の Spot VM が作成されると、Cloud Storage 上のスナップショットを使用して、以前の Spot VM が中断されたところから再開できます。また、新しい「VM を一時停止して再開する」機能を活用することで、プリエンプション イベントの間は VM インスタンスを維持しつつ、VM が使用されていない間はそのための費用を発生させないことも可能です。

さらに、Google は既存のデータセンターにあるローカルのレンダー ファームとクラウドベースのレンダー ファームを組み合わせることで、物理的データセンターへの投資を増やすことなく大規模または多数のレンダリング ワークロードに対応するハイブリッド アプローチを可能にし、お客様を支援してきました。これにより、資本支出を削減するだけでなく、既存のファームに柔軟なスケーラビリティが追加され、ビジネス パートナーにより最適なエクスペリエンスを提供できます。

財務モデル

資本市場の企業は、最先端かつ世界水準のコンピューティング グリッドを作成するために、インフラストラクチャに多大な投資を行っています。コンピューティング グリッドの登場以来、社内研究者は物理データセンターにあるこれらの大規模なグリッドを活用して取引の仮説を検証し、バックテストを行っています。しかし、事業が大きくなるにつれ、研究者全員がそれぞれに素晴らしいアイデアを持ち、それらを同時にテストしたいと思うようになったとしたらどうでしょうか。研究者は互いに限られたリソースを奪い合うことになり、作業の順番待ちが起きたり、アイデアのテストに対するリードタイムが長くなってしまったりします。また、金融市場では常に時間が足りません。そこで、クラウド コンピューティングと Spot VM の登場です。資本市場の企業は、一時的にコンピューティング リソースをスピンアップすることで、Google Cloud をオンプレミスのグリッドの延長として使用できます。あるいは、クラウドを全面的に採用し、Google Cloud 上にグリッドを構築することも可能です。Spot VM は、一時的なワークロードであるという特質と VM の大幅な割引が得られるという点から、どちらのシナリオにおいても研究ワークロードの飽和に対する理想的な対案となります。研究者はより多くの仮説を低い費用でテストごとに検証でき、企業にとって最適なモデルを生成できるようになります。Google Cloud の Spot VM の割引は、VM 自体だけでなく VM にアタッチされた GPU アクセラレータにも適用され、より大規模で複雑なモデルの処理に取り組んでいる企業にさらなる処理能力を提供します。ジョブが完了すると、Spot VM は速やかにスピンダウンされ、コストの厳密な管理を維持できます。

CI / CD パイプライン

継続的インテグレーション（CI）ツールや、継続的デリバリー（CD）ツールは、最先端のアプリケーション デベロッパーにとってごく一般的なものです。これらのツールにより、デベロッパーはテスト パイプラインを作成できます。パイプラインでは、デベロッパーと品質エンジニアは新しく作成されたコードがその環境で動作し、デプロイ時のプロセスで障害が発生しないことを確認できます。CI / CD パイプラインは多くの企業にとってミッション クリティカルではないため、CI / CD ツールやテスト環境は Spot VM 上での実行に適したワークロードです。デプロイやテストが 15 分、あるいは数時間遅れたとしても、ビジネスにとっては重要なことではありません。つまり、企業は Spot VM を利用することで、CI / CD パイプラインの運用コストを大幅に削減できます。

簡単な例としては、Jenkins Master Server をマネージド インスタンス グループ（MIG）にインストールし、VM タイプを Spot に設定することが挙げられます。VM がプリエンプトされた場合、CI / CD パイプラインは MIG が新しい VM をスピンアップするためのリソースを再び検出できるまで停止します。Jenkins がローカルにデータを保持するため、Spot VM にとって問題となることを懸念する意見が出るかも知れません。しかし、お客様は Jenkins ディレクトリ（/var/lib/Jenkins）を Google Cloud Filestore に移動して、このデータを保持できます。その後、新しい Spot VM がスピンアップすると、ディレクトリに再接続されます。大規模な Jenkins デプロイの場合、ビルド VM は MIG の一部として Spot VM を活用し、オンデマンド VM でビルドを維持できるようにしながら必要に応じてスケーリングできます。この混合型アプローチにより、ビルドに関するリスクを排除しつつ、お客様は従来のオンデマンド VM と比較して、追加 VM の費用を最大 91% 削減できます。

ウェブサービスとアプリ

大手オンライン小売店では、注文を大量に増やす方法を常に模索しています。一般的にこのような企業は、独自のプロモーション プロセスにより、月末日など毎月特定の時間をターゲットにしています。つまり、ブラック フライデーやサイバー マンデーのようなイベントを毎月開催しているケースが多いのです。これをサポートするために、企業は従来「スーパーボウル サンデー用のスタジアムのように構築する」モデルを使用していました。ただし、この場合、照明や空調、付帯設備などを、練習のためだけに稼働させ続けるのは非常に割高である点が問題となります。ほとんどのプロ スポーツチームに練習場があるのは、これが理由です。月のうち 29～30 日はほとんどのインフラストラクチャがアイドル状態になり、暖房換気空調システムや電気などを浪費しています。ただし、クラウドの弾力性を利用すれば、この容量を管理し、必要なときにだけ稼働させられます。しかし、さらなる最適化とコスト削減を進めるために Spot VM に目を向けましょう。

Spot VM は、このようなスケールアウトのイベントで効果を発揮します。上のシナリオを思い浮かべてください。ロードバランサの背後に、次のようなものがあるとしたらどうでしょうか。

• ウェブ フロントエンドのスケーリングに役立つ 1 つの MIG。この MIG は、日々のトラフィックを処理するために、オンデマンド VM に合わせたサイズになります。

• 月末の前夜、午後 11:45 からスケールアップが始まる Spot VM 用の 2 つ目の MIG。1 つ目と 2 つ目の MIG でワークロードの 80～90% を処理できるようになります。

• Spot MIG が十分な容量を確保できない場合は、ワークロード バーストとしてオンデマンド VM をスピンアップさせる第 3 の MIG が残りのトラフィックを処理して SLA を満たすと同時に、費用を可能な限り抑えます。

Kubernetes

「それはけっこうですが、当社は Google Kubernetes Engine（GKE）を使って完全にモダナイズされたコンテナ ショップです」という意見もあるかもしれません。そのようなお客様にもいい知らせがあります。Spot VM は GKE と統合されており、Spot VM を標準の GKE クラスタに使用するか、Spot Pod を Autopilot クラスタに使用することで、GKE のワークロードを迅速かつ容易に削減できます。GKE は、正常にシャットダウンする Spot VM サポートし、ワークロードにシャットダウンを通知して、正常に終了するための時間を提供します。その後、GKE は自動的にデプロイを再スケジューリングします。Spot Pod では、Kubernetes の nodeSelectors やノード アフィニティを使用してスポット ワークロードの配置を管理し、スポットとオンデマンドのコンピューティングで費用と可用性の適切なバランスを取ることができます。

一般的なベスト プラクティス

Spot VM を活用するために上のようなユースケースと完全に一致させる必要はありません。ワークロードがステートレス、スケーラブルで 30 秒以内に停止してチェックポイントを作成できる、あるいはロケーションやハードウェアに対して柔軟性がある場合、そのワークロードは Spot VM に適している可能性があります。

Spot のワークロードを可能な限りスムーズにするために実行できるアクションが複数あります。以下に、検討すべきいくつかのベスト プラクティスの概要をご紹介します。

1. リージョン マネージド インスタンス グループ（RMIG）の背後に Spot をデプロイする。

• RMIG はプリエンプトされたインスタンスを再作成できるため、Spot ワークロードに非常に適しています。

• ワークロードのプロファイルを使用して、RMIG のターゲット分配形態を決定します。たとえば、一括の研究ワークロードでは、あらゆるターゲット分布形態を選択できます。これにより、Spot インスタンスをさまざまなゾーンに自由に分散させることができ、活用されていないリソースを活用できます。

• オンデマンド RMIG と Spot RMIG を組み合わせて使用することで、ステートフルなアプリケーションを維持しながら、コスト効率の良い方法で可用性を高めることができます。

2. シャットダウン スクリプトがあることを確認する。

• Spot VM のプリエンプションが発生した場合、シャットダウン スクリプトを使用して、ワークロードの Cloud Storage へのチェックポイントを有効にし、正常なシャットダウン プロセスを実行します。

• シャットダウン スクリプトのドラフトを作成する際には、シャットダウン スクリプトがアタッチされたインスタンスを手動で停止または削除してインスタンス上でテストし、意図した動作を検証してください。

3. Cloud Storage にチェックポイント ファイルを書き込む。

4. ロードバランサの背後で複数の MIG を使用することを検討する。

ワークロードがグラフィック レンダリング、財務モデル、スケールアウトした e コマースやその他のステートレスのものであっても、Spot VM は運用コストを 60% 以上削減する最も簡単で最適な方法です。上記の例とベスト プラクティスに沿って実行することで、Spot VM が着実に適切な結果を出すようにできます。今すぐ Google Cloud の無料トライアルをご利用ください。

^謝辞

^{この投稿にご協力いただいた Cloud Compute プロダクト マネージャー Dan Sheppard 氏に心から感謝します。}