TSKaigi 2026 TypeScriptバックエンドのオブザーバビリティ戦略 — Datadog × NestJSの実践

Transcript

1. TypeScript バックエンドの オブザーバビリティ戦略 ｜ Datadog × NestJS の実践 2026. 05. 23 TSKaigi 2026 ⼭本 ⼤星 ∕ any 株式会社
2. ⾃⼰紹介 2 • エンジニア歴 9 年⽬, TypeScript 歴 5 年⽬ • Java/PHP/Vue.js 4 年 → React/NestJS 5 年 • ⼤⼿通信事業者でWebアプリ&バーチャルオフィスSaaS → any (現職 2 年半前) • 機能開発の傍ら 約 2 年前に Datadog 導⼊PJを推進 • 直近: 技術的負債解消/パフォーマンス, DX改善の専任チーム ⼭本 ⼤星 any 株式会社
3. 3 ユーザー数 80,000 ⼈突破 BOXIL SaaS AWARD 2021 ⼤企業賞 IVS Launchpad 5位 ⼊賞 社内に埋もれている情報や⼈のノウハウを蓄積し、 RAGを使っていつでも引き出せるようにすることで、 組織全体の⽣産性向上と組織の壁を超えるサービス。 ナレッジの資産化が、 企業の未来をつくり出す。 AIナレッジプラットフォーム
4. 技術スタックの紹介 4
5. オブザーバビリティとは 5
6. (私の考える)オブザーバビリティとは 6 運⽤トラブルの原因特定をスムーズに⾏うための “仕込み” よくあるトラブル ‧「あれ、なんかシステムがうまく動かないぞ」 ‧「お客さんから問い合わせ、クレームがきちゃった」 ‧「なんかエラーログ、アラートが上がってるな」 こういう時に「原因に辿り着きやすい状態」を作ること
7. オブザーバビリティ > 例えばこんなことができる状態1 7 DBの調査 どのレコードが悪さしてるのかな 外部システムの影響 レイテンシ増加が原因なのかな アクセス急増の要因分析 単にユーザー増？ それともバグでリダイレクトが⼤量発⽣？ はたまたDoS 攻撃？ → 「もうちょっと調べてみよう」ができる状態
8. オブザーバビリティ > 例えばこんなことができる状態2 8 ベテランならできること → 誰でも判断しやすい状態にする ベテラン 新顔 不慣れな⼈ ベテランの判断 新顔や普段運⽤に慣れてない⼈
9. Datadog導⼊以前(〜2024)の構成 9 ログ集約‧エラー検知 CloudWatch Logs AWSベースの 最⼩限の構成 コンテナ停⽌の通知 EventBridge → Lambda → Slack
10. 現在(2026)の構成 10 👏👏
11. 現在(2026)の構成 11 APM: アプリケーションのトレース 👏👏
12. 現在(2026)の構成 12 Error Tracking: エラーの集約‧分析 👏👏
13. 現在(2026)の構成 13 Dashboard: 各種メトリクス‧監視データを集中管理 👏👏
14. 現在(2026)の構成 14 👏👏
15. 現在(2026)の構成 15 👏👏 ツールを⼊れるだけ ではオブザーバビリティは向上しない 🙅 アプリケーションも⼀緒に “進化” させる必要がある
16. TypeScript バックエンドの オブザーバビリティ戦略   Datadog × NestJS を2年かけて整備し⾒えてきた   “気負わない運⽤”のためのアプリケーション設計
17. 2つのセクションに分けて話します 17 1. ⼊⾨者向け オブザーバビリティこれからやっていき 2. Datadog初級者向けTIPS 💪 👀 Datadog を導⼊検討中、運⽤はじめた ばかりの⼈ プラグイン有効化の罠 ちょうど良い dd-trace 依存のすゝめ ログを構造化する エラーの情報量を増やす ❶ ❷ ❶ ❷
18. 2つのセクションに分けて話します 18 1. ⼊⾨者向け オブザーバビリティこれからやっていき ログを構造化する エラーの情報量を増やす ❶ ❷ 💪 Datadog を導⼊検討中、運⽤はじめた ばかりの⼈ プラグイン有効化の罠 ちょうど良い dd-trace 依存のすゝめ ❶ ❷ 👀 2. Datadog初級者向けTIPS
19. 1. ログの “構造化” とは 19 Before: ⾮構造化（⼈間向け） After: JSON 構造化（機械向け） なぜ嬉しいか • フィールド単位で検索‧集計やアラート構築できる⼟台 • 後の trace_id 連携‧プロパティ付与の⼟台
20. 1. ログの “構造化” > Datadog での⾒え⽅ 20
21. 1. ログの “構造化” > 設定コード例 — NestJS の場合 21 NestJS docs: Logger # json-logging のサンプルを参考に • 本番では JSON、ローカルでは⾊付き text • これだけでログの フィールド検索‧集計 がしやすくなる
22. 2. エラーのプロパティを増やす 22 Before: スタックトレースとメッセージだけ After: エラークラス名 / context / cause を追加 • エラークラスにこれらのプロパティを適切に保持、Loggerで出⼒されるようにする • エラー発⽣時の状況 が⾒えやすくなる
23. 2. エラーのプロパティを増やす > コード例 23 • cause チェーンで発⽣源クラスを特定, context にエラー発⽣時の状況を保持 • ログ出⼒時に toJSON が呼び出されると各種エラー情報がログで確認できるように
24. 次にいきましょう 24 オブザーバビリティこれからやっていき ログを構造化する エラーの情報量を増やす ❶ ❷ 💪 2. Datadog初級者向けTIPS 👀 Datadog を導⼊検討中、運⽤はじめた ばかりの⼈ プラグイン有効化の罠 ちょうど良い dd-trace 依存のすゝめ ❶ ❷ 1. ⼊⾨者向け
25. TIPS1: Datadogライブラリに巻き込まれてアプリが落ちた話 25 1.ドキドキのリリース完了 2.鳴り⽌まないアラート 3. リバートするしか... 事前検証もOKだったし、 ライブラリ⼊れて APM 動かすぞ！ えっ落ちるはずない… 事前にちゃんと調べたし… 他に原因なさそうだし仕⽅ない …あれ、アラート⽌まったぞ
26. TIPS1: APMプラグインが悪さをしていた模様 26 • 後⽇調べたら Maximum call stack size exceededエラー が直接的な原因であることが判明 • SQLクエリなどを確認できる APMのDBプラグインを無効化することで事象を抑⽌ できた • APMのプラグインは⾃動で全て有効化される仕様 • 根本原因ははっきり特定できなかったが、おそらく GraphQL の Field Resolver による深いネスト再帰処理 とアプリのDBライブラリが関係してそう ※APMプラグイン=各種ミドルウェア/ライブラリの詳細をトレーシングできる機能
27. TIPS1: APMプラグインが悪さをしていた模様 27 • 後⽇調べたら Maximum call stack size exceededエラー が直接的な原因であることが判明 • SQLクエリなどを確認できる APMのDBプラグインを無効化することで事象を抑⽌ できた • APMのプラグインは⾃動で全て有効化される仕様 • 根本原因ははっきり特定できなかったが、おそらく GraphQL の Field Resolver による深いネスト再帰処理 とアプリのDBライブラリが関係してそう ※APMプラグイン=各種ミドルウェア/ライブラリの詳細をトレーシングできる機能 APMプラグインの有効化は慎重に！
28. TIPS2: dd-trace に “ちょうど良く” 依存する 28
29. 29 1.書き込み 投稿の作成/更新/削除 投稿データの永続化 変更イベントを キューイング 2.イベント発⾏ 3.メッセージ取得 4.インデックス 更新 インデックス 更新作業 ⾼速な全⽂検索を実現 dd-trace が関知してくれない TIPS2: dd-trace に “ちょうど良く” 依存する SQS編
30. 30 1.書き込み 投稿の作成/更新/削除 投稿データの永続化 変更イベントを キューイング 2.イベント発⾏ 3.メッセージ取得 4.インデックス 更新 インデックス 更新作業 ⾼速な全⽂検索を実現 dd-trace が関知してくれない TIPS2: dd-trace に “ちょうど良く” 依存する SQS編 独⾃に APM のトレースを開始するような処理を書かないといけない 書き⽅によっては “dd-trace にがっつり依存するようなコード” に⚠
31. TIPS2: dd-trace に “ちょうど良く” 依存する SQS編 31 アプリ層 ⾃作ライブラリ層 Datadog - ビジネスロジックに集中 - - @qast/sqs-helpers - tracer は import しない × SQS受信/メッセージ処理の抽象化 span の⽣成‧タグづけ Datadog依存をライブラリ内で完結 dd-trace による トレース情報の作成 APM / Trace @EventPattern('updateEntry') async handle(@Payload() msg) { // ビジネスロジック } handler を書くだけ await tracer.trace( `processMessage ${pattern}`, async span => { span.addTags({ 'sqs.body': message.Body }); await handleMessage(); }); ⾃作 SQS Transport内
32. TIPS2: dd-trace に “ちょうど良く” 依存する Logger編 32
33. TIPS2: dd-trace に “ちょうど良く” 依存する Logger編 33 アプリ層 ⾃作ライブラリ層 Datadog - ビジネスロジックに集中 - - @qast/logger - tracer は import しない × trace_id / span_id が⾃動付与 Logs (構造化ログ) APM / Trace this.logger.log( ‘User updated entry’, { entryId, userId } ); logger を呼び出すだけ const span = tracer.scope().active(); if (span) { tracer.inject( span.context(), formats.LOG, output ); } ⾃作 Logger 内 対応するリクエスト‧処理にジャンプ trace_id / span_id で紐付け ..., "dd": { "trace_id": "1234567890...", "span_id": "9876543210..." }
34. まとめ 34 1. ⼊⾨者向け オブザーバビリティこれからやっていき 2. Datadog初級者向けTIPS Datadog を導⼊検討中、運⽤はじめた ばかりの⼈ プラグイン有効化の罠 ちょうど良い dd-trace 依存のすゝめ ログを構造化する エラーの情報量を増やす ❶ ❷ ❶ ❷ 💪 👀
36. おまけ. ログに共通コンテキストを載せる 36 Before: 「何が起きた」だけ After: 「誰の何の処理か」が全ログ共通でわかる • 単発ログ → requestId などをベースに一連の 追跡可能なログへ • 顧客からの問い合わせに対応しやすくなる
37. おまけ. 共通コンテキスト > コード例 37 • 呼び出し側は何も意識せず logger を呼び出せば適切な context がセットされる • NestJSでは nestjs-cls ライブラリを使うのが慣⽤だったりする