Datadog Notebooks活用事例

このレビューでは、アンドパッドのCREチームによるDatadog Notebooksの活用事例をご紹介します。

なお、Datadogの導入部分については、SREチームへのヒアリングをもとにまとめました。

アンドパッドにおけるDatadogの歴史

アンドパッドでは、2018年頃からDatadogを導入しています。

導入当初は、インフラに関心がある人だけがダッシュボード・Monitor・Syntheticsを利用し、インフラ全体の負荷状況を監視してサーバやスケールの設定をチューニングするのが主な用途でした。

しかし、アンドパッドのサービス拡大に伴いリクエスト量やユーザーが増えて、アプリケーションのパフォーマンス改善が重要な課題となり、Datadog APMを利用し始めました。

これによりアプリケーションの動作状況が可視化され、非効率なDBのクエリやロジックを改善しやすくなりました。

この頃から、開発チーム向けにDatadogのアカウントを発行するようになり、ダッシュボードやMonitorの設定を任せ、Datadogの利用が広がっていきました。

現在では各チームがDatadogを積極的に利用しており、より高度な計測や設定、新しいサービスを活用して、アンドパッドの運用に役立てています。

その流れの中で、リリース後の監視用途にDatadog Notebooksを活用するチームが現れ、社内共有会でその利便性が発表されたことで、CREチームもNotebooksの利用を検討することになりました。

Notebooks 利用前の課題

CREでは、Datadogで規定値を超えるDurationで検知されたリクエストを調査し、必要に応じてPdMへリクエスト改善を提案しています。

従来の運用では、以下のような課題がありました。

• リクエストに対する調査観点が属人化している
• リクエストの調査に工数がかかる
• PdMへの提案資料が視覚的ではない

Jira

Notebooks利用前は、Jira (Atlassian社が提供している課題管理ツール) を使って以下のように運用しており、前述の課題を感じていました。

• Jiraでチケットを起票
• Datadog でリクエストを調査
  • 主にクライアント/ユーザー別リクエスト数などを調査
    • この時点で調査観点が属人化
• チケットに調査結果の数値を記入
• CRE内でチケットの内容を基に、PdM連携が必要か判断
  • 必要と判断した場合、PdMにチケットを共有
  • 不要と判断した場合、監視を続けるか議論

• カスタムテンプレートにより、controllerとactionを指定するだけで、定型化されたグラフやデータがそろったNotebooksを作成できるため、調査観点が平準化し、誰でも調査対応が可能になった
• Notebooksだけで調査から共有まで一貫して対応できるようになり、工数が劇的に削減された
• リクエストの時系列・要因・過去との比較をグラフで視覚的に示すことが可能になり、問題の原因や傾向を誰でも直感的に把握できるようになった

Notebooksは分析やレポート作成の効率化におすすめです。

またDatadogそのものについても、統合監視プラットフォームとして、多くのクラウドサービスやツールと連携できるため、複雑なインフラ環境でも一貫した監視や分析が可能です。

アンドパッドのDatadog活用方法については、ぜひ以下の記事も参考にしてみてください。

https://tech.andpad.co.jp/archive/category/Datadog