BigQuery Editions移行で分析コストを70%削減した話

はじめに

こんにちは。データ基盤部ゲームエンタメグループ所属の武永です。データ基盤部ゲームエンタメグループでは全社のゲーム関連プロジェクトを横断し、データ分析や機械学習に用いるデータ基盤を提供しています。

突然ですが、みなさんは毎月のBigQuery分析費用に頭を悩ませていないでしょうか。ゲームエンタメグループでは日々のデータ集計で発生する高額なBigQuery分析費用に対し課題を感じていました。

その矢先、2023年3月にBigQueryの新しい課金形態であるBigQuery Editionsが開始され、Editionsに乗り換えることで分析費用を47%~70%削減することができました。本記事では、ゲームエンタメグループで運用しているBigQueryの料金プランをOndemandからEditionsに移行し、費用を削減した方法についてご紹介します。

対象者

データエンジニア
アナリティクスエンジニア
BigQueryをOndemandプランで運用していて、分析費用削減したいと思っている方

BigQuery Editionsに移行した結果

BigQuery分析料金の削減

複数のプロジェクトでEditionsへ移行し、それぞれ47%~70%の分析コスト削減を実現することができました。

削減効果に47%~70%と幅があるのは、プロジェクトによってBigQueryで実行されるJOBが異なるためです。詳しくは後述しますが、BigQueryで実行されるJOB内容によってEditionsの導入効果は大きく異なります。プロジェクトAでは実行されるJOBの多くがEditions向きだったため、70%もコスト削減でき、プロジェクトBではEditions向けのJOBとOndemand向けのJOBが混在していたため、47%程度のコスト削減に留まりました。

移行後に苦戦したこと

OndemandからEditionsに移行することで以下のような問題が発生しました。

Slot圧迫によるJOBの遅延
一部JOBのコスト増加

いずれも工夫することで解消できており、詳細について後述します。

BigQuery Editionsの料金と機能制限

料金体系

Ondemandではデータのスキャン量に対し課金され、us-centralの場合1TiBに対し$6.25の課金が発生していました。

一方でEditionsではスロットと呼ばれるBigQueryの仮想CPUリソースが課金対象となります。似たような課金形態にFlat Rateがありましたが、Flat Rateプランの新規販売が終了し、今回Editionsとしてリリースされています。

課金についてですが、後述する各プラン毎の単価に、割り当てられたスロット量と使用時間(hour)を掛け合わせた”スロット時間”を掛け合わせた金額が課金されます。

たとえば100スロットを6分利用した場合、スロット時間は下記のように求めることができ、

100 * 0.1 = 10 slot/hour

仮にStandardプラン(単価$0.04)で登録していた場合、Editionsによる課金金額は以下になります。

0.04 * 10 = $0.4

即ち、利用状況に合わせて動的にスロットを使用することでコストを抑えることができる課金形態になっています。

また詳細は後述しますが、スロット使用時間を上手く節約できるようにスロットの自動スケーリング機能を備えており、事前にまとめてスロットを購入する必要があったFlat Rateプランに比べてコストを減らすことができます。

プランごとの単価および機能制限

Editionsにはいくつかのプランがあると前述しましたが、Standard, Enterprise, Enterprise Plusの3プランが準備されており、プランによって単価が異なるのはもちろん、使える機能も異なります。

今回は一部機能についてプラン毎に比較しています。他の機能については公式ドキュメントをご一読ください。

プラン名	Standard	Enterprise	Enterprise Plus
料金(US)	0.04 * スロット時間	0.06 * スロット時間	0.10 * スロット時間
スロット上限	1600	上限なし	上限なし
Reservation数上限	10	200	200
長期間コミットメントプラン	利用不可	1年/3年	1年/3年
列レベルのセキュリティ管理	不可	可	可
行レベルのセキュリティ管理	不可	可	可
Analytics Hub	可	可	可
BI Engine	不可	可	可
マテリアライズドビュー	既存ビューへのクエリ実行のみ可	ビューの作成、更新、クエリ共に可	ビューの作成、更新、クエリ共に可
BigQuery ML	不可	可	可
BigQuery Omni	不可	可	不可

スロットの自動スケーリング機能とは

前述したように、Editionsは利用状況に合わせて動的にスロットを使用することでコストを抑えることができる課金形態になっています。また、Editionsでは動的なスロットのスケーリング機能を提供しています。

自動スケーリング機能について

