Google Cloud試験で得たナレッジ

こんにちは。KIYONOエンジニアです。

先日の冬休みでGoogle Cloudの資格を3つ（※）取りました。※「Professional Machine Learning Engineer」、「Professional Cloud Developer 」、「Generative AI Leader」の計3つの資格

本日はその中で実際に実務に活かせそうと感じたサービスとそのユースケースをご紹介します。

Cloud Run jobs
Apigee
Cloud Profiler
最後に

Cloud Run jobs

Cloud Run jobs は、コンテナ化されたアプリケーションを「完了するまで実行する」ことに特化した、Google Cloud のフルマネージド（サーバーレス）なコンピューティングサービスです。Webサイトのようにリクエストを待ち受けるのではなく、データ処理やスクリプト実行のようなバッチタスクに最適です。

Cloud Run Servicesと何が違う？と感じた方もいらっしゃるかもしれないので比較します。

特徴	Cloud Run Services (サービス)	Cloud Run jobs (ジョブ)
主な用途	Web API, Webサイト, マイクロサービス	バッチ処理, データ集計, 定期スクリプト
起動のきっかけ	HTTPリクエストの受信	手動, スケジュール, イベント発生
実行モデル	リクエストを処理してレスポンスを返す	処理が「完了」するまで走り続ける
実行時間	短い (デフォルト5分、最大60分)	長い (最大24時間)
スケーリング	リクエスト数に応じて自動増減 (0～N)	指定した並列数で実行 (タスクの分割実行)
費用 (課金体系)	リクエスト処理中のCPU/メモリ使用量に対して課金（待機時は無料設定が可能）	ジョブ実行中のCPU/メモリ使用量に対して課金（完了後は課金終了）

イメージは画像の通りです。

弊社でも広告媒体より各広告アカウントごとにインプレッションやクリックを取得する際に、ジョブ時間が長くサービスの方ではタイムアウトになってしまうということがありましたが、ジョブの方を使うことによってタイムアウトせずデータ連携が可能となりました。なおバッチ機能としてGCE使われる方もいらっしゃるかと思いますが、やはりコンテナベースが扱いやすいということもあり、また長時間何度も起動されなければコストメリットが出やすいということで重たいバッチ処理はジョブの方を使うことが多いです。

Apigee

Apigeeの主な役割は以下の通りです。

APIプロキシ（正面玄関）: 既存のシステム（Cloud Run, GKE, オンプレミスなど）をそのまま公開せず、Apigeeが一度リクエストを受け取り、整形や認証を行ってからバックエンドへ流します。
セキュリティの統一: OAuth認証、APIキー、ボット対策（高度な異常検知）などを、個別のアプリ側ではなくApigee側で一括設定できます。
トラフィック制御: 「1分間に100回以上のアクセスは遮断する（クォータ制限）」といった制御がノーコードで可能です

機能詳細は以下の通りです。

機能	内容
ポリシー管理	認証、キャッシュ、データの形式変換（XML→JSONなど）を50種類以上の標準機能で実装。
デベロッパーポータル	APIの仕様書を自動公開し、外部の開発者が自分で登録して使い始められる「セルフサービス」サイトを作成。
高度な分析 (Analytics)	どのAPIが人気か、どこでエラーが多いか、応答時間はどれくらいか、といった情報を可視化。
収益化 (Monetization)	APIの利用回数に応じて課金する「APIビジネス」の仕組みを構築。
AI管理 (AI API Management)	生成AI（LLM）へのプロンプトインジェクション防御や、トークン消費量の監視・制限。

特にデベロッパーポータルと収益化の部分についてはAPIの仕様書を公開できたり、収益化の部分はAPIの利用回数に応じて課金する「APIビジネス」の仕組みを構築といった色々できます。

1. 従量課金モデル (Pay-as-you-go)

使った分だけ支払う、最もシンプルで公平なモデルです。

例えば：天気情報API
- 1リクエストあたり 0.1円。
- 小規模なアプリ開発者は月100円程度で済みますが、大手ニュースサイトが月1,000万回呼び出せば、100万円の収益になります。
- Apigeeの役割: 膨大なアクセスをリアルタイムでカウントし、月のアグリゲーション（集計）を自動で行います。

2. フリーミアム / 段階的（Tier）モデル

