Reservations を使用したワークロード管理
このページでは、BigQuery ワークロードの管理に BigQuery Reservations を使用する方法について説明します。
課金モデルを選択する
オンデマンドと容量ベースの課金モデルは、いつでも切り替えることができます。また、2 つのモデルを組み合わせることもできます。2 つの料金モデルは相互補完的な関係にあります。オンデマンド課金では、必要なときにのみスロットの料金を支払うことができます。一方、容量ベースの料金では、予測可能なワークロードに対するスロットの割り当てを予約できます。また、通常はオンデマンド料金に割引が適用されます。
容量ベースの課金を選択する場合は、次の要素を考慮してください。
- 費用。毎月の分析費用は、BigQuery の最小容量ベースのコミットメント程度にすることをおすすめします。
- 効率性。実行頻度の低いワークロードや一貫性のないワークロードを実行する場合は、オンデマンド料金の方がより効率的である可能性があります。オンデマンド料金では、必要なときにのみスロットに対して支払います。
- 予測可能性。毎月一定の料金を支払うオプションがあるため、月額料金の予測可能性を重視する場合は、容量ベースの課金モデルをおすすめします。
- リソース。容量ベースとオンデマンドの課金モデルは、容量の提供方法が異なります。詳細については、購入するスロット量の見積もりをご覧ください。
新規のお客様の場合、容量ベースの課金での開始をおすすめします。オンデマンド課金にした場合の費用は随時確認できます。また、自分に適したモデルをいつでも選択できます。
スロットの自動スケーリングを試すこともできます。スロットの自動スケーリングは、ワークロードの急増に対応できる柔軟性を備えており、容量ニーズの変動に対処します。
ワークロード レベルまたはビジネス ユニットレベルでオンデマンドと容量ベースの課金モデルを組み合わせることもできます。このためには、ワークロードまたはビジネス ユニットを別々のプロジェクトまたはフォルダに整理して、それぞれを予約またはオンデマンド課金に割り当てます。
あるリージョンでは容量ベースを使用し、別のリージョンではオンデマンドを使用できます。デフォルトでは、すべてのプロジェクトでオンデマンド課金が使用されます。プロジェクト、フォルダ、または組織を予約に割り当てることで、特定のリージョンで容量ベースの課金を選択できます。たとえば、米国のマルチリージョンでスロット コミットメントを購入し、デフォルトの予約に組織を割り当てた場合、組織は米国のマルチリージョンでは容量ベースの課金になり、それ以外のリージョンではオンデマンド課金が継続されます。
特定のリージョンでは、明示的にプロジェクトを予約に割り当てることで、容量ベースの課金とオンデマンド課金を組み合わせて使用できます。予約に割り当てられていないプロジェクトでは、オンデマンド課金が継続されます。予約 ID none を割り当てることにより、オンデマンド課金を使用するように、明示的にプロジェクトを割り当てることもできます。これは、フォルダまたは組織を予約に割り当てる際、そのフォルダまたは組織内の一部のプロジェクトでオンデマンド課金を使用したい場合に有効です。詳細については、プロジェクトを None に割り当てるをご覧ください。
オンデマンド課金のプロジェクトでは、コミットされた容量とは別の容量を使用します。これらのプロジェクトは、コミットされた容量の可用性に影響しません。
管理プロジェクトの作成
コミットメントと予約を作成すると、Google Cloud プロジェクトに関連付けられます。このプロジェクトによって BigQuery Reservations リソースが管理されます。このプロジェクトはこれらのリソースに対する請求のプライマリ ソースになります。このプロジェクトは、BigQuery ジョブを保持するプロジェクトと同一である必要はありません。
Reservations リソース専用のプロジェクトを作成することをおすすめします。このプロジェクトは管理プロジェクトと呼ばれ、コミットメントの請求と管理を一元化します。このプロジェクトにわかりやすい名前を付けます（bq-COMPANY_NAME-admin など）。次に、BigQuery ジョブを保持する個別のプロジェクトを 1 つ以上作成します。
管理プロジェクトと同じ組織リソース内のプロジェクトのみ、予約に割り当てることができます。管理プロジェクトが組織の一部でない場合は、そのプロジェクトのみがスロットを使用できます。
管理プロジェクトは、commit したスロットに応じて課金されます。スロットを使用するプロジェクトは、スロットではなくストレージに応じて課金されます。複数のプラン（1 年と 3 年など）を購入し、スロットを同じ管理プロジェクトに配置できます。
すべての予約に対する管理プロジェクトを 1 つ作成することをおすすめします。単一の管理プロジェクトを使用すると、請求の管理とスロットの割り当てが簡素化されます。また、管理プロジェクトでのみ BigQuery Reservations API を有効にして、すべてのコミットメントがこのプロジェクトで管理されるようにすることをおすすめします。
複数の管理プロジェクトの作成
場合によっては、複数の管理プロジェクトを作成することをおすすめします。
- 複数の予約とコミットメントの費用を異なる組織部門に分割する。
- 複数のスロットのコミットメントを特定の予約セットにマッピングする。
アイドル スロットの容量は、異なる管理プロジェクトの予約間で共有されません。
Google Cloud コンソールの [BigQuery] ページでは、現在選択されている管理者プロジェクトの予約とコミットメントのみを表示できます。
購入するスロット数の見積もり
BigQuery は、リソースの増加に比例してスケールされるように設計されています。ワークロードによっては、容量が徐々に増加することで、得られるメリットも増えていく可能性があります。このため、最適な購入スロット数は、パフォーマンス、スループット、ユーティリティの要件によって異なります。
ベースライン スロットと自動スケーリング スロットを試して、スロットの最適な構成を決定できます。たとえば、500 ベースライン スロットでワークロードをテストし、次に 1,000 スロット、1,500 スロット、2,000 スロットと順にテストして、パフォーマンスへの影響を確認します。
選択した月額料金と一緒に、プロジェクトの現在のスロット使用量も確認できます。オンデマンド ワークロードでのスロットの上限は 2,000 スロットですが、ビューの INFORMATION_SCHEMA.JOBS*、Cloud Logging、Jobs API、または BigQuery の監査ログを使用して、プロジェクトで実際に使用されているスロットの数を確認することが重要です。詳細については、利用可能なスロットと割り当てられているスロットの表示をご覧ください。
スロットを購入して少なくとも 7 日間ワークロードを実行した後、スロット見積もりツール（プレビュー）を使用してパフォーマンスを分析し、スロットの追加や削除の影響をモデル化できます。詳細については、スロットの容量要件の見積もりをご覧ください。
予約を使用したワークロードと部門の管理
BigQuery Reservations を使用して、予約を追加作成し、それらの予約にプロジェクトを割り当てることで、commit された容量をワークロード、チーム、部門間で分離できます。予約はリソースの独立したプールであり、組織全体の空き容量を活用できるという利点があります。
たとえば、合計で 1,000 スロットの commit された容量があり、データ サイエンス、ELT、BI という 3 つのワークロードの種類があるとします。
- 500 個のスロットを使用して
ds予約を作成し、関連するすべての Google Cloud プロジェクトをds予約に割り当てることができます。 - 300 個のスロットを使用して
elt予約を作成し、ELT ワークロードに使用するプロジェクトをelt予約に割り当てることができます。 - 200 個のスロットを使用して
bi予約を作成し、BI ツールに接続されているプロジェクトをbi予約に割り当てることができます。
ワークロード全体で容量を分割するのではなく、個々のチームや部門用に予約を作成することもできます。
複数のリージョン間での予約の管理
Reservations はリージョン リソースです。あるリージョンで購入されたスロットと作成された予約は、他のリージョンでは使用できません。プロジェクト、フォルダ、組織はすべて、同じリージョン内で予約に割り当て、別のリージョンでオンデマンドで実行できます。別のリージョンの予約を管理するには、BigQuery の [容量管理] ページでリージョンを変更する必要があります。
- BigQuery コンソールで、[予約] をクリックします。
- [ロケーション] 選択ツールをクリックし、予約を管理するリージョンを選択します。
- リージョンを選択したら、スロットの購入、予約の作成、予約へのプロジェクトの割り当てを行えます。
複雑な組織用の BigQuery Reservations
BigQuery Reservations は、組織を対象にしたリソースです。組織全体で使用する予約を一元的に購入します。commit された容量を購入し、その容量を部門や部署全体に分配することで、個々の部門や部署に BigQuery Reservations の管理を求めることができます。Cloud 請求先アカウントには、管理プロジェクトが関連付けられており、容量に対して課金されます。
部署ごとに別個の Google Cloud 組織を使用できます。このシナリオでは、組織ごとに管理プロジェクトを定義し、その管理プロジェクトからその組織の BigQuery Reservations を管理します。複数の組織間で、commit された容量や未使用の容量が共有されることはありません。
アイドル スロットと未割り当てのスロットは、同じ管理プロジェクト内で同じエディション内に作成された予約間でのみ共有されます。複数の管理プロジェクトを使用する場合、異なる管理プロジェクトの予約間でスロットが共有されることはありません。