以前までのFlat Rateプランでは事前に一定期間分のスロットをまとめて購入し確保する必要がありました。そのため、月の利用状況にばらつきがあるにもかかわらず1ヶ月分のスロット確保量に対し課金される等、融通が効かない問題がありました。たとえば月のMaxに合わせてスロットを購入するとスロットを持て余し、月の平均に合わせてスロットを購入するとスロットを多く利用するJOBで遅延が発生してしまうという問題がありました。一応flexプランで60秒単位でスロットを購入するという方法もあったみたいですが、使い終わったら都度プランをキャンセルするのも手間でした。

スロットの自動スケーリング機能はこの手間を解消しており、文字通り、スロットを事前に確保するのではなく、必要に応じて50スロット単位で動的にスロットを割り当てます。そのため、利用状況にばらつきがある場合もJOBに必要なスロット量のみを使用するため、スロットを持て余すこともないですし、スロットが足りずにJOBが遅延することもありません。

上の図はEditionsを適用したプロジェクトのスロット割り当て状況のメトリクスになります。

Flat Rateプランでは事前にまとめて購入したスロット量が常に確保され割り当てられるのに対し、Editionsでは必要に応じてスロットがスケールされるため、割り当てられたスロットが1.6kだったり0.4kだったりと一定ではないことがメトリクスから確認できると思います。

Baseline SlotsとMax Slotsについて

スロット割り当て状況メトリクスを見ると、0〜1600の間に収まっているように見えます。これはBaseline Slotsを0、Max Slotsを1600に設定しているためです。

Baseline Slotsとは最低スロット確保量のことで、0に設定することで、スロットをまったく使用しない時間帯の確保量は0となり、余分なコストを節約できます。 Baseline SlotsはStandardプランだと0固定で、Enterpriseから任意の値を設定できます。

Max Slotsとは上限スロット確保量のことで、設定することで確保するスロットに上限を設けることができ、Slotの過剰確保によるコスト増加を防ぐことができます。一方で制限されたスロット確保量で処理を行うため、処理時間が長くなってしまう可能性があります。

Max Slotsと処理時間の関係を簡単なイメージ図にしてみました。Max Slotsを1600に設定することで、スロットの確保量を4800から1600に減らすことができていますが、その代わりに処理時間が伸びているのが見て取れると思います。

Editionsへの移行フロー

今回は以下のフローでEditionsへの切り替えを行いました。

Editionsに移行するプロジェクトの選定
Reservationの作成
Editionsに切り替え
Editions切り替え後のコスト監視および問題解消

Editionsに移行するプロジェクトの選定

Editionsはプロジェクト単位で切り替えが必要なため、プロジェクトをEditionsに移行することでコスト削減が見込めるか、移行する場合はどのプランとMaxSlotが好ましいかを選定する必要があります。

Ondemandはスキャン量に対して課金されるのに対し、Editionsでは割り当てられたスロット量に対して課金されるため、初めにそれぞれのコストを比較することによって、移行すべきかどうかを判断します。

Ondemand(スキャン量)に対する課金は JOBSビューのデータから試算でき、以下のクエリで概算を行いました。

## スキャン量/月
WITH scan AS (
  SELECT
    TIMESTAMP_TRUNC(creation_time, month) as month,
    SUM(total_bytes_billed) / (1024 * 1024 * 1024 * 1024) as scan_tib
  FROM
    `{PROJECT_ID}.region-{REGION_NAME}.INFORMATION_SCHEMA.JOBS`
  WHERE
    creation_time > '{YYYY-MM-DD}'
    AND creation_time < '{YYYY-MM-DD}'
  GROUP BY
    month
)

## スキャン金額/月
SELECT
  month,
  ROUND(scan_tib * 6.25, 2) as scan_cost
FROM
  scan
ORDER BY
  month

一方でEditions(スロット使用量)に対する課金は JOBS_TIMELINEビューのデータから概算します。 JOBSビューにもtotal_slot_msというJOB毎のスロット割り当て量データがあるのですが、Editionsは1秒毎に割り当てられたスロット量に対して課金され、且つ、複数JOBが並行に実行される可能性もあるため、1秒毎のJOBデータであるJOBS_TIMELINEビューのperiod_slot_msから算出します。また、最小課金時間が1分なため、どんなに小さなJOBを実行したとしても、50スロット1分間分に対して課金が発生します。

以上を踏まえて、以下クエリで概算を行いました。

