Observability向上ツールとしてのDatadog活用 株式会社ログラスの事例

ログラスでは創業時からAWSを中心にシステム構成を設計しており、その監視基盤としてDatadogを選定しました。創業初期は以下の課題を抱えていました。

総合的な監視基盤の実装

• インフラやアプリケーションのログを適切に監視し、安定したサービス運用を実現したかった。
• 特に、APM（Application Performance Monitoring）の活用によって、アプリケーションのパフォーマンスやボトルネックを可視化したいと考えていました。

リソースとコストの制約

• 創業当初の売上がないタイミングだったので、監視基盤にかけるコストを最小限に抑える必要がありました。監視サーバの金銭的なコストを考えると、使った分だけ課金される従量課金モデルの方が創業当初は望ましいと思っていました。
• 自前で監視サーバを構築・運用するのは負担が大きいと判断し、SaaSを積極的に活用する方針を採用しました。

特に比較したサービスはありません。決め打ちでDatadogを利用しようと考えていました。

費用面だけ気にしていました。創業当初は売上もなかったので、毎月どれぐらい運転資金をバーンするのかだけ気にしていました。

自分が過去に使ったことがあったこと。

アプリケーション開発に不可欠な基盤として成長してきました。 今はアプリケーションのログだけではなく、外部のSaaSのログなども連携し、Datadogに集約をしています。 ただ全データを長期間入れておくことは出来ないので、直近のログはDatadogを参照し、昔のデータは必要になったときに都度Datadogに入れ直しをしています。 その辺のやり方については別のブログにまとめたので参照してください。 Datadog Log Rehydrationの紹介

創業時から導入したことで、導入に関する苦労は特にありません。 すでに何らかの監視ツールが入っておりリプレイスしたい場合は苦労があるかと思いますが、弊社は特にありませんでした。

多機能なので、段階的に利用度を増やしていくと良いと思います。

新しく入ってきた方がDatadogに習熟されるのに時間がかかるという話があるので、オンボーディングの一貫としてDatadogの機能を一緒に学ぶという時間を作りたいと思います。