このドキュメントでは、Compute Engine ゾーンリソースの予約の動作、要件、制限、請求について説明します。
予約を使用すると、必要なときに同じプロパティを持つ仮想マシン（VM）インスタンスを特定のゾーンで使用できることが高い確度で保証されます。予約は、スケーリング、移行、障害復旧に役立ちます。
概要
予約を使用すると、必要なときに同じハードウェア（メモリと vCPU）とオプションのリソース（GPU とローカル SSD ディスク）を使用して VM を作成するためのリソースを確保できます。予約には次の利点があります。
容量の確実性が高い: 成長、計画的または計画外の負荷の急増、多数の VM の移行、バックアップと障害復旧など、将来の需要の増加に備えてリソースが予約されます。
独占的アクセス: 予約すると、他のユーザーが予約済みリソースを使用できなくなります。
継承されたプロパティ: 予約は、選択したマシン ファミリーと同じプロパティを継承します。
予約を作成するときに、Compute Engine は、指定されたゾーンでリクエストされた容量が使用可能であることを確認します。使用可能な場合、Compute Engine はリソースを予約し、予約を作成します。これにより、次の処理が行われます。
予約済みリソースはすぐに使用でき、予約を削除するまで使用可能となります。
予約済みリソースは、予約が削除されるまで、実行中の VM と同じオンデマンド料金（適用される割引を含む）で課金されます。予約を使用する VM に対しては、別途料金は発生しません。
予約の仕組み
予約を使用すると、ユーザーが指定した構成で 1 つ以上の VM の容量を確実に確保できます。 Compute Engine のコミットメントや VM を使用するその他のプロダクトで予約を使用することもできます。
予約を作成するときは、次のプロパティを定義します。
- プロビジョニングの種類（オンデマンドまたは将来）
- オンデマンド予約（デフォルト）は、リクエストされた容量が利用可能な場合、リクエスト時にプロビジョニングされます。
将来の予約を使用すると、重要な容量または取得が難しい容量を事前にほぼ確実にリクエストできます。具体的には、将来の予約は 2 つのリソースタイプで構成されます。将来の予約リクエストは、承認された場合、自動作成予約を将来の指定された時間に提供します。リクエストされた予約期間が経過すると、自動作成予約は自動的に削除されるか、オンデマンド予約と同様に動作します。
将来の予約を使用すると、 Google Cloudがリクエストを処理する時間が増えるため、オンデマンド予約よりも容量を確実に確保できます。将来の予約を使用する場合は、このドキュメントではなく将来の予約リクエストについてをご覧ください。
- 自動削除
自動削除オプションは、完全に使用されたかどうかに関係なく、予約を自動的に削除することを指定します。自動削除オプションを有効にすると、予約はデフォルトで指定された日時から 2 時間以内、またはカスタムで設定した日時に削除されます。予約の自動削除は、しばらく使用されていない予約に不要な料金が発生しないようにすることができます。
- 消費タイプ（自動または特定）
- 自動的に使用される予約は、予約を自動的に使用することを許可する（デフォルト）予約アフィニティ プロパティを持つ VM が使用できます。この使用タイプは、大量の VM を作成および削除し、可能な限り予約を消費する場合に便利です。
- 明示的に対象となっている予約は、その特定の予約を対象とする予約アフィニティ プロパティを持つ VM のみが使用できます。この使用タイプを使用すると、どの VM がどの予約を消費しているかを簡単に追跡および制御できます。
-
- 単一プロジェクトの予約（デフォルト）は、予約と同じプロジェクト内にある VM のみが使用できます。
- 共有予約は、予約が存在するプロジェクト内の VM と、予約を共有している他のプロジェクトで使用できます。共有予約を使用すると、予約の使用率が改善され、作成や管理が必要な予約の数を減らすことができます。詳細については、このドキュメントの共有予約の仕組みをご覧ください。
共有ポリシーでは、Vertex AI のカスタム トレーニング ジョブまたは予測ジョブで GPU VM の予約を使用できるかどうかを指定します。デフォルトでは、カスタム トレーニング ジョブまたは予測ジョブは GPU VM の予約を使用できません。これを変更するには、Vertex AI で使用される予約を作成または更新する方法をご覧ください。
- VM 数
VM 数は、予約の作成時に予約するプロパティとゾーンが一致する VM の数です。予約を作成したら、VM 数を変更できます。
- VM のプロパティ
VM のプロパティでは、予約する VM のハードウェア要件（メモリと CPU）とオプションのリソース（ローカル SSD ディスクと GPU）を記述します。予約を作成するときに、これらのプロパティを直接指定するか、既存の VM に基づいてプロパティを指定するか、インスタンス テンプレートを使用してプロパティを指定できます。VM のプロパティと予約の VM プロパティが両方とも完全に一致する場合にのみ、VM は予約を使用できます。詳細については、このドキュメントの要件をご覧ください。
- 省略可: リソース プレースメント ポリシー（コンパクト）
コンパクト プレースメント ポリシーは、予約済み VM 間のネットワーク レイテンシを短縮するために予約済み VM 同士をできるだけ近くに配置するように示します。
予約を消費している VM を停止、一時停止、または削除すると、その VM は予約の使用数として計算されなくなります。予約済み容量が再び使用可能になります。
予約を削除して予約済み容量を解放するものの、予約を消費している VM は保持する場合は、次の点を考慮してください。
自動的に消費される予約は、VM を停止または一時停止することなく削除できます。予約を削除しても、その予約を消費していた VM は引き続き実行されます。引き続き課金が発生します。
明示的に対象となっている予約を削除できるのは、VM がその予約を消費していない場合のみです。VM を停止または一時停止した場合、予約を削除した後に VM を再起動または再開できるのは、削除された予約と一致する名前、ゾーン、プロパティを持つ新しい予約を明示的に指定して作成した場合のみです。
共有予約の仕組み
共有予約内の各 VM は、予約を作成したプロジェクト（オーナー プロジェクト）または予約を共有するプロジェクト（コンシューマ プロジェクト）の VM で使用できます。VM が共有予約の使用を停止すると、予約が共有されているプロジェクト内の別の VM が共有予約を使用できます。共有予約で複数の VM を予約している場合、複数プロジェクトの VM が同じ共有予約を同時に使用できます。
デフォルトでは、プロジェクトで共有予約の作成と変更を行うことはできません。プロジェクトで共有予約を作成および変更するには、共有予約オーナー プロジェクト（compute.sharedReservationsOwnerProjects）組織のポリシー制約の許可リストにプロジェクトを追加する必要があります。予約を共有する場合は、追加の割り当て要件の影響を受けます。また、単一プロジェクトの予約とは使用動作が異なります。
要件
すべての予約に次の要件があります。
VM インスタンスは、次に示すすべてのプロパティが VM と 予約の両方で正確に一致している場合にのみ、予約を使用できます。
プロジェクト
- プロジェクトの要件は、予約の共有タイプによって異なります。
ゾーン
マシンタイプ
最小 CPU プラットフォーム
GPU のタイプと数（該当する場合）
ローカル SSD のタイプと数（該当する場合）
予約アフィニティ
- 予約アフィニティの要件は、予約の使用タイプによって異なります。
コンパクト プレースメント ポリシー（該当する場合）
- 必要に応じて予約にコンパクト プレースメント ポリシーを含めると、予約済み VM 間のネットワーク レイテンシを短縮するために予約済み VM 同士をできるだけ近くに配置するように指示することができます。予約でコンパクト プレースメント ポリシーを指定すると、同じコンパクト プレースメント ポリシーを指定する VM のみが予約を使用できます。
位置情報のヒント（該当する場合）
- 予約には必要に応じて
locationHintフィールドを含めることができます。このフィールドは、REST を使用して予約する場合または VM を作成する場合にのみ指定できます。予約を作成するときにlocationHintフィールドを指定することはおすすめしません。
- 予約には必要に応じて
予約するリソースに対して、プロジェクトで未使用の割り当てが利用可能である必要があります。予約が正常に作成されると、これらのリソースの割り当てがすぐに消費されます。
コミットメントに関連付けられている予約の追加要件
コミットメントに関連付けられている予約には次の要件があります。
予約は、コミットメントと同じプロジェクトとリージョンに存在する必要があります。
予約は、コミットメントと同じマシン ファミリー シリーズである必要があります。ただし、そのマシン ファミリー シリーズ内の任意のマシンタイプを選択できます。
予約では自動削除オプションを無効にする必要があります。
コミットメントで GPU、ローカル SSD ディスク、またはその両方が指定されている場合、関連付けられた予約（または関連付けられた予約の組み合わせ）では、コミットメントとまったく同じ数と種類のリソースを指定する必要があります。
詳細については、予約をリソースベースのコミットメントに関連付けるをご覧ください。
インスタンス テンプレートから作成された予約の追加要件
インスタンス テンプレートを指定して予約を作成する場合は、次の点を確認してください。
予約は、テンプレート内のリソースと同じリージョン、ゾーン、プロジェクトに作成する必要があります。特に、以下の点に注意してください。
インスタンス テンプレートで指定されているリージョン リソースやゾーンリソース（マシンタイプやディスクなど）によって、テンプレートの使用はそれらのリソースが存在するロケーションに限定されます。たとえば、インスタンス テンプレートで
us-central1-aゾーンの既存のディスクが指定されている場合、同じゾーンに予約を作成する必要があります。インスタンス テンプレートにはプロジェクト固有の設定が含まれているため、アクセスして使用できるのは同じプロジェクト内のインスタンス テンプレートに限られます。共有予約が共有されているプロジェクトでは、それらのプロジェクトに同じテンプレートを作成するか、プロパティを直接指定して VM を作成する必要があります。
インスタンス テンプレートでコンパクト プレースメント ポリシーを指定する場合は、特定の予約を作成する必要があります。次に、予約を使用する VM を作成する際に、予約を名前で明示的に指定にする必要があります。明示的に指定しなければ、VM は予約を使用できません。
共有予約の追加の割り当て要件
共有予約のオーナー プロジェクトとコンシューマー プロジェクトには割り当てによって以下のような影響があります。
オーナー プロジェクト: オーナー プロジェクトは、次のように割り当てを使用します。
共有予約を作成すると、オーナー プロジェクトは予約済みリソースの合計に対する割り当てを使用します。
予約済みリソースを使用すると、オーナー プロジェクトは使用したリソースの割り当てを使用します。
コンシューマー プロジェクト: コンシューマー プロジェクトは、予約済みリソースを使用した場合にのみ割り当てを使用します。その割り当ては、使用したリソースのみを対象とします。
たとえば、プロジェクト A（オーナー プロジェクト）が 10 個のリソースの共有予約を作成し、その予約をプロジェクト B および C（コンシューマー プロジェクト）と共有するとします。共有予約を作成すると、プロジェクト A は 10 個のリソースの割り当てを使用します。プロジェクト A と B がそれぞれ 2 つの予約済みリソースを使用する場合、プロジェクト A と B はそれぞれ 2 個のリソースの割り当てを使用します。プロジェクト A は合計で 12 個のリソースの割り当てを使用して、プロジェクト B は 2 個のリソースの割り当てを使用し、プロジェクト C は（予約を使用しなかったため）0 個のリソースの割り当てを使用します。
コンパクト プレースメント ポリシーを使用した予約の追加要件
予約にコンパクト プレースメント ポリシーを指定する場合は、次の要件を確認してください。
コンパクト プレースメント ポリシーは、予約をサポートしている必要があります。
コンパクト プレースメント ポリシーでは、最大距離値を
1に指定することはできません。コンパクト プレースメント ポリシーでは、一度に複数の予約で指定することはできません。
予約はコンパクト プレースメント ポリシーをサポートしている必要があります。
コンパクト プレースメント ポリシーは、コミットメントに関連付けられていないオンデマンド予約、単一プロジェクト予約、明示的に対象となっている予約に対してのみ指定できます。
予約によって予約される VM は、コンパクト プレースメント ポリシーでサポートされている必要があります。
予約のゾーンは、コンパクト プレースメント ポリシーのリージョン内に存在している必要があります。
予約の VM 数は、コンパクト プレースメント ポリシーがサポートする VM の最大数以下にする必要があります。
予約のマシンタイプは、コンパクト プレースメント ポリシーでサポートされている必要があります。
制限事項
すべての予約に次の制限があります。
予約は、次の Google Cloudプロダクトでのみ使用できます。
- バッチ
- Compute Engine
- Dataflow
- Dataproc
- Google Kubernetes Engine
- Vertex AI
1 つの予約で予約できる VM は最大 1,000 台です。
次の Compute Engine リソースでは予約を使用できません。
f1-microおよびg1-smallマシンタイプSpot VM またはプリエンプティブル VM
単一テナントノード
VM の予約アフィニティ プロパティを更新して、一致する予約（
ANY_RESERVATION）または予約なし（NO_RESERVATION）を自動的に消費するように設定できます。
コミットメントに関連付けられている予約の追加の制限事項
コミットメントに関連付けられている予約には、次の制限があります。
予約はリソースベースのコミットメントにのみ関連付けることができます。
予約を関連付けることができるのは、コミットメントの購入時のみです。
特定の予約は 1 つのコミットメントにのみ関連付けることができます。
コミットメントに関連付けられている予約を削除またはサイズ変更することはできません。代わりに、コミットメントに関連付けられている予約を置き換える方法をご覧ください。
詳細については、予約をリソースベースのコミットメントに関連付けるをご覧ください。
共有予約の追加の制限事項
共有予約には次の制限があります。
予約を共有できるのは、予約を作成するプロジェクトと同じ組織内のプロジェクトのみです。
各共有予約は、1～100 個のコンシューマー プロジェクトと共有できます。
各組織で、VM プロパティの一意の組み合わせごとに最大 100 個の共有予約を作成できます。
一覧表示できるのは、そのプロジェクトで作成された予約のみです。つまり、共有予約はその予約を作成したプロジェクトでのみ表示されます。組織内のすべての共有予約や、特定のプロジェクトと共有されているすべての予約を一覧表示することはできません。
インスタンス テンプレートを指定して共有予約を作成した場合、プロジェクト内のユーザーのみが同じインスタンス テンプレートにアクセスし、インスタンス テンプレートを使用して VM や他の予約を作成できます。
共有予約を作成する際に、コンパクト プレースメント ポリシーを指定することはできません。
共有予約を使用していたプロジェクトを新しい組織に移行しても、その共有予約は新しい組織に移行されません。このプロジェクトで作成された共有予約はすべて削除されます。このプロジェクトと共有されていた以前の組織の予約を新しい組織で使用することはできません。詳細については、このドキュメントの共有予約の仕組みをご覧ください。
共有予約のベスト プラクティスに沿うことで、一部の要件の制限を緩和できます。
コンパクト プレースメント ポリシーを使用した予約の追加の制限事項
コンパクト プレースメント ポリシーを指定する予約には次の制限があります。
コンパクト プレースメント ポリシーを予約間で共有することはできません。代わりに、コンパクト プレースメント ポリシーを適用する予約ごとに別々のコンパクト プレースメント ポリシーを使用する必要があります。
コンパクト プレースメント ポリシーのみ指定できます。インスタンス スケジュールやスナップショット スケジュールなど、他のいかなるタイプのリソース ポリシーもサポートされていません。
請求
予約は、予約済みリソースと同じレート（予約されていない実行中の VM と同じオンデマンド料金や 1 分単位の最小料金など）で課金されます。 実行中の VM と同様に、継続利用割引（SUD）、CUD、カスタム料金も適用されます。
たとえば、次のようなシナリオがあるとします。
us-central1で 3 基の vCPU のコミットメントを購入している。us-central1-aで 5 基の vCPU を使用している。us-central1-aで 10 基の vCPU を予約している。
このシナリオでは、 Google Cloud は次のように課金します。
| 対象 | vCPU 数 |
|---|---|
| 確約利用割引の料金 | 3 |
| オンデマンド料金（予約で使用済みの 2 基の vCPU の使用料金 + 予約で未使用の 5 基の vCPU の使用料金） | 7 |
予約では、予約済みリソースが使用中であるかどうかにかかわらず、予約が存在する限り予約済みリソースに対する料金が発生します。予約を使用している間、予約済みリソースの料金がすでに請求されているため VM に重複するリソース料金は発生しません。詳細については、VM の料金をご覧ください。
また、予約の使用傾向をモニタリングして、無駄なリソースや未使用のリソースによる不要な費用を削減できます。詳細については、予約の使用をモニタリングするをご覧ください。
共有予約のその他の課金情報
共有予約の使用に追加料金は発生しません。単一プロジェクトの Compute Engine の予約と同じ料金が課金されます。ただし、プロジェクトごとに CUD が違う可能性があるため、共有予約の課金対象となるプロジェクトは使用量に応じて変わります。
共有予約の請求プロジェクトと料金は次のように処理されます。
- 課金プロジェクト: デフォルトでは、オーナー プロジェクトが共有予約に対して課金されます。ただし、共有予約のリソースがコンシューマー プロジェクトによって使用されている場合、そのコンシューマー プロジェクトが予約に対して課金されます。
- 請求割引: デフォルトでは、請求はオンデマンド料金に基づいて行われます。ただし、課金対象のプロジェクトまたはそのプロジェクトに関連付けられた Cloud 請求先アカウントのいずれかで CUD を利用できる場合は、代わりに割引料金が使用されます。
次のステップ
- 予約の作成方法を学習します。