要約

  • Google Cloudは9月8日、Compute Engineの単一プロジェクト予約と共有予約の相互変換を正式提供にした。変わるのは既存容量を使える範囲だ。
  • 共有自体に追加料金はないが、未使用資源の課金は続く。共有予約を明示的に指定する利用側インスタンスがある場合、単一プロジェクトに戻す際には運用上の条件がある。

待機中の容量に別の使い道を与える

将来の作業に備えてあるチームが確保した容量を、別のチームが今すぐ使えることがある。Google Cloudの9月8日の更新記録は、その利用範囲を変える機能を正式提供とした。条件を満たす予約は、単一プロジェクト用から共有へ、共有から単一プロジェクト用へ変更できる。

共有予約そのものが初めて登場したわけではない。今回の新機能は二つの方式の切り替えだ。他組織に容量を転売する仕組みでもない。変更ガイドによると、共有先は同一組織内の最大100プロジェクトで、共有予約の変更は作成元のプロジェクトから行う。資源を使う側に所有者が移ることはない。

集中的に容量を管理するチームにとっては、条件の合う別の需要に空きを振り向けられる可能性がある。ただし、共有先が増えても予約済み資源は増えず、権限や割り当て上限の要件もなくならない。

利用先が変わると請求先も変わる

予約の基本説明では、予約が存在する限り、資源は使用の有無にかかわらず課金される。その資源を使う仮想マシンに、同じ予約資源の料金が二重に発生するわけではない。

共有そのものへの追加料金はない。標準では所有者プロジェクトに請求されるが、利用側プロジェクトが共有資源を使うと、その分の請求先は利用側になる。適用可能な確約利用割引などの条件によって料金は変わり得る。したがって、利用範囲の変更は新しい値引きではなく、どのプロジェクトでも同じ請求額になるという約束でもない。

例えば、後日の処理に備えて容量を持つチームと、今すぐ対応する資源を必要とするチームを考えてみる。これは仮定であり、Googleが報告した導入効果ではない。共有により待機中の資源を活用できる可能性はある。それでも両者の需要が重なれば、有限の容量をどう配分するかは残る。設定が業務上の優先順位を決めてくれるわけではない。

元に戻す側には依存関係が残る

共有予約を明示的に指定するインスタンスがある場合、単一プロジェクト予約への変更前に、共有先プロジェクトでその予約を使うインスタンスを停止、サスペンド、または削除する必要があるとガイドは説明する。この要件は所有者プロジェクトのインスタンスには適用されない。

さらに、停止またはサスペンドした利用側インスタンスがその共有予約を指定していると、代わりの予約ができるまで起動・再開できない。代替予約は元と同じ所有者プロジェクト、ゾーン、名前を持ち、属性が一致する必要がある。これは仕様上の依存条件の説明であって、障害が起きたという報道でも、処理の削除を勧めるものでもない。自動的に共有容量を消費する全インスタンスへ一般化してはいけない。

確約に結び付いた予約は別の置換手順に従い、将来予約から自動生成される予約にも固有の制限がある。今回の正式提供は、あらゆる予約や商業条件を自由に書き換えられるという意味ではない。利用範囲の柔軟性と、他者が依存した資源を容易に回収できることは別だ。