はじめに
Google Cloudを運用していく上で、コスト管理とガバナンスは常に意識する必要があります。
予期せぬサービスの利用や設定ミス、監視ツールの予期せぬ動きなどにより、特定のSKUの課金が急激に跳ね上がるといったケースは、インフラ運用において珍しくありません。
原因を特定するために通常は Cloud Logging を利用して「誰が、どのリクエストを叩いているか」を調査しますが、ログ出力設定をしないと出力されないものもあります。
原因を特定するために通常は Cloud Logging を利用して「誰が、どのリクエストを叩いているか」を調査しますが、ログ出力設定をしないと出力されないものもあります。
ログが無いから調査のしようがないのでしょうか？
そんな場合に、課金の足跡を辿っていくことができる方法をご紹介します。
背景
Google Cloudの課金コンソールでは、サービス単位だけでなくSKUという最少課金単位で、どのサービスにいつどの費用が発生したかを見ることができます。
ただし、「コストがかかっているのは分かるがなぜかかっているのか分からない」というケースもあると思われます。BigQueryやGCEインスタンスのように、リソースが存在していたり実行によるコストが可視化されているものであれば別ですが、LoggingやMonitoringリソースのように課金の中身が判別しづらいものもあります。それ以外でも、意識的に使っているわけでなくてもAPIが大量に呼ばれていて実は課金されてしまった、ということも考えられます。
そういったAPIの呼び出しを全て見つけるようにするために、Google Cloudの「データアクセス監査ログ」を有効化するというのは一案です。ただし、データアクセス監査ログをむやみに有効化することは、公式ドキュメントでも推奨していません。
公式ドキュメントより
重要: データアクセス監査ログのボリュームは大きなものになる可能性があります。データアクセス ログを有効にすると、 Google Cloud プロジェクトに対して追加のログ使用量の費用が発生する可能性があります。 料金については、Google Cloud Observability の料金ページの Cloud Logging セクションをご覧ください。
調査のためとはいえど、予期せぬ量の課金がされてしまうのは避けたいところでしょう。
では、どんな調べ方があるでしょうか？
解決策
今回、以下のステップを踏むことで確認が出来ました。
- Step 1：Metrics Explorer（時系列統計）による対象の絞り込み
まずは「自プロジェクト内からの呼び出しなのか」「外部の別プロジェクトからのアクセスなのか」という、通信の発生源と、実行されている具体的なAPIメソッドを絞り込みます。 - Step 2：「APIとサービス」による「アカウントの特定」
原因のプロジェクトが分かったら、プロジェクト全体のAPI利用統計ダッシュボードを活用し、その呼び出しをしている 「特定の認証情報（サービスアカウントなど）」 を特定します。
実例
今回、Cloud Monitoringのメソッドで課金されていることが分かったものの、どこからどう呼ばれているか不明というケースに直面したので、その際の手順を説明します。
課金対象は「Time series billed count」ですが、こちらを呼び出している認識が無いところからのスタートです
Step 1
Google Cloudコンソールから [Monitoring] → [Metrics Explorer] を選択し、PromQLのクエリを記述します。
sum(increase({"monitoring.googleapis.com/billing/time_series_billed_for_queries_count"}[7d])) by (project_id, api_method)集計関数を用いて by (project_id, api_method) でグループ化することにより、「どのプロジェクト内から」「どのAPIメソッドが」 実行されているかの統計が可視化されます。これにより、実行されている具体的なメソッド名（例: ListTimeSeries など）が特定できます。
このような画面で、呼び出し状況をチャートとテーブルで確認できました。今回の場合重要だったのが、「project_id」が、実際に課金レポートで課金対象となっていたプロジェクトとは異なるものだったと判明したことです。
つまり、コストが計上されたプロジェクト内で原因を探しても、見つけることは出来なかったわけです。
Step 2
どのプロジェクトが呼び出し元か分かったため、そのプロジェクト内でさらに深堀していきます。
コンソールのナビゲーションメニューから [API とサービス] → [ダッシュボード]（または [有効な API とサービス]）を選択します。
リスト内から、原因となっているAPI（例: [Cloud Monitoring API]）をクリックします。
ここから、今回大量に呼び出しされている処理（ListTimeSeries）の呼び出し状況を確認します
設定箇所
グラフを選択 「認証情報別のトラフィック」を選択します
フィルタ > Versions 「v3」を選択します
フィルタ > Methods 「ListTimeSeries」を選択します
上記を設定するとグラフが更新されます。
赤線部のところに、このメソッドを呼び出しているサービスアカウントが表示されます
※ 例の場合は1件のみですが、複数ある場合上位数件が表示されます
ここで出てくるサービスアカウントが、今回課金対象となったメソッドを呼んでいるサービスアカウントです。このサービスアカウントを利用しているVMなどのワークロードを調査し、メソッドの呼び出しが適切なのかどうかの検討に進むことが出来ます。
まとめ
今回のようにコストの発生源が分かりにくいサービスもGoogle Cloudでは少なくないでしょう。そのような時に手がかりを探す方法を今回ご紹介しました。
是非参考にしてみてください。
Google Cloud、Google Workspace に関するご相談はXIMIXへ！
Google Cloud、Google Workspaceに関する お問い合わせはこちら
執筆者紹介
![[GWSStudio100本ノック] Workspace Studio が NotebookLM 連携 ― Chat の問い合わせを AI が一次回答するデモ](https://ximix.niandc.co.jp/hs-fs/hubfs/Gemini_Generated_Image_r967l1r967l1r967.png?width=84&name=Gemini_Generated_Image_r967l1r967l1r967.png)
