Server-TimingとDevOpsエージェントを用いたLambdaコンテナの動的ルーティング制御

2026/07/09 AWS Summit Japan 2026 振り返らNight！の登壇資料です。

Transcript

1. Server-TimingとDevOpsエージェントを用いた Lambdaコンテナの動的ルーティング制御 2026/07/09 AWS Summit Japan 2026 振り返らNight！ usanchu
2. ① AWS Summit出展ブース「ヘッダー 1 行から始める！ レイテ ンシ改善」のデモに衝撃を受けた！ ② 「Server-Timing×DevOpsAgent」を自分のサイトで再現し て検証してみた 今回の内容
3. 発表者について フジイ ヒカリ と申します・x・ 2026 Japan AWS Jr.Champions 社会人2年目：SIerのアーキテクチャチームでSEしてます AWSについて　 保有資格：CLF,AIF,SAA,MLA,DEA ★パフォーマンスチューニングに興味があります！ X：@usanchuu
4. ① AWS Summit出展ブース「ヘッダ ー 1 行から始める！ レイテンシ改善」 のデモに衝撃を受けた！
5. LT内容の背景：AWS Summit出展ブース「ヘッダー 1 行から始め る！ レイテンシ改善」のデモに衝撃！ ※ブースのタイトルが見切れており申 し訳ございません Amazon CloudFront が付与する Server-Timing メトリクス ×DevOpsAgent「異常検知から改善 提案」まで、自動でおこなえることに 驚き ↓ 自分の環境での再現してみたい！！
6. デジタル名刺用に自分のドメインを取得したので、 たくさん遊んでいきたい！ ↓ バックエンドに Java 17 / JVM を採用 ：ランタイムが重く、ヒープ管理（GC）のスパイク によってアプリが一瞬完全にフリーズする特性 ↓ 意図的に負荷をかけたい検証にうってつけ！ LT内容の背景：最近ドメイン取得した
7. ② 「Server-Timing×DevOpsAgent」 を自分のサイトで再現して検証してみた
8. 検証の目的 ② 「Server-Timing×DevOpsAgent」を自分のサイトで再現して検証してみた 遅延状態を意図的に発生させ、エラーを検知→コンテナの自 動制御・復旧させる仕組みを構築・検証する 1. バックエンド遅延の可視化 GCによるフリーズ状態がServer-Timingとして正しく視覚化させる 2. コンテナの自動制御、復旧 システムの異常を検知した際、環境変数をリセットして自動でルーティング制御と復旧を行う 3. AIエージェントによる原因分析の評価 AWS DevOps Agentがインフラ全体の因果関係をどこまで正確に自律分析できるかを評価
9. フロー図 ② 「Server-Timing×DevOpsAgent」を自分のサイトで再現して検証してみた ※Gemini Canva生成 ①Javaの内部遅延 を可視化 ②ユーザー側の影響 をRUMで収集 ③Pythonによるルーティン グの自動初期化 ④AIによる根本原因の特定
10. 構成図 ② 「Server-Timing×DevOpsAgent」を自分のサイトで再現して検証してみた
11. 検証スタート！ 1回30MBのリクエストを1クリック で5回送り込む処理を実装 ↓ Java Lambdaのメモリ（128MB） を溢れさせ、OutOfMemoryを大量 発生させたい ② 「Server-Timing×DevOpsAgent」を自分のサイトで再現して検証してみた
12. CloudFrontのレスポンスヘッダー ポリシーでServer-Timingをオン 　　　　　　　　↓ ブラウザの待ち時間（2.55s）の内 訳を一元化 遅延の主因がJavaのGC（578ms） であると即座に特定できた! ①Server-TimingによるJava内部遅延の可視化 ② 「Server-Timing×DevOpsAgent」を自分のサイトで再現して検証してみた
13. ②ユーザー側の影響をRUMで収集 ② 「Server-Timing×DevOpsAgent」を自分のサイトで再現して検証してみた Server-Timing をCloudWatch RUMが自動で回収 閾値超過を検知し、 CloudWatch AlarmがALARMに 遷移
14. ③Pythonによるルーティングの自動初期化 アラームの ALARM 遷移をトリガー に、ミリ秒単位で復旧Lambdaを自 律起動 ② 「Server-Timing×DevOpsAgent」を自分のサイトで再現して検証してみた 環境変数の動的上書きにより、コンテナ 設定を強制リフレッシュして自動復旧
15. ④AIによる根本原因の特定 Pythonコード内にWebhook連携を組み込 み、インシデント通知を自動でPOSTするよ う実装した ↓ 手動でアクションを入れなくても、自動的に 調査を開始してくれる！ ② 「Server-Timing×DevOpsAgent」を自分のサイトで再現して検証してみた
16. ④AIによる根本原因の特定 Pythonが書き換えた環境変数を瞬時に見 つけ、 「自己回復の挙動」だと正確に調査 ② 「Server-Timing×DevOpsAgent」を自分のサイトで再現して検証してみた
17. ログの文脈や命名規則から、これが意図 的な「サンドボックス」だと見透かす ④AIによる根本原因の特定 ② 「Server-Timing×DevOpsAgent」を自分のサイトで再現して検証してみた 時系列データを横断分析し、エラーの実 体は500（OutOfMemory）ではなく 503（同時実行数の急増）であると判断
18. まとめ ★OOM（500）を起こすつもりが「同時実行数超過（503） 」が主因と判 明！ DevOpsAgentは人間の思い込みを正す最強のパートナー！ ★自作の自動復旧コードに「メモリを増やさなければ根本解決にならない」 とガチレビュー