はじめに

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

この投稿は AoTo Advent Calendar 2023 23日目の記事です。

Google Cloud Next Tokyo ’23 にて「Datadog で GKE とマネージドサービスを効率的に運用する方法」というタイトルで Datadog のスポンサーセッションを担当させていただきました。

Google Cloud の公式からも期間限定でアーカイブ動画が公開されています。

この記事ではその内容を振り返るとともに、細かい部分の解説をします。資料はこちらから確認できます。

Kubernetes の監視と課題

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

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

さらに Kubernetes 全体のコンポーネントについても触れ、それらを管理するコントロールプレーンモニタリングの重要性についても触れています。Datadog ではコントロールプレーンの4つのコンポーネント全てから主要なメトリクスを収集する、コントロールプレーンモニタリングを提供しています。

ここで、Kubernetes やその上のアプリケーションコンテナの監視を行う上で重要となるのが　Kubernetes のラベルとセレクターです。アプリケーションに問題が起きた時に、そのアプリケーションが何なのか・誰が管理しているのか・どこで実行されていたかなどの情報を把握するためにもラベルやセレクターが有効活用できます。

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

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

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

GKE の特徴と監視方法

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

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

コントロールプレーンは必ず Google Cloud が管理するため、コントロールプレーンのメトリクスやログは Google Cloud の設定により収集することができます。

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

Google Cloud によるユーザーポッド監視

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

GKE Dataplane V2 Observability は Cilium を利用した次世代のデータプレーンを使用して実装された GKE Dataplane V2 で利用できる機能です。これにより、前述の基本的なログ・メトリクスに加えてクラスタ内のトラフィックフローや Kubernetes のネットワークポリシーなどを監視できます。これを可視化するために、Google Cloud Managed Service for Prometheus(GMP) や Hubble UI・Grafana などのオープンソースのソリューションを利用します。

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

Datadog によるによるユーザーポッド監視

Datadog は単一の Datadog Agent による様々な機能を用いて、Kubernetes の監視を実現できます。Datadog Agent を Kubernetes に実装する際も、Helm や Operator などを利用してシンプルなステップでデプロイを実行することができます。

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

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

マネージドサービスの監視

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

Google Cloud 特有の運命共有モデルの考え方に触れながら、マネージドサービスの定義について再確認しました。Google Cloud におけるマネージドサービスは責任・運命共有モデルにおける PaaS/SaaS に当たります。

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

Datadog で運用する方法

Datadog で運用する方法として、Datadog の Google Cloud integration について説明をしました。Google Cloud integration ではメトリクスの収集とログの収集をそれぞれ行うことができ、それぞれ異なる方法で監視テレメトリデータの収集が行われます。

インテグレーションのアーキテクチャについてもご紹介しました。これは昨年私が執筆した『3大クラウドのDatadog Integrations アーキテクチャ』から引用しています。

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

Helm で Datadog Agent をインストール

#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

さらに、Google Cloud 上で利用できる Datadog との連携機能について触れています。Google Cloud の Eventarc はイベントのトリガー元として 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日にはこのケーススタディを含めたウェビナーを開催しました。

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

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

おわりに

個人的には、昨年に引き続き Google Cloud Partner Top Engineer に選出いただいたことで、より一層 Google Cloud と Datadog のパートナーソリューションをより広めていくためにも活動を続けていきます。
それだけではなく、純粋な Google Cloud と Datadog それぞれのソリューションの面白さを皆さんにお伝えすることができれば嬉しいです。

AoTo Advent Calendar 2023 でも『Datadog DBM で AlloyDB を監視する』という非公式の機能検証も行っています。ご興味があれば是非ご覧ください！