Datadogの導入事例

11年もののJavaScriptのモノリスをTypeScriptのマイクロサービスへ移す途中で、出したリリースを戻す手段がなかった。

AIの機能も本番へ出し始め、不具合が起きたときの切り戻しが重い作業になっていた。

1. BFF層にDatadog Feature Flagsを置いた。
2. 古い仕組みと新しい仕組みの振り分けをフラグで切り替える。
3. 準備できた機能から5%のカナリアで出す。
4. AIの機能も同じやり方でまず少人数に見せる。
5. APMなどで原因が自社側かAzure側かを切り分ける。

リリースの切り替えが30分の手動の再デプロイから10秒のフラグ操作になった。

バックエンドの入れ替えは利用者に見える不具合ゼロで終わった。

障害が起きるたびに当番のエンジニアがSlackの部屋を手で作り、関係者を一人ずつ呼んでいた。

誤った警報も多くて通知が信用されなくなり、振り返りの文書づくりも重い負担になっていた。

1. 障害対応を気づく・宣言・共有・対処・振り返りの5段階に決めた
2. その5段階を全部Datadogの上に組み直した
3. 当番が宣言するとSlackの部屋が自動で作られる
4. 応急処置はWorkflow Automationで自動か半自動で動かす
5. OpenAI APIで振り返りの最初の原稿を書かせ人が直して確定した

誤った警報が大きく減って当番の疲れが軽くなり、振り返りを一から書く手間もなくなった。

障害に気づくまでの時間は平均3.89分まで縮んだ。

36のキャンパスにまたがる約200のシステムを別々の監視ツールで見ていて、全体をつないで原因を追うのが難しかった。

利用者から先に不具合を知らされることも多かった。

1. インフラやアプリやログやDBの監視をDatadogに寄せた。
2. 指標とトレースとログを1つの画面で突き合わせられるようにした。
3. 社内向けの相談役を作り土台にDatadog MCP Serverを置いた。
4. 開発者の普通の言葉の質問をMCPがDatadogへの問い合わせに直す。
5. 使い始めはSREと運用のチームだけで後に開発チーム全体へ広がった。

調査にかかる時間が80%減り、よくある確認は最大5分かかっていたものが1分未満で終わるようになった。

入学の申込時期に起きた遅さは原因がアプリではなくリクエストを振り分けるWebサーバーだと分かり、増強して復旧できた。

AIエージェントの処理が増えるほどLLMの費用が膨らんだが、クラウドの請求では合計しか見えなかった。

どの顧客やどのモデルが費用を押し上げているかを調べるには手作業の集計が必要だった。

1. Datadog for Startupsで早い段階から監視の土台を入れた
2. Agent Observabilityと独自のメトリクスで記録した
3. 顧客・モデル・工程など20以上の切り口のダッシュボードを作った
4. 監視の設定はコードで管理し異常時に通知が飛ぶようにした
5. 技術者は新しいAI機能を出すたびに影響を自分で確かめる

AIにかかる費用を年28万ドル分減らした。

費用や性能の急な悪化もほぼ即時に気づけるようになった。

AlarmyとDAROを同じ基盤で動かしているのに、プラットフォームを見るエンジニアは2〜3人だった。

信号はあちこちに出ていても一つの画面でつながらず検知から復旧までの時間を縮めにくかった。

1. Datadogを入れてモバイルからデータベースまでの信号をまとめた。
2. アプリはMobile RUMで追いサーバはAPMとKubernetesで見る。
3. 稼働データを30日間で99.9〜99.95%を狙う7つのSLOへ流す。
4. アラートに影響としきい値と対象のサービスを入れた。
5. 原因の切り分けをBits AIに任せた。

Bits AIを入れてから障害の調査が速くなり、人に引き継がなくても解決できる問題が増えた。

原因を見つけるまでの時間も短くなった。

これまでの監視ではエージェントがどう考えて答えを出したのか分からなかった。

エラーが出ずAPIも成功しているのに応答の質だけが落ちていくことがあり原因を探すのに時間がかかっていた。

1. Amazon Bedrock AgentCoreの上にエージェントを組んだ
2. Strands Agents SDKでエージェントの動きを記録させた
3. OpenTelemetryのGenAI規約でDatadogへ自動で送る
4. 本番前にトレースと評価を見比べて使うモデルと設定を決めた
5. 本番でも評価を回して幻覚や個人情報の漏れを検知する

評価をもとに使うモデルを選べるようになりエージェントと道具と基盤のトレースが1つにつながった。

試作から本番までの道のりも速くなった。

本番で動くAIアシスタントの中身が見えず、不具合が出ると技術者が利用者のやり取りを手元で再現して調べていた。

到着予想のモデルも本番で返している値をすぐ確認できず、データウェアハウスへ手で問い合わせて最大1日待っていた。

1. DatadogのAgent Observabilityを入れた
2. やり取りをプロンプトと出力とツール呼び出しまで追えるようにした
3. 長い会話で遅くなる型を見つけプロンプトを直し要約させる作りを足した
4. 到着予想の遅延と出力値をCustom Metricsで見張った
5. 検証環境のトレースも同じ画面で見て出す前に確かめた

エージェントの不具合を直すまでの時間が短くなり、到着予想を返す仕組みの速さも改善した。

本番の状態をその場でつかめるようになった。

SulAméricaは2,000を超えるサービスを複数のクラウドと自社のデータセンターで動かしていたが、監視のツールがばらばらでつながっていなかった。

障害のときは画面を行き来して指標とトレースを手で結び付けるしかなく、対応が遅れてSLAを守りにくかった。

