株式会社カンムのDatadog導入事例

ツール導入前の課題

元々はサービスのモニタリングのために、Mackerel・New Relic・Sentryを利用していたのですが、複数のメトリクスを見るためには異なるSaaSをまたがなければならない状態になっていました。また、同じ時期にAmazon EC2からAmazon ECSへの移行も検討しており、コンテナのログを収集するために新しいSaaSを導入する必要もありました。

どのような状態を目指していたか

• 複数のログインを挟むことなく、同じサイトでAPM・エラートラッキング・メトリクスを閲覧できる
• コンテナのログの閲覧をWeb上から行える
• APM・エラートラッキングとログを紐付けて、エラー情報からAPM・ログを辿ることができる

• New Relic
• Sentry
• Mackerel

• コスト（特にログのコスト）
• ECSで問題なくログを収集できるか
• Goのアプリケーションでトレーシングが正しく機能するか

• すでに導入中のサービスと比較して妥当なコストだった
• 機能検証での使用感が良かった
• AWSとの連携機能が豊富だった
• すでにDatadogに慣れたメンバーがいた

改善したかった課題はどれくらい解決されたか

APM・エラートラッキング・メトリクス、さらに外形監視ネットワーク監視など、バックエンドシステムのモニタリングに必要な情報のほとんどをDatadogに集約することができ、各種モニタリングの情報をまとめて見ることができるようになりました。 また、コンテナのログもすべてDatadogから閲覧することができ、かつAPM・エラートラッキングと紐付けられているので、エラー情報からログ・トレース情報を追うことができ、原因の調査もスムーズに行えるようになりました。

どのような成果が得られたか

• モニタリング情報を一元管理することにより、複数のメトリクスをまたいでシステムの状態を分析することが簡単になった
• コンテナ環境でもシンプルにログの閲覧・検索ができるようになった
• APM・エラートラッキング・ログの紐付けによるアプリケーションのオブザーバビリティの向上

• エラートラッキングがエラーを収集するだけのものではなくAPMと一体化されたものだったため、機能を理解してアプリケーションに組み込むまでに時間がかかった
• APMが基本的にWebアプリケーションをターゲットとしており、WebではないアプリケーションへのAPMを組み込みについてのドキュメントが乏しかった
• 当時、Goアプリケーションでのエラートラッキングの利用について十分なドキュメントがなく、導入のために試行錯誤が必要だった

無料枠があるので、まずは簡単に使ってみて各種機能の動作を検証をした方が良いです。カンムでのDatadogの導入当時は詳しくドキュメント化されていない機能があったり、予期しない振る舞いをすることがあったので、実際に触ってみることで分かることも多いと思います。

また、課題点で指摘したとおり、料金体系がわかりづらくコストの見積もりが難しいので、導入前にDatadogにコンタクトをとった上で、抱えている課題や予算感を共有し、適切なソリューションの提案やコストの説明を受けることをおすすめします。

データベース モニタリングやCloud SIEMなどの活用できていない機能や、MCP Serverなどの新しい機能などを積極的に導入していきたいと考えています。