Google CloudのメンテナンスでGPUを失わないために

世界的なGPU需要は天文学的な規模に達しています。Google Cloud Platform（GCP）でNVIDIA L4、A100、H100といったリソースを確保できれば、エンジニアリングチームにとって大きな成果と感じられるでしょう。しかし、基盤となるハードウェアのメンテナンスが発生したときや、定期的な作業のためにインスタンスを手動で停止したときに、その容量を失ってしまう可能性があります。

Google Cloudの定期メンテナンスイベントであれ、ドライバーの適用、イメージの入れ替え、インスタンススコープの変更のためにユーザーが行う停止であれ、VMを停止するとリソースは解放されます。その結果、GPUはパブリックプールに戻され、重要なML学習ジョブや推論ワークロードが立ち往生することになります。ここでは、GPUを確実に押さえ、インフラの更新を乗り切る方法をご紹介します。

重要な制限とエッジケース

予約は容量喪失に対する標準的な防御策ですが、GCP特有のアーキテクチャルールを考慮する必要があります。

• 予約できないGPU構成： 極端な供給制約のため、一部の新しいGPUや需要の高いGPU構成は、標準のオンデマンド容量予約では予約できません。たとえば、A4X Max、A3 Ultra、および8基未満のGPUを持つA3 High構成には現在制限があります。予約の可否は必ずGCPドキュメントで確認してください。
• Spot VMとCUD： 予約が保護するのは標準VMのワークロードです。Spot VMは予約を消費できず、設計上プリエンプトされる可能性があるため、保護の対象外です。
• CUD： 確約利用割引（CUD）は料金に影響しますが、それ自体が容量を予約するわけではありません。CUDはVMだけでなく、使用されていない予約に対しても課金される点に注意してください。
• GKE連携： Compute Engineの予約は、Google Kubernetes Engine（GKE）で使用するGPU容量の保護にも利用できます。GKE Standardでは、ノードプールに予約アフィニティを構成します。GKE Autopilotでは、予約を明示的に選択するか、サポートされているカスタムComputeClassを構成する必要があります。

ユーザーメンテナンスに向けたGPU予約の実装方法

構成のずれを防ぐ最も安全なアプローチは、インスタンステンプレートでVMを一度定義し、そのテンプレートから予約を作成することです。デフォルトでは、予約は**「自動的に消費」**に設定されています。予約の仕様と完全に一致するVMがプロジェクト内に作成されると、自動的にその予約が使用されます。

1. 予約を作成する

クラスタ全体でローリングメンテナンス（ノード単位のOSパッチ適用など）を行う場合、フリート全体分の容量を予約する必要はありません。同時に停止させる予定のインスタンス数に合わせて予約のサイズを設定してください。たとえば、一度に2ノードをドレインして更新するなら、--vm-count を2に設定すれば、停止・再起動するそれらのインスタンスを確実に捕捉できます。

完全一致を担保するために、コマンドラインを使用してインスタンステンプレートから予約をプロビジョニングできます。

gcloud compute reservations create gpu-maintenance-reservation \
    --project=my-project-id \
    --source-instance-template=projects/my-project-id/global/instanceTemplates/my-gpu-template \
    --vm-count=1 \
    --zone=us-central1-c

あるいは、予約を直接定義することもできます。

gcloud compute reservations create reservation-v100 \
    --project=joshua-playground \
    --zone=us-east1-c \
    --machine-type=n1-standard-1 \
    --accelerator=count=1,type=nvidia-tesla-v100 \
    --vm-count=1 \
    --require-specific-reservation=false

もちろん、Google Cloud Consoleからも実行できます。

2. VMをデプロイして消費状況を確認する

--require-specific-reservation がfalseに設定されているため、VMのデプロイスクリプトを変更する必要はありません。同じゾーンで完全に一致するVMを起動すれば、GCPは自動的にそのVMを予約済み容量に割り当てます。

想定した数のインスタンスが予約枠を消費していることを確認するには、Google Cloud Consoleで予約の指標をチェックしてください。現在の予約は Compute Engine > 予約 で確認でき、過去の使用状況はGoogle Cloud Monitoringで指標 compute.googleapis.com/reservation/used および compute.googleapis.com/reservation/reserved を使って確認できます。

3. 予約をクリーンアップする

標準のVMとは異なり、容量予約は不要になった時点で明示的に削除する必要があります。ワークロードを完全に廃止してVMを削除しても、予約の削除を忘れると、空のGPU容量に対してオンデマンドの全額料金を払い続けることになります。さらにCUDも課金されます。

予約が不要になったら、コマンドラインで削除します。

gcloud compute reservations delete gpu-maintenance-reservation \
    --project=my-project-id \
    --zone=us-central1-c \
    --quiet

費用について

GCPの予約に追加料金はかかりません。ただし、予約したリソースについては、実行中のVMにアタッチされているかアイドル状態かにかかわらず料金が発生します。すでにアクティブなGPU VMの料金を支払っているのであれば、予約を追加してもコストは変わりません。アイドルコストが発生するのは、メンテナンス中にVMが再起動しているわずか数分間だけであり、ハードウェアを失うリスクに対する安価な保険と言えます。

インスタンスの停止中に予約済み容量に対していくら支払ったかを正確に確認するには、DoiT Cloud Analyticsが利用できます。compute.googleapis.com/reservation SKUでレポートをフィルタリングすれば、ダウンタイム中に保証された容量の正確なコストを監査できます。

GCPの予約を活用することで、ハードウェアの可用性を運任せから予測可能な保証へと変えられます。予約には基盤となるコンピュートに対する追加料金が一切かからないため、重要なGPUインスタンスを予約で保護しないままにしておくのは無用なリスクです。対象ゾーンで必要な容量を正確にプロビジョニングし、一致するインスタンステンプレートからデプロイして、日常的な再起動や避けられないGoogleのメンテナンスイベントでワークロードが立ち往生しないようにしましょう。