Slide 1

Slide 1 text

はじめてのDatadog AI開発とオブザーバビリティ 1

Slide 2

Slide 2 text

丸山  海理 所属 役職 出身地 出身校 趣味 好きなAWS サービス SNS (株)サンエー 情報システム部 課長 京都府 琉球大学  法文学部  経済 スポーツ観戦(サッカー/野球) KIRO cli @KairiM0kinawa 2

Slide 3

Slide 3 text

基幹システムを内製開発    技術スタック 2026 Main Architecture Layers Design & Frontend API & Backend Database & Auth Data Analytics Infrastructure DevEx & Observability AI-Driven-DX Quality &Tools Ops & Collab 3

Slide 4

Slide 4 text

すべてのプログラムを コントロール出来ていますか? 迫る期限、品質の担保、予算や技術の課題。バイ ブで生まれたブラックボックスのコード。実際の 開発現場ではすべてのプログラムを完璧な状態に保 つのはなかなか難しい。 4

Slide 5

Slide 5 text

品質の低下 → チームの疲弊・・・ 解決できない 4XX / 5XX エラー・・・ 突然のレイテンシー悪化・・・ UI/UXに関するクレーム・・ 未知の未知・・ 5

Slide 6

Slide 6 text

Datadog で解決しよう!! オブザーバビリティツールであるDatadogを活用し 正しく・素早く問題を解決。ユーザー体験を良く して信頼性を勝ち取ろう!! 6

Slide 7

Slide 7 text

Datadog を使うモチベーション Serverless Architecture 今までのようにサーバーのCPUやメモ リの使用量、ロードアベレージだけで は問題解決に至らない・・・ Multi Account or Cloud 大量のアカウントをまたいで、ログを 見に行くのは大変。マルチクラウドな らなおさら・・・ 運用負荷軽減 もちろん左記をOSSで対応することは 可能かもだが・・・一定の技術力が必 要。またOSSの運用負荷もある。 7

Slide 8

Slide 8 text

オブザーバビリティとは? 観測可能性とは、システムの外部出力に関する知 識から、その内部状態をどの程度正確に推測でき るかを示す尺度である 出典:CNCF Observability White Paper https://github.com/cncf/tag-observability/blob/main/whitepaper.md#what-is-observability System Output Metrics Logs Traces Profiles infer 内部を推測 8

Slide 9

Slide 9 text

Datadog APM(Application Performance Monitoring) 9

Slide 10

Slide 10 text

↑様々なタグで フィルタリング ←Tracesの情報は Flame Graph や Waterfallな ど様々な見方が可能 Lambdaのコールドスタート 等も把握 ←MetricsやLogsもタブの切替 だけで一元管理 10

Slide 11

Slide 11 text

APMで見れるもの・出来ること ↓Profiles では関数内のどの処理がメモリを使っているかまで把握 11

Slide 12

Slide 12 text

これからは、Bits アシスタントに聞くだけでいいかも ↓かなりの精度でAIが質問に答えてくれる 12

Slide 13

Slide 13 text

再現不可・迷宮入りを回避する ユーザーからの報告を受けて、エラーの状況を再 現しようとしても、全く再現せず迷宮入りするケー スはないですか? 13

Slide 14

Slide 14 text

RUM(Real User Monitoring) ユーザーの動きを可視化する!! 14

Slide 15

Slide 15 text

実際に・・・ 自分のローカル環境でどれだけ再現しよう としても再現できなかった、動作がRUM のセッションリプレイをみて解決。 15

Slide 16

Slide 16 text

生成AI時代の開発 Code Developer GenAI Code Code 生成AIによりコードのアプトプットは増加 16

Slide 17

Slide 17 text

生成AI時代の開発 Code Review Build TEST Deploy Developer GenAI Code Code それらを捌くCI/CDが重要 17

Slide 18

Slide 18 text

生成AI時代の開発 Code Review Build TEST Deploy Developer GenAI Code Code レビューの待ちやPipeline自体の遅延が発生するケースも 18

Slide 19

Slide 19 text

生成AI時代の開発 Code Review Build TEST Deploy Developer GenAI Code Code PipelineもDatadogでO11Y出来る = CI Visibility 19

Slide 20

Slide 20 text

詳しい話は今日参加している賢者にお任せ 20

Slide 21

Slide 21 text

生成AI時代の開発 Code Review Build TEST Deploy Developer GenAI Code Code おざなりにすると予期せぬバグが混入 21

Slide 22

Slide 22 text

生成AI時代の開発 Code Review Build TEST Deploy Developer GenAI Code Code だからこそのO11Y、だからこそのDatadog !! 22

Slide 23

Slide 23 text

実際に・・・ ↑もともと3並行でAPIが叩かれすぐに終わるはず処理が ↑AIによって直列に書き換えられていた・・・・ がTraceで発見!! 23

Slide 24

Slide 24 text

す べての情報を活用したAI活用 System post-mortem MD DatadogのMCPを使って目指せ一発解決! MCP IaC 24

Slide 25

Slide 25 text

実際にMCPで調査・修正・確認を行ってみた 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ## デプロイ前後の比較 | | 旧バージョン (2026.03.16.1135) | 新バージョン (2026.03.18.1148) | |---|---|---| | 直近15分のログ総数 | 1,660 | 2,297 | | DD_EXTENSION エラー | 8件 | 2件 | | エラー率 | 0.48% | 0.087% | 新バージョンでのエラーは logout 関数の1回分(2行で1セット)のみ です。 ## 評価 大幅に改善しています。旧バージョンでは全関数で満遍なく発生していたのが、新バージョンでは logout の み1件 に激減しました。 logout で残っている理由は、Okta への refresh token revocation がタイムアウトしている問題(別件のエ ラー)と関連している可能性があります。Okta 側のタイムアウトで Lambda の実行時間が長引き、Extension のフラッシュタイミングに影響しているケースです。 もう少し時間が経って全 Lambda が新バージョンに切り替わったら、ほぼゼロに近づくと思います。30分後く らいにもう一度確認しますか? 25

Slide 26

Slide 26 text

まとめ 26

Slide 27

Slide 27 text

・Datadogの機能を使って、自分のサービスの中身を知ろう! APMを駆使することで、バックエンドの課題を発見 RUMでユーザーの振舞いを可視化 ・AI開発時代のO11Y 生成AIによる非破壊的な変更をすぐにキャッチ MCPを使えば、原因の切り分け、対策、経過観察までお任せ ・O11Yを推進する設計や組織論 課題を発見した後、チームとして対応できるのか? アーキテクチャーとしても対応可能か? 27