MNTSQ Techブログ

「MNTSQ(モンテスキュー)」のTechブログです。

Datadog Notebook の活用:メトリックとメモの素早い情報共有とネクストアクションの提案

MNTSQ Tech Blog TOP > 記事一覧 > Datadog Notebook の活用:メトリックとメモの素早い情報共有とネクストアクションの提案

はじめに

Datadog には Notebook というものがあります。以前から存在する機能であり、目新しいものではありません。

詳細は公式のドキュメントが詳しいのですが、Datadog で取り扱えるログやメトリックなどを埋め込めるドキュメンテーションツールという捉え方で然程ズレは無いはずです。単にログやメトリックを追うという意味ではダッシュボード*1 も使え、継続的な観測をする場合は ダッシュボードのほうが断然よいです。

いっぽうでこういった課題感もあると思います。すくなくとも私は常々あります。

  • あのメトリックとこのメトリックとは何らか関連性のある動きをするはずなんだが、パッと追いづらいぞ
  • 監視やダッシュボードの設計をしたいのでメトリック状況を追いたいのだが、メトリクスエクスプローラーではいまいち状況がわからないぞ
  • 複数のメトリックを束ねて計算したい*2が、メトリクスエクスプローラーで頑張っていたら訳分からなくなってしまった*3
  • メトリックを見つつ考察や見解を添えておきたい。別途存在するドキュメント側に Datadog への誘導を設けるでもよいが、ひとつの場所で扱いたい

こういった場合、ダッシュボードをつくるよりも Notebook を使うほうが手軽かつ確実な効果が得られます。 本項にて弊社で活用事例をあげつつ、Datadog Notebook は便利だよ、という声を微々たるものながら上げられればと思います。

事例1:Elasticsearch → OpenSearch への移行準備にかかる既存調査

弊社では現在検索基盤の更改を検討しており、現状利用している Elasticsearch から Amazon OpenSearch への移行を手段のひとつとして考えています。

この移行にあたり、移行先 OpenSearch ドメイン*4のリソース見積もりをする必要があり、その材料を既存 Elasticsearch の状態から得ようと考えました。

実際に使った Elaseticsearch 状況確認用の Notebook(黒塗り部分が多い点ご容赦ください)

出すべき材料はおおむね以下のようになるはずです:

  • Elasticsearch ノード台数
  • 各 Elasticsearch ノードのリソース消費量
    • CPU
    • RAM*5
    • ディスク
  • 収容テナント数
  • 収容シャード量
  • 発生しているコスト

これらメトリックは既に Datadog 上に蓄積されています。もちろんこれらを一瞥するようなダッシュボードを作ることも可能ですが、今回は

  1. 定点監視することを目的に確認したい訳ではない
  2. 並べた数字を眺めながら議論をすすめるケースが多々有った
  3. 既にあるドキュメントは詳細な考察と検討に使い、メトリックを並べた場所は純粋にメトリックから得られる所感だけを扱うようにしたい需要があった

ということもあり、とりわけ 1. を主要な目的として Notebook へ、いわば「書き散らし」することにしました。 継続的な観察を目的とせず一時的な調査として Notebook という手段をもっておくことで、こういった書き散らしに数字的な意味を持たせることができます。かつ体裁を気にせず素早くまとめが仕上げられるので、議論と結論出しを迅速に行うことができました。

事例2:Datadog Cloud Cost と Unit Economics

もうひとつの事例は、Datadog Cloud Cost を活用した、一歩踏み込んだコスト分析での利用です。

実際に使った Unit Economics 検討用 Notebook (こちらも黒塗り部分が多い点ご容赦ください)

弊社では先般 Datadog の Cloud Cost を使い始めており、AWS / Google Cloud / Azure 各コストの俯瞰的な観察ができるようになっています。以下拙稿も参照ください。

一方で Cloud Cost を折角導入した以上、コストをただ観察するのではなく、よりよい洞察を得たい気持ちもあります。前掲拙稿の通り

Datadog メトリックとして各クラウドベンダのコスト情報を適切な分解能でもって Datadog 内で扱える

という利点が Cloud Cost にはあり、各種メトリックとコスト情報とを掛け合わせたものが整備できそうです。つまり単に「いくらかかっているか」を眺めるだけでなく、その費用対効果を定量的に評価できる余地がありそうです。そこで Unit Economics の概念を取り入れ、クラウド利用にかかるコストの経済性を考察することにしました。

SaaS における Unit Economics といえば、一般的には

  • LTV(Life Time Value;顧客生涯価値)
  • CAC(Customer Acquisition Cost;顧客獲得コスト)

の比率で語られます。しかし、エンジニアリングの側面からこれを捉え直すと

  • 1テナントあたりの提供コスト (COGS)
    • Cost Of Goods Sold;売上原価
  • アクティブユーザー(以下 Active User を略して AU と表記します)あたりのインフラ費用

といったものをいかに最適化し、粗利を最大化するかという議論に単純化できます。

こうした指標を追跡するなかで、特定の利用パターンにおいて Unit Economics の悪化が見られた場合、それはそのパターンを支えるインフラ的なアーキテクチャやリソース配分に改善の余地がある、という仮説が立ちます。単なるコストの総額ではなく、ユニットあたりの効率を見ることで、エンジニアリングとして優先的に手を入れるべき箇所を特定しようという試みです。

