Datadogを利用しての可用性向上とリソースの最適化と開発生産性の向上を実現

参考になった

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

アソビュー株式会社 / disc99

CTO・VPoE / VPoT/VPoP / 従業員規模: 301名〜500名 / エンジニア組織: 101名〜300名

最終更新日2024/05/01投稿日2024/03/27

利用プラン	ツールの利用規模	ツールの利用開始時期
Datadog Pro	101名〜300名	2018年9月

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

導入背景

サービスも成長段階に差し掛かり、モノリスなシステムだけではなくマイクロサービス化されたシステムが増えていたり、組織規模も拡大傾向にあり、1つのプロダクトやシステムに対して複数チームで開発を行う機会が増えていった時期であり、サービス全体のパフォーマンスや障害点などの可視化し、信頼性を高めていく上で必要となるへ素早くたどり着けるようにすることをゴールにしていました。
当時は、利用者も増え、障害影響も大きくなっており、システムとしても複雑化していく中で、問題点を素早く正確に見つけ判断することの何度が高い状態になっていました。
その中でログやメトリクスはAWS CloudWatch、Grafana/Prometheus、分散トレーシングはZipkinなど利用しておりツール群が分散して情報にたどり着くのに時間がかかったり、当時はマネージドサービスが無いもの多く自分たちで運用が必要なものも多かった状況でした。

比較検討したサービス

AWS CloudWatch
Grafana/Prometheus
Zipkin

比較した軸

実際に運用しているアプリケーションや外部SaaSなどのログや必要メトリクスを取り込んだり、カスタマイズ可能か
問題の事前検知や障害発生時に状態を統合して追うことができるか、アラートなど素早く対応するための運用が回るか
AWSのマネージドサービスや自前でOSSのミドルウェアなどをセルフホストする場合と比べコスト面が優位か

選定理由

導入に際しては段階的に利用を始めたため、技術選定として利用するしないではなく、導入を進めながら課題となっている項目クリアしながら最終的に全面的な導入に至りました。

導入の成果

現状では、Datadogを起点に問題点の洗い出しや対策を検討する運用がSRE、開発チームと連携しながら進んでいます。
元々利用していたサービスを使いこなせていなかった部分もありますが、20以上あるアプリケーションのログを一括管理できていたり、部分的にしか追えていなかったメトリクスやトレーシングも基本的に殆ど全てのアプリケーションに導入できています。
また、弊社ではJavaのアプリケーションをメインで利用していますが、JVMメトリクスやContinuous Profilerなどより内部状態も含め可視化ができるため、外部からの監視だけでは不可能だった詳細な状態も含め問題特定がしやすくなっています。

導入時の苦労・悩み

機能が豊富なため、開発者が使いこなせるようになるまでオンボーディングやナレッジシェアがそれなりにかかりました。
また、Datadogに限った話しではないですが、モニタリングやアラート、またSLOなどの設計は実際のシステムやサービスの方針に合わせてするかなどは手探りで進めた部分もあります。

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

経営陣・上長への説明

経営メンバーであるCTOが技術面での理解度が高く、段階的に利用し費用対効果を具体化していくこと、既存のシステムからの置き換えを行うことで、特別大きな説明をすることはなかったです。

活用方法

SREでは、サーバ全体のリソースの監視をして、安定稼働しているかどうかを常時チェックしています。不安定な部分や想定外の負荷がかかったときには、Slackでアラートを通知して素早い対応ができるようにしています。また、Datadogからのアラートを受信して、24/365対応が可能な会社に一部業務を委託して安定稼働のために利用しています。また、Javaアプリケーションが必要以上に負荷をかけてないかを切り分けるなどの場合にもDatadogを活用しています。
開発チームも週次のSLOの運用やトラブル対応時のログの検索やAPMの情報の確認などを実行しDevOpsの一部としてDatadogを活用しています。

よく使う機能

SLOsの機能
日々レイテンシーが目標値以内に収まっているか、エラー率が目標値以内に収まっているかどうかを週次で確認しています。また、Monitor機能も併用して、SLOが枯渇したらSlackに通知して、なるべく早く気付けるようにしています。システム全体のSLOの枯渇状況は、SREの方で週に一度はチェックして、枯渇状態が続いてないかどうかや、続いていて問題ないかどうかをチェックして運用状況を確認する形で利用しています。その際に、タグ付けの機能やチームを割り当てる機能も便利に使っています。
APMのTrace機能
分散トレーシングができるように、nginxからマイクロサービスのJavaアプリケーションがどのように呼び出されているかなどを確認してます。また、各ログとTrace機能を結びつけて、ログからAPMの情報に行ったり、APMの情報からログを参照できるようにしてトラブル発生時に調査がしやすいように設定して運用しています。
Metricsの機能
Metricsをkubernetesに取り込み水平自動スケール（HPAの）の材料にしています。当社のサービスでは、アクセス数は、休日と平日でも大きく異なりますし、夜間帯と日中帯でもそれぞれの時間帯に応じて負荷の特性があったりします。負荷に応じて自動的にPodの数を変えることを実現するためにDatadogのメトリックスを利用してリソースの最適化を行っています。

アーキテクチャ

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

Dataedogをログ管理のメインに置くように途中から変更しています。Datadogのログを保管時間が長いと料金も高くなるので、必要時には、Datadogに再度取り込むケースとAWS内でAthenaを利用して検索可能と２つの方法をサポートすることにより、コストが掛からないような工夫をしています。また、ログをDatadogに送付してErrorTrackingなどの機能を有効してエラー分析が行いやすいようにしています。

ツールの良い点

ダッシュボードもいろいろ自由に作成してシステムをいろいろな角度から監視ができ、異常時の通知設定が簡単にできる点
利用者に応じた料金体系ではないので閲覧する人が増えても気にせずに利用できる
マネージドサービスのため、セルフホストと比べインフラ等の可用性やバージョンアップなどを運用を気にすることなく、便利な機能が随時アップデートされていく点

ツールの課題点

サービスごとに課金体系が分かれていたり、機能によってはそれなりに高価な機能だったりするのとUI的にコストが発生しているか気づきにくい点
非常に豊富な機能、アップデートが進んでいますが、最近追加されているものは外部サービスと比べると機能面で今一歩な部分もあったりする点
SaaSサービスなので仕方がない部分もありますが、突然ドキュメントの内容が更新されていたり、同じような記載が新旧も含めあちこちにあって、どれを参考に利用していけばいいか迷う点

その他

Datadogを使っている中で、失敗したエピソード

テスト環境に適用されたモジュールの不具合により、ログが暴発することが有り、課金がとんでもない金額になってしまったことが有りました。テスト環境のログはフィルターやリミット制御するなどを行っています。また、常に最新のdd-java-agent.jarを利用するようにしていましたが、互換性が無い変更が含まれていたことがあり、それに気づかず障害につながったことがあり、それ以降はバージョンを固定し定期的にバージョンアップする運用に切り替えています。