Datadogの導入効果をレビューでご紹介(Shogo Muranushi-株式会社ABEJA)

参考になった

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

株式会社ABEJA / Shogo Muranushi

開発部長 / CTO / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名

最終更新日2024/06/20投稿日2023/11/10

利用プラン	ツールの利用規模	ツールの利用開始時期
インフラストラクチャー: Pro、ログ管理	10名以下	2019年11月

利用プラン	インフラストラクチャー: Pro、ログ管理
ツールの利用規模	10名以下
ツールの利用開始時期	2019年11月

アーキテクチャ

アーキテクチャの意図・工夫

主にログ周りに特徴があります。収集しているログは自社だけで利用するのではなく、顧客向けのダッシュボードにもログを表示しています。詳細はこちら。

https://tech-blog.abeja.asia/entry/tech-stack-201911

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

導入背景

当時の状況
- PrometheusをEC2上で動かしていました。
当時の課題
- モニタリング自体は使いやすいのですが、Prometheusが動いているDockerコンテナがたまに停止したりエラーで監視が出来ていなかったり、1-2人が週に数時間取られていました。
検討の背景
- 週に数時間を1-2人あれば何かしらの機能開発や価値提供ができるため、フルマネージドの監視サービスを検討し始めました。

比較検討したサービス

Prometheus
Datadog
Amazon CloudWatch

選定理由

運用負荷が低い
- フルマネージドでサポートもレスポンス早い
導入方法の簡単さ
- datadog-agent を daemonset としてデプロイするだけ
コスト
- InfraはPrometheus + 外部委託よりは安い
- LogはCloudWatch Logsの1/4位に収まった
Datadogの目指す世界観に共感
- https://dev.classmethod.jp/articles/read-monitoring-modern-infractructure-datadog/

導入の成果

監視サーバの運用から解放された。少ない人数でモニタリングの仕組みを構築できるようになった
Logの基盤の運用において、全てDatadogにオフロードできるので考えることが減った。もしなかったら、ログ量と性能のパフォーマンスチューニングで定期的に悩んでいたと思う

導入時の苦労・悩み

社内で最初に取り組んだこと
- 障害時にペアプロ的に一緒に操作しながら使い方と質疑を指南
苦労した点
- インフラ系じゃないエンジニアに一気に引き継ぐ（情報を渡す）と受け取り手が混乱して使いこなせなかったりするので、使い方を限定して使ってもらいつつ使う範囲を広げていった

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

上長・チームへの説明

自分達の時間を削るのは勿体無かったので、Datadog or Prometheusの運用を外部委託を検討しました。

Datadogの場合は10万円/月
Prometheusの場合はサーバ代 + 外部への Prometheus 運用 = ??万円/月

となり、仮に2が10万円/月だとしたら（OSSでクセあるのでもっとかかると思う）個人の手を介さないDatadogの方が良いのではないかと考えました。また、新しいツールは好きな文化なので特にハレーションや苦労はなかったです。

活用方法

よく使う機能

Log -> Error Rate をみたり、ログの量を確認してコストを抑えたり
Notebook -> 障害時の調査の際に作業を記録し次回も使えるようにする

ツールの良い点

使い易いLog機能
- ElasticSearchでも出来るが、月間2桁億を超えてくる処理量をElasticSearchで運用するのは手間がかかるので、フルマネージドで「利用するだけ」というのは非常に楽。
- インデックスを大量に張ってもパフォーマンスのチューニングも不要。

ツールの課題点

機能が多過ぎて使いこなせない
（注意点）新機能は初めは無料だけど後から課金されるので、無料だからと言って組み込み過ぎると引き剥がすのが大変になる

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

単純にサービスの費用だけではなく、インフラ周りの運用工数や、チームのスキルセット（現在の職種分布や今後成長して欲しいスキル）、ビジネス価値などを踏まえて検討することをおすすめします。

例えば、Istio等はオブザーバビリティとしては優れたツールかもしれませんが、Isitoを導入することでどれくらいのビジネス価値になるのか、数年後のチーム構成を見据えた時にIstioは大事なコア技術なのか、違うならどこに注力してスキルを磨いて欲しいのか、その前提に立った時にどの程度の複雑さ、シンプルさの技術を選定するのが良いのか、を考えて意思決定すると良いと思います。

株式会社ABEJA / Shogo Muranushi

開発部長 / CTO / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名

前職でAWSのクラウドインテグレーターとして大規模案件を多数コンサル、構築、運用する。2017年にABEJA Platformを開発するためにABEJAに参画。AWSパートナーとしてAWS Well-Architectedに準拠したMachine Learningコンピテンシーの取得を推進。現在はCTO室室長とABEJA Platformの責任者として従事。