無料枠でユーザーを呼び込み、ヘビーユーザーや企業から収益を得るモデルです。

例えば：翻訳API / AI解析API
- Free: 月1,000回まで無料（個人開発者向け）。
- Standard: 月1万回までで 5,000円。
- Enterprise: 月無制限、優先サポート付きで 10万円。
- Apigeeの役割: 「月1,000回を超えた瞬間にエラーを返す（クォータ制限）」、または「有料プランへのアップグレードを促す」といった制御を自動化します。

3. トランザクション・シェア（レベニューシェア）モデル

APIを通じた「売上」の一部を分け合うモデルです。

例えば：宿泊予約プラットフォーム
- 提携サイトのAPI経由でホテル予約が成立したら、予約額の3%をAPI提供者に支払う。
- 逆に、API提供者が開発者にインセンティブ（紹介料）を支払う形も可能です。
- Apigeeの役割: 単なる「アクセス数」ではなく、リクエストの中身（予約金額など）を読み取って、金額ベースでの課金計算を行います。

といったように色々な活用方法があります。これを使えばユーザごと、または企業ごとに使用料に応じた従量課金を簡単に設定することができるのでSaaSやパッケージ関連のビジネスの幅が膨らんでくるかと思います。

またAPIを管理する似たようなサービスとしてAPI GatewayやCloud Endpointsがありますのでそれらとの比較をすると以下の通りです。

比較項目	API Gateway	Cloud Endpoints	Apigee
位置づけ	サーバーレスな窓口	分散型の軽量ツール	APIビジネス基盤
運用負荷	極めて低い (フルマネード)	中 (プロキシの管理が必要)	高 (多機能ゆえの設計が必要)
主な対象	Cloud Run, Functions	GKE, Compute Engine	あらゆる環境 (Hybrid/Multi)
得意なこと	手軽な認証・制限	低レイテンシ、gRPC対応	収益化、高度な分析、変換
開発者ポータル	なし	簡易的なもの	本格的なポータルを提供
コスト	安価 (従量課金)	安価 (従量課金)	高価 (エンタープライズ向け)

図解すると以下の通りとなります。

Cloud Profiler

Cloud Profilerは、本番環境で実行されているアプリケーションのリソース消費を、極めて低いオーバーヘッド（通常5%未満）で継続的に計測する常時稼働型プロファイラです。

主な特徴

「どの関数」が重いか特定: ソースコードのどの行やどの関数がCPUを大量に消費しているか、またはメモリを占有しているかを特定します。
統計的サンプリング: 全てのリクエストを追跡するのではなく、統計的にサンプリングを行うため、本番環境のパフォーマンスに大きな影響を与えません。
コスト削減: 非効率なコードを特定して最適化することで、計算リソース（CPU/メモリ）を減らし、クラウド利用料の削減に直結します。

Cloud Profiler と Cloud Trace の違い

どちらも「パフォーマンス向上」を目的としていますが、「何を見るか（観点）」と「粒度」が大きく異なります。

項目	Cloud Profiler	Cloud Trace
主な目的	リソース消費の最適化（コスト・効率）	レイテンシの改善（応答速度・ユーザー体験）
分析対象	CPU時間、ヒープメモリ、スレッドなど	リクエストの経過時間、RPC呼び出し、依存関係
視点	アプリケーション内部（コード、関数レベル）	システム全体（マイクロサービス、分散環境）
代表的な問い	「どの関数がCPUを一番使っているか？」	「なぜこのリクエストに3秒もかかったのか？」
可視化ツール	フレームグラフ	ウォーターフォール図（スパン図）

図解すると以下のイメージです。

使い分けのシナリオ

これら2つは「補完関係」にあります。

Cloud Trace を使うべき時:
- 特定のAPIリクエストが遅い原因を知りたい。
- マイクロサービス間で、どのサービスがボトルネックになっているか特定したい。
- データベースクエリや外部API呼び出しに時間がかかっていないか確認したい。
Cloud Profiler を使うべき時:
- サーバーのCPU使用率が常に高く、コードのどこで計算処理が走っているか知りたい。
- メモリリークが発生しており、どの関数がメモリを確保し続けているか特定したい。
- インフラの実行コストを削減するために、プログラムのアルゴリズムを最適化したい。