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

参考になった

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

Cloudbase株式会社 / ryuke

メンバー / バックエンドエンジニア / 従業員規模: 11名〜50名 / エンジニア組織: 10名以下

最終更新日2024/05/01投稿日2023/11/10

利用プラン	ツールの利用規模	ツールの利用開始時期
Datadog Proプラン	10名以下	2022年9月

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

導入背景

システム監視ツールとしてはAWSの組み込みのCloudWatchを使っていたのですが、次のような課題がありました。

ロググループ（サービス）を横断した検索やフィルタリングが難しい
- 1つの処理が複数のサービスにまたがることがシステム特性上多いのですが、調査の際は開発者がコンソールに入ってそれぞれのサービスの関連するログを1つ1つ手動で見に行く必要がありました。UIもなかなか直感的に使えない部分が多く開発者のストレスにもなっていました。
UIが直感的でなく使いづらい
アラートのSlackへの通知を簡単に行いたい
SLI/SLOの運用を手軽に行いたい

システムの品質や信頼性を担保していくためにSLI/SLOの運用を本格的にやっていこうとなったタイミングで、Datadogの検討を始めました。

比較検討したサービス

Amazon CloudWatch
New Relic

選定理由

全体的な使い勝手の良さ、特にログ管理機能
社内に経験のあるメンバーが多いこと
クラウドとのインテグレーションの充実度

また、導入背景の③アラート通知やメッセージが簡単に設定・カスタマイズできる点、④のSLI/SLOの運用機能が標準でサポートされている点が決め手となり、Datadogの導入を決めました。一方で、導入にあたってのツール選定はあまり時間をかけてはおらず、社内メンバーにDatadogを以前に使ったことがあり慣れているメンバーが多いことが主な選定理由でした。Datadogというと他サービスと比較したときに主に料金面がネックになってくることが多いと思いますが、スタートアップということもあり時間をお金で買うことで本質的なプロダクト開発に集中できる環境を作ろうという意思決定をしました。

導入時の苦労・悩み

SaaSとして提供されており、導入フローなく従量課金制で小規模からでもすぐに使い始めることができるため、トライアルは実施せず一部のサービスから導入し始めて徐々に全体の利用規模を拡大しています。
システム・組織規模が大きくないこともあり、比較的スムーズに全体に導入を完了することができました。クラウドのインテグレーションが充実しているおかげで少しのステップで本番環境に標準メトリクスを導入することができたのも大きかったです。

RUM系の機能は当初重視していませんでしたが、セッションリプレイやError Trackingなど元々他ツールでカバーしようと思っていた機能も一部Datadogで見ることができたのは思わぬサプライズで、特にSaaS開発チームも巻き込んで導入を進めていく上でいい追い風となりました。
ただし、一部Datadogを導入した結果AWSの思わぬ料金の増加が発生したり、ステップ通りセットアップしたのにログやメトリクスがうまく送信されないなどのトラブルもありました。（詳しくはこちら）

【どのように乗り越えたか】
どれも技術的な問題だったので、関連記事を参照しながら不具合を一つ一つ解消していきました。インターネットに関連記事も多く、また公式のドキュメントも充実しているためそこまで行き詰まることはなかったです。

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

経営陣・上長への説明

スタートアップで人数も多くなく、システム監視体制の整備が急務であったため導入に際しての意思決定にはそこまで時間はかかりませんでした。

導入に際しては料金面が主な懸念だったため、現在のサービス規模をDatadogに移行した時にかかる金額をホスト数やログのデータ量等を元に試算し、月あたりの上限額の目安を決めてまずはこれを超えない範囲で運用していこうという形で社内で合意を得て導入を進めました。

また、Datadogの使いやすさという強みを活かし、開発者がよりダッシュボードを頻繁に確認したりログ・メトリクスを仕込むようになったりと、一人一人が自律的にオブザーバビリティについて考える文化の醸成に繋がることも期待して導入を進めました。

費用対効果の算出

費用対効果として、障害対応・調査におおよそエンジニアあたり週2時間程度の時間が取られている現状があり、ログ横断機能やUXの向上によってその作業時間の2-3割の削減が見込まれることからざっくりと試算を行いました。

活用方法

よく使う機能

システムのログやメトリクスは基本的に全てDatadogに集約する設計としており、インシデント調査時などはDatadogを見にいけば必要な情報が手に入るようになっています。

メトリクスの変化やエラーログの件数に応じてアラートを設定しており、異常が発生した際は直ちにSlackに通知が飛ぶようになっているため、アラートに気づいた開発者がDatadog上で関連するデータを調査して原因を特定・影響範囲に応じてインシデント宣言やエスカレーションを行うという流れになっています。

