Datadog integrations Deep Dive - Google Cloud 編

はじめに

こんにちは、Datadog Japan で Sales Engineer をしている AoTo です。

本記事は『【完全解説】4大クラウドの Datadog integrations アーキテクチャ【2024年版】』で解説仕切れなかった、Datadog Google Cloud integration の細かな仕様と注意点を解説します。

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

Google Cloud integration の全体像

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

Google Cloud integration のネットワーク接続

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

これは、Pub/Sub のコントロールプレーンの仕様と Dataflow ワーカー(GCE) にデフォルトで適用される Network Service Teir によって推察できますが、必ずしも保証されません。

Google Cloud Private Service Connect 経由で Datadog に接続オプションにより、プライベート IP しか持たない Dataflow を用意することでは明示的にプライベートネットワークを介した通信を強制できます。

プライベート IP しか持たない Dataflow を用意する方法は公式には案内はありませんが、『Datadog に Google Cloud のログをセキュアに送信する』で詳しく解説しています。

メトリクス収集

改善されたセットアップ

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

2023年以前は、サービスアカウントを権限として利用するためにサービスアカウントキーを利用していました。そのため、インテグレーションのためにサービスアカウントキーの作成と Datadog へのアップロードが必要でした。

「サービスアカウントキーからの移行」ガイドのように、サービスアカウントキーの利用は Google Cloud でも推奨されておらずいません。キーを利用する場合は、ユーザーは常にキーの漏洩に対処する必要があります。

この変更により、サービスアカウントキーの利用からサービスアカウントの権限借用によりインテグレーションを完了できるようになり、現在はよりセキュア・簡単にセットアップを完了できます。

2023年以前にサービスアカウントキーでのセットアップを行なったユーザーは、サービスアカウントの権限借用に移行することが推奨されています。
古い方式でセットアップを行なっている場合は、Google Cloud integration タイル上では対象の設定に Legacy と上部に以下の文章が表示されます。

Recommended Update
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 をはじめとする権限リソースがプロジェクト内で管理されるリソースではないためです。

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

収集メトリクスの除外・制限

メトリクスの連携が不要な場合は名前空間やリソース・リビジョンタグに基づく除外ができます。

Datadog の Google Cloud integration タイルから、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 インテグレーションの請求」ガイドを併せてご参照ください。¹

ログ収集

• 推奨構成
  

• 非推奨構成
  

2024年12月に Datadog の公式情報として Google Cloud のクラウドアーキテクチャセンターに『Stream logs from Google Cloud to Datadog』が公開されました。こちらも合わせてご確認ください。

Pub/Sub サブスクリプション方式の変更

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

従来のプッシュサブスクリプションは Pub/Sub トピックから直接 Datadog Logs inteke API にログを送りつける方式です。設定の簡便さの一方で、ネットワークや Datadog API の問題でログの転送が失敗した際にログが失われることや、プライベートネットワークでのログの転送ができないことなどの問題を抱えていました。

この問題に対し、プルサブスクリプションと Dataflow を利用することで、ログの圧縮・再送・暗号化をした上での送信が可能となりました。さらに、Dataflow ワーカーをプライベート IP のみで稼働し、Private Service Connect を介することでプライベートネットワークのみを経由したセキュアなログ送信が可能となりました。

現在も非推奨構成のドキュメントは公開されていますが、これはトラブルシューティングやレガシーセットアップの変更のためにのみ残されており、サポートは提供されません。
また、非推奨構成は近い将来に廃止される予定のため、こちらも推奨構成への移行が推奨されています。

Dataflow パイプラインの調整

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

Datadog は Pub/Sub to Datadog Dataflow テンプレートを公開しています。このテンプレートは主に Apache Beam Java SDK 2.50.0² で書かれており、Dataflow のさまざまなオプションを利用することができます。

Pub/Sub to Datadog を利用する際に、Dataflow パイプラインのオプションと内部のオプションパラメーターを変更することで、扱えるログの量が大幅に変化します。

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

Dataflow サービスのオプション

一般的な構成であるDataflow パイプラインのオプションは、本テンプレートに限らず利用できるオプションですが、基本的に Datadog へのログ送信の際にはそれほど変更する必要はありません。

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

加えて、「enableStreamingEngine=Streaming Engine の有効化」³も有効です。Dataflow の Streaming Engine とは、複数のステップ間の中間状態をワーカー VM 外(Dataflow バックエンド)に保存し、高スケーラビリティ・低レイテンシー・高耐障害性のメリットを享受できます。さらに、ワーカー VM のリソース消費を軽減し、さらに小さいマシンタイプの選択による高コスト効率なスケーリングが期待できます。

これらは設定によっては必ずしもログ転送を効率化するものではありません。ワーカー VM が過剰なスペックのマシンタイプを選択している場合、ワーカー VM 低い CPU 使用率のまま過剰に水平スケールする可能性があります。これらがうまく活用されているかは、Dataflow 自動スケーリングをモニタリングすることで確認できます。

オプションパラメーター

本テンプレート内の Apache Beam 内で利用されるオプションパラメーターは、大容量のログ転送を伴う場合に変更する必要があります。「batchCount=イベントのバッチサイズ」と「parallelism=並行リクエストの最大数」はどちらもデフォルトでは共に 1 (バッチ・並列処理なし)となっています。

batchCount はバッチ処理で扱うログの数となるため、最大で　1000　など十分に大きな値とすることが可能です。⁴加えて、parallelism はこれらの処理を並列実行する数となるため、並列実行のオーバーヘッドを考慮すると 5~10 程度の数値に収めることが賢明です。

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

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

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

リソース変更収集

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

Pub/Sub でアセットの変更をモニタリングすることで Google Cloud 上のリソース変更情報を Datadog に収集できます。これにより、Datadog Event Management 上でリソース変更イベントを管理し、重大な変更の検知を実現できます。

Datadog の Google Cloud integration タイルから、[Resource Collection]タブに移動し、□[Enable Resource Collection]チェックボックスを有効化します。

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

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

おわりに

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

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

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

1. 一部、説明が古い可能があります ↩

2. 2024年12月時点。GitHub GoogleCloud Platform/DataflowTemplates リポジトリ より確認 ↩

3. Pub/Sub to Datadog テンプレートは Apache Beam SDK v 2.50.0 以上を利用しており、Streming Engine の最小要件を満たしています。 ↩

4. Datadog Logs intake API の最大同時エントリーが　1000　のため、テンプレート内でも MAX_BATCH_COUNT は 1000 に固定されています。 ↩