Datadog integrations Deep Dive - Google Cloud 編

## はじめに
こんにちは、Datadog Japan で Sales Engineer をしている [**AoTo**](https://qiita.com/AoTo0330) です。

この投稿は **[<font color="#6495ED">AoTo Advent Calendar 2024</font>](https://qiita.com/advent-calendar/2024/aoto) 4日目**の記事です。

本記事は『[【完全解説】4大クラウドの Datadog integrations アーキテクチャ【2024年版】](https://qiita.com/AoTo0330/items/33d7b58a3cfddcbd3fe2)』で解説仕切れなかった、<INS>Datadog Google Cloud integration の細かな仕様と注意点</INS>を解説します。

主にメトリクス・ログ収集に関する **Google Cloud integration** の様々なオプションについて解説しているので、参考にしていただけると幸いです🐶

## Google Cloud integration の全体像
![Datadog-GoogleCloud-Integration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/c174706c-c2cb-357a-520d-1ad892d8ab34.png)

**Datadog Goolge Cloud integration** は主に **Google Cloud Monitoring/Logging** からのメトリクス・ログ情報の収集と、各リソースのメタデータの参照と監視情報への紐付けを行います。

### Google Cloud integration のネットワーク接続
Google Cloud integration はメトリクス・ログを Datadog Organization 毎に用意された API Key による認証でデータを適切な Datadog Org に収集します。この時、Datadog Site として **US5, EU** を選択することで、<INS>暗黙的に Google Cloud ネットワーク内を経由した通信</INS>が行われ、安全性効率性が高い状態での監視データ連携ができます。

これは、[**Pub/Sub** のコントロールプレーン](https://cloud.google.com/pubsub/architecture?hl=ja#control_plane)の仕様と **Dataflow ワーカー(GCE)** にデフォルトで適用される [Network Service Teir](https://cloud.google.com/network-tiers/docs/overview?hl=ja) によって推察できますが、必ずしも保証されません。

[Google Cloud Private Service Connect 経由で Datadog に接続](https://docs.datadoghq.com/ja/agent/guide/gcp-private-service-connect/?site=us5)オプションにより、<INS>プライベート IP しか持たない Dataflow を用意する</INS>ことでは明示的にプライベートネットワークを介した通信を強制できます。

<INS>プライベート IP しか持たない Dataflow を用意する</INS>方法は公式には案内はありませんが、『[Datadog に Google Cloud のログをセキュアに送信する](https://zenn.dev/aotolog/articles/datadog-gc-logs-dataflow)』で詳しく解説しています。

https://zenn.dev/aotolog/articles/datadog-gc-logs-dataflow

## メトリクス収集
![Datadog-GoogleCloud-Integration-Metrics.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/1c041c1d-0f45-945b-0396-d07a916b4e5e.png)

### 改善されたセットアップ
新しく Google Cloud integration を利用される場合には意識することはありませんが、2023年6月にセットアップの方式が改善されより少ないステップでインテグレーションを完了できるようになりました。

https://www.datadoghq.com/ja/blog/google-cloud-service-account-impersonation/

2023年以前は、サービスアカウントを権限として利用するために[サービスアカウントキー](https://cloud.google.com/iam/docs/service-account-creds?hl=ja#key-types)を利用していました。そのため、インテグレーションのために<INS>サービスアカウントキーの作成と Datadog へのアップロード</INS>が必要でした。

「[サービスアカウントキーからの移行](https://cloud.google.com/iam/docs/migrate-from-service-account-keys?hl=ja)」ガイドのように、サービスアカウントキーの利用は **Google Cloud でも推奨されておらず**いません。キーを利用する場合は、ユーザーは常に[キーの漏洩に対処する](https://cloud.google.com/iam/docs/migrate-from-service-account-keys?hl=ja#respond-to-leaked-keys)必要があります。

この変更により、サービスアカウントキーの利用から[**サービスアカウントの権限借用**](https://cloud.google.com/iam/docs/service-account-impersonation?hl=ja)によりインテグレーションを完了できるようになり、現在はよりセキュア・簡単にセットアップを完了できます。

:::note warn
2023年以前にサービスアカウントキーでのセットアップを行なったユーザーは、サービスアカウントの権限借用に移行することが**推奨**されています。
古い方式でセットアップを行なっている場合は、[Google Cloud integration タイル](https://app.datadoghq.com/integrations/google-cloud-platform)上では対象の設定に <font color="de5f0c">**`Legacy`**</font> と上部に以下の文章が表示されます。
> <font color="de5f0c">**Recommended Update**</font>
We detect legacy Project ID files that are using a deprecated authentication flow, and recommend that they be updated as soon as possible.
:::

### 複数プロジェクトの監視
サービスアカウントに他のプロジェクト・フォルダ・組織へのアクセスを許可をすることで、自動プロジェクト検出が可能です。メトリクスを収集したい環境の `Compute Viewer`, `Monitoring Viewer`, `Cloud Asset Viewer` 権限を付与することで、Datadog は自動的に他のプロジェクトやフォルダ・組織配下のプロジェクトを検出します。

他のクラウドインテグレーションと比較しても、複数環境のメトリクスを最も簡単に収集できます。これは、Google Cloud の IAM をはじめとする権限リソースが<INS>プロジェクト内で管理されるリソース**ではない**</INS>ためです。

こうした IAM の違いは、G-gen さんの記事がわかりやすく解説しているので、併せてご参照ください。

https://blog.g-gen.co.jp/entry/iam-explained

### 収集メトリクスの除外・制限
メトリクスの連携が不要な場合は[名前空間](https://cloud.google.com/monitoring/api/v3/naming-conventions?hl=ja)やリソース・リビジョンタグに基づく除外ができます。

Datadog の [Google Cloud integration タイル](https://app.datadoghq.com/integrations/google-cloud-platform)から、Google Cloud のサービス名毎に用意される Cloud Monitoring の名前空間(`projects/<プロジェクト ID>/<メトリクス種別>/<サービス名>.googleapis.com/`) ごとに収集を無効化できます。[Metric Collection] タブを選択し各サービス名のトグルをオフにすることで、Datadog クローラーは対象のメトリクス名前空間への API リクエストを行わなくなります。

さらに、**Google Compute Engine(GCE), Google Kubernetes Engine(GKE), Google Cloud Run** はホワイト/ブラックリストの両形式でリソースタグに応じたメトリクス収集の限定ができます。これにより、**GCE, GKE**のインスタンス数と **Cloud Run** のリビジョン数に応じた Datadog 上の課金を制限できます。

詳細は「[Google Cloud インテグレーションの請求](https://docs.datadoghq.com/ja/account_management/billing/google_cloud/)」ガイドを併せてご参照ください。[^1]
[^1]: 一部、説明が古い可能があります

## ログ収集
 - 推奨構成
![Datadog-GoogleCloud-Integration-Logs.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/3ecb9512-d3f6-bac4-777b-fc5c608a88ae.png)

 - 非推奨構成
![Datadog-GoogleCloud-Integration-Logs-depricated.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/dba9b115-41dc-a106-d8fb-b8c8ec23a0ba.png)

:::note info
2024年12月に Datadog の公式情報として Google Cloud のクラウドアーキテクチャセンターに『[Stream logs from Google Cloud to Datadog](https://cloud.google.com/architecture/partners/stream-cloud-logs-to-datadog)』が公開されました。こちらも合わせてご確認ください。
:::


### Pub/Sub サブスクリプション方式の変更
メトリクス収集と同様に、2023年10月にログ収集の方式も改善されました。**Pub/Sub トピック**までログを転送する点は変わらず、**Pub/Sub サブスクリプション**の方式とそれに伴い **Dataflow** の利用が推奨となりました。

https://www.datadoghq.com/ja/blog/stream-logs-datadog-dataflow-template/

従来の[**プッシュサブスクリプション**](https://cloud.google.com/pubsub/docs/create-push-subscription?hl=ja)は **Pub/Sub トピック**から直接 [Datadog Logs inteke API](https://docs.datadoghq.com/api/latest/logs/#send-logs) にログを送りつける方式です。設定の簡便さの一方で、<INS>ネットワークや Datadog API の問題でログの転送が失敗した際にログが失われること</INS>や、<INS>プライベートネットワークでのログの転送ができないこと</INS>などの問題を抱えていました。

この問題に対し、[**プルサブスクリプション**](https://cloud.google.com/pubsub/docs/create-subscription?hl=ja)と **Dataflow** を利用することで、ログの圧縮・再送・暗号化をした上での送信が可能となりました。さらに、Dataflow ワーカーをプライベート IP のみで稼働し、**Private Service Connect** を介することでプライベートネットワークのみを経由したセキュアなログ送信が可能となりました。

:::note alert
現在も[非推奨構成のドキュメント](https://docs.datadoghq.com/ja/logs/guide/collect-google-cloud-logs-with-push/)は公開されていますが、これはトラブルシューティングやレガシーセットアップの変更のためにのみ残されており、サポートは提供されません。
また、非推奨構成は近い将来に**廃止**される予定のため、こちらも推奨構成への**移行が推奨**されています。
:::

### Dataflow パイプラインの調整
ログ送信方式が変更されたことで、Dataflow を新たに構成する必要が生まれ Google Cloud ログ送信設定の複雑性が増しました。特に、Dataflow を利用したことがないユーザーにとっては Dataflow の推奨される構成を考慮することが難しくなっています。

Datadog は [Pub/Sub to Datadog](https://cloud.google.com/dataflow/docs/guides/templates/provided/pubsub-to-datadog?hl=ja) Dataflow テンプレートを公開しています。このテンプレートは主に `Apache Beam Java SDK 2.50.0`[^2] で書かれており、Dataflow のさまざまなオプションを利用することができます。
[^2]: 2024年12月時点。GitHub [`GoogleCloud
Platform/DataflowTemplates` リポジトリ](https://github.com/GoogleCloudPlatform/DataflowTemplates/tree/main/v1/src/main/java/com/google/cloud/teleport/datadog) より確認

[Pub/Sub to Datadog](https://cloud.google.com/dataflow/docs/guides/templates/provided/pubsub-to-datadog?hl=ja) を利用する際に、[Dataflow パイプラインのオプション](https://cloud.google.com/dataflow/docs/reference/pipeline-options)と内部の[オプションパラメーター](https://cloud.google.com/dataflow/docs/guides/templates/provided/pubsub-to-datadog?hl=ja#optional-parameters)を変更することで、扱えるログの量が大幅に変化します。

以下では、ログ送信のパフォーマンスに影響するオプションについて解説します。

#### Dataflow サービスのオプション
一般的な構成である[Dataflow パイプラインのオプション](https://cloud.google.com/dataflow/docs/reference/pipeline-options)は、本テンプレートに限らず利用できるオプションですが、基本的に Datadog へのログ送信の際にはそれほど変更する必要はありません。

まず初めに考えられるオプションは、「`workerMachineType`=ワーカー VM のマシンタイプと 「`maxNumWorkers`=最大ワーカー VM 数」です。Dataflow におけるワーカー VM とは自動的に用意される Google Compute Engine(GCE) のことであり、この GCE は平均 CPU 使用率とパイプラインの並列処理に基づいてスケーリングを行います。そのため、ワーカー VM 間の並列実行を十分に発揮するためには最大ワーカー VM 数を増やし、マシンタイプは十分に**小さい**マシンタイプを選択し、[水平自動スケール](https://cloud.google.com/dataflow/docs/horizontal-autoscaling?hl=ja)の特性を活かすことが重要となります。

加えて、「`enableStreamingEngine`=Streaming Engine の有効化」[^3]も有効です。Dataflow の [**Streaming Engine**](https://cloud.google.com/dataflow/docs/streaming-engine?hl=ja) とは、複数のステップ間の中間状態をワーカー VM 外(Dataflow バックエンド)に保存し、高スケーラビリティ・低レイテンシー・高耐障害性のメリットを享受できます。さらに、ワーカー VM のリソース消費を軽減し、さらに小さいマシンタイプの選択による高コスト効率なスケーリングが期待できます。
[^3]: Pub/Sub to Datadog テンプレートは Apache Beam SDK v 2.50.0 以上を利用しており、Streming Engine の最小要件を満たしています。

これらは設定によっては<INS>必ずしもログ転送を効率化するものではありません</INS>。ワーカー VM が過剰なスペックのマシンタイプを選択している場合、<INS>ワーカー VM 低い CPU 使用率のまま過剰に水平スケールする可能性があります</INS>。これらがうまく活用されているかは、[Dataflow 自動スケーリングをモニタリングする](https://cloud.google.com/dataflow/docs/guides/autoscaling-metrics?hl=ja)ことで確認できます。

#### オプションパラメーター
本テンプレート内の **Apache Beam** 内で利用される[オプションパラメーター](https://cloud.google.com/dataflow/docs/guides/templates/provided/pubsub-to-datadog?hl=ja#optional-parameters)は、大容量のログ転送を伴う場合に変更する必要があります。「`batchCount`=イベントのバッチサイズ」と「`parallelism`=並行リクエストの最大数」はどちらもデフォルトでは共に `1` (バッチ・並列処理なし)となっています。

`batchCount` はバッチ処理で扱うログの数となるため、最大で `1000` など十分に大きな値とすることが可能です。[^4]加えて、`parallelism` はこれらの処理を並列実行する数となるため、並列実行のオーバーヘッドを考慮しワーカー VM のスケーリングに合わせて `ワーカー数 × 2` 程度の数値に収めることが賢明です。
[^4]: [Datadog Logs intake API](https://docs.datadoghq.com/api/latest/logs/#send-logs) の最大同時エントリーが　`1000`　のため、テンプレート内でも `MAX_BATCH_COUNT` は `1000` に固定されています。
[^5]: 実際の設定時にパフォーマンスが懸念される際は、Datadog の営業・サポートを通してお問い合わせください。より詳細な設定案内をご提供できる場合がございます

これらはどちらも単一ワーカー VM 内のリソース消費量(主に CPU)の増加につながるため、上記のマシンタイプの選択もこれらのパラメーターの設定に併せて行う必要があります。

![Datadog-GoogleCloud-Integration-Logs-Optimized.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/6f2230aa-4307-0deb-6ae8-1554b6c0e1af.png)

Dataflow パイプラインの中では主に、ログの読み取り・変換・書き込みが行われており、これらは上記のオプションパラメーターにより Apache Beam の特性によりバッチ・並列処理が実現されます。細かいですが、読み取り・変換ではバッチ処理は行われず、書き込み時にはバッチ処理が実行されます。

さらにこれらの処理は水平スケールした複数のワーカー VM で並列実行され、中間状態は逐次 Streaming Engine に保管されます。

:::note info
2024年12月に Google Cloud の **Cloud Architecture Center** に Datadog の公式でアーキテクチャの説明が『[Stream logs from Google Cloud to Datadog](https://cloud.google.com/architecture/partners/stream-cloud-logs-to-datadog
)』公開されました。公式の見解はこちらをご参照ください。
:::

## リソース変更収集
![Datadog-GoogleCloud-Integration-Resource-Changes.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/47a783f0-9d69-02a6-b077-a67dd00030ea.png)

:::note info
2024年12月時点で、本機能はプレビュー版(申請に応じた有効化)となっています。
:::

[Pub/Sub でアセットの変更をモニタリングする](https://cloud.google.com/asset-inventory/docs/monitor-asset-changes)ことで Google Cloud 上のリソース変更情報を Datadog に収集できます。これにより、**Datadog Event Management** 上でリソース変更イベントを管理し、重大な変更の検知を実現できます。

Datadog の [Google Cloud integration タイル](https://app.datadoghq.com/integrations/google-cloud-platform)から、[Resource Collection]タブに移動し、□[Enable Resource Collection]チェックボックスを有効化します。

Google Cloud 上では**アセットフィード**とフィードを受け取る **Pub/Sub トピック**を作成します。さらに、Google Cloud integration で用意したサービスプリンシパルに `Pub/Sub subscriber` 権限を付与します。

リソースの変更は**プロジェクト・フォルダ・組織**のレベルでフィードを通じて検知できます。フィードは対象のリソースを [Common Expression Language (CEL)](https://github.com/google/cel-spec) で制限できますが、Datadog ではすべての変更を検知するために `.*` を `asset-types` に設定することを推奨しています。

## おわりに
本記事では Dtadog Google Cloud integration の理解を深めるために**オリジナルの図**と共に最新機能を含めながら解説しました。

Datadog は専任チームと共に機能開発に力を入れており、Google Cloud integration も2023年にログ・メトリクスの収集どちらでもセットアップが改善されました。これに伴い従来から本機能をご利用の方々には変更の手間が発生しますが、本記事をご参考により良い構成を見つけていただけると幸いです🐶

特に、本機能で Dataflow を初めて触る利用者も多く、こちらはより詳細に踏み込んで解説しています。皆さんの Datadog × Google Cloud 構成の手助けとなれば嬉しいです。