Professional Data Engineer（Google Cloud） 問題集

正解: A

正解の理由
Sizing slot reservations の節は、性能を試すリージョンにアイドル スロットがあると、予約は想定より少ないスロットで性能を満たすことがあると書く。予約がアイドル スロットを使って必要なスロットを賄ったからである。ほかの予約の負荷が変わってアイドル スロットが減れば、性能は落ちうる。そのため、締め切りのある本番の負荷では、予約をスロットの容量の面で自立させ（self-reliant）、アイドル スロットの増減がジョブの性能に直接響かないようにするよう書く。

違う選択肢
「試しに作った予約は、あとで本番用の別の管理プロジェクトへ移せるので、試したベースラインのまま本番に持ち込める」… Specifying an administration project の節の注記は、予約やコミットメントを作ったあとは、別の管理プロジェクトへ移せないと書く。本番を別の管理プロジェクトで動かすなら、そこで予約を作り直す。ページは、管理プロジェクトの数を絞り、できれば組織の予約をすべて1つの管理プロジェクトにまとめるよう勧める。
「スロットの見積もりツール（slot estimator）はオンデマンドの料金では使えないので、切り替える前は試しの予約で測る」… Estimate and control costs のページの Use the slot estimator の節は、オンデマンドの料金モデルの利用者も、容量ベースの料金へ移るときの、同じくらいの性能のコミットメントと自動スケーリングの予約の大きさの推奨を見られると書く。Sizing slot reservations の節は、スロットを割り当てて負荷を少なくとも7日間動かしたあとに、見積もりツールで性能を分析し、スロットの増減の影響をモデル化できると書く。
「オンデマンドのプロジェクトは2,000スロットが固い上限なので、切り替える前の使用量はその値として見積もるだけでよい」… 同じ節は、オンデマンドの負荷には2,000スロットのソフトな上限（soft slot cap）があると書き、プロジェクトが実際に使っているスロットの数を INFORMATION_SCHEMA.JOBS のビュー・Cloud Logging・Jobs API・監査ログで確かめることが大切だと書く。固い上限ではなく、その値を使用量と見なすこともしない。

押さえどころ
Slot reservations の節は、締め切りのある本番の負荷には十分なベースラインのスロットを持つ予約を作るよう書き、ベースラインのスロットは常に使えると書く。自動スケーリングの予約の容量は必ずしも確保されていない。予約は1つの管理プロジェクトに置き、ベースラインを0にして上限だけを決めれば、エディションを完全にオンデマンドのように使うこともできる（Estimate and control costs のページ）。