本日は私がよくお客様より質問を受けるBigQueryの料金がどこに請求されるかについて解説したいと思います｡
今回のテーマであるBigQueryの料金がどこに請求されるかですがこれは非常に多くの質問をいただきます｡
BigQueryは従量課金のサービスであり、意図せず高額な請求が発生することもあるため弊社では利用を開始するにあたりきっちり説明を行います｡
ただこの質問はBigQueryをすでにご利用いただいている場合、特に複数のプロジェクトでの利活用、専用のプログラムを開発しているといった普及期に差し掛かっているお客様から質問されることが多いのです｡
最初は少ないユースケースのみからスタートしたが、ユーザーや用途が増えるにあたり明確に周知・理解がなされていない状況がカオスを産み、ある日覚えのないクエリ料金が別プロジェクトにて発生している、といったことから質問をいただくことが多いです｡
これはBigQueryを利用する上で
の考え方がごちゃごちゃになってしまうことから発生します｡
特に多いのがサービスアカウントを生成したプロジェクトが請求プロジェクトという誤解です｡なぜこのような誤解が発生するのかも含め解説していきます｡
以下の3つをまずは覚えていただければと思います｡
データが保存されているプロジェクトが請求されるプロジェクトとなります｡
こちらは直感的なためあまり間違えることが無いです｡
BigQueryのWeb UIからもプロジェクト→データセット→テーブルといった階層構造となりますし、SQL内でも<PROJECT>.<DATASET>.<TABLE>と記載するのでどこにあるかは一目瞭然です。
誤解が多いのが分析料金です｡
これはBigQueryのジョブを動かしたプロジェクトが請求プロジェクトとなりますがそもそもどこでジョブが動くのかを理解する必要があります｡
ジョブの実行方法毎に考え方、指定の方法が異なるため混乱を招くポイントとなっています。
というのも分析をする方法はどのような物があるでしょうか。
今回は上記4つについてそれぞれ解説してきましょう。
もっとも直感的に判別できます｡
Web UIはGoogle アカウントをもったユーザーのみが利用できます｡
BigQuery Web UIの画面左上のプロジェクトを確認しましょう。そこにあるプロジェクトが請求されるプロジェクトとなります｡
Web コンソールにて指定されているプロジェクトを必ず確認しましょう。
bqコマンドはCloud SDKを導入することで利用できるCLIコマンドとなります｡
コマンドを発行できるユーザーとしてサービスアカウントが加わってきますがまだ考慮は不要です｡
bqコマンドの場合以下の順に評価されます｡
1はジョブ単位で明確に指定をするので問題は起きづらいです。
2のgcloud config set project で指定したプロジェクトの場合意図しない動作をすることが多いです｡
bqコマンドを利用するケースとしてShell スクリプトにて一連の処理を記載することが多いです｡
1つのShellスクリプトの中で複数のプロジェクトを対象としたジョブが動くといったケースとして以下の処理を考えてみましょう
この場合gcloud config set project は初期化処理として最初に実行したあとはそのままになりがちです｡
Bプロジェクトへのクエリが追加要件として発生した場合BigQuery の課金についてあまり理解されていない方が修正・追加を行うといった背景から紛れ込むことがあります｡
こういった場合は明確にbqコマンドにproject_idオプションをつけるように意識をしましょう。
gcloudコマンドのコンフィグはOSユーザー毎に設定を保存します｡
そのため同一のOSユーザーで並行してgcloud config setを実行した場合後続処理にて別のプロジェクトにて実行されたり失敗する場合があります｡
なかなかレアケースですが以下のようなケースが考えられます｡
この場合10時10分のバッチが失敗したりバッチAの4にて実行されるクエリがBプロジェクトにて実行される場合があります｡
これは前述の通りbatch_user というOSユーザーがgcloud config set を実行したタイミングでローカルのコンフィグ設定としてジョブ実行プロジェクトをBプロジェクトに書き換えてしまうからです｡
バッチAからはこれを検知することはできないのでバッチBプロジェクトにてジョブを実行してしまいます｡
これはなかなか気づきにくいのですがbqコマンドを実行するジョブサーバーを単一ユーザーで運用している場合は特に注意が必要です。
明確にbqコマンドにproject_idオプションをつけるように意識をしましょう。
オプション付与が難しい場合はジョブを実行するユーザーやタイミングについて整理をしましょう。
Client Libraryの利用のケースではClientのインスタンス化処理および実行するユーザーの情報が重要になります｡
PythonのClient Libraryの場合以下の順に評価されます｡
1はClientインスタンス化時の指定になります｡
ですので1つのコード内にて複数のプロジェクトにてジョブを実行する場合はprojectパラメータへ値を指定できるようにする必要があります｡1つのインスタンスを使い回すような作りの場合は注意が必要です｡
これはGoogle Cloudのサンプルコードでも`client = bigquery.Client()`とだけ記載があることが多いのでそのまま実装してしまい気づかない or 気づいても改修が大変なのでなかなか直せないといった場合があります｡
2以下についてはインスタンス化時に指定していなかった場合にgoogle.auth.default()を呼び出し順次評価します｡(参考: GitHub ISSUE)
よく勘違いされることとして、BigQueryの分析料金はサービスアカウントを払い出したプロジェクトに請求(≒ジョブが実行)されるというものがあります｡
これはまさに上記3が原因となります｡
この背景には利用が拡大するにつれ運用ルールのみが伝わり、利用方針やなぜそうなのかといった原理原則が正しく伝えられないことがあります｡
クラウドサービスは日々変化していくものなので利用ガイドを配布して終わるのではなく、双方向のやり取りができる場として勉強会や対話会といった啓蒙活動を行っていくことが重要となります｡
ジョブ実行プロジェクトは非常に重要な要素となるため明示的に指定ができるようにプログラムのI/Fを見直すことを推奨します｡
マジックコマンドもおおよそ上記同様となります｡
1にてプロジェクトが指定されなかった場合はClient Library同様の処理となります｡
こちらはセル単位となるので修正はClient Libraryに比べ容易となることが多いです｡
マジックコマンドを利用する場合も明示的に--projectにて指定することを推奨します｡
明示的に指定していない場合ノートブックを共有した際に意図しない環境でジョブが稼働してしまう恐れがあることに注意しましょう。
非常に長くなりましたが以上がおおよそ抑えるべきポイントとなります｡
Client Library については言語毎に実装が異なる可能性があるので念のためソースコードを確認いただければと思います｡
ともあれなにごとも
これらを念頭に置くことで誤解やカオスな状況は避けられるでしょう。
ぜひこの記事を読んだことでご自身の環境の見直しのきっかけや話のネタになればと思います｡
Google Cloud、Google Workspaceに関する お問い合わせはこちら
XIMIX（サイミクス）は商標登録出願中です