この分析を行うには、クラウドコストのデータに加えて、Datadog 上の既存メトリックやログから生成したメトリックを突き合わせる必要があります。この試行錯誤において、 Notebook が非常に役立ちました。

扱うデータの検討

まずはクラウドコストをテナントで割るか AU で割るかの検討が必要です。テナント単位で見るのが前述のとおり筋と当初は考えたのですが、両者の実態や傾向に差異がある都合、実際にはユーザーあたりで見た場合によりよい洞察が得られるケースもあり、最終的には両者を状況によって比較する(つまりテナント按分コストと AU 按分コストとを両方算出する)手法をとることになりました。

この試行を素早く繰り返す際に役立ったのが Notebook で、複数の計算結果を(再び)書き散らし、実態を最も反映していそうな指標が何かをグルグル考え回すことができました。

観察

コスト観察は長期間の観察が不可欠です。日単位や週単位ではあまり意味のある情報は得られません。定点観察にはダッシュボード化が適しますが、そもそも今組み立てているデータが有意義かどうかが判っていない段階でのダッシュボード化は早計でしょう。

まずは Notebook をサンドボックスとして使い、少ない整備の手間で傾向観察をはかることが可能となりました。

考察

データが揃い、観察が出来るようになったのち、必要なのはその結果の考察です。これにも Notebook への「書き散らし」が便利でした。

データの定義はどういったものでこの結果は何を示すものと考えられるか等の情報がデータと同じ場所にメモでき、何を伝えればよいのだ等と思い悩む必要性が減り、思い切った検証ができるようにもなります。

また検討と訂正を繰り返していると訪れる「果たしてこれは何を意味するのだったか」と失念して困惑するという事態も、書き散らしによって避けることができます。

要するに

いきなり「正解」のダッシュボードを作るのではなく、 Notebook 上でこうした泥臭い検証を重ねられたことが、最終的に精度の高い可視化への近道になりました。

なお最終的に Notebook の内容はダッシュボードとして新たに整備することになりました。有益さが判った結果ですが、最初からダッシュボードにしておけばよかったと思わないでもないです。 これは現時点(2026年1月)では Notebook からダッシュボードに移行できるような機能が Datadog には無いためで、 Notebook 上に整備した各種メトリックをダッシュボードに気合で移す作業が必要になりました。今となっては良い思い出です。

おわりに

今回の活用を通じて、以下のような嬉しさがありました。

  • Elasticsearch 移行
    • 検証数値的な裏付けを持って机上での検討ができるようになり、移行計画に際し十分な情報を提示することができた
    • Notebook に適宜情報を追加しながら仮説検証を繰り返すサイクルが回せたことで、手戻りの少ない検討が可能となった
  • Unit Economics 分析
    • 仮説検証が Notebook で素早く行え、これが有益かどうかの検討が手軽に行えるようになった
    • まずは Notebook で「これで本当に分析できるか?」を確かめ、確信を持ってからダッシュボードとして正式に整備する、というフローを検証できた

Datadog Notebook は、監視や o11y*6 といったメイン機能に比べると、正直なところ影が薄い印象があります*7。しかし、実際に使ってみると「ダッシュボードを作るほど大掛かりではないが、メトリクスエクスプローラーよりは踏み込んだことがしたい」という場面で大変丁度よいツールです。

メトリクスエクスプローラーでは複数メトリックの取扱が勿論可能ですが、どうしてもその場限りの確認になりがちです。一方、 Notebook であれば複数のメトリックを時系列や比率で比較した「論理構造」をそのまま残しておけます。これはつまり

  • グラフの側に「なぜこの数字を見たのか」というコンテキストを記録できる
  • 一時的な調査結果を、そのままチーム内への共有レポートとして転用できる
  • ダッシュボード化する前の「プロトタイプ」として活用できる

このように、一種の「思考の跡地」としての価値が生まれるわけです。

ダッシュボード化する前の下書きとして、あるいは一時的な調査レポートとして。便利な手段のひとつとして Datadog Notebook があるという点、認知に貢献できたら幸いです。

MNTSQ 株式会社 SRE 秋本

*1:https://docs.datadoghq.com/dashboards/

*2:例:https://docs.datadoghq.com/monitors/guide/monitor-arithmetic-and-sparse-metrics/

*3:私的にこれが一番あります

*4:https://docs.aws.amazon.com/opensearch-service/latest/developerguide/createupdatedomains.html の語法に則り「ドメイン」と呼びますが、データノードおよび専用マネージドノードの集合体という意味から「クラスタ」と同一視してよいはずです

*5:Elasticsearch であることから実際には JVM ヒープメモリ量などの状況も重要になります。今回このあたりを引っ括めて "RAM" と読んでいます

*6:observability;可観測性。本稿を読んでいる方には釈迦に説法感がありますが念の為

*7:これまで在籍してきたいくつかの会社でわたしは Datadog Notebook を使ってきましたが、いざ共有などすると「こんな機能があったのか!!!」という反応に毎度なります