スロットについて
BigQuery スロットは、BigQuery で SQL クエリ、Python コード、その他のジョブタイプの実行に使用される仮想コンピューティング ユニットです。あるクエリで使用されるスロット数は、クエリ実行中に BigQuery によって自動的に決定され、このとき処理データ量、クエリの複雑さ、利用可能なスロット数が考慮されます。一般に、スロットが多いほど同時実行可能なクエリの数が増え、複雑なクエリをより高速に実行できます。
オンデマンド料金と容量ベースの料金
スロットはすべてのクエリで使用されますが、使用量の課金方法には、オンデマンド料金モデルと容量ベースの料金モデルの 2 種類があります。
デフォルトではオンデマンド モデルが適用され、各クエリによって処理されたデータの量（TiB 単位）に基づいて課金されます。オンデマンド モデルを使用するプロジェクトには、一時的なバースト容量を備えた、プロジェクトごとおよび組織ごとのスロット上限が適用されます。このオンデマンド モデルのスロット容量上限は、ほとんどのユーザーにとって十分なものです。ただし、ワークロードによっては、アクセスできるスロットが多いほどクエリのパフォーマンスが向上する場合があります。アカウントのスロット使用状況を確認するには、健全性、リソース使用率、ジョブをモニタリングするをご覧ください。
容量ベースのモデルでは、クエリに割り当てられたスロット容量に対して、時間の経過とともに料金が発生します。このモデルでは、合計スロット容量を明示的に制御できます。使用するスロットの数は、予約で明示的に選択します。予約のスロット数は、ベースライン数（常に割り当てられた状態となる数）として指定することも、自動スケーリング数（必要に応じて割り当てられる数）として指定することもできます。自動スケーリング スロットを含む予約は、ワークロードの需要に合わせて容量をスケーリングします。BigQuery は、ワークロードの変更に応じてスロットを割り当てます。これにより、予約を使用するワークロードのパフォーマンスや重要度に基づいて、予約のスロット数を構成できます。
スロットを使用したクエリ実行
BigQuery でクエリジョブを実行すると、SQL ステートメントが実行プランに変換され、一連のクエリステージで構成されます。ステージは、実行ステップのセットで構成されます。BigQuery は、分散並列アーキテクチャを使用してクエリを実行します。ステージは、並列実行できる作業単位をモデル化したものです。ステージ間でのデータの受け渡しには、分散シャッフル アーキテクチャが使用されます。このアーキテクチャの詳細については、この Google Cloud ブログ投稿をご覧ください。
BigQuery のクエリ実行は動的です。クエリの処理中にクエリプランを変更できます。ステージが追加されると、データ分散に合わせてワークロードの分散を最適化できます。また、他のクエリの開始や終了、オートスケーラーによる予約へのスロットの追加などに伴って、クエリの実行容量が変化する可能性があります。
BigQuery は複数のステージを同時に実行でき、投機的実行によってクエリを高速化できます。また、ステージを動的に再パーティション分割して最適な並列化を実現できます。
スロット リソースの利用の仕組み
利用可能な量を超えるスロットがクエリによってリクエストされた場合、個々の作業単位はキューに入れられ、スロットが利用可能になるまで待機状態になります。クエリ実行の処理が進行してスロットが解放されると、キューに格納された作業単位が動的に取得されて実行されます。
BigQuery は、クエリの特定のステージで任意の数のスロットをリクエストできます。リクエストされるスロットの数は、購入容量とは関係なく、BigQuery によって選択されたそのステージの最適な並列化係数を反映したものです。作業単位はキューに入れられ、スロットが利用可能になると実行されます。
コミットしたスロット数を上回るクエリの需要が発生しても、追加スロットや追加のオンデマンド レートが課金されることはありません。個々の作業単位はキューに入れられます。
たとえば
- クエリステージは 2,000 個のスロットをリクエストしていますが、1,000 個のスロットしか利用できないとします。
- 1,000 個のスロットがすべて消費され、残りの 1,000 個のスロットがキューに入れられます。
- その後、100 個のスロットが作業を終了すると、キューに入れられた 100 個の作業単位から動的に 1,000 個の作業単位が選択されます。キューには、900 作業単位が残ります。
- その後、500 個のスロットが作業を終了すると、キューに入れられた 900 個の作業単位から動的に 500 個の作業単位が選択されます。キューには、400 作業単位が残ります。
ワークロードに必要なスロット数が、予約で利用可能なスロット数を超えている場合、スロットが利用可能になるまでジョブが待機するため、ジョブのランタイムが増加する可能性があります。これはスロット競合と呼ばれます。ワークロードの需要が、予約に使用可能なスロットよりもはるかに大きい場合、スロット競合が増加する可能性があります。
容量の優先順位付け
BigQuery が特定のリージョンでスロット リソースの需要が高い場合、容量の優先付けにより競合を管理します。この優先順位付けにより、上位の容量モデルを使用しているお客様への影響が軽減されます。システムは、次の順序で容量を優先的に割り当てます。
- Enterprise Plus エディションと Enterprise エディションのベースラインとコミット済みの容量。
- Enterprise Plus の自動スケーリングされた容量。
- Enterprise エディションの自動スケーリングされた容量。
- Standard エディションとオンデマンドの容量。
リージョンで競合が発生した場合、システムはまず上位エディションにリソースを割り当てるため、Standard エディションとオンデマンド容量リクエストでアクセス遅延が発生する可能性が高くなります。
BigQuery のフェア スケジューリング
BigQuery では、フェア スケジューリングと呼ばれるアルゴリズムを使用して、単一の予約にスロット容量を割り当てます。
BigQuery スケジューラでは、スロットを予約内の実行中のクエリとともにプロジェクト間で均等に共有し、さらに特定のプロジェクトの複数ジョブでも均等に共有するように自動的に調整されます。スケジューラでは最終的な公平性を確保します。短期間に、一部のジョブでスロットの割り当てが不均衡になる可能性がありますが、スケジューラは最終的にこれを是正します。スケジューラの目的は、積極的に実行中のタスクでエビクションが発生する（結果としてスロット時間が無駄になる）状況と、過度に寛容で、ジョブでのタスク実行が長引く（結果としてスロット時間の割り当てが不均衡になる）状況のバランスを取ることです。
フェア スケジューリングは、すべてのクエリが、使用可能なすべてのスロットにいつでもアクセスできることを意味します。また、各クエリの要求量が変化すると、アクティブなクエリ間で容量が動的かつ自動的に再割り当てされることも意味します。次の条件の下で、クエリが完了し、新しいクエリが送信されて実行されます。
- 新しいクエリが送信されるたびに、実行中のクエリ間で容量が自動的に再割り当てされます。個々の作業単位は、各クエリでより多くの容量が使用可能になると、一時停止、再開、キューへの格納が適切に行われます。
- クエリが完了すると、そのクエリが消費していた容量が他のすべてのクエリですぐに自動的に使用可能になります。
- クエリの動的 DAG の変更によりクエリの容量が変化するたびに、BigQuery はそのクエリおよびその他のすべてのクエリの利用可能量を自動的に再計算し、必要に応じてスロットを再割り当ておよび一時停止します。
クエリの複雑さとサイズに応じて、利用できるスロットをすべて利用しない場合もあれば、さらに多くのスロットを必要とする場合もあります。BigQuery では、フェア スケジューリングが有効になっていると、すべてのスロットをいつでもフルに利用できる状況が動的に実現されます。
重要なジョブが、スケジューラによる割り当て量よりも多くのスロットを終始必要としている場合は、必要なスロット数で追加の予約を作成し、その予約にジョブを割り当てることを検討してください。
フェア スケジューリングの例として、次のような予約構成があるとします。
- 自動スケーリングのない 1,000 個のベースライン スロットがある予約
A - 予約に割り当てられているプロジェクト
AとプロジェクトB
シナリオ 1: プロジェクト A で、高いスロット使用率を必要とするクエリ A（1 つの同時クエリ）を実行し、プロジェクト B で 20 個の同時クエリを実行します。予約 A を使用しているクエリは合計 21 個ありますが、スロットの分配は次のようになります。
- プロジェクト
Aに 500 個のスロットが割り当てられ、クエリAは 500 個のスロットで実行されます。 - プロジェクト
Bには 500 個のスロットが割り当てられ、20 個のクエリで共有されます。
シナリオ 2: プロジェクト A で、100 個のスロットを必要とするクエリ A（1 つの同時クエリ）を実行し、プロジェクト B で 20 個の同時クエリを実行します。クエリ A には予約の 50% は必要ないため、スロットの分配は次のようになります。
- プロジェクト
Aに 100 個のスロットが割り当てられ、クエリAは 100 個のスロットで実行されます。 - プロジェクト
Bには 900 個のスロットが割り当てられ、20 個のクエリで共有されます。
逆に、次の予約構成について考えてみましょう。
- 自動スケーリングのない 1,000 個のベースライン スロットがある予約
B - すべて予約
Bに割り当てられている 10 個のプロジェクト
10 個のプロジェクトで十分なスロット需要のあるクエリが実行されている場合、各プロジェクトで実行されているクエリの数に関係なく、各プロジェクトには予約の合計スロットの 1/10（100 個のスロット）が割り当てられます。
スロットの割り当てと上限
スロットの割り当てと上限により、BigQuery の安全性が確保されます。次のように、料金モデルによって使用するスロット割り当てのタイプが異なります。
オンデマンド料金モデル: 一時的なバースト機能を備えた、プロジェクトごとおよび組織ごとのスロット数の上限が適用されます。ワークロードによっては、アクセスできるスロットが多いほど、クエリのパフォーマンスが向上します。
容量ベースの料金モデル: 予約の割り当てと上限によって、ロケーション内のすべての予約に割り当てることができるスロットの最大数が決まります。 自動スケーリングを使用する場合、最大予約サイズの合計がこの上限を超えないようにしてください。割り当てではなく、予約とコミットメントに対してのみ課金されます。 スロットの割り当てを増やす方法については、割り当ての増加リクエストをご覧ください。
使用しているスロットの数を確認するには、BigQuery のモニタリングをご覧ください。
アイドル スロット
任意の時点で、一部のスロットがアイドル状態のこともあります。これには次のものが含まれます。
- 予約のベースラインに割り当てられていないスロット コミットメント。
- 予約のベースラインに割り当てられているものの、使用されていないスロット。
アイドル状態のスロットは、オンデマンド料金モデルを使用する場合は適用されません。
デフォルトでは、予約で実行されるクエリは、同じリージョンと管理プロジェクト内の他の予約のアイドル状態のスロットを自動的に使用します。BigQuery は、割り当てられた予約に、必要に応じてすぐにアイドル状態のスロットを割り当てます。別の予約で使用されていたアイドル状態のスロットは、元の予約で必要になった場合、すぐにプリエンプトされます。短い時間ですが、スロットの合計消費量がすべての予約で指定した最大値を超えることがありますが、この追加のスロット使用量に対しては請求されません。
たとえば、次のような予約設定があるとします。
project_aはreservation_aに割り当てられています。自動スケーリングのない 500 個のベースライン スロットがあります。project_bはreservation_bに割り当てられています。100 個のベースライン スロットがあり、自動スケーリングは行われません。- 両方の予約が同じリージョンと管理プロジェクトにあり、これらの予約に割り当てられているプロジェクトはほかにありません。
project_b で query_b を実行します。project_a で実行中のクエリがない場合、query_b は reservation_a から 500 個のアイドル スロットにアクセスできます。query_b が実行中の場合、最大 600 スロット（100 ベースライン スロット + 500 アイドル スロット）を使用することがあります。
query_b の実行中に、500 個のスロットを使用できる project_a で query_a を実行するとします。
project_aに 500 個のベースライン スロットが予約されているため、query_aはすぐに開始され、500 個のスロットが割り振られます。query_bに割り当てられるスロット数は、100 個のベースライン スロットに急速に減少します。project_bで実行される追加のクエリは、これらの 100 個のスロットを共有します。後続のクエリで開始に十分なスロットがない場合は、実行中のクエリが完了してスロットが使用可能になるまでキューに追加されます。
この例では、project_b がベースライン スロットまたは自動スケーリングのない予約に割り当てられている場合、query_a の実行後に query_b にスロットがなくなります。アイドル スロットが利用可能になるか、クエリがタイムアウトするまで、BigQuery は query_b を一時停止します。project_b の追加クエリは、アイドル状態のスロットが使用可能になるまでキューに入ります。
プロビジョニングされたスロットのみが予約で使用されるようにするには、ignore_idle_slots を true に設定します。ただし、ignore_idle_slots が true に設定された予約では、アイドル スロットを他の予約と共有できます。
異なるエディションの予約の間でアイドル スロットを共有することはできません。共有できるのは、ベースライン スロットまたはコミット済みスロットのみです。自動スケーリング済みスロットは一時的に利用できる場合がありますが、スケールダウンされる可能性があるため、他の予約のアイドル スロットとして共有することはできません。
ignore_idle_slots が false である限り、予約にスロット数 0 の設定が可能で、未使用のスロットに引き続きアクセスできます。default 予約のみを使用する場合は、ベスト プラクティスとして ignore_idle_slots をオフに切り替えてください。それから、その予約にプロジェクトまたはフォルダを割り当てると、アイドル スロットのみが使用されます。
ML_EXTERNAL タイプの割り当ては例外であり、BigQuery ML の外部モデル作成ジョブで使用されるスロットはプリエンプティブルではありません。ML_EXTERNAL と QUERY の両方の割り当てタイプを含む予約のスロットは、ML_EXTERNAL ジョブがスロットを占有していない場合にのみ、他のクエリジョブに使用できます。また、これらのジョブは、他の予約のアイドル スロットを使用できません。
予約ベースの公平性
予約ベースの公平性を有効にすると、BigQuery は、各予約でジョブを実行しているプロジェクトの数に関係なく、同じ管理プロジェクト内のすべての予約に対して均等に、アイドル スロットを優先的に割り当てます。各予約にアイドル スロット プール内の利用可能な容量がほぼ均等に割り当てられた後、その予約のスロットがプロジェクト内で公平に分配されます。この機能は、Enterprise エディションまたは Enterprise Plus エディションでのみサポートされています。
次の図は、予約ベースの公平性が有効になっていない場合に、アイドル状態のスロットがどのように分配されるかを示しています。
この図では、アイドル状態のスロットがプロジェクト間で均等に共有されています。
予約ベースの公平性が有効になっていない場合、利用可能なアイドル状態のスロットは、予約内のプロジェクト間で均等に分配されます。
次の図は、予約ベースの公平性が有効になっている場合に、アイドル状態のスロットがどのように分配されるかを示しています。
この図では、アイドル状態のスロットはプロジェクトではなく、予約間で均等に共有されています。
予約ベースの公平性が有効になっている場合、利用可能なアイドル状態のスロットは、予約間で均等に分配されます。
予約ベースの公平性を有効にする場合は、リソース消費量を確認して、スロットの利用可能性とクエリのパフォーマンスを管理します。
厳しい時間要件がある本番環境ワークロードでは、アイドル状態のスロットのみを使用することは避け、ベースライン スロットまたは自動スケーリング スロットを使用してください。アイドル スロットはいつでもプリエンプトされる可能性があるため、優先度の低いジョブに使用することをおすすめします。
スロットの自動スケーリング
次のセクションでは、自動スケーリング スロットと、それらが予約とどのように連携するかについて説明します。
自動スケーリングの予約を使用する
自動スケーリングの予約を作成する前に、スロット コミットメントを購入する必要はありません。スロット コミットメントでは、一貫して使用されるスロットに対して割引料金が適用されますが、自動スケーリングの予約ではこれはオプションです。自動スケーリングの予約を作成するには、予約に最大数のスロット（最大予約サイズ）を割り当てます。自動スケーリング スロットの最大数は、最大予約サイズから、予約に割り当てられたオプションのベースライン スロットをすべて差し引くことで特定できます。
自動スケーリングの予約を作成する場合は、次の点を考慮してください。
- BigQuery は、ジョブの実行に必要なスロット数に達するか、予約に使用できるスロットの最大数に達するまで、予約をほぼ瞬時にスケーリングします。スロットは常に 50 の倍数に自動スケーリングされます。
- スケールアップは実際の使用量に基づいており、50 スロット単位で切り上げられます。
- 自動スケーリングされたスロットには、スケールアップの際に、関連するエディションの容量コンピューティング料金が適用されます。請求は、使用したスロットの数ではなく、スケーリングされたスロットの数に対して行われます。この料金は、BigQuery をスケールアップするジョブが失敗した場合にも適用されます。このため、請求と照合するためにジョブ情報スキーマを使用しないでください。代わりに、情報スキーマを使用して自動スケーリングをモニタリングするをご覧ください。
- スロット数は常に 50 の倍数でスケーリングされますが、1 ステップで 50 を超えるスロットがスケーリングされる場合があります。たとえば、ワークロードで 450 スロットを追加する必要がある場合、BigQuery は容量要件を満たすために一度に 450 スロットをスケーリングしようとする可能性があります。
- 予約に関連付けられたジョブが容量を必要としなくなった場合、BigQuery はスケールダウンします（最小 1 分）。
自動スケーリングされた容量は 60 秒以上保持されます。この 60 秒をスケールダウン ウィンドウと呼びます。容量の新しいピークが発生すると、スケールダウン ウィンドウがリセットされ、容量レベル全体が新しい割り当てとして扱われます。ただし、前回の容量増加から 60 秒以上が経過し、需要が減少している場合、システムはスケールダウン ウィンドウをリセットせずに容量を削減します。これにより、遅延なく連続して削減が行われます。
たとえば、初期ワークロード容量が 100 スロットにスケーリングされた場合、ピークはすくなくとも 60 秒間保持されます。このスケールダウン ウィンドウ中にワークロードが 200 スロットの新しいピークにスケーリングされた場合、60 秒間の新しいスケールダウン ウィンドウが開始されます。このスケールダウン ウィンドウ中に新しいピークがない場合、60 秒の終了時にワークロードのスケールダウンが開始されます。
次の具体例について考えてみましょう。12:00:00 に初期容量が 100 スロットにスケーリングされ、使用が 1 秒間続くとします。このピークは、12:00:00 から少なくとも 60 秒間保持されます。60 秒が経過した後（12:01:01）、新しい使用量が 50 スロットの場合、BigQuery は 50 スロットにスケールダウンします。12:01:02に新しい使用量が 0 スロットの場合、BigQuery はすぐに 0 スロットにスケールダウンします。スケールダウン ウィンドウが終了すると、BigQuery は新しいスケールダウン ウィンドウを必要とせずに、連続して複数回スケールダウンできます。
自動スケーリングの操作方法については、自動スケーリング スロットの操作をご覧ください。
ベースライン スロットと自動スケーリング スロットとともに予約を使用する
最大予約サイズを指定するだけでなく、必要に応じて予約あたりのスロットのベースライン数を指定できます。ベースラインは予約に常に割り当てられる最小スロット数であり、それらは常に課金されます。自動スケーリング スロットは、すべてのベースライン スロット（と、該当する場合はアイドル スロット）が使用された後にのみ追加されます。1 つの予約のアイドル ベースライン スロットは、容量を必要とする他の予約と共有できます。
予約のベースライン スロット数は数分ごとに増やすことができます。ベースライン スロットを減らしたい場合、ベースライン スロット容量が最近変更され、ベースライン スロットがコミット済みスロットを超過する場合は、1 時間に 1 回に制限されます。それ以外は、ベースライン スロットを数分ごとに減らすことができます。
ベースライン スロットと自動スケーリング スロットは、最近のワークロードに基づいて容量を提供することを目的としています。最近のワークロードとかなり異なる大規模のワークロードが予想される場合は、ワークロードの容量に対応する自動スケーリング スロットをあてにするのではなく、イベントの前にベースライン容量を増やすことをおすすめします。ベースライン容量の増加に問題が発生した場合は、15 分待ってからリクエストを再試行してください。
予約にベースライン スロットがない場合、または他の予約からアイドル スロットを借用するように構成されていない場合、BigQuery はスケーリングを試みます。それ以外の場合、スケーリングの前にベースライン スロットを十分に活用する必要があります。
予約では、次の優先度でスロットを使用および追加します。
- ベースライン スロット。
- アイドル スロットの共有（有効になっている場合）。予約では、同じエディションと同じリージョンで作成された他の予約のアイドル ベースライン スロットまたはコミット済みスロットのみを共有できます。
- 自動スケーリング スロット。
次の例では、スロットは指定されたベースラインの量からスケーリングされます。etl 予約と dashboard 予約は、それぞれベースライン サイズが 700 スロットと 300 スロットです。
この例では、etl 予約は 1,300 スロットまでスケーリングできます（700 ベースライン スロット + 600 自動スケーリング スロット）。dashboard 予約が使用されていない場合、etl 予約は、ジョブが何も実行されていなければ dashboard 予約からの 300 スロットを使用できるため、使用できるスロット数は最大 1,600 になります。
dashboard 予約は、1,100 スロットまでスケーリングできます（300 ベースライン スロット + 800 自動スケーリング スロット）。etl 予約が完全にアイドル状態の場合、dashboard 予約は、最大で 1,800 スロットまでスケーリングできます（300 ベースライン スロット + 800 自動スケーリング スロット + etl 予約の 700 アイドル スロット）。
etl 予約で常に使用可能な 700 を超えるベースライン スロットが必要な場合、次の順序でスロットの追加が試されます。
- 700 のベースライン スロット。
dashboard予約の 300 ベースライン スロットとの共有のアイドル スロット。予約は、同じエディションで作成された他の予約とのみ、アイドル状態のベースライン スロットを共有できます。- 最大予約サイズまでの 600 の追加スロットのスケールアップ。
スロット コミットメントの使用
次の例は、容量コミットメントを使用したスロットの自動スケーリングを示しています。
予約ベースラインと同様に、スロット コミットメントでは、すべての予約で使用可能な固定数のスロットを割り当てることが可能になります。ベースライン スロットとは異なり、期間中はコミットメントを削減できません。スロット コミットメントはオプションですが、ベースライン スロットが長期間必要な場合は、費用を節約できます。スロット コミットメントは、予約のベースライン スロットをカバーするために使用されます。未使用のスロット容量は、他の予約間でアイドル スロットとして共有されます。スロット コミットメントは自動スケーリング スロットには適用されません。コミットされたスロットの割引料金を受け取るには、スロット コミットメントがベースライン スロットをカバーするのに十分であることを確認してください。
この例では、容量コミットメント スロットに対して事前定義されたレートで課金されます。自動スケーリングが有効になり、予約がアップスケールされた状態になると、自動スケーリング スロットの数に対してスケーリング料金が課金されます。自動スケーリング料金では、使用されたスロット数ではなく、スケーリングされたスロット数に対して課金されます。
次の例は、ベースライン スロットの数がコミット済みスロットの数を超えている場合の予約を示しています。
この例では、2 つの予約のベースライン スロットの合計は 1,000 個です（etl 予約から 500 個、dashboard 予約から 500 個）。ただし、コミットメントは 800 スロットのみを対象としています。このシナリオでは、超過したスロットは従量課金制（PAYG）のレートで課金されます。
使用可能なスロットの最大数
予約で使用できるスロットの最大数は、ベースライン スロット、自動スケーリング スロットの最大数、および同じエディションで作成され、ベースライン スロットで消費されていないコミットメントのスロットを合計することで計算できます。前の画像の例では、次のように設定されています。
- 年間 1,000 スロットの容量コミットメント。それらのスロットは、
etl予約とdashboard予約でベースライン スロットとして割り当てられます。 etl予約に割り当てられる 700 のベースライン スロット。dashboard予約に割り当てられる 300 のベースライン スロット。etl予約の 600 の自動スケーリング スロット。dashboard予約の 800 の自動スケーリング スロット。
etl 予約の場合、使用可能なスロットの最大数は etl ベースライン スロット（700）、dashboard ベースライン スロット（すべてのスロットがアイドル状態の場合、300）、自動スケーリング スロットの最大数（600）の合計に等しくなります。したがって、この例では etl 予約で使用できるスロットの最大数は 1,600 です。この数は容量コミットメントの数を超えています。
次の例では、年間のコミットメントが割り当てられたベースライン スロット数を上回っています。
この例でのスロット数は以下のとおりです。
- 年間 1,600 スロットの容量コミットメント。
- 1,500 （500 の自動スケーリング スロットを含む）の最大予約サイズ。
etl予約に割り当てられる 1,000 のベースライン スロット。
予約に使用できるスロットの最大数は、ベースライン スロット（1,000）、ベースライン スロット専用ではないコミットされたアイドル スロット（1,600 の年間スロット - 1,000 のベースライン スロット = 600）、自動スケーリング スロットの数（500）の合計に等しくなります。したがって、この予約のスロットの取りうる最大数は 2,100 です。自動スケーリングされるスロットは、容量コミットメントを超える追加スロットです。
自動スケーリングのベスト プラクティス
オートスケーラーを初めて使用するときは、自動スケーリング スロットの数を、過去および予想されるパフォーマンスに基づいて妥当な数に設定します。予約を作成したら、失敗率、パフォーマンス、請求をアクティブにモニタリングして、必要に応じて自動スケーリング スロットの数を調整します。
オートスケーラーのスケールダウンには最低でも 1 分はかかるため、パフォーマンスと費用のバランスを考慮して自動スケーリング スロットの最大数を設定する必要があります。自動スケーリング スロットの最大数が大きく、ジョブがすべてのスロットを使用して数秒で完了する場合でも、1 分間の最大スロット数分の費用が発生します。最大スロットを現在の半分に減らすと、予約はより少ない数にスケーリングされ、その分ジョブは 1 分間に多くの
slot_secondsを使用できるため、無駄が減ります。スロットの要件を判断する方法については、ジョブのパフォーマンスをモニタリングするをご覧ください。スロット要件を決定する別の方法については、エディション スロットの推奨事項を表示するをご覧ください。スロットの使用量は、ベースラインとスケーリングされたスロットの合計を超える場合があります。ベースラインとスケーリングされたスロットの合計を超えるスロットの使用量に対しては課金されません。
オートスケーラーは、複数の同時実行クエリを持つワークロードなど、大規模で時間がかかるワークロードに最適です。クエリは 1 個ずつ送信しないでください。クエリごとに予約がスケーリングされ、スケーリングは最低でも 1 分間維持されます。クエリを継続的に送信し、ワークロードが一定の場合、ベースラインを設定して確約購入すると、割引価格で一定の容量が提供されます。
BigQuery の自動スケーリングは、容量の可用性の影響を受けます。BigQuery は、過去の使用状況に基づいてお客様の容量需要を満たそうとします。容量を保証するために、オプションのスロット ベースライン（予約で保証されるスロット数）を設定できます。ベースラインを使用すると、スロットは直ちに利用可能になり、使用するかどうかにかかわらず課金されます。大規模な需要（祝日におけるトラフィックの急増など）のために容量を確保するには、数週間前に BigQuery チームにお問い合わせください。
ベースライン スロットに対しては常に課金されます。容量コミットメントが期限切れになった場合は、不要な料金が発生しないように、予約のベースライン スロット数を手動で調整する必要があります。たとえば、100 スロットの 1 年間のコミットメントと 100 ベースライン スロットの予約があるとします。コミットメントが期限切れになり、更新プランはありません。コミットメントが期限切れになると、従量課金制で 100 ベースライン スロットに対して支払いを行うことになります。
自動スケーリングのモニタリング
自動スケーリングによるスロット使用率とジョブ パフォーマンスのモニタリングについては、自動スケーリングをモニタリングするをご覧ください。
スロットの過剰使用
ジョブがスロットを長時間保持すると、スロット割り当てが不公平になる可能性があります。遅延を防ぐために、BigQuery では他のジョブが追加のスロットを借りられます。その結果、指定されたスロット容量を超えるスロット使用量が発生することがあります。スロットの使用量が超過した場合、その超過分は、公平な割り当て以上の割り当てを受けたジョブにのみ適用されます。
超過分のスロットに対しては、直接課金されません。代わりに、ジョブは引き続き実行され、超過使用量が、すべて割り当てられた容量でカバーされるまで、公平な割合でスロット使用量が蓄積されます。余分なスロットは、特定の実行統計情報を除き、報告されるスロット使用量から除外されます。
ただし、将来の遅延を減らし、スロットのコスト変動の減少や、テール レイテンシの低減などのメリットを得るために、スロットのプリエンプティブな借用が行われることがあります。スロットの借用は、合計スロット容量のごく一部に制限されます。