その他、チームの週次ミーティング等でダッシュボードやSLI/SLOの数値を定期的に確認するなどのルールを設けて運用を行なっています。APMやRUMの機能については現状特にルールは設けず開発者が必要に応じて参照できるようになっています。

Dashboards
- サービスごとにProduction Readiness CheckとしてDatadogのダッシュボードを用意することを要件として定義しており、ダッシュボードを見ればそのサービスの状態が一目でわかるようになっています。
- チームの週次ミーティングでダッシュボードを眺めながらSLI/SLOや各種メトリクスに異常がないかを確認している他、アラートが上がった時に何が起きているかの全体像を把握するためのエントリポイントとして機能しています。
Logs Error Tracking (beta)
- エラーログの内容に応じて自動的にグルーピングを行い、発生した件数や頻度を集計してくれる機能です。環境内で発生しているエラーをサービス横断で把握しトリアージするのに便利で重宝しています。まだbeta版らしいので本番環境で運用する際は一応注意が必要です。
Session & Replays
- RUM (Real User Monitoring) の一機能で、名前の通りWebページにおけるユーザーの動作をマウスカーソル付きでリプレイすることができるため、実際のユーザーの操作や画面遷移の様子を観察することでプロダクト改善における貴重な手がかりの一つとなっています。ユーザーのプライバシーに関わる画面上の表示データをマスキングしてくれるところも痒い所に手が届く設計となっていて素晴らしいです。

アーキテクチャ

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

クラウド環境としてAWSを利用しており、ECSやLambda、Step Functionといったサービスで動作するワークロードに対し、Datadog Agentをアタッチして各種テレメトリーを取得しています。
Datadog AgentはほとんどをDocker Imageとして導入しています。通信量の削減のため、ECRのPull through cache機能とVPCエンドポイントを活用しています。
メトリクスはAgentからDatadogサーバーへ直接送信されます。ログはDatadog Forwarderと呼ばれるLambda関数で、CloudWatchのログを転送しています。

ツールの良い点

監視ツールとしての機能は一通り揃っており、使い勝手も良いので料金体系がフィットするのであればまず試して損はないと思います。
UIが直感的で、ドキュメントも充実しているため使ったことがない人でもすぐに操作に慣れることができます。
使いやすさの反面カスタマイズ性も高く設計されておりユースケースに合わせた柔軟な使い方が可能です。
インテグレーションが充実しており、最小限のセットアップで豊富なメトリクスを使い始めることができます。
かなり成熟したプロダクトであるものの未だに開発速度が非常に速く、日々新しい機能がリリースされるのが密かな楽しみになっています。最近だとSession & Replaysからブラウザテストを自動生成する機能が公開されていたりして社内が騒然としました。

ツールの課題点

料金に関するコントロール
- AWSなどのクラウドに比べるとかなり機能不足を感じます。月毎の予測コスト、累積コストのグラフは確認することができますが、過去のコストについては請求レポートのPDFでしか確認できないようです。Datadog自体の料金に対するメトリクスがなく、上限額を設定したり予算を超えた場合にアラートを設定したりといったことが現状できません。対策として各サービスごとのesitmated_usage（予測使用量）のメトリクスが用意されており、これに対するアラートを設定することができますが、数十あるサービスについてそれぞれ設定する必要があり料金額ベースで一元管理したい場合には不便です。
イベント管理の機能があるのですが機能も少なくメトリクス・ログとの使い分けがわかっていないです。
クラウドのコストを可視化できる機能があり、Datadogでコストを一元管理できたら便利だなと思ったのですが、現在の利用規模だとかなり料金が割高になってしまい利用を諦めました。

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

サービスごとに料金体系が全く異なるため、それぞれについてしっかり料金の計算方法を把握していないと思わぬ料金の高騰に繋がる可能性がある点に注意が必要です。タグ込みのカーディナリティベースで料金が計算されるカスタムメトリクスやログの取り込みに対して費用がかかるログなどは特に注意が必要です。

Cloudbase株式会社 / ryuke

メンバー / バックエンドエンジニア / 従業員規模: 11名〜50名 / エンジニア組織: 10名以下

2022年4月に株式会社メルカリに新卒入社し、Microservices Platform CI/CD チームとしてGithub Actions self-hosted runnerをベースとした社内のCI基盤の刷新・マイグレーションの推進を担当。 2023年1月から現職のCloudbase株式会社にジョインし、引き続きPlatformエンジニアとしてシステムのオブザーバビリティ基盤の整備や社内開発者の生産性向上を担当。