このドキュメントでは、Compute Engine ゾーンリソースの予約の動作、要件、制限、請求について説明します。
概要
必要なときに Compute Engine リソースを確実に使用できるようにするには、予約を使用します。予約を使用すると、Compute Engine ゾーンリソースの容量を確実に確保できます。予約を使用すると、プロジェクトで将来的に必要となるリソースの増加にも対応できます。たとえば、次のような場合に役立ちます。
- 成長
- 計画的または想定外の負荷の急増
- 多数の仮想マシン（VM）インスタンスの移行
- バックアップと障害復旧
予約では、VM の 95% が 120 秒以内に起動します。各予約では、同じプロパティを持つ 1 台以上の VM が確保されます。予約を作成すると、予約したリソースがすぐに使用可能になり、予約を削除するまで使用できます。同様に、予約したリソースに対する課金がすぐに開始されます。予約が不要になった場合は、予約を削除して課金を停止できます。VM が予約を使用している間、別途課金されることはありません。
予約済みリソースの使用量にかかわらず、予約すると他のユーザーが予約済みリソースを使用できなくなります。予約すると予約されていない実行中の VM と同じ量のリソースが占有されるため、予約済みリソースは実行中の VM と同じオンデマンド料金（適用される割引を含む）で課金されます。
予約の仕組み
予約により、指定した構成で 1 つ以上の Compute Engine VM に容量を確保できます。 Compute Engine のコミットメントや VM を使用するその他のプロダクトで予約を使用することもできます。
予約を作成するときは、次のプロパティを定義します。
- プロビジョニングの種類（オンデマンドまたは将来）
- オンデマンド予約（デフォルト）は、リクエストされた容量が利用可能な場合、リクエスト時にプロビジョニングされます。
将来の予約を使用すると、重要な容量または取得が難しい容量を事前に確実にリクエストできます。具体的には、将来の予約は 2 つのリソースタイプで構成されます。将来の予約リクエストは、承認された場合、自動作成予約を将来の指定された時間に提供します。リクエストされた予約期間が経過すると、自動作成予約は自動的に削除されるか、オンデマンド予約と同様に動作します。
将来の予約を使用すると、Google Cloud がリクエストを処理する時間が増えるため、オンデマンド予約よりも容量を確実に確保できます。将来の予約を使用する場合は、このドキュメントではなく将来の予約リクエストについてをご覧ください。
- 自動削除
自動削除オプションは、完全に使用されたかどうかに関係なく、予約を自動的に削除することを指定します。自動削除オプションを有効にすると、予約は指定した日時から 2 時間以内に削除されます。予約の自動削除は、しばらく使用されていない予約に不要な料金が発生しないようにすることができます。
- 使用タイプ（自動または特定）
- 自動的に使用される予約（デフォルト）は、予約を自動的に使用することを許可する（デフォルト）予約アフィニティ プロパティを持つ VM が使用できます。
- 明示的に対象となっている予約は、その特定の予約を使用対象とする予約アフィニティ プロパティを持つ VM のみが使用できます。明示的に対象となっている予約を使用すると、どの VM がどの予約を使用しているかを簡単に追跡および制御できます。
-
- 単一プロジェクトの予約（デフォルト）は、予約と同じプロジェクト内にある VM のみが使用できます。
- 共有予約は、予約が存在するプロジェクト内の VM と、予約を共有している他のプロジェクトで使用できます。共有予約を使用すると、予約の使用率が改善され、作成や管理が必要な予約の数を減らすことができます。詳細については、このドキュメントの共有予約の仕組みをご覧ください。
- 省略可: リソース プレースメント ポリシー（コンパクト）
コンパクト プレースメント ポリシーは、予約済み VM 間のネットワーク レイテンシを短縮するために予約済み VM 同士をできるだけ近くに配置するように示します。
- VM 数
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 のみが予約を使用できます。
プロジェクトで、予約するリソースに対して十分な割り当て量が設定されている必要があります。予約が正常に作成されると、そのリソースの割り当ても課金対象になります。
コミットメントに関連付けられている予約の追加要件
コミットメントに関連付けられている予約には次の要件があります。
予約は、コミットメントと同じプロジェクトとリージョンに存在する必要があります。
予約は、コミットメントと同じマシン ファミリー シリーズである必要があります。ただし、そのマシン ファミリー シリーズ内の任意のマシンタイプを選択できます。
予約では自動削除オプションを無効にする必要があります。
コミットメントで 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 個のリソースの割り当てを使用します。
コンパクト プレースメント ポリシーを使用した予約の追加要件
予約にコンパクト プレースメント ポリシーを指定する場合は、次の要件を確認してください。
コンパクト プレースメント ポリシーは、予約をサポートしている必要があります。
コンパクト プレースメント ポリシーでは、固定数の VM を指定することはできません。
コンパクト プレースメント ポリシーでは、最大距離値を
1に指定することはできません。コンパクト プレースメント ポリシーでは、一度に複数の予約で指定することはできません。
予約はコンパクト プレースメント ポリシーをサポートしている必要があります。
コンパクト プレースメント ポリシーは、コミットメントに関連付けられていないオンデマンド予約、単一プロジェクト予約、明示的に対象となっている予約に対してのみ指定できます。
予約によって予約される VM は、コンパクト プレースメント ポリシーでサポートされている必要があります。
予約のゾーンは、コンパクト プレースメント ポリシーのリージョン内に存在している必要があります。
予約の VM 数は、コンパクト プレースメント ポリシーがサポートする VM の最大数以下にする必要があります。
予約のマシンタイプは、コンパクト プレースメント ポリシーでサポートされている必要があります。
詳細については、コンパクト プレースメント ポリシーの制限事項をご覧ください。
制限事項
すべての予約に次の制限があります。
1 つの予約で予約できる VM は最大 1,000 台です。
A3 VM を予約できるのは、オンデマンドかつ明示的に対象となっている予約のみです。
予約は、次の Google Cloud プロダクトの VM の使用に対してのみ適用されます。
- Batch
- Compute Engine
- Dataflow
- Dataproc
- Google Kubernetes Engine
予約は、以下のリソースには適用されません。
f1-microおよびg1-smallマシンタイプ- プリエンプティブル VM
- 単一テナントノード
- 上記以外のサービス（Cloud SQL など）
Compute Engine は、予約の作成時にオンデマンド リソースを割り当てようとします。リクエスト時にゾーン内のリソースが不足していると、容量不足によってリソースの可用性エラーが発生し、予約が失敗します。予約が正常に作成されると、リソースが使用可能になります（すぐに使用する必要はありません。後で利用することも可能です）。
コミットメントに関連付けられている予約の追加の制限事項
コミットメントに関連付けられている予約には、次の制限があります。
予約はリソースベースのコミットメントにのみ関連付けることができます。
予約を関連付けることができるのは、コミットメントの購入時のみです。
特定の予約は 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 を利用できる場合は、代わりに割引料金が使用されます。
次のステップ
- 予約の作成方法を学習します。