WITH
  jobs_timeline_1 AS (
    SELECT
      period_start,
      SUM(period_slot_ms) / 1000 AS period_slot_s
    FROM
      `{PROJECT_ID}.region-{REGION_NAME}.INFORMATION_SCHEMA.JOBS_TIMELINE_BY_PROJECT`
    WHERE
      period_start > '{YYYY-MM-DD}'
      AND period_start < '{YYYY-MM-DD}'
    GROUP BY
      period_start
  ),

  ## 最小単位50スロットで切り上げ
  jobs_timeline_2 AS (
    SELECT
      period_start,
      CEIL(period_slot_s / 50) * 50 AS period_slot_s
    FROM
      jobs_timeline_1
  )

  SELECT
    TIMESTAMP_TRUNC(period_start, month) AS month,
    ROUND(SUM(period_slot_s) / 3600, 2) AS period_slot_hour,
    ROUND(SUM(period_slot_s) / 3600 * 0.04, 2) AS cost_standard_editions,
    ROUND(SUM(period_slot_s) / 3600 * 0.06, 2) AS cost_enterprise_editions,
    ROUND(SUM(period_slot_s) / 3600 * 0.1, 2) AS cost_enterprise_plus_editions,
  FROM
    jobs_timeline_2
  GROUP BY
    month
  ORDER BY
    month

あくまで概算のため実際の課金額とは異なりますが、それぞれのクエリ結果を見比べることで、Editionsに移行することによるコスト削減効果を大まかに確認できます。その上で各プロジェクトで使われている機能がEditionsプランでサポートされているかを確認しながら、Editionsに移行するプロジェクトの選定を行いました。

Reservationの作成

BigQueryの容量管理画面からReservationの作成を行うことができます。 Reservationの作成自体も難しくなく、プラン、Max Slots, Baseline Slotsを指定するのみで簡単に作成できます。

一点気をつける点として、Reservationを作成できるプロジェクトは組織毎に10個と決まっており、各プロジェクトで使用するResevationを各プロジェクト上で作成する運用だと上限に抵触する可能性があります。

そのため公式ドキュメントではReservationの管理を行う管理プロジェクトを新規作成し、管理プロジェクトから中央集権的に各プロジェクトにResevationを割り当てるという方法が紹介されています。

Editionsへの切り替え

Reservationを作成すると一覧に表示され、各プロジェクトに割り当てが可能になります。組織内のプロジェクトであれば自由に割り当てができ、割り当てるとすぐにOndemandからEditionsに切り替わります。

また、EditionsからOndemandに切り戻す際は割り当てを削除することですぐに切り戻すことができます。

Editions移行後のコスト監視

Editions移行後の正確なコストはBillingのreport機能から確認しています。グループ条件をSKUに設定し、サービスをBigQuery Reservation APIに絞ることでEditions移行後のコスト実績値を確認できます。

また、Editions移行直後はJOB単位でコストを確認するために、JOBS_TIMELINEビューからjob_id毎のコストを算出し、Lookerダッシュボードで可視化をしています。 JOB単位で監視を行うことで高コストなJOBを洗い出し、棚卸し、クエリの改修を都度実施しています。

Editions移行後に発生した問題

slot使用量の逼迫

Max Slotsの説明でも記載した通り、実行されるJOBに対しMax Slotsが不足していると、その分処理時間が横に伸びてしまいます。そのため、Metrics ExplorerのSlots used by project指標等でプロジェクトで使われているスロット量を事前に確認した上でMax Slotsを設定する必要があります。万が一、遅延等が生じた場合はResevation画面からOndemandへの切り戻しも可能です。

Editionsに不向きなJOB

当然ながらEditionsに移行することによってコストが高くなってしまうJOBが存在します。具体的にはスキャン量自体はそこまで多くないが、複雑な処理をしているためスロットが多く割り当てられるJOBはコストが高くなってしまいます。

この問題を回避するために、Ondemand向けのJOB実行用プロジェクトを用意し、JOBによってプロジェクトを使い分ける運用をしています。前述した通り、job_id単位でOndemand、Editionsそれぞれのコストを算出し、日々監視することで実行用プロジェクトの判断材料としています。

まとめ

Ondemandの値上がりもあり、Editionsに移行したところ大幅なコスト削減を実現できました! 移行直後はMax Slotsの設定が甘く、JOB遅延等の問題が発生しましたが、設定の見直しやプロジェクトの使い分けを実施した後は安定して稼働しており、移行から1年以上経っていますが大きな問題は発生していません。

今後の課題として、Editions環境下ではクエリ実行時に発生する課金が事前に分からない点は不便に感じています。クエリによるスキャン量はGUI上に表示されているため、Ondemand環境下ではクエリ実行時にかかる費用を事前に察知できました。一方でスロット割り当て量は事前に表示されないため、Editions環境下ではクエリ実行時にかかる費用の感覚は作成者の経験値に依存しています。この点が解消されるともっと使い勝手がよくなると感じています。

今回はBigQueryの料金プランをEditionsに移行し、費用を削減した方法についてご紹介しました。本稿が今後のみなさまのコスト削減活動の参考になりましたら幸いです。