Datadogの導入効果をレビューでご紹介(Shogo Muranushi-株式会社ABEJA)
株式会社ABEJA / Shogo Muranushi
開発部長 / CTO / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
利用プラン | ツールの利用規模 | ツールの利用開始時期 |
---|---|---|
インフラストラクチャー: Pro、ログ管理 | 10名以下 | 2019年11月 |
アーキテクチャ
![アーキテクチャ図](https://cdn.findy-tools.io/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBDdz09IiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--8ed456311b78967d06803aa5046338fcc66f7826/architecture.png?disposition=inline)
アーキテクチャの意図・工夫
主にログ周りに特徴があります。収集しているログは自社だけで利用するのではなく、顧客向けのダッシュボードにもログを表示しています。詳細はこちら。
導入の背景・解決したかった問題
導入背景
- 当時の状況
- PrometheusをEC2上で動かしていました。
- 当時の課題
- モニタリング自体は使いやすいのですが、Prometheusが動いているDockerコンテナがたまに停止したりエラーで監視が出来ていなかったり、1-2人が週に数時間取られていました。
- 検討の背景
- 週に数時間を1-2人あれば何かしらの機能開発や価値提供ができるため、フルマネージドの監視サービスを検討し始めました。
比較検討したサービス
- Prometheus
- Datadog
- Amazon CloudWatch
選定理由
- 運用負荷が低い
- フルマネージドでサポートもレスポンス早い
- 導入方法の簡単さ
- datadog-agent を daemonset としてデプロイするだけ
- コスト
- InfraはPrometheus + 外部委託よりは安い
- LogはCloudWatch Logsの1/4位に収まった
- 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の責任者として従事。
よく見られているレビュー
株式会社ABEJA / Shogo Muranushi
開発部長 / CTO / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
前職でAWSのクラウドインテグレーターと...
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法