要点:GoogleはBigQueryのコンピュートとストレージの両方について、料金体系とコンピュートモデルを大幅に変更します。Flat-rateおよびFlex Slotsの新規購入は終了し、flat-rateから新料金体系への移行は4月、料金変更は2023年7月5日に開始されます。
2023年3月29日、GoogleがBigQuery Editionsを発表しました。BigQueryのほぼ全期間にわたって続いてきた料金モデルからの大転換です。本記事ではBigQueryのコンピュート側に絞り、今回の発表で何が変わったのかを解説します。なお、Editionsに伴うストレージ側の変更については、同僚のPhilippがこちらの記事でまとめていますので、あわせてご覧ください。
料金を検討する際は、コンピュートとストレージの両方を見比べることが重要です。本記事で取り上げるコンピュートの値上げは、新しいストレージ変更によって相殺され、場合によっては完全に打ち消されることもあるためです。
あらかじめお断りしますが、本記事はかなりの長文です。役職や立場によって必要となる情報は異なりますので、目次から必要な箇所を探して読み進めていただくことをおすすめします。DoiT Internationalのチームで蓄積してきた知見を結集し、想定されるあらゆる疑問をBigQueryチームにぶつけたうえで、すべてのGCPユーザー(現在のお客様も、これからご縁のある皆さまも!)に向けてまとめました。
Googleからも、Editionsの選び方や必要なサイジングのガイドがこちらに公開されています。
長文のため、目的の箇所にすぐ飛べるよう以下に目次を用意しました。
目次
Flat-rateとFlex Slots——一つの時代の終わり
> Enterprise Plus Edition (EPE)
Flat-RateとEditionsのオートスケーリングの併用 まとめ
押さえておきたい主要用語
本記事で使う用語の簡単な解説です。BigQueryに精通している方にはおなじみの内容ですが、そうでない方は読み進める前に目を通しておくとスムーズです。
従来からの用語:
- Job(ジョブ)
BigQuery上で実行される処理単位で、クエリ、データのロード、データのコピーなどが該当します。最も一般的なのがクエリで、ジョブとクエリはほぼ同じ意味で使われることもよくあります。
- Slot(スロット)
BigQueryでジョブを処理する基本的なコンピュートの構成要素です。「小さな仮想マシン」のようなもので、多数が連携してジョブを処理するイメージです。
- Reservation(予約)
0個以上のプロジェクトに割り当てるスロットのセットを確保するための仕組みです。
- Commitment
通常1か月または1年といった一定期間、固定数のスロットを予約する代わりに割安な料金が適用される仕組みです。
- Admin Project(管理プロジェクト) BigQueryの予約とcommitmentsを束ねる「マネージャー」役のプロジェクトです。通常は組織ごとに1つ(または少数)を用意し、組織内のBigQueryリソースを「単一画面」で管理できるようにします。flat-rateやEditionsを利用するプロジェクトでは、組織全体の予約課金SKUがこのプロジェクトに紐づきます。
- Flex Slots
短期的なスロット数の急増に対応するため、予約に追加できるスロットです。秒単位課金ですが、最低課金時間は60秒です。
- Idle Slot(アイドルスロット) 現時点でジョブに使われていないスロットです。
- Workloads
workloadは、単一プロジェクト内で実行されるジョブの集合を指します。
Editions固有の新しい用語:
- Slot-Hour(スロット時間)
BigQuery Editionsプロジェクトの基本的な課金指標で、1つのスロットを1時間ジョブで使用した状態を指します。注: 本記事では実態をより的確に表すため「スロット/時間」と表記します。
使用したスロット/時間の計算式は以下の通りです。
使用スロット/時間 = <使用スロット数> * (<秒単位の時間>/3600秒)
- Autoscaling Slots(オートスケーリングスロット) 2023年初頭にパブリックプレビューとして公開された新しい仕組みで、実行中のworkloadの必要量に応じて、ベースラインスロット数から最大スロット数までスケールアップします。
- Baseline Slots(ベースラインスロット) BigQuery Editions予約で常時「ホット」かつアクティブに維持される最小スロット数です。オートスケーリングが発動する前にまず利用され、予約がアクティブな間は課金されます。
- Max Slots(最大スロット)
BigQuery Editions予約においてオートスケーリングで到達できるスロット数の上限です。親予約に含まれる全プロジェクトのworkloadを合算しても、割り当てられるスロット数がこの値を超えることはありません。
タイムライン
これらの変更がいつ反映されるかは、Googleがタイムラインとして公開しています。準備のためにも、何がいつ変わるのかを正確に把握しておくことが重要です。
2023年3月29日
GoogleがBigQuery Editionsと料金変更を発表。料金変更の適用は7月5日からです。
2023年3月30日
BigQuery Slot AutoscalingがGenerally Available(GA)に。
2023年4月 BigQuery Editionsの展開が開始されますが、この時点では料金変更は伴いません。すべてのflat-rateのcommitmentsおよび予約は、識別用にflat-rateを示すタグを付与したEnterprise Edition版へ切り替わります。
2023年7月5日
現時点で個別契約のないお客様について、BigQueryのflat-rateおよびflex slotsの販売が終了します。
非オンデマンドプロジェクトに対してEditions料金が適用開始。
オンデマンドプロジェクトには、新しいオンデマンド料金である「スキャンデータ1TBあたり6.25 USD(25%値上げ)」が適用開始されます。
Editionsとは何か?
Googleは今年初めにSlots Autoscalingを発表しましたが、これがBigQuery Editionsへのさりげない布石となっていました。BigQuery Editionsは、BigQueryのコンピュート料金モデルを「常時オン」型から「使った分だけ課金」型へと抜本的に見直すものです。本記事ではBigQuery Editions、または略してEditionsと呼びます。
Slots Autoscalingが示唆していた通り、Editionsの根幹はそこにあります。今後の標準課金モデルは「スロット/時間」、すなわち1つのスロットを1時間使用するという単位に基づきます。
名称が「Edition」ではなく「Editions」と複数形であることからも分かる通り、Googleはサービス、機能、料金が異なる3つのレベルを用意しました。それぞれが「Edition」と呼ばれます。
Slots Autoscalingのリリース時に最も多く寄せられた質問は「これは現行の料金モデルを置き換えるのか?」というものでした。当時は不明でしたが、今回の発表でGoogleは、EditionsがFlex Slotsを含むflat-rate料金モデルを置き換えると明言しました。施行日は7月5日です。
元の料金体系に戻せるのか?
あいにくタイムマシンのデロリアンでもない限り、現在flat-rate料金を利用しているお客様について、Googleはflat-rateからEditionsへ移行させる一方で、元の料金モデルに戻す手段は提供しません。
つまり2023年7月5日には、月次commitsは自動的にEditions料金モデル、具体的には後述するEnterprise Editionへ変換されます。年次commitsは1年間料金が変わらない契約のため、そのまま継続されます。
ただし年次commitに加入している場合、そのスロット数で固定され、2023年7月5日以降はflex slotsや追加スロットを購入できなくなります。それを超える追加スロットが必要であれば、近い将来Googleが折衷案を打ち出さない限り、Editionsへ切り替える必要があります。
4月中は「テクニカルマイグレーション」が進み、すべてのflat-rate資産がEditions資産へと変換されます。この時点で新規のflat-rate予約は作成できなくなり、その時点に存在する予約構造が「固定」されます。以降、既存のflat-rate予約の修正は可能ですが、新規作成はできません。
他にどんな変更があるのか?
各Editionの概要に入る前に、多くの方が抱いているであろう疑問にお答えしておきましょう。本記事を読まれる頃には、ニュースサイトやTwitterでこの情報は広く拡散されているはずです。明日の朝7時にCEOから「これってどういうこと?」と電話がかかってきても答えられるよう、要点を整理していきます。
前述の通り、読み込み中心のユーザーから長く愛されてきたflat-rate料金モデルは、Editionsに席を譲ることになります。4月中、Googleはflat-rate予約上のすべてのプロジェクトをEnterprise Edition(略してEE。詳細は後述)へ切り替えます。この時点では当該プロジェクトの料金には影響しません。
既存のworkloadのパフォーマンスが低下することはなく、workloadの観点で何らかの変化が見られることもないはずです。Googleからは、シームレスな移行になると確約されています。
この体制は、Editionsの料金が正式に適用される7月5日まで、プロジェクトの修正を引き続き許容する形で運用されます。
既存のcommitを利用している場合は?
flat-rate料金を利用している場合、月次または年次のcommitに加入しているはずです。デフォルトは月次のため、よく分からない場合はおそらく月次でしょう。請求書で「BigQuery Flat Rate Monthly for
デフォルトである月次commitのお客様の場合、7月5日にこれらのcommitsは自動的にEnterprise Editionへ変換されます(詳細は本記事後半で解説)。
現在年次commitに加入している場合、その条件は契約満了日まで変わらず、満了時点で紐づくすべての予約がEnterprise Editionに切り替わります。これはcommitが期間中の法的拘束力を持つ契約とみなされるためです。
Flat-rateとFlex Slots——一つの時代の終わり
2023年7月5日、Googleアカウントチームと明示的にこれ以降の利用を許可する契約を結んでいない限り、すべてのユーザーに対しflat-rate料金とflex slotsの購入が無効化されます。つまり、現在年次flat-rate commitに加入している場合でも、7月5日以降はflex slotsを購入できなくなります。
flat-rate料金とflex slotsを愛用してきた私たちのために、ここで少しの間、黙祷を捧げましょう。
黙祷が済んだら、続けます。
つまり、今回の変更を見据えて環境を再設計する時間を稼ぎたい場合や、その他の理由でflat-rateスロットを維持したい場合は、その日までに年次commitを購入しておくのが得策です。commitments獲得に向けた「ゴールドラッシュ」が起きて発表内容が変わる可能性もあるため、7月5日のかなり前に動いておくことをおすすめします。
オンデマンド利用はどうなる?
勘の鋭い読者の方や、ふだんBigQueryをライトに使われている方は、ここまでflat-rate課金の変更ばかりで、オンデマンド料金に触れていないことにお気づきでしょう。
現在、BigQueryのデフォルト料金モデルはオンデマンドモデルで、米国リージョンではクエリやジョブによってスキャンされたデータ1TBあたり5 USDが課金されます(請求や多くのユーザーは「analysis」と呼びます)。7月5日以降、これは米国でスキャンされたデータ1TBあたり6.25 USDに引き上げられ、一部の他リージョンはこれよりわずかに高くなります。25%の値上げで、リージョンごとに料金が異なる場合も、それぞれ同様に25%引き上げられます。
オンデマンドを継続するお客様の既存の機能や上限は一切変わりません。詳しくは後述しますが、オンデマンド料金はEnterprise Plus Editionと同じ機能セットを持ちつつ、2,000クエリスロットなど従来の上限は維持されます。何度かいただいた質問にお答えしておくと、BigQuery ML(BQML)は2023年7月5日以降もオンデマンド課金で引き続き利用できます。
オンデマンドとCompressed Storageに関して、すでに何度か挙がっている質問があります。「Compressed Storageとオンデマンドを併用する場合、論理(非圧縮)ストレージと物理(圧縮)ストレージのどちらに対して課金されるのか?」答えは、BigQueryが分析前に解凍する必要があるため、非圧縮ストレージに対して課金されます。この値はINFORMATION_SCHEMAおよび監査ログシンクのbytes_billed値に反映されます。
追記:以前は「オンデマンドではCompressed Storageを利用できない」と書きましたが、これは誤りでした。調査の結果、誤った記述であることが判明しました。「Edition対応」、すなわち組織内にflat-rateプロジェクトがない、Edition予約を保有している、またはオンデマンド課金モデルである場合、Compressed Storageは利用可能です。ここで「組織」と書いた点に注意してください。2023年7月5日時点で、年次commitによるflat-rate予約が組織内に1つでも残っている場合、そのcommitの期間が終了するまでCompressed Storageは利用できません。
各BigQuery Editionの概要
Googleが今回のEditionsで強く打ち出しているポイントの一つは、影響範囲がBigQueryのコンピュート料金側のみで、ストレージ側には及ばないという点です。ストレージは今回の変更の影響を一切受けません。この前提を念頭に、以降を読み進めてください。
詳細を見ていく前に、1つのEditionは1つの予約に適用でき、その予約には0個以上のプロジェクトを含められる点を押さえておきましょう。つまり、利用効率やコスト最適化に応じて、予約やプロジェクトをまたいでEditionを自由に組み合わせることができます。
Standard Edition (SE)
- スロットのオートスケーリング
- 予約あたり1,600スロットがハード上限
- 同時実行クエリ数は最大100
- 管理プロジェクトあたり最大5予約
- コンピュートworkloadは単一ゾーンのみで実行
- HIPAA準拠
- Google管理キー
- SEタイプはプロジェクトあたり最大5予約まで
- BigQuery MLのworkloadは実行不可
- SLAは99.9%のみのため、本番workloadには推奨できない場合あり
Enterprise Edition (EE)
- Standard Editionの全機能
- スロット数および同時実行クエリ数の上限なし
- 保証された最小/ベースラインおよび予約済み容量
- クエリアクセラレーション
- クロスユーザー結果キャッシュ
- BigQuery MLのworkload実行が可能
- オブジェクトテーブルのサポート
- データ持ち出し防止のためのVPCセキュリティコントロール
- データマスキング、列および行レベルセキュリティのサポート
- ゾーン単位のコンピュート冗長性および災害復旧(1ゾーン障害時、同一リージョン内の別ゾーンでジョブを実行可能)
- クラウドプロバイダーをまたいだジョブ実行(BigQuery Omni)に対応
- 管理プロジェクトあたり最大200予約
- SLAは99.99%
Enterprise Plus Edition (EPE)
- Enterprise Editionの全機能
- 顧客管理の暗号鍵
- Assured Workloadsを通じたFedRAMP、ITARなどのコンプライアンス要件のサポート
- リージョン単位のコンピュート冗長性および災害復旧(1リージョン障害時、同一マルチリージョン内の別リージョンでジョブを実行可能)
どのEditionを選ぶべきか?
クラウドの世界ではよくあることですが、答えは「ケースバイケース」です。これでは身も蓋もないので、適切なEditionを選ぶための基本的な質問をいくつか挙げてみましょう。
まず、workloadのコンピュートを単一ゾーン以上で実行する必要があるかどうかです。Yesであれば、Standard Editionは単一ゾーンに限定されるため即座に候補から外れます。これはあくまでworkloadのコンピュート部分の話で、ストレージは別である点に改めてご注意ください。
次に、workloadで1,600を超えるスロットが必要かどうかです。Yesなら、こちらでもStandard Editionは候補から外れます。Googleは1,600スロットがハード上限であり、現行のオンデマンド2,000クエリスロットのようなバースト的な余地は認められないと述べています。
続いて、いずれかのworkloadでBigQuery MLを使用する予定があるかどうかです。使用するなら、対応しているのはEnterprise Editionです。
その他に、100の同時実行クエリ上限に頻繁に到達している場合は、その制限が撤廃されているEnterprise Editionの検討をおすすめします。
近年増えているシナリオとして、独自の暗号鍵を管理する必要がある場合は、Enterprise Plus Editionが必須となります。
最も重要なのは、各プロジェクトをオンデマンドにすることも、異なるEditionを適用することもできるという点です。これにより、プロジェクト単位、または予約単位での利用とコストの最適化が可能になります。
DoiTのお客様は、お気軽にCustomer Reliability Teamのメンバー宛にチケットを作成いただき、通話や利用状況の分析をご相談ください。
BigQuery Editionsのオートスケーリング
Editionsの大きなセールスポイントの一つがスロットのオートスケーリングです。スロットが必要なときに、ベースライン値から最大スロット値まで自動でスケールアップします。
これは、現在flat-rate課金を使っていて、予約しているスロット数を超える要求が発生する場面で非常に強力です。Flex Slotsもスロットを追加する手段でしたが、自動ではなく追加のツールが必要でした。一般的には、Cloud Functionを定期実行して使用中スロットのメトリックを確認し、必要に応じてFlex Slotsを予約に追加・削除する運用です。残念ながら即座に追加スロットが必要なケースには、自前のインフラを構築・運用しない限り対応できませんでした。
そこで登場するのがEditionsです。GCPがジョブ単位で必要に応じて自動的にスケールアップ・ダウンを行ってくれます。
とはいえ、スケーリングの判定には10秒のウィンドウがあります。私たちのテストでは現実的には約7秒です。これは、最低課金時間にも満たないクエリで最大までスケールアップしてしまうのを避けるための仕組みです。したがって、10秒で完了するクエリでは最大スロットには達しないでしょうし、複雑さによってはベースラインにすら届かない可能性があります。
スロットがスケールアップしてジョブが完了した後、次のジョブで使えるようになるまでスケールダウンに1分以上かかる場合があります。
ベースラインと最大スロットはいずれも、予約内のプロジェクトで実行される全ジョブが共有するスロットプールを表しており、これはflat-rate予約と同様です。スロットがジョブで使われなくなるとスケールダウンされ、課金もされなくなります。これは手動で削除するまで課金され続けるFlex Slotsとの大きな違いです。
オートスケーリングについて最後にひとつ。後述するcommitment内のスロットを除き、スロットの利用可否は保証されず、対象リージョンまたはマルチリージョンの空き状況に左右されます。
予約(Reservation)の構造
BigQuery Editionsの予約は、これまでのflat-rate課金の予約と大きく異なるわけではありませんが、完全に理解するうえで押さえておきたい新しい概念がいくつか加わっています。
引き続き管理プロジェクト内に作成され、各予約には、スロットを割り当てる対象として0個以上のプロジェクトが含まれます。前述のEdition比較で見た通り、Editionの種類によっては予約に含められるプロジェクト数に上限があります。
Editionsではオートスケーリングの概念が導入されたため、最小スケーリング値である「ベースラインスロット」と、最大スケーリング値である「最大予約サイズ」が存在します。Standard Editionにはスロット上限が課されているためか、ベースラインスロットの概念がなく、この値は常にゼロです。
最大値は、ベースラインスロット値と、予約全体のオートスケールスロット数の合計として定義されます。
デフォルトでは、ジョブまたはジョブ群が予約のオートスケーリング上限を超えた場合、同じ管理プロジェクト内で同じEditionを使用する他の予約からスロットを借りることができ、これは標準の予約と同様の挙動です。「予約の作成」画面には、この機能を無効化できるチェックボックスが用意されています。
Ignore Idle Slotsの説明
Editionsには、作成できる管理プロジェクトの最大数に上限があり、組織あたり5つまでです。6つ目を作成しようとすると、次のエラーメッセージが表示されます。
組織内で5つを超える管理プロジェクトを作成しようとした際のエラーメッセージ。
Editionsのcommitments
従来通り、BigQuery Editionsでも一定期間のcommitmentと引き換えに低料金を得るという考え方が引き継がれています。これらのcommitmentsは固定数の専用スロットに対して作成され、24時間365日課金されますが、レートはより低く抑えられます。課金面では、ベースラインスロット値が設定されているのと同様で、契約期間が終わるまで毎月支払いが発生し、その分だけ安いレートが適用されると考えてください。
Editionsでcommitしたスロットの利点は、24時間365日活用できる予約専用スロットを安価に確保できる点にあります。常時使わないスロットをcommitmentに含めるべきではありません。使われていないリソースに課金されることになるためです。commitされたスロットは利用可否が保証されます。
flat-rateでは月次か年次のcommitmentを選べましたが、Editionsのcommitmentsは年次と3年版のみです。
従来のflat-rateのcommitmentsが100スロット単位だったのと同様、新しいcommitmentsも100スロット/時間単位です。
注意点として、これらはEnterpriseおよびEnterprise Plus Editionにのみ適用可能です。料金は次のセクションで説明します。
料金の更新
料金は、これまでBigQueryで提供されてきた従来の料金モデルとはほぼ完全に異なります。新しい料金モデルは「スロット時間」(より分かりやすく「スロット/時間」と呼びます)という概念に基づき、1スロットを1時間使ったぶんを秒単位で課金します。
Editionsはスロットの使用時間に応じて課金されます。秒単位の課金ですが、数値の見やすさから時間単位を基準にしています。たとえば、1スロットを900秒(1時間の1/4)使うと0.25スロット/時間、3,600秒(1時間)使うと1.0スロット/時間が課金されます。実際のジョブでは複数のスロットを使うはずなので、これに使用スロット数を掛ければ、請求対象のスロット/時間が求められます。
料金算出に必要なもう一つの要素が、Editionごとに異なる「スロット/時間あたりの単価」です。すべての料金は米国マルチリージョンのUSD建てで、他リージョンでは異なる場合があります。
提供開始時点の各Editionの料金は次の通りです。
- Basic Edition:1スロット/時間あたり0.04 USD
- Enterprise Edition:1スロット/時間あたり0.06 USD
- Enterprise Plus Edition:1スロット/時間あたり0.10 USD
ジョブのコストを算出する全体式は次の通りです。
料金 = <スロット/時間あたりの単価> * <使用スロット数> * (<秒単位の時間>/3600)
使用スロット数に使用時間(使用秒数 / 3600秒)を掛け、最後にEditionの単価を掛けるだけです。見た目ほど難しくありません。
最後にもう一点。ここでも60秒の最低課金時間があります。flex slotsと同様、60秒未満の利用も可能ですが、課金は60秒分発生します。
Commitmentの料金は次の通りです。最小サイズは100スロット、月730時間で計算しています。
Enterprise Edition
- 1年:
1スロット/時間あたり0.048 USD
100スロット/時間あたり4.80 USD(時間単位)
100スロット/時間あたり3,504 USD(月額)
100スロット/時間あたり42,048 USD(年額)
- 3年:
1スロット/時間あたり0.036 USD
100スロット/時間あたり3.60 USD(時間単位)
100スロット/時間あたり2,628 USD(月額)
100スロット/時間あたり31,536 USD(年額)
Enterprise Plus Edition
- 1年:
1スロット/時間あたり0.08 USD
100スロット/時間あたり8 USD(時間単位)
100スロット/時間あたり5,840 USD(月額)
100スロット/時間あたり70,080 USD(年額)
- 3年:
1スロット/時間あたり0.06 USD
100スロット/時間あたり6 USD(時間単位)
100スロット/時間あたり4,380 USD(月額)
100スロット/時間あたり52,560 USD(年額)
課金SKU
Editionsでのスロット利用は、オンデマンド課金モデルのようにジョブを起動したプロジェクトではなく、管理プロジェクト自体に課金されます。これはflat-rate課金と同じ仕組みであるため、flat-rateからの移行に伴い新SKUを反映するレポートの修正は最小限で済みます。これらのSKUは、課金データのBigQuery Reservations APIグループ配下に分類されます。
SKU名はEdition名とリージョン名を組み合わせて、次のような形式になります。
- BigQuery Enterprise Edition for US (multi-region)
- BigQuery Basic Edition for US (multi-region)
Commitmentsの場合のSKU名も、Edition名とリージョン名を組み合わせて、次のような形式です。
- BigQuery Enterprise Edition 1 Year for US (multi-region)
現時点では、コストを発生させたジョブを実行したプロジェクトや予約と費用を紐づける手段はありません。これは2023年7月5日が近づくか、その後に変わる可能性があります。
BigQuery Editionsへの自動切り替え
2023年7月5日には、契約済みでない、かつ年次commitでないflat-rateプロジェクトはすべて、Enterprise Editionの課金体系に変換され、その下で課金が始まります。Googleからは、痛みを伴わないプロセスであり、いかなるworkloadにも影響を与えないと確約されています。
オンデマンドからEditions(またはflat-rate)への切り替えにはもう少し手順が必要です。切り替え前に、Googleのこちらのドキュメントを必ず読んだうえで、予約作成の手順に従い、メニューでflat-rateの代わりに目的のEditionを選択することを強くおすすめします。
Flat-RateとEditionsのオートスケーリングの併用
このセクションは新しく追加したものです。4月下旬から利用可能になっていましたが、公式ドキュメントには明記されておらず、一部のお客様には気付かれにくい状況でした。私たち自身の検証を経てBigQuery製品チームと通話した際に説明を受け、「予約の作成」ページの「!」マークの注釈(下のスクリーンショット参照)でしか言及されていないことが分かりました。
flat-rate予約をベースに、その上にオートスケーリングのEnterprise Editionsスロットを上乗せして利用できます。
えっ、本当に!?——はい、可能です。4月にGoogleがすべてのflat-rate予約とcommitmentsをEnterprise Editionバックエンド上で動作するように移行したため、これらは実質的にflat-rate料金で動作するEnterprise Editionの予約・commitmentsとなっているからです。つまり、7月5日もしくは年次flat-rate commitmentが満了するまでの間、flat-rateを支払いつつ、flex slotsの代替としてオートスケーリングを使えるわけです。
これは予約内で、flat-rateのcommitmentスロットをEditionsのベースラインスロット相当として扱い(flat-rate料金で課金)、最大予約サイズまでスケールアップ(EE料金で課金)する形で機能します。バックエンドはすべてEditions上で動作しているため、純粋なEnterprise Edition予約とまったく同じ挙動になります。
具体例で詳しく見ていきましょう。
flat-rate予約内で1,000スロットを使っているプロジェクトがあり、月次のETLジョブが実行されているとします。このジョブは実行中に1,500スロットまでスケールアップすることが確認されています。
このとき必要なのは、予約を編集する、または古い予約を削除して新しい予約を作成し、ベースラインを1,000スロット、最大予約サイズを1,500スロットに設定することです(下記参照)。これらの値が表示されない場合は、ドロップダウンで「カスタム」予約サイズを選択してください。
これを保存すると、ベースラインの1,000スロット(flat-rate料金で課金)と、利用時にEnterprise Editionレートで課金されるオートスケール可能な追加500スロットを備えた予約が作成されます。
これは、7月5日以降の年次flat-rate commitmentsで「ライフジャケット」を確保しつつ、必要なときにスケールしたいお客様にとって、ちょうどよい折衷案となります。スケール用スロットはFlex Slotsより割高ですが、予約を手動で作成・削除する手間がなくなりました。
この挙動は、新規の月次commitments作成機能が廃止される7月5日まで、すべての月次flat-rate commitmentsで利用できる点に注意してください。
まとめ
DoiT Internationalの私たちは、これがBigQueryの料金における大きなパラダイムシフトであると認識しています。だからこそ、ここまでの知見と、最後にいくつかの注意点をお伝えしておきたいと思います。
2023年7月5日のこの変更に向けて、万全の準備を整えてください。特にflat-rate課金を利用している場合、flat-rateからEnterprise Editionへの切り替えで費用が大幅に増える可能性があります。オンデマンドを使っている場合は一律25%の値上げなので、事前にスキャンコストを削減しておくことで影響を緩和できます。
組織内のBigQueryで課金が発生しているすべてのプロジェクトを洗い出し、それぞれがflat-rateとオンデマンドのどちらの課金モデルかを把握することをおすすめします。これにより、想定外のコスト急増を防げます。これはBilling Explorer、またはDoiTのお客様であればDoiT Consoleで行うのが最適です。
もう一つの重要なステップとして、ご自身のスロット利用状況に基づいたコスト試算を行ったうえで、ストレージコストも確認し、圧縮の活用が有効かどうかを検討することを強くおすすめします。これだけの料金変更は、計画なしでは大幅なコスト上昇を招きかねないため、しっかりと備える必要があります。本記事執筆時点から7月5日まで時間はあまり残されていませんが、その間にわずかでも準備しておくことは、特に長期的な設計を見据えるうえで大きな見返りをもたらします。
スロット分析が済んだら、Editionsでworkloadを本番稼働させる前の最終ステップとして、「サイドプロジェクト」を立ち上げ、そこでworkloadのサンプルを実行し、挙動と発生コストを確認することをおすすめします。これによりオートスケーラーの動きを把握でき、試算とは異なる予期せぬコストへの備えにも役立ちます。
最後に、お決まりの自社紹介を一言。私の所属するDoiT Internationalでは、こうした変更を踏まえた分析や長期計画でお客様を支援することが、主要業務の一つです。まだお客様でない方は、ぜひ一度ご検討ください。手前みそですが私たちは本当に頼れるチームで(自分でも偏見が入っているのは承知のうえですが、本気でそう思っています)、こうした課題でお客様や貴社のお力になれます。