「どのログを見ればいい？」 から始めた サーバーレス障害解析

ログは各サービスにあっても、障害調査で困るのは「経路のつながりが見えない」こと。そこをAthenaでの段階的絞り込み → Bedrock AgentCoreによる調査支援の仕組み化、という流れで解決していく話。

Transcript

1. SERVERLESS × TROUBLESHOOTING 「どのログを見ればいい？」 から始めた サーバーレス障害解析 ログを残す≠原因を追える AWS Observability 現場のリアル 三菱電機株式会社 若井(y_waka1) © Mitsubishi Electric Corporation
2. 自己紹介 これまで 2019–2021 非機能・クラウド設計支援 AWS / Azure の仕様調査、性能・コスト検討 2022–2024 量産システムとデータ分析基盤の開発・運用 若井 祐樹 @y_waka1 AWSサーバーレス開発 2025– 生成AI・MLOps 生成AI活用、MLOps、開発プロセス改善 好きなAWSサービス このLTとの接点 AWSサーバーレスシステムの開発・運用と、障害解析を経験 今日は、そこで感じた 『ログはあるのに追えず、原因調査が進まない』経験をお話しします 02 © Mitsubishi Electric Corporation
3. 当時のシステム構成 サービス・経路は説明用に一部省略／変更しています STATIC 静的コンテンツ Client CloudFront DynamoDB API APIアクセス Client API Gateway AWS Lambda Amazon S3 DynamoDB IoT 非同期 メッセージ Amazon S3 Device MQTT AWS IoT Core AWS Lambda Amazon S3 ログはサービスごとにある。けれど処理は、サービスをまたいで流れる。 Icons: AWS Architecture Icons (2026 Q3) 03 © Mitsubishi Electric Corporation
4. ログはちゃんとある、けど…… 各サービスのログ・メトリクスは取得済み 障害発生 CloudFront API Gateway Lambda DynamoDB IoT Core S3 ログが「ない」 わけではない。 で、最初に どれを見る？ ある日、 障害が起きて初めて困った。 04 © Mitsubishi Electric Corporation
5. なぜ分からなかったのか 01 症状はひとつ 02 候補はたくさん 03 つなぐのは人間 ! 「データを登録できない」 「デバイスから届かない」 CloudFront？ API Gateway？ Lambda？ DynamoDB ？ IoT Core？ ログの種類が増えるほど 関係性を頭の中で組み立 てる ログの量ではなく、経路のつながりが見えていなかった。 05 © Mitsubishi Electric Corporation
6. Athenaで「何が分かるか」から始めた 1 2 対象期間で絞る 例：障害発生前後の時間帯に限定 ステータス別に集計 例：5xx応答が通常時より増加 Amazon Athena 3 原因を直接見つける 道具ではなく、 調査範囲を 絞る道具 当時の記憶に基づく再構成 4 URI・デバイス別に比較 例：特定APIに偏りがあるか確認 次に見るサービスを決める 例：到達状況から深掘り先を選ぶ 手順を重ねるほど、次に確認するログが少なくなる 説明用の架空例です。実データ・実クエリ・実障害原因の再現ではありません。 Icon: AWS Architecture Icons (2026 Q3) 06 © Mitsubishi Electric Corporation
7. 調査は「広く」から「深く」へ 調査対象を段階的に絞り込む 広く見る 障害発生 何が起きた？ 時間帯 いつ増えた？ エラー傾向 何が増えた？ API/ デバイス どこに偏る？ 対象 サービス どこまで 届いた？ 詳細ログ なぜ失敗した？ 原因 検証して確定 架空例：5xx増加 → 特定APIに集中 → Lambda到達済み → 後段を詳しく見る 深く見る 説明用の架空例です。実障害の再現ではありません。 07 © Mitsubishi Electric Corporation
8. 今ならどうする？ 当時 現在 Metrics / Logs / Traces Athena + SQL 検索 → 結果を見る → 仮説を立てる → またSQL 人間が仮説検証を繰り返す AI 関連情報をまとめる → 仮説候補を整理する AIが整理し、人間が検証する AIがあっても、可観測性（Observability）の土台となる「何を観測し、どう関連付けるか」は設計する。 Icons: AWS Architecture Icons (2026 Q3) 08 © Mitsubishi Electric Corporation
9. 「どのログを見るか」を選ぶ仕組みを作ってみた ARCHITECTURE 簡略アーキテクチャ OUTPUT 処理をオーケストレーション AWS Step Functions Amazon EventBridge Amazon Bedrock AgentCore Runtime AWS Lambda ログ取得・集計 Strands Agents / 深掘り先を判断 日次スケジュール Lambda tools 追加集計 できたもの Amazon Bedrock Knowledge Bases 過去比較 Amazon S3 レポート保存 Guardrails PII保護 Amazon SNS 通知 リソース名・識別情報のみ省略 ログを読むAIではなく、見るべき場所を選び、調査の入口をつくるAI。 09 © Mitsubishi Electric Corporation
10. 持ち帰ってほしいこと 01 当時の学び 02 AIOps時代 ログは「残す」だけでなく、 「どこを見るか」を絞れる形にする AIには整理を任せ、 原因は人間が検証する 原因探しの前に調査範囲を小さくし、 次に確認するログを選べるようにする。 時間・ID・経路でデータを関連付け、 AIが仮説候補を扱える観測設計を用意する。 「どのログを見ればいい？」に答えられる観測設計から、Observabilityは始まる。 10 © Mitsubishi Electric Corporation