🐶

大規模 Cloud Run 環境を支える Datadog の Terraform 実装

AoTo

2025/12/03に公開

!この記事は、人間が全て執筆し、Zenn AI レビュー機能によって校正しています。
この記事は Datadog Advent Calendar 2025 シリーズ2 の3日目の記事です。

 TL;DRGoogle Cloud Run はそのサービスの特性から、監視すべきテレメトリーが多くあります。

Datadog は Cloud Run へ軽量版の Datadog Agent である serverless-init エージェントの実装を通じて、Cloud Run からテレメトリーを収集し監視できます。
従来大規模な Cloud Run 環境において、手動の実装では導入コストが高いことが課題でした。

こうした大規模 Cloud Run 環境では、新しく登場した Datadog Terraform module for Google Cloud Run が最適です。そのため、本記事はこの Terraform モジュールの概要を紹介し、その特性と注意点を解き明かします。
本記事は、Terraform で Cloud Run を管理している方々や、Cloud Run へ Datadog をシンプルに実装したい方々を対象としています🐶

 Cloud Run 監視の難しさGoogle Cloud Run はサーバレスなコンテナ実行を支えるマネージドサービスです。

特に、Cloud Run services の場合はそのサービスの特性から、以下のようなメトリクスを監視することが推奨されます。

 コンテナCPU 使用率
CPU 割り当て時間
メモリ使用率
メモリ割り当て時間

 ウェブアプリリクエスト数
リクエストレイテンシー
リクエストエラー

 マネージドサービス課金インスタンス時間
コンテナインスタンス数
これらのメトリクスは全て設定不要で Cloud Run と統合されている Cloud Monitoring へ収集され、さらに Google Cloud Console 上の Cloud Run UI からも直接確認できます。
これらのメトリクスが重要だという考え方の背景は、Datadog の公式ブログ(The Monitor)の『Key metrics for monitoring Google Cloud Run』でも述べられていますので、是非あわせてお読みください🐕
https://www.datadoghq.com/blog/key-metrics-for-cloud-run-monitoring/
Cloud Run はサーバレスなサービスでもあります。

そのためこうしたメトリクスに加えて、スケーリングに伴い コールドスタート が発生する可能性があります。上記と同様にまとめてみると、次のようなメトリクスを監視したくなると考えられます。

 サーバレスコールドスタート発生数
シャットダウン数
しかし、これらの情報は Cloud Monitoring や Google Cloud 上の設定では確認できません。

サーバレスサービスの特性に合わせたメトリクスを新たに取得できなければ、Cloud Run の特性を理解しながら対処することが難しいでしょう。
さらに Cloud Run 上のサービスの稼働状況・依存関係・トランザクションの処理時間を正しく把握するにはこうしたメトリクスでは限界があります。

こうした背景からも、より詳細なコンテキストを保持できる ログやメトリクス といった監視情報も欠かせません。
統合的なオブザーバビリティツールである Datadog は、こうした Cloud Run の特性に合わせた serverless-init 実装を提供しています🐶

Cloud Run へ軽量エージェントの serverless-init の実装を通じて、以下のような方式で Cloud Run のメトリクス・ログ・トレースを監視できます。
拡張メトリクスとしてのコールドスタート・シャットダウンの記録
DogStatsD カスタムメトリクスの収集

stdout, stderr のストリームをラップしたログ収集(同一コンテナ内)
ファイルルーティング(テイリング)によるログ収集
トレースエージェントによるアプリケーショントレースの収集
こうした serverless-init の実装は、従来コンテナイメージへや cloudrun.yaml への追記を手動で行う必要がありました。
しかし、大規模なサービスを Cloud Run で提供している環境の場合はどうでしょうか？こうした大規模 Cloud Run 環境では、数多くの Cloud Run services, jobs, worker pools, functions を管理していることが考えられます。

これらの環境内の個々のリソースに手動で実装を行うには、大きな導入コストが想定されていました…
こうした背景から登場したのが、「Datadog Terraform module for Google Cloud Run」です！

 Datadog Terraform module for Google Cloud Run の登場
