【Google Cloud Next Tokyo ’23】Datadog で GKE とマネージドサービスを効率的に運用する方法【Datadog】

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

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

[**Google Cloud Next Tokyo ’23**](https://cloudonair.withgoogle.com/events/next-tokyo) にて「**Datadog で GKE とマネージドサービスを効率的に運用する方法**」というタイトルで **Datadog のスポンサーセッション**を担当させていただきました。

https://cloudonair.withgoogle.com/events/next-tokyo/watch?talk=d2-pl-10

:::note info
Google Cloud の公式からも期間限定で[アーカイブ動画](https://youtu.be/agA9nBZUEu4)が公開されています。
:::

この記事ではその内容を振り返るとともに、細かい部分の解説をします。資料は[こちら](https://speakerdeck.com/aoto/how-to-efficiently-run-gke-and-managed-services-with-datadog)から確認できます。

https://speakerdeck.com/aoto/how-to-efficiently-run-gke-and-managed-services-with-datadog

## Kubernetes の監視と課題
まず初めに、Google Kubernetes Engine(GKE) の前に **Kubernetes 全般の監視と課題**について触れています。

![監視すべきコンポーネントの増加.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/5546a148-e9d4-7ca3-7c00-8b332480d3fd.png)

端的にまとめると、従来の VM や物理ホストの監視、Docker などのコンテナ仮想化の監視と比べてオーケストレーションとして Kubernetes の機能が増えることによって、それ自体を監視する必要が出てきます。


さらに [Kubernetes 全体のコンポーネント](https://kubernetes.io/docs/concepts/overview/components/)についても触れ、それらを管理する[コントロールプレーンモニタリング](https://docs.datadoghq.com/ja/containers/kubernetes/control_plane/?)の重要性についても触れています。Datadog ではコントロールプレーンの4つのコンポーネント全てから主要なメトリクスを収集する、[コントロールプレーンモニタリング](https://docs.datadoghq.com/ja/containers/kubernetes/control_plane/?)を提供しています。

ここで、Kubernetes やその上のアプリケーションコンテナの監視を行う上で重要となるのが　[**Kubernetes のラベルとセレクター**](https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/labels/)です。アプリケーションに問題が起きた時に、そのアプリケーションが何なのか・誰が管理しているのか・どこで実行されていたかなどの情報を把握するためにも**ラベルやセレクター**が有効活用できます。

メトリクス・ログ・トレースなどの監視情報にメタデータのラベル・タグとして、**Kubernetes のラベルとセレクター**のようなキーと値のペアを付与しすることで監視情報を識別するのに役立てられます。

![Kubernetes の監視.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/8a0ffe82-a5d6-b30d-7d37-a44319b752e6.png)

最後に、Kubernetes の『[監視、ログ、デバッグ](https://kubernetes.io/ja/docs/tasks/debug/)』ページからアプリケーション(アプリケーション・コンテナ)・クラスター(ホスト)の監視ポイントについて、引用しまとめています。

https://www.datadoghq.com/ja/blog/monitoring-kubernetes-era/

Datadog の公式ブログでも Kubernetes における監視のポイントをまとめた内容があるので、是非ご覧ください。

## GKE の特徴と監視方法
続いて **Google Kubernetes Engine(GKE)** の特徴に触れて、GKE 特有の監視方法についてまとめました。

![GKE の概要.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/124b75e1-239f-e8e8-09e0-82e79b3b7f4c.png)

GKE は Google Cloud のマネージドの Kubernetes のため、Kubernetes をそのまま適用できない部分があります。GKE ではノードとして意識せずに Google Compute Engine(GCE) が起動し Kubernetes コンポーネントが用意されます。この時、Standart/Autopilot モードによってワーカーノードの管理責任が利用者か Google Cloud かが変わります。

コントロールプレーンは必ず Google Cloud が管理するため、コントロールプレーンの[メトリクス](https://cloud.google.com/kubernetes-engine/docs/how-to/configure-metrics#control-plane-metrics)や[ログ](https://cloud.google.com/kubernetes-engine/docs/how-to/view-logs#control_plane_logs)は Google Cloud の設定により収集することができます。

![GKE のアーキテクチャ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/6bf97bb8-8127-8044-fc9f-e126b3d26fda.png)

しかし、ここで重要なのがどのような場合であっても、ワーカーノード上のユーザーポッドは必ず利用者が管理する必要があります。この監視の方法として、監視エージェントをノードにインストールして詳細な情報を取得する手法です。このセッションでは Google Cloud ネイティブな方法と Datadog を利用する方法に触れています。

### Google Cloud による ユーザーポッド監視
![Google Cloud Managed Observability①.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/df0be617-9fe8-c969-615e-da2e9fe283cd.png)

[**Observability for GKE**](https://cloud.google.com/kubernetes-engine/docs/concepts/observability) は全ての GKE ユーザーにデフォルトで実装されるソリューションです。GKE クラスタの作成時に Cloud Logging/Monitoring が有効化され基本的なログ・メトリクスが収集されます。この時、裏側では GKE ノードに専用のエージェントがデプロイされます。このエージェントは [Fluent Bit](https://fluentbit.io/) によるログ収集と [Prometheus](https://prometheus.io/) 形式のメトリクスを提供します。

![Google Cloud Managed Observability②.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/98b6f340-2888-c1e6-1480-30ea6ebe15aa.png)

[**GKE Dataplane V2 Observability**](https://cloud.google.com/kubernetes-engine/docs/concepts/about-dpv2-observability) は Cilium を利用した次世代のデータプレーンを使用して実装された [**GKE Dataplane V2**](https://cloud.google.com/kubernetes-engine/docs/concepts/dataplane-v2) で利用できる機能です。これにより、前述の基本的なログ・メトリクスに加えてクラスタ内のトラフィックフローや Kubernetes のネットワークポリシーなどを監視できます。これを可視化するために、[Google Cloud Managed Service for Prometheus(GMP)](https://cloud.google.com/stackdriver/docs/managed-prometheus) や [Hubble UI](https://docs.cilium.io/en/latest/gettingstarted/hubble/)・[Grafana](https://grafana.com/) などのオープンソースのソリューションを利用します。

このように、Google Cloud で提供されている GKE の Observability はオープンソースベースの技術を複数組み合わせることで実現できるような仕組みになっています。

### Datadog による による ユーザーポッド監視
Datadog は単一の Datadog Agent による様々な機能を用いて、Kubernetes の監視を実現できます。Datadog Agent を Kubernetes に実装する際も、[**Helm**](https://helm.sh/) や [**Operator**](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) などを利用してシンプルなステップでデプロイを実行することができます。

![Datadog Agent for GKE.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/f5367ef3-2543-4397-64b2-b4f2a3319db8.png)

Datadog Agent は<INS>それ単体でプロセス単位の監視やアプリケーションのトレースなどを収集</INS>できます。さらに、前述の実装方法は GKE に限らず<INS>共通した方法で他のプラットフォームにも適用</INS>できます。さらに、Datadog に収集したデータは <INS>Datadog による強力な可視化機能や監視テレメトリデータの紐付け</INS>により、Obesrvability のベストプラクティスを実現できます。

Datadog Agent の機能や種類については、昨日のブログでも触れているため、是非ご覧ください🐶

https://qiita.com/AoTo0330/items/5125e468232c0196d916

## マネージドサービスの監視
GKE に限らないマネージドサービス自体も Datadog で監視することの重要性に触れています。

![Google Cloud の責任・運命共有モデル.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/b1dd28bf-a04a-eb9b-286a-1af983d1edc1.png)

Google Cloud 特有の[**運命共有モデル**](https://cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate)の考え方に触れながら、マネージドサービスの定義について再確認しました。Google Cloud におけるマネージドサービスは責任・運命共有モデルにおける PaaS/SaaS に当たります。

![マネージドサービスの監視.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/b59008cb-7dfb-eb80-0d7d-8b31926655dd.png)

こうしたマネージドサービスのうち、Google Cloud の管理範囲であるプラットフォーム側の監視テレメトリデータであるメトリクスやログは、Cloud Logging/Monitoring へ収集できるようになっています。このような Google Cloud の監視テレメトリデータを集約できることも、Datadog の大きな特徴です。

## Datadog で運用する方法
![Google Cloud Integration How-to.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/23c4a332-c421-b606-dffa-b3033af37c5a.png)

Datadog で運用する方法として、Datadog の [Google Cloud integration](https://docs.datadoghq.com/ja/integrations/google_cloud_platform/) について説明をしました。[Google Cloud integration](https://docs.datadoghq.com/ja/integrations/google_cloud_platform/) ではメトリクスの収集とログの収集をそれぞれ行うことができ、それぞれ異なる方法で監視テレメトリデータの収集が行われます。

![Google Cloud Integration Architecture.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/2a63a782-8e5e-6b01-709d-16a9306e5179.png)

インテグレーションのアーキテクチャについてもご紹介しました。これは昨年私が執筆した『[3大クラウドのDatadog Integrations アーキテクチャ](https://qiita.com/AoTo0330/items/545a229fd33d92c01562)』から引用しています。

https://qiita.com/AoTo0330/items/545a229fd33d92c01562

さらに、GKE に対する Datadog Agent の Helm を利用したインストール方法についても触れています。こちらは前ん術の通り、GKE に限らずさまざまなプラットフォーム上の Kubernetes 全般に対して適用可能です。

<details><summary>Helm で Datadog Agent をインストール</summary>

```zsh
#Helm リポジトリに Datadog リポジトリ を追加し、更新
$ helm repo add datadog https://helm.datadoghq.com
$ helm repo update

#GKE に Datadog Agent, Datadog Cluster Agent のデプロイ(values.yaml を使用しない場合)
$ helm install <RELEASE_NAME> \
    --set datadog.apiKey=<DATADOG_API_KEY> \
    --set datadog.appKey=<DATADOG_APP_KEY> \
    --set clusterAgent.enabled=true \
    --set clusterAgent.metricsProvider.enabled=true \
    --set datadog.logs.enabled=true \
    --set datadog.apm.enabled=true \
    datadog/datadog

```

</details>

![Datadog Integration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/c7272a3e-370b-b68f-5a89-0c5a3963f9bf.png)
![Datadog Integration2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/d8a5772b-7973-5e48-9f62-b37f15a4a985.png)

さらに、Google Cloud 上で利用できる Datadog との連携機能について触れています。Google Cloud の [Eventarc](https://cloud.google.com/eventarc/docs) はイベントのトリガー元として Datadog Monitor による通知を設定できるため、Datadog によるあらゆる監視データを元にしたイベントのアクションが可能です。


## 裏話
Google Cloud Next Tokyo では、イベントの開催前に CfP が公開されていました。セッションの募集はブレイクアウトセッションの40分で私は Cloud Run と Observability 関連のセッションの応募をしていましたが、今回の登壇は叶いませんでした。

そんな時、Datadog は Google Cloud Next Tokyo ’23 のスポンサーとしてセッション枠があったため、Datadog を代表してお話しすることとなりました。今回のセッションはこうした中で、さまざまな聴衆を想定して特にモダンなアーキテクチャを Google Cloud で採用されている場合での Datadog のソリューションの親和性についてまとめました。

この裏側のロールモデルとして、PLAID 様の「KARTE」のアーキテクチャがあります。
実は、今回お話しした内容のほとんどは「KARTE」で実際に運用されている Google Cloud と Datadog の環境のお話で、2023年11月28日にはこのケーススタディを含めた[ウェビナー](https://www.datadoghq.com/ja/event/gcpjapan/
)を開催しました。

https://www.datadoghq.com/ja/event/gcpjapan/

このウェビナーのアーカイブは公開されていませんが、[PLAID Engineer Blog](https://tech.plaid.co.jp/) では Google Cloud や Datadog に関連する実際の活用方法についてさまざまなトピックで記事を掲載されています。

https://tech.plaid.co.jp/aws_gcp_multicloud_3

https://tech.plaid.co.jp/datadog_sensitive_data_detection

https://tech.plaid.co.jp/datadog_admin_performance_monitoring

さらに PLAID 様は Datadog と Google Cloud の事例としても紹介されているので、興味があれば是非ご覧ください。

https://www.datadoghq.com/ja/case-studies/plaid/

https://cloud.google.com/blog/ja/topics/customers/plaid-anthos-clusters-on-aws

## おわりに
個人的には、昨年に引き続き [**Google Cloud Partner Top Engineer**](https://cloud.google.com/blog/ja/topics/partners/partner-top-engineer-2024-award-winners?hl=ja) に選出いただいたことで、より一層 Google Cloud と Datadog のパートナーソリューションをより広めていくためにも活動を続けていきます。
それだけではなく、純粋な Google Cloud と Datadog それぞれのソリューションの面白さを皆さんにお伝えすることができれば嬉しいです。

**[<font color="#6495ED">AoTo Advent Calendar 2023</font>](https://qiita.com/advent-calendar/2023/aoto)** でも『[Datadog DBM で AlloyDB を監視する](https://qiita.com/AoTo0330/items/298fe7dadea7a0be4c5d)』という**非公式の機能検証**も行っています。ご興味があれば是非ご覧ください！

https://qiita.com/AoTo0330/items/298fe7dadea7a0be4c5d