はじめに

はじめまして。グループ経営ソリューション事業部の三谷です。
この記事では、電通総研で監視ツールとして利用しているDatadogについてどのようなサービスなのか基本的な情報と、導入手順をまとめた記事になります。

Datadogとは

Datadog は、クラウドやコンテナ環境向けの「監視・可観測性プラットフォーム」です。
サーバ・コンテナ・ミドルウェア・アプリケーション・クラウドサービスからデータを集めて、1 つの画面で横断的に可視化・分析できる SaaS 型のサービスです。

Datadog が扱う主なデータは次の 4 種類に整理できます。

メトリクス
CPU 使用率、メモリ使用量、ディスク I/O、リクエスト数、レイテンシなどの時系列データ。
ログ
アプリケーションログ、アクセスログ、システムログ、ミドルウェアログなど。
トレース (APM)
1リクエストがどのサービス・コンテナを通過したか、その経路と各区間のレイテンシ。
つまり、アプリケーションの動作をトレースして、どこで遅延やエラーが発生しているかをDatadogから調査が可能です。
イベント
デプロイ、スケールアウト/イン、障害、設定変更などの「出来事」を表す情報。

私は今まで、監視は主にCloudWatchを利用していました。CloudWatchだと、AWSアカウントを跨いだ一元監視が難しく「ほかのAWSアカウントではどうなっているんだっけ・・・」と調査のために比較したいとき、AWSアカウントを切り替えながら確認が必要で非常に手間がかかっていました。
Datadogではその問題は発生せず、複数のAWSアカウントのデータを一目で確認することができます。

Datadogでなにができるか（どのように監視するか）

Datadog による監視の全体像は、大きく分けて4つの段階があります。

1. データを集める

Agent による収集

監視対象のサーバやコンテナにDatadog Agentを導入すると、標準で次の情報を収集できます。

OS レベルのメトリクス
CPU、メモリ、ディスク、ネットワーク I/O など
コンテナメトリクス
コンテナごとの CPU / メモリ / ネットワーク利用状況
ミドルウェアメトリクス
nginx, Redis, PostgreSQL, MySQL などの各種インテグレーションを通じたメトリクス

ログ・トレースの収集

Datadog はログ・トレースも一元的に扱えます。
ログの収集の例として下記の構成があります。

Datadog Agentでのログ収集
CloudWatch Logsや FireLens + Fluent Bit でのログ収集
それを Datadog に転送して保存・検索・解析

2. タグで関連づける

Datadog では、すべてのメトリクス・ログ・トレース・イベントをタグで管理しています。
タグ設計が監視の品質を左右する、重要な設計要素になります。
たとえば、以下の調査を行いたい場合、Datadogだけで調査が完結します。

「ECSの特定タスクで500エラーが増えたタイミングで、CPU・メモリ利用率はどうだったか」
「その直前にデプロイやスケールイベントは発生していなかったか」
「どのリリースバージョンからエラー率が上がっているか」

代表的なタグ（例）：

環境別env:prod, env:staging, env:dev
サービス別service:my-api, service:batch-worker
クラスター別cluster:my-ecs-cluster

3. 可視化・分析する

収集したデータはDatadogのコンソール上でダッシュボードを作成することが可能です。

ダッシュボードでの管理例

ECS / Fargate 向けの標準ダッシュボードを作る
- クラスタ全体の CPU / メモリ使用率
- サービスごとの runningタスク数
カスタムダッシュボード
- 本番環境env:prod に特化したダッシュボードを作る
  - リクエスト数
  - エラー率
  - CPU / メモリ使用率

4. モニター（アラート）で通知する

可視化して満足していても意味がないので、閾値や条件を定義して必要な通知を行う必要があります。Datadogではモニターと呼ぶ機能がこれに該当します。

代表的なモニターの例（ECS タスクの場合）

ECS サービスのタスク数監視
- 条件例:
  running_tasks < desired_tasks が 5 分以上継続したらアラート
エラー率監視
- 条件例:
  service:my-api AND env:prod の 5xx 発生率が一定以上でアラート

通知先

各種ツールへの通知が可能です。なおJiraと連携することで、Datadogにてアラート発生時にJiraのチケットを自動起票することも可能です。
https://www.atlassian.com/ja/devops/observability-tutorials/jira-datadog-integration
社内でJira自動起票について少し検討したことがありました。便利ではあるものの、長時間アラートが出た場合連続して同じチケットが起票されるのでは等、導入における考慮すべき点が多く、導入は一旦ステイとなりました。
また、オンコールについてもDatadog On-Callというサービスが存在しており一元管理することが可能です。
https://docs.datadoghq.com/ja/service_management/on-call/

ECSサービスの監視を実際にやってみる

Datadogの基本的な機能が分かったところで、今回はDatadog Agentを導入してECSサービスの監視を行いたいと思います。

前提条件

AWSアカウントを持っていること
Datadogアカウントを作成済みであること
DatadogのAPIキーを取得済みであること
Datadog AgentとDatadogが通信可能であること
- Datadogは収集するデータによって使用するポートが異なります。今回利用するAgentはTCP/443を使用します。
- 詳細はDatadogのドキュメントをご確認ください。https://docs.datadoghq.com/ja/agent/configuration/network/

AWSでの作業

タスク定義の作成

まず、ECSで使用するタスク定義を作成します。

今回のタスク定義では、以下の2つのコンテナを設定しました。

Datadog Agentコンテナ
- イメージURI: public.ecr.aws/datadog/agent:latest
Apacheコンテナ
- イメージURI: public.ecr.aws/docker/library/httpd:latest

※今回はECRのパブリックイメージを使用しました。

Datadogでの監視を有効化するため、Datadog Agentコンテナに以下の環境変数を設定します。

DD_API_KEY: DatadogのAPIキー
DD_SITE: Datadogのサイト（例: datadoghq.com）
ECS_FARGATE: true

クラスターの作成

次に、ECSクラスターを作成します。

任意のクラスター名を入力し、その他デフォルトの設定で作成します。

サービスの作成

作成したクラスター上でサービスを起動します。

サービス作成時の設定項目：

タスク定義ファミリー: 先ほど作成したタスク定義を選択
環境: 「起動タイプ」を選択
ネットワーキング:
- VPCを選択
- サブネットを選択
- 適切なセキュリティグループを選択
  （添付画像は入力前のものです）
その他の項目はデフォルトのまま作成

サービスが正常に開始すると上図のようになります。

Datadogコンソールでの確認

監視を開始するためにDatadog側で必要な作業はほぼありません。APIキーさえ用意できれば、Agent導入後すぐに監視が始まります。
AWSマネジメントコンソールからサービス起動は確認できたので、Datadogからも確認してみます。
DatadogコンソールにてInfrastructure→Containers→ECS Explorerから起動したサービスが確認できます。