株式会社ニーリーのDatadog導入事例
株式会社ニーリー / miya10kei
チームリーダー / SRE / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
利用プラン | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|---|
Datadog Pro | 51名〜100名 | 2022年2月 | B to B B to C |
アーキテクチャ
![アーキテクチャ図](https://cdn.findy-tools.io/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBWDQ9IiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--4d0e7049fa01e7745d747e49fc9a9709671f9656/datadog_review%20(1).png?disposition=inline)
アーキテクチャの意図・工夫
システムのテレメトリーデータは基本的にはDatadogに集約する方針をとっています。
ログについては以下理由により全てはDatadogに集約せず、一部をS3に保存しAthenaから検索するようにしています。
- 全てのログをDatadogに取り込むと料金が高くなってしまう。
- 個人情報が含まれるログに対してDatadogだと閲覧対象を制限することができない。
導入の背景・解決したかった問題
導入背景
Datadogを導入するにあたり次の2つの課題がありました。
- 監視体験の改善
- Datadogを導入する前はAmazon CloudWatchを利用して監視運用をしていました。しかし、ログからメトリクスフィルターを作成しアラームを設定するという体験があまり良くないと感じていました。
- システムの各種テレメトリーデータの収集
- AWSでデフォルトで計測される以上のデータを取得しておらず可観測性がとても低い状態にありました。
導入の成果
- 監視の改善
- DatadogのMonitor機能は計測される様々なデータ(ログ、メトリクス、イベント、SLO、etc..)から直接Monitorを作成することが可能なため監視運用の体験がとても向上したと感じています。
- システムの各種テレメトリーデータの収集
- APMを導入したことで今まで収集できていなかったトレース情報を確認できるようになったためシステムのパフォーマンス改善に大いに役立っています。
- OpenTelemeryを使って自分で計測したメトリクスを簡単に可視化できるようになったため可観測性の向上にも寄与しています。(計測例)
導入に向けた社内への説明
上長・チームへの説明
CTO含め当時の課題を共有できていたため特別な説明が必要になることはありませんでした。また、料金についてもスモールスタートで開始したこともあり社内での予算内に収めることができたので問題にはなりませんでした。
本導入の前にトライアル期間を活用して必要な機能を十分にテストしました。合わせて導入手順の整備もおこなったためチーム内で作業を分散してスムーズに本導入をおこなうことができました。
活用方法
■ SREチームでの主な使い方
システム全体を俯瞰できるダッシュボードを数個作成し、毎日の朝会で日々のデータ推移を確認するようにしています。不審なデータの推移や異常値を見つけた場合には該当日のリリースやイベントを確認したり、開発チームにエスカレーションすることで早期に問題の芽を摘む活動をしています。
■ アプリケーション開発チームでの主な使い方
アプリケーションエラーをDatadogで監視し、Slackに通知するようにしています。アプリケーション開発チームでは日々通知内容を受け取ったら、Datadogでログ等を確認し対応する運用をしています。
よく使う機能
- Dashboards
- システム全体を俯瞰できるダッシュボードを作成し、毎日定期観測をしています。
- ECSやRDSなど各AWSサービスに特化したダッシュボードを作成し、異常時に詳細を確認できるようにしています。
- SLO
- ALBのアクセスログから作成したメトリクスを使用してSLOを設定しています。一部のSLOにはBurn Rateによる監視を設定しており、異常を検知できるようにしています。
- SLOに関するDatadogのリソースはTerraformでIaC化しています。TerraformコードからMarkdown形式のSLOドキュメントを生成することで実態とドキュメントのズレを防ぐ工夫をしています。
- Monitor
- インフラとアプリケーションの両方の監視に使用しています。異常があればSlackに通知するようにしています。通知にはランブックを紐づけ簡単なものは誰でも対処がおこなえるようにしています。
- APM(Trace)
- パフォーマンス悪化時の調査でどのAPIのどの部分がボトルネックになっているのかを大まかに把握するのに使用しています。
ツールの良い点
- 機能間の連携
- Logs、Metrics、APMなどの機能が連携しているためちゃんと設定すればシームレスにデータ間を行き来することができます。
- Datadog Agentによるデータの自動収集
- アプリケーションにDatadog Agentを導入することでメトリクスやトレースといった多くのデータを自動で収集してくれます。
- SLO機能の充実度
- メトリクス/モニター/タイムスライスベースと3種類の計測方法から選択することができます。また、Error BudgetとBurn Rateのどちらでも監視設定をおこなうことができ必要な機能がしっかりと揃っています。
- 課金体系
- 機能毎に課金体系が細かく分かれているので使用機能を絞ることで小さく導入することが可能です。
ツールの課題点
- ログ検索の柔軟性
- DatadogのログはログパイプラインでパースしAttribute化した項目に対して検索するのが基本となります。例えば正規表現でログを検索したり、SQLのサブクエリのように検索結果を使って更に検索するといったことができません。
- 一度取り込んだログをパースし直すことができないため過去ログに属性を付与するといったことができません。
- コスト関連の機能不足
- AWSなどのパブリッククラウドのようにコストに対する予算アラートを設定する機能がありません。各サービス毎の予測利用量メトリクスに対してアラートを設定することできますが、金額ベースではないため少し難しいです。
ツールを検討されている方へ
Datadogは多くの機能が提供され現在も頻繁にアップデートがおこなわれています。一度に多くの機能を使うのではなく、まずは対象を絞って小さく導入していくことをおすすめします。また、良くも悪くも従量課金なので日常的に見るデータに絞ってDatadogに集約していくのが良いと思います。特にログは増えることはあっても自然に減ることはあまりありません。その結果、気づいたらログ料金が膨れ上がっているということが起きかねないので気をつけてみてください。
今後の展望
ソースコードインテグレーションとDatabase Monitoring機能の導入を検討しています。
ソースコードインテグレーションはGitHubなどのソースコード管理ツールと接続することで、テレメトリーデータとソースコードを関連付ける機能です。APMのError Trackingからエラーが発生したコードを確認できるようになるため障害時の調査を効率的におこなえるようになると期待しています。
Database Monitoringはデータベースに関する様々なデータを可視化してくれる機能です。スロークエリーの特定や実行計画の確認などをDatadog上でおこなえるようになるためパフォーマンス改善がよりやりやすくなると期待しています。また、カスタムクエリーという任意のクエリー結果からメトリクスを生成する機能があります。たとえば、テーブルのレコード数などをメトリクス化しその推移とクエリーのレイテンシーなどを比較することで新たな改善点を発見できるのではないかと考えています。
株式会社ニーリー / miya10kei
チームリーダー / SRE / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
2011年に株式会社日立ソリューションズに新卒入社。Web系業務システムのスクラッチ開発に従事。2017年2月にヤフー株式会社に入社。Yahoo!メール、PayPayフリマのサービス開発やSWATとして複数サービスの開発支援に従事。2023年3月に株式会社ニーリーに入社しSREチームリーダーとして従事。
よく見られているレビュー
株式会社ニーリー / miya10kei
チームリーダー / SRE / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
2011年に株式会社日立ソリューションズ...
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法