Reservations の概要
BigQuery Reservations では、オンデマンド料金と容量コミットメント料金を切り替えることができます。容量コミットメント料金では、専用のクエリ処理容量を購入します。BigQuery のエディションを操作する場合は容量コミットメントの作成は任意ですが、費用を節約できます。異なるプロジェクト、または組織の異なる部署に容量プールを予約することで、購入した容量を組織全体にを割り当てることができます。
概要
BigQuery には、分析用の次の 2 つの料金モデルが用意されています。
オンデマンド料金: クエリでスキャンされたデータに対して料金が発生します。プロジェクトごとにクエリの処理容量が固定されており、処理したバイト数に基づいて費用が設定されます。
容量コミットメント料金: 専用のクエリ処理容量を購入します。
デフォルトでは、オンデマンド料金モデルに沿って請求されます。BigQuery Reservations を使用してコミットメントを購入することにより、容量コミットメント料金に切り替えることができます。 コミットメントは、BigQuery スロットの単位で購入します。処理データの費用はすべて定額料金に含まれます。
BigQuery Reservations を使用すると、次のメリットがあります。
予測可能性。定額料金では、費用が固定で予測可能です。何の費用かを前もって把握できます。
柔軟性。購入する容量を選択できます。容量コミットメントを削除するまで、1 秒あたりの定額料金で課金されます。両方の課金モデルを組み合わせることができます。たとえば、一部のワークロードをオンデマンド料金で実行して、それ以外は定額料金で実行できます。
BigQuery では、最小限の月間コミットメントまたは年間コミットメントを購入した場合、割引の定額料金が適用されます。
ワークロード管理。スロットを購入したら、ワークロードに割り当てることができます。これにより、ワークロードには利用可能な BigQuery 計算リソースの専用プールができます。それと同時に、ワークロードが割り当てられたスロットを一部しか使用していない場合、未使用のスロットは他のワークロード間で自動的に共有されます。
一元購入: スロットをまとめて購入し、組織全体に割り当てることができます。BigQuery を使用するプロジェクトごとにスロットを購入する必要はありません。
コミットメント
容量コミットメントは、最小期間の BigQuery コンピューティング容量の購入です。コミットメントは、計算能力の単位である BigQuery スロットで測定されます。スロットは、BigQuery で使用される仮想 CPU を表しています。一般的に、より多くのスロットを購入すると、同時に実行できるクエリの数が増え、複雑なクエリでも高速で実行できるようになります。 容量コミットメントは、エディションで作成された予約では必須ではありませんが、費用を節約できます。
BigQuery では、いくつかのコミットメント プランから選択できます。これらは主に、コミットメントの費用と最小使用期間によって異なります。最新の料金情報については、容量コミットメント料金をご覧ください。- 3 年間の確約利用。3 年間のコミットメントを購入します。3 x 365 日後に、更新または別のタイプのコミットメント プランへの変更のいずれかを選択できます。
年間契約。365 日間分のコミットメントを購入します。365 日後に、更新または別のタイプのコミットメント プランへの変更のいずれかを選択できます。
月次契約。最低 30 日間分のコミットメントを購入します。30 日後には、いつでもプランをキャンセルできます。
Flex Slots。60 秒のコミットメントを購入します。60 秒後にいつでもそれを削除できます。Flex Slots は、長期のコミットメントを購入する前に、定額制でワークロードがどのように動作するかをテストするのに適しています。周期的または定期的に使用したい場合や、税務申告など負荷の大きいイベントに使用するのにも便利です。
どのプランを選択しても、コミットメント期間の終了時にスロットは期限切れになりません。スロットは削除しない限り、保持されて課金されます。最小期間後にプランの種類の変更もできます。
スロットは容量の可用性の影響を受けます。スロット コミットメントを購入しようとするとき、その購入が成功するとは限りません。ただし、コミットメントの購入が成功すると、確保した容量はコミットメントを削除するまで保証されます。
これらのプランについて詳しくは、コミットメント プランをご覧ください。
予約
スロットの購入後、予約と呼ばれる別のバケットに割り当てることができます。予約を使用すると、特定の組織に合った方法でスロットを割り当てることができます。
たとえば、本番環境ワークロード用に prod という名前の予約と、テスト用に test という名前の個別の予約を作成するとします。これにより、テストジョブが本番環境ワークロードに必要なリソースと競合しなくなります。または、組織内の部門ごとに予約を作成することもできます。
スロットを購入するときに、default という名前の予約が自動的に作成されます。default の予約は特別なものではなく、便宜上作成されたものです。追加の予約が必要か、またはデフォルトの予約を使用するだけかを決めることができます。
購入したスロットを使用するには、次のセクションで説明するように、プロジェクトを予約に割り当てる必要があります。
スロット割り当てを指定するには少なくとも予約が必要です。予約で割り当てられたスロット割り当ては、BigQuery スケジューラによって処理されます。
割り当て
購入したスロットを使用するには、1 つ以上のプロジェクト、フォルダ、または組織を予約に割り当てる必要があります。リソース階層内の各レベルには、その上位のレベルから割り当てが継承されます。つまり、プロジェクトやフォルダが割り当てられていない場合、そのプロジェクトやフォルダには親フォルダや組織の割り当てが継承されます。リソース階層の詳細については、BigQuery リソースの整理をご覧ください。
予約に割り当てられているプロジェクトからジョブが開始されると、その予約のスロットが使用されます。（直接、または親フォルダか組織からの継承で）プロジェクトが予約に割り当てられていない場合、そのプロジェクトのジョブはオンデマンド料金を使用します。
None 割り当ては、割り当てがないことを表します。None に割り当てられたプロジェクトはオンデマンド料金を使用します。None 割り当ての一般的な使用例は、組織を予約に割り当て、その予約からオプトアウトできるよう、一部のプロジェクトまたはフォルダを None に割り当てるというものです。詳細については、プロジェクトを None に割り当てるをご覧ください。
割り当てを作成するときに、その割り当てのジョブタイプを指定します。
QUERY: この予約は、SQL、DDL、DML、BigQuery ML クエリなどのクエリジョブに使用します。PIPELINE: この予約は、読み込み、抽出、その他のパイプライン ジョブに使用します。デフォルトでは、読み込みジョブと抽出ジョブは無料で、スロットの共有プールを使用します。BigQuery は、この共有プールの使用可能容量や、表示されるスループットを保証しません。大量のデータを読み込む場合は、スロットが使用可能になるまでジョブが待機することがあります。その場合は、専用スロットを購入してパイプライン ジョブを割り当てることができます。アイドル スロットの共有を無効にして、専用の予約を追加作成することをおすすめします。
読み込みジョブは、予約に割り当てられると無料のプールにアクセスできなくなります。パフォーマンスをモニタリングして、ジョブに十分な容量があることを確認してください。そうしないと、実際には無料プールを使用するよりもパフォーマンスが低下する可能性があります。
BACKGROUND: この予約は、独自の予約を使用してインデックス管理ジョブを実行する場合に使用します。また、Datastream のバックグラウンド適用オペレーションでソース データベースを BigQuery にレプリケートする場合にも、この予約を使用します。BACKGROUND予約は Standard Edition では使用できません。ML_EXTERNAL: この予約は、BigQuery の外部にあるサービスを使用する BigQuery ML クエリに使用します。詳細については、BigQuery ML ワークロードへのスロットの割り当てをご覧ください。ML_EXTERNAL予約は Standard Edition では使用できません。
特定の割り当てにスロットを割り当てることはできません。BigQuery スケジューラは、予約のスロット割り当てを処理します。
スロットのスケジューリング
スロットはプロジェクト間で均等に分配され、次にプロジェクトのジョブ内で分配されます。
BigQuery スケジューラでは、スロットを予約内の実行中のクエリとともにプロジェクト間で均等に共有し、さらに特定のプロジェクトの複数ジョブでも均等に共有するように自動的に調整されます。スケジューラでは最終的な公平性を確保します。このため、短期的にいくつかのジョブでスロットの割り当てが不均衡になることがあっても、スケジューラによって最終的には是正されます。スケジューラの目的は、過度に積極的で、実行中のタスクのエビクションが発生する（結果としてスロット時間が無駄になる）状況と、過度に寛容で、ジョブでのタスク実行が長引く（結果としてスロット時間の割り当てが不均衡になる）状況の中間を見つけることです。
重要なジョブがスケジューラから受け取るより多いスロットを終始必要とする場合は、保証されているスロット数で追加の予約を作成し、その予約にジョブを割り当てることを検討してください。詳細については、ワークロードの管理をご覧ください。
アイドル スロット
任意の時点で、一部のスロットがアイドル状態のこともあります。これには次のものが含まれます。
- 予約に割り当てられていないスロット。
- 予約に割り当てられているが、現在使用されていないスロット。
デフォルトでは、予約で実行されるクエリは、他の予約のアイドル スロットを自動的に使用します。つまり、容量がある限り、ジョブは常に実行できます。オンデマンド料金モデルで実行されるクエリでも、他の予約のアイドル スロットが使用されます。オンデマンド スロットは、BigQuery のデフォルト予約にあります。
リソースを必要とするクエリの優先度にかかわらず、アイドル状態の容量は必要に応じて元の予約にプリエンプティブルに戻ります。この処理はリアルタイムで自動的に行われます。
この機能を無効にして、予約にプロビジョニングされたスロットのみが使用されるようにするには、ignore_idle_slots を true に設定します。ignore_idle_slots が true に設定された予約では、アイドル状態のスロットを受け取りません。
異なるエディションの予約間でアイドル スロットを共有することはできません。共有できるのは、ベースライン スロットまたはコミット済みスロットのみです。自動スケーリング済みスロットは一時的に利用できる場合がありますが、スケールダウンされる可能性があるため、共有することはできません。
ignore_idle_slots が false である限り、予約にスロット数 0 の設定が可能で、未使用のスロットに引き続きアクセスできます。default 予約のみを使用する場合は、この方法で設定することをおすすめします。その予約にプロジェクトまたはフォルダを割り当てると、アイドル状態のスロットのみが使用されます。
ML_EXTERNAL 型を割り当てることは、上記動作の例外にあたります。BigQuery ML の外部モデル作成ジョブによって使用されるスロットは、プリエンプティブルではありません。つまり、ml_external とクエリ割り当てタイプの両方を含む予約のスロットは、そのスロットが ML_EXTERNAL ジョブによって占有されていない場合にのみ、他のクエリジョブに使用できます。また、これらのジョブは、他の予約のアイドル スロットを使用することもありません。
制限事項
- 購入した予約は他の組織とは共有できません。
- 組織ごとに個別の予約と個別の管理プロジェクトを作成する必要があります。
- アイドル状態の容量は、組織間や単一の組織内の異なる管理プロジェクト間で共有できません。
- コミットメントは、リージョン リソースです。あるリージョンやマルチリージョンで購入したコミットメントは、他のリージョンやマルチリージョンでは使用できません。コミットメントを、リージョン間や、リージョンとマルチリージョン間で移動することはできません。
- あるプロジェクトで購入したコミットメントは、別のプロジェクトへの移動はできません。
- 異なるエディションの予約間でアイドル スロットを共有することはできません。共有できるのは、ベースライン スロットまたはコミット済みスロットのみです。自動スケーリング済みスロットは一時的に利用できる場合がありますが、スケールダウンされる可能性があるため、共有することはできません。
割り当て
スロット割り当ては、ロケーションで購入できるスロットの最大数です。割り当てに対して料金は発生しません。購入したコミットメントに対してのみ請求されます。詳細については、割り当てと上限をご覧ください。スロットの割り当てを増やす方法については、割り当ての増加リクエストをご覧ください。
料金
予約の料金については、フラットレート料金をご覧ください。
次のステップ
BigQuery Reservations を開始するにあたり、Reservations スタートガイドをご覧ください。
使用する課金モデルを決定する際の参考として、課金モデルの選択をご覧ください。