ナレッジワークでのDatadog導入事例

ツール導入前の課題

当時は Google Cloud や Vercel など複数のクラウドサービスを組み合わせて利用しており、インフラもワークロードもバラバラで、監視が分断されていた。

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

利用中サービスのモニタリングを集約し、異常検知から調査までを一貫して行える状態を目指した。

• Google CloudのCloud Monitoring

• マルチクラウド環境での監視が統合されること。
• ログ、メトリクス、アラートを同じ UI と仕組みで扱えること。

• ログ・メトリクス・トレースを統合管理できる
• Monitor + SLO で異常検知が速い
• Logs Explorer と Metrics Explorer が同一 UI で使える

アーキテクチャ

Datadog に全ログを集約するとコストが跳ね上がるため、責務を分割して必要なデータだけ Datadog に送る構成にした。

• エラーログのみ Datadog に送信し、アラート生成に使用。
• HTTP リクエストログは必要分だけ送って Log-Based メトリクス化。
• それ以外の大量ログは Google Cloud の Cloud Logging に集約。

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

サービスごとにログ・メトリクス・アラートが分散しやすい構成だったが、リリース時から Datadog を導入したことで、これらの情報を一箇所で確認できる基盤を最初から整備できた。データが自動的に関連付けられ、ログからメトリクス、アラートへと横断的に遷移できるため、サービス全体の状態を把握する初動をすぐに開始できる体制が構築できた。

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

1. インシデント検知と初動対応の高速化
   初期リリースに伴う不具合を素早く検知できる体制が整い、リリース直後の品質リスクを早期に把握できるようになった。 さらに Slack 連携により、重要なアラートが発生した際には即座に通知が届き、そのまま関連ログやメトリクスへと遷移して原因調査に取り掛かれるフローが構築できたことで、初動対応の速度が大きく向上した。

2. SLOの運用
   チームごとに SLO を追える体制を整備したことで、サービスごとの正常な状態を明確化でき、議論や改善の基準が揃った。 また、SLO を Terraform で管理することで作成・更新をセルフサービス化でき、各チームが自律的に運用品質を高められる仕組みを整備できた。

3. コストバランスを取りながら必要十分な監視を実装
   すべてのログやメトリクスを無制限に取り込むのではなく、利用頻度の高いデータを中心に監視設計を行う方針を採用した。 その結果、コストを抑制しつつも、障害検知や調査に必要な observability を十分に確保できた。運用品質と運用コストを両立できる現実的な監視体制へと改善できた。

OSS で監視基盤を自前で作るより、導入後の運用はかなり負担が軽くなると思います。 ただ、ログ量によってコストが変わりやすいので、どのデータを Datadog に送るのか は最初に整理しておく方が安心です。 役割分担をうまく設計できれば、監視の質と費用のバランスは十分に取れると考えています。

今後は監視運用の中に AI を取り入れ、アラート調整や気づきにくい傾向の発見などを自動的にサポートできるようにしたいと考えている。 日々の運用負荷を軽くしつつ、異常の早期発見につながる仕組みを整えていくことを目指している。