「Datadogを見ればすべてがわかる」状態を作っていく

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

レビュー投稿日の情報になります

株式会社グロービス / Jutaro Numata

チームリーダー / SRE / 従業員規模: 501名〜1,000名 / エンジニア組織: 101名〜300名

最終更新日2024/09/09投稿日2024/09/09

利用プラン

利用機能

ツールの利用規模

ツールの利用開始時期

事業形態

Pro

メトリクス、ログ（アーカイブ）、Synthetics、SLO、APM、RUMなど

11名〜50名

2020年4月

B to B

B to C

利用プラン	Pro
利用機能	メトリクス、ログ（アーカイブ）、Synthetics、SLO、APM、RUMなど
ツールの利用規模	11名〜50名
ツールの利用開始時期	2020年4月
事業形態	B to B B to C

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

EC2を基軸としたインフラ環境から、Kubernetes（EKS）を基軸としたインフラ環境への移行を検討していました。そのなかで、従来利用していた監視ツールでは、コンテナに特化した監視機能が不十分ではないかという課題が浮かび、監視ツールの再考を始めました。

どのような状態を目指していたか

EKSへの環境移行は数年に渡るため、コンテナのみならず、EC2の従来環境も含めて、1つのツールがワンストップで監視を担える状態を考えていました。

比較検討したサービス

Mackerel
Amazon CloudWatch Container Insights（コンテナ監視のみ）
Amazon Elasticsearch Service（ログ保存のみ）
Prometheus（OSS）

比較した軸

以下の点を重視していました。

コンテナ（Kubernetes、EKS）、サーバOS（EC2）それぞれに適した監視が可能であること
費用が妥当であること
マルチプロダクト運用を行っているため、プロダクトごとにログなどを分離して収集できること
ログやメトリクスなど、複数の指標を横断的に確認できること
Infrastructure as Codeでの設定管理が可能であること

選定理由

非常に多機能なSaaSであり、ログ監視やメトリクス監視といった機能ごとに複数のツールを使い分けることなく、Datadogだけであらゆる監視をまかなえそうだというイメージを持てたことが一番の決め手となりました。

また、先述した「重要視していた点」もそれぞれ満たすことができました。

コンテナ（Kubernetes、EKS）、サーバOS（EC2）それぞれに適した監視が可能であること
- Kubernetes向けの Helm Chart が用意されている。
- AWSとのIntegration機能があり、各AWSサービスに適した監視を行うことができる。
費用が妥当であること
- 極めて安価というわけではないが、サーバ1ホストあたり15コンテナまで無料（当時）であったり、ボリュームディスカウントが存在するなど、妥当な金額設定と判断した。
マルチプロダクト運用を行っているため、プロダクトごとにログなどを分離して収集できること
- Organization で名前空間を分離したり、 RBAC でアクセス制御したりできる。
ログやメトリクスなど、複数の指標を横断的に確認できること
- アラート発生時に、その時間帯のログやメトリクスを簡単に追跡できる。
Infrastructure as Codeでの設定管理が可能であること
- Datadog社公式の Terraform Provider が用意されている。

導入の成果

改善したかった課題はどれくらい解決されたか

EC2、EKSなど環境の差異を気にせず、ログやメトリクスはすべてDatadogに収集される形をつくることができ、導入時の目的を果たすことができました。

どのような成果が得られたか

従来はメトリクスの監視、ログによるアラート、ログの閲覧、ログの長期間保存など、それぞれ別々のツールを利用していたのですが、Datadogはこれらすべての機能を有しているため、1つのツールで一貫した運用ができるようになりました。トラブルの際などは、プロダクトや構成を問わず、まずはDatadogを見ればよい、という状態になっていき、運用負荷が軽減できました。また、いわゆるオブザーバビリティの向上に寄与するRUMやAPMといった機能も充実しているため、プロダクト開発チームでの活用も広がっていきました。

導入時の苦労・悩み

Agentの設定項目が多岐に渡り、適切な設定を理解しながら導入するのが難しい。
AWSからのログの取り込み方法が、AWS Lambdaを利用する場合、Amazon Data Firehoseを利用する場合など複数存在しており、サービスによって使い分けなければならない。
初期状態では、1つのUI上であらゆるすべてのログが表示されるため、適切なフィルタリング設定などに慣れるまでは活用しづらい。
Terraform Resourceで定義する各種設定値が、GUI上ではどこで設定されているのかわかりづらい場合がある。

導入に向けた社内への説明

上長・チームへの説明

チームリーダーも含めて、チーム全員でツールの検証と議論を行いながら導入を進めており、改めて導入のための説明や提案プロセスは発生していません。

先述の各ツールの機能や費用などを比較するなかで、全員一致でDatadogの採用がよいという結論に至りました。

活用方法

SREチームが全体管理を行いつつ、各プロダクト開発チームにもユーザーを払い出して活用していただいています。各チームでは主に以下の場面で利用しています。

SREチーム

障害発生時などにおけるメトリクス、ログでの状況確認
Kubernetesクラスタの調整、設定変更時などのログ確認
標準的なアラート、Synthetics、ダッシュボードなどのセットアップ

開発チーム

障害発生時などにおけるメトリクス、ログでの状況確認
APMやRUMでのパフォーマンス検証、トラブルシュート
過去の不具合などを、Rehydrate from Archivesにより調査

よく使う機能

1. Log Explorer & Rehydrate from Archives

Datadogに転送したすべてのログを横断的に検索することができるため、障害発生時刻近辺において、各レイヤーそれぞれでどのようなログが出ていたのかを確認する際など、非常に重宝します。

またAmazon S3をはじめとしたオブジェクトストレージへの自動アーカイブ機能を使用し、監査目的での長期間ログ保存も行っています。この機能で保存したログは、Rehydrate from Archivesを活用することで再度Datadogへ書き戻し、閲覧が可能になるため、数か月前のログの調査も容易に行うことができます。

2. APM

コード上の各種処理や、SQL queryごとの性能をトレースしていくことができるため、アプリケーションのより詳細なトラブルシューティングができるようになりました。

3. SLOs

Site Reliability Engineeringの考え方に沿ったSLO運用を簡単に始められます。エラーバジェットやバーンレートのグラフ表示も可能で、SLOの状況が掴みやすくなっています。

ツールの良い点

多機能で多くのモニタリングユースケースに対応できる
Organizationによる名前空間の分離、RBACなどで細かな権限制御ができる
料金の調整などについては日本法人からのアドバイスを受けることができる

ツールの課題点

従量課金であり、急激にログ出力が増加した際などに料金を抑制するのが難しい
利用したい機能が高額だったため、導入を見送ったことがある
多機能かつ新規機能リリースも早いため、追跡には学習コストがかかる

ツールを検討されている方へ

ほとんどのアプリケーションやインフラストラクチャの監視に対応することができるため、機能不足で悩む場面は少なく、優秀なSaaSだと捉えています。一方では、多機能であるがためにオーバースペックになるケースもありえます。特に規模の小さな企業やプロダクトにおいては、自社のユースケースを満たす、よりシンプルな監視SaaSを比較検証してみてもよいかと思います。