Datadog Terraform module for Google Cloud Run は上記の通り、Datadog の軽量な serverless-init エージェントの実装する Terraform モジュールです。
本モジュールは Cloud Run の Terraform リソースである google_cloud_run_v2_service のリソースをラップしてDatadog の実装を行います。この実装は Cloud Run のサイドカー機能を利用して、既存のアプリケーションコンテナを変更せず新たに serverless-init コンテナを Cloud Run services のサービスに追加するものです。[1]
モジュールの形式は以下のように、source = "DataDog/cloud-run-datadog/google" を指定した上で datadog_ で始まる変数を指定します。これに加えて datadog_sidecar で serverless-init のバージョンなどの詳細を指定することもできます。この中で必須の変数は datadog_api_key, project, region のみです。
datadog-cr.tf
module "datadog-cloud-run-v2" {
  source = "DataDog/cloud-run-datadog/google"
  name = var.name
  location = var.region
  deletion_protection = false

  datadog_api_key = "[DD_API_KEY]"
  datadog_service = "[DD_SERVICE]
  datadog_version = "[DD_VERSION]"
  datadog_env = "[DD_ENV]"
  datadog_enable_logging = true

  datadog_sidecar = {
    # イメージの指定やコンテナ名の変更などが可能
  }

# google_cloud_run_v2_service リソースで定義している内容と同様

}
アプリケーションコンテナの定義は google_cloud_run_v2_service リソースで記載する内容とほとんど同じです。既に単純な定義で Cloud Run service を Terraform で実装していれば変更は最小限で済みます。
一方で移行の際に注意しなければならない点もあるため、ここからは移行や実装の際の注意点に触れていきます。

 注意点
 移行時先ほどの続きで、google_cloud_run_v2_service リソースを既に利用していた場合に、この Terraform モジュールに移行する際は問題が発生する可能性を最小限にするために以下の変更が推奨されています。
各リソースブロックに = を追加する

volumes, volume_mounts, env, containers のような繰り返しがあるブロックはリスト型のオブジェクトへ変換する
既に Datadog の設定がされている場合は、コンテナや環境変数を残さない
Datadog の環境変数はモジュールの定義(datadog_*) or コンテナの環境変数として template.containers[*].env で設定する
設定ファイルに moved ブロックを宣言し、リソースとモジュールのアプリケーションコンテナの name パラメータを一致させる
複雑な定義で Cloud Run を管理している場合は必ず複数の観点から確認を行い、tflint や terraform fmt などを利用して確認を怠らないようにしましょう🐶

 実装時元のリソースが存在しない場合にも、Datadog の実装方式や環境変数の役割を知っておくことが重要です。以下に、誤解が生まれやすいポイントをまとめました。

Datadog の環境変数はアプリケーションコンテナに定義するものと、サイドカーコンテナに定義するものがある
Datadog の環境変数はアプリケーションコンテナでは APM SDK(Tracer, Tracing Library) が利用し、サイドカーコンテナでは serverless-init エージェントが利用する

DD_TRACE_ENABLED だけではトレースは取得できず、別途　APM SDK(Tracer, Tracing Library) の実装が必要

DD_SERVERLESS_LOG_PATH は両コンテナに設定することで、コンテナ間でログ収集を可能にする
Datadog の Docker や Kubernetes の実装に用いられる環境変数は基本無効
無効な環境変数の設定や環境変数名の間違いを防ぐためにも、モジュールの定義として環境変数を設定することを推奨します🐶

 まとめ今回まとめたように、現在は Datadog Terraform module for Google Cloud Run が公開されたことにより、大規模 Cloud Run 環境でも Datadog の恩恵を受けやすくなっています。
serverless-init エージェントのサイドカー実装の場合は、他にも Datadog CLI, yaml 定義, Cloud Console などでも設定可能です。実装環境に合わせて最適な実装方法を選択しましょう！

脚注
Datadog はアプリケーションコンテナ内に serverless-init インストールする実装方式をサポートしていますが、コンテナイメージの変更を伴うため Terraform モジュールでの実装ではサポートされません。 ↩︎

GitHubで編集を提案

Datadog Tech BlogPublication

Datadog はオブザーバビリティとセキュリティの統合プラットフォームです。本 Publication は Datadog Japan のエンジニアを中心に有志で発信・運営されています。各記事の内容は個人の意見であり、企業を代表するものではございません。

TL;DR

Cloud Run 監視の難しさ

コンテナ

ウェブアプリ

マネージドサービス

サーバレス

Datadog Terraform module for Google Cloud Run の登場

注意点

移行時

実装時

まとめ

Discussion