はじめに
2024年3月4日からBigQueryユーザー全員を対象にDataplex APIをデフォルト有効化するというGoogle Cloudの発表は、分析機能の強化に向けた大きな可能性を切り開くものです。
しかし同時に、この変更はコスト面で深刻な影響を及ぼしかねません。Dataplex API自体の性質に加え、Data Lineage APIやData Catalog APIといった関連APIを踏まえると、なおさら注意が必要です。
本記事では、この変更の詳細、コストへの影響、そしてその影響を抑えるための具体策について解説します。これらの内容は、私とDoiTのGoogle Data Practice Lead仲間であるSayle Matthewsが2月29日のウェビナー、およびLinkedInの投稿で解説したものをベースにしています。
変更の概要
2月中旬にGoogle CloudチームからGoogle BigQueryユーザー全員に届いたメール（件名：「[要対応] BigQueryのアップデート内容を確認し、プロジェクトでの対応要否をご判断ください」）で、2024年3月4日より稼働中の全BigQueryプロジェクトでDataplex APIが自動的に有効化され、新規Google CloudプロジェクトでもデフォルトでオンになることがGoogleから明らかにされました。
これは、ユーザーに分析プラットフォームの追加機能をシームレスに提供することを目的とした、より広範なBigQuery Studioのローンチ（リンク）の一環です。
このメールの要点は以下のとおりで、3月4日の変更に伴って自動有効化される他のAPIについても触れられています。
上記のうち、最も大きな懸念となるのはDataplexサービス全般の有効化、およびData CatalogやData Lineage APIといったDataplex関連APIの影響です。
本記事の前提として補足しておくと、Sayle MatthewsのLinkedIn投稿にあるとおり、2月26日の週にGoogleからDataplexの大型アップデートがリリースされ、コストの発生する機能の自動有効化に関する懸念のいくつかが解消されました。そのため幸いにも、現時点でこの変更による影響を受ける可能性のあるユーザーは以前より少なくなっています。
DataplexがGCPコストに及ぼす影響
Dataplexの導入はGCPユーザーに高度なデータガバナンスと管理機能をもたらす一方で、3月4日からの自動有効化に伴う潜在的なコスト影響を把握しておくことが欠かせません。
Dataplexは、Google BigQuery、Cloud Dataflow、Cloud Pub/Subなど、さまざまなGoogle CloudのデータサービスやAPIに関連する機能や、目に見えないバックグラウンド処理を持ち込みます。GCPプロジェクト内でこの変更を適切に管理しなければ、コストが膨らむおそれがあります。
Dataplexの料金ページによれば、Dataplex本体は4つの主要なSKUで課金され、それぞれ請求方式が異なります。
- Dataplex処理（StandardおよびPremium）
- Dataplexシャッフルストレージ
- Data Catalog APIコール
- Data Catalogメタデータストレージ
これらのうちDataplexコストへの影響が最も大きいのが処理SKUで、執筆時点ではDCU時間単位で課金されています（Standard Dataplex処理が$0.060/DCU時間、Premium Dataplex処理が$0.089/DCU時間。料金はリージョンにより異なる場合があります）。
Dataplex料金ページから引用した下表は、Dataplex処理が実際にどのように課金されるかを示しています。
上記のとおり、Dataplexの処理SKUは制御せず動かすとGCPデータソースに対して相当多くの処理を実行します（しかも、これはData LineageやData Catalogの関連APIに触れる前の話です）。では、Dataplex処理SKUは実際にはどのような仕組みで動作するのでしょうか。
その答えは、DataplexのLakeとZoneの作成にあります。DataplexにおけるLakeは、事業部門のデータアセットを格納するデータメッシュドメインに相当します。下図のように、LakeはZone、Asset、Entityを内包でき、Google BigQueryやGCSなどに格納されたデータを、自社の業務やデータ構造に合わせて管理できます。
Dataplex Lakeを作成する際（リンク）には、Lakeの名前、リージョン、適用したいラベリングポリシーを指定するほか、LakeをDataproc Metastoreにリンクする必要があります。
これがDataplex処理の総コストを大きく押し上げる要因です。MetastoreはDataplexがデータ探索ワークベンチの処理を管理するために利用され、Metastoreの稼働コストを通じてDataprocの料金にも影響します。Metastoreは複数のティア（Metastore v1のDeveloperおよびEnterpriseティア、v2のEnterpriseおよびEnterprise Plusティア）が用意されており、Dataproc Metastoreの利用要件に応じてリソース構成と価格が異なります。詳細はこちらをご覧ください。
Dataplex Lakeを作成すると、Dataplex APIは前述のデータ探索プロセスに従ってデータの処理とスキャンを開始します。この段階で、Google Cloudの請求情報に処理SKUが現れ始め、コストが上昇する可能性があります。
ただし押さえておきたいのは、Dataproc Metastoreを伴うDataplex本体だけでも一定のコストが発生する処理を実行する一方、Data Lineage、Data Profiling、Data Catalog、Data QualityといったDataplex傘下の他サービスは、有効化しなければコストが発生しない、という点です。本記事では特に、お客様において最もコスト影響が大きくなりがちなLineage APIとCatalog APIを取り上げます。
Data Lineage APIは、その名のとおりDataplex経由で定義されたデータ処理をスキャンし、アセットの作成につながった操作を追跡します。具体例としては、アセットの変更を引き起こしたBigQueryジョブ、Dataflowパイプライン、Pub/SubやDataprocの操作などが挙げられます。文面だけ見ると無害に思えるかもしれませんが、これらの操作は1件ごとに膨大なAPIコールを生み出すことがあり、後述するData Lineage APIの料金体系に直結します。
Data Catalog APIもData Lineage APIと同じく、別途有効化が必要なAPIです。Data Lineageと連携してオペレーションに関するメタデータを保存し、さらにDataplex傘下の大半のサービスとも連携して、Dataplexおよび特にData Lineage APIに関連する操作からAPIコールを生成します。
下のスクリーンショットはGoogleのDataplex料金ページから引用したもので、Data LineageおよびData Catalogのコスト内訳を詳しく示しています。
前述のとおり、両APIともAPIコール数に基づいて課金されます。Google Cloud上で利用するデータサービスのスケールによっては、コール数が容易に数百万単位に達することもあり、両APIを有効化すると無視できない費用となります。
加えてData CatalogもメタデータをDataproc Metastoreに保存するため、Dataplexの場合と同様に、利用しているDataproc Metastoreのバージョンや、保存するメタデータ量に応じてコストが増えていきます。
Dataplex全体のコスト影響を見積もる
このDataplexの変更について、お客様から最も多く寄せられる質問の一つが「これらすべてのDataplex要素にどれくらいコストがかかるのか、どう見積もればよいのか？」というものです。残念ながら、簡潔に答えるなら「容易に見積もる方法はない」というのが結論です。
この点についてGoogleと直接やり取りした結果、当社のEngineersは、特定の処理と特定のDataplex APIコールを紐づける方法は存在せず、この部分のコストを正確に見積もることは事実上不可能であることを確認しました。
処理コストについても見積もりは難しいものの、Dataplex Lakeに関連付けられたデータ量に対して線形に比例することはドキュメントに明記されています。
これは皆さんが期待されるようなすっきりした答えではないかもしれませんが、Dataplex APIとサービスを適切に管理すれば、これらのコスト要因はすべて確実に抑えることができます。
追加コストへの対策：取りうる選択肢
追加コストへの対策：取りうる選択肢
Dataplexおよび関連APIをすべて無効化する
現状Dataplexの高度な機能を活用していない、あるいは固有のデータガバナンス機能を導入する直近の予定がないユーザーにとっては、Dataplexと関連APIをまとめて無効化するのも一つの選択肢です。
もっとも手軽なのはGoogle Cloud Consoleの利用です。シンプルなインターフェースの「APIs and Services」コンソールページから、任意のAPIを有効化／無効化できます。
Google Cloud Consoleの該当ページに移動すると、上図のように有効化されているAPIとサービスの一覧が表示されます。そこから無効化したいAPI（例：Cloud Dataplex、Data Catalog、Data Lineage API）を検索し、下のスクリーンショットのとおり「Disable API」をクリックすれば、当該APIとそれに伴うコストや処理を停止できます。
また、関連ウェビナーでは多くのお客様から「この作業をコマンドライン形式のスクリプトで自動化できないか？」という質問もいただきました。答えはイエスです。以下のスクリプトをGoogle Cloudプロジェクト内の特定のAPIに対して実行すれば、当該APIをプログラム的に無効化できます。
gcloud services disable API_SERVICE_NAME — project PROJECT_ID
ただし、APIが過去30日以内に使用されている場合、上記スクリプトはそのままでは動作しません。その場合は、APIサービス名の後ろに--forceオプションを付与すれば、Dataplex APIを問題なく無効化できます。
GCP Organization内の複数プロジェクトにまたがってこの作業を行う必要がある場合は、Organization全体に対して同様のスクリプトを実行することも可能です。例を以下に示します。
API_TO_DISABLE=API_SERVICE_NAME
for PROJECT_ID in $(gcloud projects list –filter=’parent.id=ORG_ID’ — format=’value(projectId)’)
do
echo "Processing $PROJECT_ID"
# Disable the API for the project
echo "Disabling $API_TO_DISABLE in $PROJECT_ID"
gcloud services disable $API_TO_DISABLE — project $PROJECT_ID
done
さらに便利なことに、Googleは2月16日付の最初のメールで、2024年3月4日から有効化される予定のAPIがプロジェクトで自動的に有効にならないようにするフォームのリンクを提供していました。社内で適切な権限を持つ方が既にこのリンクから手続きを済ませている場合は、関連APIはいずれもすでに無効化されているはずです。
なお本記事の趣旨として強調しておきたいのは、Google CloudでAPIやサービスを無効化するのは、それらが社内のいずれの業務プロセスでも使用されていないと確信できる場合に限るべき、という点です。上記のスクリプトはあくまでDataplex関連の特定APIに限って実行し、Dataplexのデータリネージやデータカタログの仕組みを自社で使用していないと確信できる場合のみ実施することを強くお勧めします。
Dataplexの機能を絞って有効化する
Dataplexを活用しつつ、データガバナンスの強化とコスト効率のバランスを保ちたいユーザーには、必要なDataplex機能だけを選択的に有効化する方法が賢明です。
プロジェクトに必要なDataplexの機能やAPIを丁寧に洗い出すことで、要件に合致する機能だけを有効化できます。Google Cloudユーザーの皆さまには、Dataplexで何を実現したいのかを慎重に検討し、利用すると決めた場合も、有効化する機能やAPIには十分注意していただくことを強くお勧めします。
また、Dataplexサービスを利用したいGoogle Cloudユーザーには、Dataplexの全機能を集約して稼働させる「管理用」GCPプロジェクトを1つ作成することを推奨します。これによって、今回の変更後の運用におけるコストと複雑さを最小限に抑えられます。Google Cloud Organization内の複数プロジェクトでDataplexを有効化したことで発生しうるAPIコール、処理、メタデータストレージの料金影響を限定できるためです。
継続的なモニタリングと最適化
Dataplex関連コストの継続的なモニタリングは欠かせません。Google Cloudには支出を追跡するための詳細な請求／コスト管理ツールが備わっています。Google Cloud Billing、Cloud Monitoring、Cloud Loggingなどがその代表例で、SKU別の支出、見やすいダッシュボードによる利用状況、Dataplexサービスや前述の各APIに関する個別ログをそれぞれ追跡できます。
これらのレポートやサービスの出力を定期的に確認することで、Google Cloudユーザーは想定外のコスト急増をすばやく察知し、利用状況を最適化するためのアクションを迅速に打てます。
さらにCloud Monitoringのポリシーでアラートを設定すれば、下のスクリーンショットのように、Dataplexサービスや関連リソースなど、追跡したい利用メトリクスのしきい値超過を能動的に検知できます。
まとめ
Google BigQueryプロジェクトにおけるDataplex APIのデフォルト有効化は、Google Cloudのお客様にとって機会と課題の両面をもたらします。
その影響を正しく理解し、能動的なコスト管理策を講じることで、BigQueryと進化を続けるDataplexの機能を活用しつつ、コスト効率の高い運用を維持できます。
本記事でご紹介した推奨事項と、DoiTの業界エキスパートによる知見を活用すれば、Google BigQueryユーザーは今回の変更にスムーズに対応し、変更後のGoogle Cloudの利用と支出を最適化していけるはずです。
最後に、私たちDoiT Internationalについて少し触れさせてください。今回のように影響範囲の広い変更が生じた際に、お客様の分析や中長期の計画づくりを支援することは、当社が事業の柱としている取り組みの一つです。
まだDoiTのお客様でない方は、ぜひ本記事をきっかけに当社のページ（こちら）をご覧ください。DoiTには高いスキルと豊富な経験を備えたチームがあり、お客様のGoogle Cloud（およびAWS、Azure）リソースを最大限に活かしていただけるよう日々サポートしています。また、こうした変更が起きるたびに、お客様を的確にガイドできるよう、本記事のようなブログやウェビナーを継続的に発信しています。
本記事をお読みいただきありがとうございました。本記事や当社の幅広いコンテンツ、そして経験豊富なチームが、近く訪れるBigQueryおよびDataplex機能の変更を乗り越える一助となれば幸いです。
追加のFAQ
3月4日以降のBigQueryへの変更による広範な影響を解説したDoiTのSayle MatthewsによるLinkedIn記事（こちら）に加え、Sayleと私は2024年2月29日（木）に同テーマでウェビナーを開催し（リンク）、多くの追加質問をいただきました。読者の皆さまの参考のため、その一部への回答を以下に掲載します（すべての質疑応答はウェビナーのリンクからご視聴いただけます）。
Q1：100以上のGCPプロジェクトにわたって、有効化されたAPIを「スキャン」する最も負担の少ない方法は何でしょうか？
回答：本文中に掲載したスクリプトをご参照ください。ただし、APIを一斉に無効化するのはリスクを伴うため、組織のニーズを踏まえ、不要だと確信できるAPIを選択的に無効化することを強くお勧めします。
Q2：3月4日の何時にこれらのAPIを無効化しなければならないか分かりますか？
回答：Googleはこの変更が適用される時刻を明示していませんが、Google Cloudユーザーには、不要なAPIの無効化を3月4日当日またはそれ以降できるだけ早く実施し、Google Cloud請求への想定外の影響を抑えることを強くお勧めします。多くのお客様にとっては影響のない変更ですが、変更後に請求面で不快な驚きを経験していただきたくないというのが当社の願いです。
Q3：Googleが今回自動的に有効化するサービスをまったく使っていない場合、4日以降にAPIを無効化すれば、コストはこれまでどおりに保たれるのでしょうか？（当社は主にBigQueryを利用しています）
回答：そのとおりです。先日のアップデート以降、すべて「オプトイン」モデルに変わりました。ただし、これらの処理が知らぬ間に課金されることのないよう、事前にData Lineage、Data Catalog、Data Discoveryの各APIをオフにしておくことをお勧めします。
Q4：DoiTのサポートコンソールでこれらのDataplexコストを確認・追跡できますか？
回答：はい。「Dataplex」サービスでフィルタをかければ、すべて一覧表示されます。当社のEngineersがトラブルシュートする際は、サービスでDataplexにフィルタしたうえで、SKUとプロジェクトでグルーピングするのが定番です。これでDoiT Console上でプロジェクト別・SKU別のコストを確認できます。