株式会社DegicaのDatadog導入事例

ツール導入前の課題

Datadogを本格的に導入する前は、New Relicを使用してRailsアプリケーションのパフォーマンス監視をして、ログはDatadogでインデクスするという複数サービス使用してサービス全体を監視する形になっており、問題が起きた時の原因調査に手間取ることが多かった。

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

インフラのリソース監視やログ監視、セキュリティ脆弱性の検知など、すべてを1つのサービスに統合して、このサービスを見れば全部必要な情報が集まるという状態を目指しDatadogへの完全移行をすることにした。

• AWS内で完結させる (クラウドプロバイダはAWSを使っているため)
• Prometheus

AWSにはパフォーマンス監視(APM)の機能以外はだいたいマネージドサービスが提供されているが、Datadogと比べるとUIの作り込みが弱く、直感的に操作しづらいという問題がある。

Prometheusはリソース監視やログ監視には強みがあるが、セキュリティ周りのソリューションは提供していない。また当時この領域を担当していたチームメンバーが2,3人しかいないということで、Prometheusを自前で管理する手間を考えるとSaaSであるDatadogに分があった。

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

すべてのデータがDatadog内に集まり、ロードバランサーのログから、APM、インフラリソースのメトリクスまで一気通貫してトレースすることができ、対象のメトリクスから関連するログへのジャンプなども一瞬でできるようになったので、トラブルシューティングがとても効率よくできるようになった。

インフラを見ているエンジニアが少人数の場合、低い運用コストで広範囲の監視ができるのでオススメです。 一方で十分な数のエンジニアがいる場合はPrometheusなどのOSSを使用する方が、運用コスト(人件費)を考慮してもトータルのコストは節約できるかもしれません。