Cloud Profiler

解決する課題

アプリの応答が遅い、あるいはコンピューティング費用が想定より高いとき、原因がコードのどこにあるのかを突き止めるのは簡単ではありません。開発環境のプロファイラは本番の実負荷を再現しづらく、計測のために負荷をかけると挙動も変わります。Cloud Profiler は 本番環境で継続的に動かせる軽量プロファイラ として、この課題に答えます。

• 本番で CPU 時間を多く使っている関数 を特定し、最適化の優先順位を付けたい
• メモリ割り当てが多い箇所 を見つけ、GC 負荷やメモリ増大を抑えたい
• 開発環境では再現しない、実トラフィック下のボトルネック を捉えたい
• 計測そのものの オーバーヘッドを最小化 して、常時稼働させたい
• リリース前後で どの関数のコストが変化したか を比較したい

主要概念と用語

Cloud Profiler は Google Cloud Observability の一部で、メトリクスの Cloud Monitoring やトレースの Cloud Trace と並ぶ、コードレベルの性能分析を担うサービスです。

• 継続的プロファイリング（Continuous Profiling）: 本番環境で常時、低頻度のサンプリングを続ける方式。特定時点ではなく長期の傾向を捉える
• プロファイルの種類（Profile Type）: 採取対象のこと。CPU 時間（Wall/CPU）、ヒープ（割り当て中のメモリ）、割り当て量、競合（contention）、スレッドなど。言語により取得できる種類が異なる
• Flame Graph（フレームグラフ）: コールスタックを横幅＝消費量として積み上げた可視化。幅の広いフレームほど多くのリソースを使っている関数を表す
• 統計サンプリング（Statistical Sampling）: 全呼び出しを計測せず、一定間隔でスタックを抽出して集計する手法。オーバーヘッドが小さい
• プロファイリングエージェント（Agent）: アプリに組み込むライブラリ。定期的にプロファイルを採取し、Profiler のバックエンドへ送信する
• デプロイメントラベル: サービス名・バージョン・ゾーンなどの識別子。これらでプロファイルを絞り込み、バージョン間の比較ができる

仕様・制限・クォータ

• 対応言語が限られる。Go・Java・Python・Node.js が主な対象で、取得できるプロファイルの種類も言語ごとに異なる（例: CPU は広く対応、ヒープは一部）
• 採取は 統計サンプリング が前提で、全関数呼び出しの完全な記録ではない。短時間しか実行されないプロセスは十分なサンプルが集まりにくい
• エージェントの導入が必要で、アプリ起動時に サービス名とバージョン を指定して初期化する
• プロファイルデータには 保持期間 があり、一定期間を過ぎたものは参照できなくなる
• 採取・取り込みには API のレート上限 があり得る。具体的な保持日数や上限値は変動するため、設計時は最新の公式ドキュメントとプロジェクトのクォータ画面で確認する

内部の仕組み

アプリに組み込んだプロファイリングエージェントが、一定間隔で短時間だけ実行スタックをサンプリングします。たとえば CPU プロファイルなら、ある期間にわたって「いまどの関数を実行しているか」を低頻度で抜き取り、関数ごとの出現回数を集計します。これにより、計測を全呼び出しに仕掛けることなく、統計的に「どの関数が時間を食っているか」を推定できます。

採取したプロファイルはデプロイメントラベル（サービス名・バージョンなど）とともに Profiler のバックエンドへ送信され、コンソール上で Flame Graph として再構成されます。複数インスタンスのプロファイルは集約されるため、フリート全体の傾向として読めます。

設計パターン / ベストプラクティス

• エージェントの初期化時に サービス名とバージョンを必ず指定 し、リリースごとにプロファイルを比較できるようにする
• まず CPU/Wall プロファイルで遅い関数を特定 し、メモリ問題が疑われる場合に ヒープ/割り当てプロファイル を追加で見る、と種類を使い分ける
• Flame Graph は 幅の広いフレームから掘る。自前コードだけでなく、ライブラリ呼び出しのコストも確認する
• リリース前後で 同じワークロード下のプロファイルを比較 し、最適化の効果や回帰を定量的に確認する
• Cloud Monitoring のメトリクスで異常（CPU 高騰など）を検知し、Cloud Profiler で 原因関数まで掘り下げる 二段構えにする
• 採取対象は本番だけでなく、負荷試験環境にも組み込む と、リリース前にボトルネックを洗い出せる

運用・監視

• プロファイルが表示されない → エージェントの初期化、対応言語・ランタイムか、サービスアカウントの IAM 権限（書き込み権限）、Profiler API の有効化を確認
• サンプルが少なすぎる → プロセスの実行時間が短すぎないか、十分なトラフィックがあるかを確認
• バージョン比較ができない → エージェント初期化時のバージョンラベルが正しく設定されているかを確認
• ボトルネック調査 → CPU プロファイルの Flame Graph で幅の広い関数から特定し、必要に応じてヒーププロファイルでメモリ消費を確認
• コスト回帰の検知 → デプロイ前後のプロファイルを並べ、重い関数の変化を確認する

コスト

Cloud Profiler 自体の利用は、追加料金なしで提供されるのが基本的な位置づけです。請求の主眼は Profiler の使用料ではなく、プロファイル結果を使ってコンピューティング費用を下げること にあります。重い関数を特定して最適化すれば、VM や Cloud Run の CPU・メモリ消費が減り、その分のインフラ費用が削減できます。

セキュリティ

• プロファイルの書き込み権限は IAM ロール で最小化する。送信にはエージェント相当の書き込みロール、閲覧には参照ロールを割り当てる
• アプリからの送信には、キー JSON ではなく アタッチされたサービスアカウント を使う（GKE では Workload Identity）。鍵ファイルの漏洩リスクを避ける
• プロファイルが扱うのは 関数名やコールスタック であり、リクエスト本文のような業務データは含まないのが基本。ただし関数名やパッケージ構成から内部実装が読み取れるため、閲覧権限の付与範囲には注意する
• Profiler API は、不要なプロジェクトでは無効のままにしておく

関連サービス・比較

Cloud Profiler は単独ではなく、Observability の他サービスと組み合わせて使います。トレースの Cloud Trace とは、どちらも性能分析でありながら粒度が異なります。Cloud Trace が「サービス間の時間軸（どの区間が遅いか）」を見るのに対し、Cloud Profiler は「1 プロセス内のどの関数が重いか」を見ます。

GCP 内では、メトリクスは Cloud Monitoring、ログは Cloud Logging、サービス間の遅延は Cloud Trace が担い、Cloud Profiler は「コードレベルのリソース消費」に特化します。これらを併用して可観測性を構成します。

ハンズオン / CLI例

# プロジェクトで Cloud Profiler API を有効化する
gcloud services enable cloudprofiler.googleapis.com --project=PROJECT_ID

# アプリ実行用サービスアカウントにプロファイル書き込み権限を付与する
# （roles/cloudprofiler.agent がプロファイル送信に必要なロール）
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:app-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/cloudprofiler.agent"

# プロファイルの参照は Cloud Console の Profiler 画面で行う。
# アプリ側ではエージェントを初期化し、service と version を指定する。
# 例（Go）: profiler.Start(profiler.Config{Service: "my-app", ServiceVersion: "1.0.0"})