3大クラウドのDatadog Integrations アーキテクチャ

## はじめに
こんにちは、AoTo(@AoTo0330)です。現在は Datadog Japan で Sales Engineer をしています。
この記事は [Datadog Advent Calendar 2022](https://qiita.com/advent-calendar/2022/datadog "Datadog Advent Calendar 2022") の8日目の記事です。

今回は、Datadog が提供している様々な Integrations のうち、Amazon Web Services(AWS)、Microsoft Azure、Google Cloud のいわゆる「3大クラウド」の Integrations がどのように実現されているかまとめてみました🐶

ここではインテグレーションの設定方法については詳しく言及しません。
設定方法をご覧になりたい方は、Datadog の公式ドキュメントをご参照ください。
 + [AWS](https://docs.datadoghq.com/ja/integrations/amazon_web_services/)
 + [Microsoft Azure](https://docs.datadoghq.com/ja/integrations/azure/)
 + [Google Cloud Platform](https://docs.datadoghq.com/ja/integrations/google_cloud_platform/)

## Datadog Integrations とは
Datadog は現在、[600以上のインテグレーション](https://docs.datadoghq.com/ja/integrations/)を提供しており、それによってシステム・アプリケーション・サービスの横断的な監視を実現しています。

ですが、そもそもこのインテグレーションとは何でしょうか？

[公式ドキュメント](https://docs.datadoghq.com/ja/getting_started/integrations/)によると…
> インテグレーションとは、最上位レベルにおいては、通常個別に検討される要素から統合されたシステムを構築することをいいます。Datadog では、インテグレーションを利用することで、インフラストラクチャーからすべてのメトリクスとログを収集して、統合システムを全体として把握することができます。1 つひとつの要素はもちろん、個々の要素が全体にどのように影響を与えているかも確認できます。

何やらいろいろと難しい説明がありますが、「インフラストラクチャーからすべてのメトリクスとログを収集」という内容がポイントのようです。

続いて文章を読み進めると、
> Datadog では、主に次の 3 種類のインテグレーションが提供されています。

と説明されています。

その「3種類のインテグレーション」とは、以下の3つです。
 + エージェントベース
 + 認証 (クローラー) ベース
 + ライブラリ

この中で、パブリッククラウドのインフラストラクチャーに対するインテグレーションは「認証 (クローラー) ベース」にあたるようです。インテグレーションと一言で言っても、思ったよりも複雑ですね…

## メトリクスの収集
さて、ここで認証ベースのインテグレーション(以下、認証ベース)について詳しく見ていきましょう。
先ほどの続きで、[公式ドキュメント](https://docs.datadoghq.com/ja/getting_started/integrations/)を見てみましょう。
> 認証 (クローラー) ベースのインテグレーションは、Datadog で設定されます。その際、API を使用してメトリクスを取得するための資格情報を指定します。これには、Slack、AWS、Azure、PagerDuty などのよく使用されるインテグレーションがあります。

この内容を整理すると、認証ベースでは Datadog 側から定期的にクラウドサービスの API にアクセスを試みて(クローリングをして)おり、アクセス先の認証サービスを利用して適切な権限を得ることでクラウド上の情報を取得している、ということです。少しずつ全容が見えてきましたね…

ということは、この認証サービスがインテグレーションとして利用されていそうです。
以上を踏まえて、クラウドインテグレーションの設定を確認すると、各クラウドサービスの認証サービスは以下の内容です。
 + [AWS Identity and Access Management (IAM)](https://aws.amazon.com/jp/iam/)
 + [Azure Active Directory](https://azure.microsoft.com/ja-jp/products/active-directory/) ([Azure AD RBAC](https://learn.microsoft.com/ja-jp/azure/active-directory/roles/custom-overview))
 + (Google Cloud) [Identity and Access Management (IAM)](https://cloud.google.com/iam?hl=ja)

ですが、ここで注意点があります。
先程、インテグレーションは「インフラストラクチャーからすべてのメトリクスとログを収集」するもの と確認しましたが、この認証ベースで取得できる情報は「メトリクス」の情報のみなんです…

## ログの収集
では「ログ」情報はどのように取得しているのでしょうか？
ここがクラウドサービス毎に異なっている点でもありますが、それぞれ以下のサービスを利用してログを Datadog へ送信しています。
 + [AWS Lambda](https://aws.amazon.com/jp/lambda/) or [Amazon Kinesis Data Firehose](https://aws.amazon.com/jp/kinesis/data-firehose/)
 + [Azure Event Hubs](https://azure.microsoft.com/ja-jp/products/event-hubs/) and [Azure Functions](https://azure.microsoft.com/ja-jp/products/functions/)
 + (Google Cloud) [Cloud Pub/Sub](https://cloud.google.com/pubsub/docs/overview?hl=ja)

これらはそれぞれ役割が異なるサービスではありますが、大量のログデータを取り込み Datadog に送信することができるという点で共通していると言えます。(Azure では [Azure Blob Storage](https://azure.microsoft.com/ja-jp/products/storage/blobs/) と [Azure App Service](https://azure.microsoft.com/ja-jp/products/app-service/) を利用する方法もありますが、ここでは割愛します)
これらのサービスを適切に設定することによって、各クラウドサービス上で収集されているログも Datadog に送信することができるという訳です…！

## AWS のアーキテクチャ
以上の内容を踏まえて、AWS ではどのようなリソースが展開され、インテグレーションが実現されているのか、そのアーキテクチャを見てみましょう。

![AWS-Datadog-Integration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/8b947932-90ae-9f78-c736-278624b1bcb8.png)

:::note info
取得できる情報は AWS アカウント単位です。
:::

メトリクスはDatadog のクローラーが定期的にポーリングを行い、IAM role で得た権限を利用して、CloudWatch Metrics を CloudWatch API 経由で取得します。CloudWatch Metrics Streams と Kinesis Data Firehose を活用することで、より低レイテンシーのメトリクス収集も可能です。

ログはCloudWatch Logs のロググループを Datadog Forwarder 用の Lambda Functions でサブスクライブし、Datadog へ転送します。他にも、ログを格納した S3 バケットをサブスクライブしたり、Kinesis Data Firehose 配信ストリームを利用することでログを転送する方法もあります。

## Azure のアーキテクチャ
同様に、Azure の場合はこのようなリソースとアーキテクチャになります。

![Azure-Datadog-Integration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/977e5e96-1543-5452-a733-bd02a11c099a.png)

:::note info
取得できる情報は Azure サブスクリプション単位です。
:::

メトリクスはDatadog のクローラーが定期的にポーリングを行い、Azure AD RBAC のサービスプリンシパルで得た権限を利用して、Monitor Metrics を Azure Monitor metrics REST API 経由で取得します。

ログは Monitor Logs に対して診断設定を作成することで、Event Hubs へログをストリーミングし、それをトリガーとした Function Apps によって Datadog へログが転送されます。ログはアクティビティログとリソースログの両方に対して診断設定を作成する必要があります。

## Google Cloud のアーキテクチャ
そして、Google Cloud ではこのようなリソースとアーキテクチャです。

![GoogleCloud-Datadog-Integration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/a97cd3af-a50e-02cb-3b08-3d48eca47742.png)

:::note info
取得できる情報は Google Cloud プロジェクト単位です。
:::

メトリクスはDatadog のクローラーが定期的にポーリングを行い、IAM のサービスアカウントで得た権限を利用して、Cloud Monitoring Metrics を Cloud Monitoring API 経由で取得します。また、図には示していませんが、Cloud Billing API、Compute Engine API、Cloud Asset API に対しても同様に情報を取得することができます。

ログは Cloud Logging でエクスポート先を Cloud Pub/Sub に指定したログシンクを作成することで、Cloud Pub/Sub が Datadog へログをプッシュすることができます。

## Datadog 側のしくみ
### Datadog API
今回の記事では説明を省略しましたが、Datadog のクラウドサービスインテグレーションでは [Datadog API](https://docs.datadoghq.com/ja/api/latest/) が直接利用されています。

Datadog API は HTTP REST API を採用しています。どの Datadog Organization に情報を登録するかや、取得した情報が Datadog のサービスからアクセスできるかは、[API キーやアプリケーションキー](https://docs.datadoghq.com/ja/account_management/api-app-keys/#api-keys)を利用して Datadog 側で認証・認可が行わています。

### Datadog サイト
Datadog には、世界中に[さまざまなサイト](https://docs.datadoghq.com/ja/getting_started/site/)が用意されています。
図上では、監視するシステムと同一のクラウド上に Datadog Organization がある想定で描きましたが、これはサイトを指定することで実現可能です。

:::note info
サイトによって、提供されているサービスが異なる場合があります
:::

Datadog 側のしくみについてもご興味があれば、是非目を通してみてください！

## おわりに
この記事では Datadog Integraions の中でも3大クラウドのインテグレーションを利用すると、クラウド上でどのようなリソースが展開・構成されているかに注目してみました。

普段は意識しないインテグレーションの仕組みを考えることで、クラウドサービスによるアーキテクチャの違いについても知るきっかけとなればと思います。そして、インテグレーションを利用する際のブラックボックス化の解消になれば幸いです。

最後に、ここまで説明はしましたが Datadog Integrations 自体は Datadog のサポート範囲となっています。トラブルが起きた際には [Datadog のサポート](https://www.datadoghq.com/ja/support/)を利用できるので、もし不明な点があれば是非ご利用ください。