1. 2025年1月にDatadogを選び3月までに移行を終えた。
2. アプリの性能監視でトレースをたどり障害の根っこを探す。
3. コンテナはBits AIに任せ問題のあるワークロードを直す。
4. 毎週土曜の午前6時に自動の処理を走らせイメージ取得の失敗を片づけた。
5. SREがAI機能でトレースを突き合わせレート上限の変更が原因だと突き止めた。

別のチームが4時間かけても分からなかった障害の原因をAIの支援で短い時間で突き止めた。

メモリの使用量は250MBから150MBに減り、割り当て容量は400GBから240GBに下がった。

AIが製品の中心になり画像生成のような重い処理をいつでも素早く返す必要があった。

ユーザーの操作からモデルの推論までが何層にも分かれていて遅さの原因がどこにあるか分からなかった。

1. メトリクスとログとトレースをDatadogに1つに集める
2. APMでバックエンドとAIの処理の流れを見えるようにした
3. 可用性と応答時間の目標を本番の実績から決める
4. Real User Monitoringで地域や端末ごとの使い勝手も取る
5. 特定のモデルのバージョンで推論時間の伸びを突き止めた

検知から原因の特定までが速くなり平均復旧時間が約40〜50%短くなった。

デバッグにかかる時間も同じくらい減り複数のツールを行き来せずに済むようになった。

AWS上で急に規模が広がり、10個のKubernetesクラスタと300のワークロードを抱えることになった。

サービスごとに作ったELKのログを人が探し回っていて、障害対応の時間の70%がログ探しに消えていた。

1. AWSのEKSへ移すのに合わせてHelmチャートでDatadogを入れた
2. サービスIDやチーム名や環境やクラスタ名を先に決める
3. 指標とトレースとエラーログを1つのダッシュボードへ集めた
4. Service Mapでどこで落ちているかを目で追う
5. アラートをきっかけに担当チームへ手順つきで通知する

3つ以上のツールを行き来しなくても1つの画面で指標とログを追えるようになった。

どのチームのどのサービスがどこで動いているか数クリックで分かり、障害の切り分けが進めやすくなった。

ログと処理の追跡が別々のツールに散っていて、障害のたびに手で突き合わせる手間がかかっていた。

警告とログの量も増え、大事なものを選び出すのが難しくなっていた。

1. 散らばった監視ツールをDatadogへまとめた
2. AWSとつなぎEC2やLambdaの状態をすぐ見える状態にする
3. 取り込み方とタグ付けを決める専任チームを作った
4. WatchdogとBits AIに関係の深い信号を拾わせる
5. 警告は担当するチームへ自動で振り分けた

監視に使うツールを13本やめ、問題が解決するまでの時間が35%短くなった。

障害の発生は40%減り、Watchdogでは異常を最大3時間早く見つけられるようになった。

20人ほどのチームで何百もの病院が使う仕組みを支えていて、不具合の報告が来ても原因にたどり着くまで数時間かかっていた。

多くのAIモデルを同時に動かしているため、本番での動きが見えないままでは直しに入れなかった。

1. アプリとインフラとデータベースの情報をDatadogへ集めた
2. 社内のAIエージェントにDatadogのAPIをつなぐ
3. ログや処理の追跡や操作記録を自分で選んで読ませた
4. 不具合の報告から該当する利用者と関わる機能を割り出す
5. 患者の情報はDatadogへ送らない決まりにした

一部の不具合では原因の切り分けが数時間から数分になり、90%短くなった。

問い合わせを受けた担当者だけで調べて返せるようになった。

サイトとアプリを自社で作る形に切り替えたが中の状態が見えず、不具合に気づくのは客に影響が出た後だった。

外部のSaaSが多く全体をまとめて見張る手段がなかった。

1. 97項目の要件で試して満たしたDatadogを選んだ
2. APMで主要なサービスを見える形にして目標値と画面を作る
3. RUMで実際の利用者の動きを確かめ公開前にエラーをメールで拾う
4. 予約と搭乗手続きの流れを定期的に試して失敗したら知らせる
5. 障害のときは見立てを添えた調査で原因を切り分ける

原因の切り分けが速くなり、客に影響が出る前に直せるようになった。

いまは社内の100人以上が毎日Datadogを見て主要なサービスの状態を追っている。

GPUが1,700台の規模に増えたのに割り当ては人の手で行い回収の基準も無かった。

Microsoft Azureと社内の環境でダッシュボードが分かれ誰がどこで何台使っているかをExcelへ書き写していた。

1. GPUの流れを申請から回収まで5段階で決めた
2. SlackでのGPU申請でDatadogのインシデントを自動で作った
3. 発行されたIR番号をGPUノードにタグとして付けた
4. タグのAPIでクラウドと社内のGPUを追った
5. インシデントの状態をActive・Stable・Reservedで管理した

1,700台以上のGPUと60件以上のAIプロジェクトについてプロジェクト単位の使用状況を一つの画面で見られるようになった。

申請から回収までが自動で回りExcelへの手入力と画面の切り替えが要らなくなった。

数百のクラウドアカウントをばらばらのツールで見ていたため全体の動きと費用がつかめなかった。

国の決まりを守りながら費用も下げる必要があった。

1. ICFに相談して候補を比べ試験導入で中身を確かめた
2. Datadogに監視とAPMとログと費用管理をまとめた
3. AWSとGCPの300超のアカウントをつないだ
4. AIが出す改善案を費用の見直しに回した
5. ダッシュボードをアプリと部門ごとに分けた

ライセンス費が25%超下がった。

300超のAWSとGCPのアカウントで費用が見えるようになり700台を超えるホストを1つの画面でまとめて見られるようになった。