「Datadogを見ればすべてがわかる」状態を作っていく
株式会社グロービス / Jutaro Numata
チームリーダー / SRE / 従業員規模: 501名〜1,000名 / エンジニア組織: 101名〜300名
利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|---|---|
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を比較検証してみてもよいかと思います。
今後の展望
今後も引き続きDatadogを利用していくことを考えています。長年の利用で料金が膨らんできている部分もあるため、適宜設定の見直しなどを行いつつ、うまく付き合っていきたいです。
株式会社グロービス / Jutaro Numata
チームリーダー / SRE / 従業員規模: 501名〜1,000名 / エンジニア組織: 101名〜300名
よく見られているレビュー
株式会社グロービス / Jutaro Numata
チームリーダー / SRE / 従業員規模: 501名〜1,000名 / エンジニア組織: 101名〜300名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法