Slide 1
Slide 1 text
Amazon DevOps Guru
のベー
スラインを整備して1
ヶ月ほ
ど運用してみた
川原 征大
2025-06-10
1
Slide 2
Slide 2 text
Table of Contents
イントロ
DevOps Guru
について
DevOps Guru
を導入してみた
DevOps Guru
を少し運用してみて
(
時間あれば)
通知の仕組み
おわりに
2
Slide 3
Slide 3 text
イントロ
3
Slide 4
Slide 4 text
自己紹介
Classmethod
クラウド事業本部 コンサルティング部
https://dev.classmethod.jp/author/kawahara-masahiro/
4
Slide 5
Slide 5 text
最近仕事でやっていること
AWS
マルチアカウント環境のセキュリティ可視化
コスト最適化いろいろ
好きなこと
ツーリング、ゲーム、Emacs
、愛猫と戯れる
5
Slide 6
Slide 6 text
(
本題の前に) AWS
環境について
6
Slide 7
Slide 7 text
組織環境
AWS Organizations
環境
AWS
アカウント数: 40
以上
複数の利用部門/
システムが存在
7
Slide 8
Slide 8 text
私の役割
CCoE
の技術メンバー として活動
全AWS
アカウントの統制(
ベースライン)
各利用部門とのコミュニケーション
8
Slide 9
Slide 9 text
DevOps Guru
について
9
Slide 10
Slide 10 text
DevOps Guru
とは？
AWS
アプリケーションの運用問題を自動検出・予測するマネージド監視サ
ービス
機械学習を使ってリソースのメトリクス/
ログを分析
異常なパフォーマンスや障害の兆候を インサイト として自動生成
10
Slide 11
Slide 11 text
小ネタ:
昔の公式ドキュメント 機械翻訳 「DevOps
アマゾンの達人」
画像引用:
※ Guru =
指導者
AWS
上のアプリの障害監視をAI
に任せる(DevOps Guru + Chatbot
のカスタム通知) - Zenn
11
Slide 12
Slide 12 text
インサイトの種類
事後的インサイト(reactive):
既に発生した問題を検出
予測的インサイト(proactive):
将来発生する可能性のある問題を予測
12
Slide 13
Slide 13 text
ほか補足
エージェント不要でワークロードに影響なし
分析した分の従量課金。気軽に始められる
多くのリソースタイプに対応(25
以上)
13
Slide 14
Slide 14 text
料金グループA:
約$2/month
14
Slide 15
Slide 15 text
料金グループB:
約$3/month
15
Slide 16
Slide 16 text
DevOps Guru
を導入してみた
16
Slide 17
Slide 17 text
導入の目的
1.
信頼性向上
2.
パフォーマンス効率向上
3.
コスト最適化
RDS
が総コストの相当な割合を占有
ボトルネックとなるクエリやDB
固有の問題を特定して、 パフォー
マンス効率を改善できれば…
→
結果的にコスト最適化に繋がるはず！
17
Slide 18
Slide 18 text
目標
各利用部門のAWS
アカウントにて リソースに特定タグを付与するだけで、
DevOps Guru
分析をすぐに開始できる状態。
18
Slide 19
Slide 19 text
実装方法
CloudFormation StackSet
として全アカウントに展開
AWSTemplateFormatVersion: "2010-09-09"
Description: Enable DevOps Guru baseline
Resources:
### リソース収集の設定
CollectionByTagKey:
Type: AWS::DevOpsGuru::ResourceCollection
Properties:
ResourceCollectionFilter:
Tags:
- AppBoundaryKey: devops-guru-monitoring
TagValues:
- default # 複数値指定可
### ログ異常検知機能を有効化(追加コスト無し)
EnableLogAnomalyDetection:
Type: AWS::DevOpsGuru::LogAnomalyDetectionIntegration
DependsOn: CollectionByTagKey
19
Slide 20
Slide 20 text
補足:
分析対象の登録方法
アカウント全体
サポートされる全てのAWS
リソースを分析(
コストに注意)
CloudFormation
スタック単位
特定のスタックに含まれるリソースを分析
タグベース(
★今回の方式)
特定タグベースで分析
20
Slide 21
Slide 21 text
やらかしポイント:
ワイルドカードの罠
少し寄り道します。
21
Slide 22
Slide 22 text
最初のテンプレート（間違い）
Q.
このときの挙動はどうなる？
.oO(
特定タグが付いているリソース "
のみ"
が分析される…
？)
# 抜粋
CollectionByTagKey:
Type: AWS::DevOpsGuru::ResourceCollection
Properties:
ResourceCollectionFilter:
Tags:
- AppBoundaryKey: devops-guru-monitoring
TagValues:
- "*" # ← ワイルドカード！
22
Slide 23
Slide 23 text
起きたこと
A.
全リソーススキャン が発生！
その日に気づいてロールバック。
全リソーススキャンが走った日の DevOps Guru
使用タイプ別コスト
23
Slide 24
Slide 24 text
教訓:
タグ値は指定しよう
ワイルドカードを設定すると…
1.
アカウント内の全リソースをスキャン する (
ここ大事)
2.
指定タグがあれば、その値がアプリケーション境界としてグループ化
される
な挙動になる。
24
Slide 25
Slide 25 text
DevOps Guru
を少し運用してみて
25
Slide 26
Slide 26 text
トライアル
以下2
件、1~2
ヶ月 分析させてみた。
利用部門の Aurora MySQL
CCoE
管理の NAT
ゲートウェイ
26
Slide 27
Slide 27 text
Aurora MySQL
での検証
事前に Performance Insights
を有効化 ※
タグを付与してもらって分析開始
※
の前提条件。より高精度/
詳細なインサイトを生成で
きる
DevOps Guru for RDS
27
Slide 28
Slide 28 text
→
結果:
インサイトは特に出なかった😢
(
いい解釈をすると、特に問題は無かった)
28
Slide 29
Slide 29 text
CCoE
管理 NAT
ゲートウェイでの検証
前提:
各AWS
アカウントのアウトバウンド通信を、CCoE
管理 NAT
ゲートウ
ェイに集約している
CCoE
管理NAT
ゲートウェイを分析
29
Slide 30
Slide 30 text
→
結果:
数件のインサイトが発生
30
Slide 31
Slide 31 text
NAT
ゲートウェイのインサイトを深堀り
31
Slide 32
Slide 32 text
出てきたインサイト
The number of idle connections to NAT Gateway nat-example
increased
32
Slide 33
Slide 33 text
DevOps Guru
のマネコン画面
インサイトの概要
33
Slide 34
Slide 34 text
グラフ化された異常
34
Slide 35
Slide 35 text
集約されたメトリクス
35
Slide 36
Slide 36 text
関連イベントリスト、ほか
36
Slide 37
Slide 37 text
レコメンデーション
37
Slide 38
Slide 38 text
追加で確認したこと
「どこからどこへの通信」が局所的に発生したか、 DevOps Guru
インサイ
トだけでは分からなかった。
38
Slide 39
Slide 39 text
追加調査1: VPC Flow Logs
の分析
Source/Destination
のIP
を特定する
39
Slide 40
Slide 40 text
追加調査2: DNS
クエリログ の分析
Destination
ドメインを特定する
40
Slide 41
Slide 41 text
最終的なアクション
事象をまとめて利用部門に連携
アプリログなどを見てもらうよう依頼
41
Slide 42
Slide 42 text
(
時間あれば)
通知の仕組み
42
Slide 43
Slide 43 text
モチベーション
所感:
マネージドCloudWatch
アラーム みたいで良い感じ
→
高重要度のインサイトはやっぱり通知させたい
43
Slide 44
Slide 44 text
通知の仕組み構築のハマりポイント
前提: Organizations
連携でメンバーアカウントを委任管理者にできる
委任管理者内でインサイトを集約して確認可能
44
Slide 45
Slide 45 text
ただし委任管理者内の [
設定 >SNS
トピック]
や EventBridge
イベントには集
約されない 。
45
Slide 46
Slide 46 text
最終的に実装した通知アーキテクチャ
EventBridge → Lambda → SNS → Q → Slack
46
Slide 47
Slide 47 text
通知サンプル
(
展望: Bedrock
あたりを呼び出して、インサイトを要約させて通知したい)
47
Slide 48
Slide 48 text
思ったこと
インサイトの通知テストがめっちゃ面倒！
機械学習による異常検知のため意図的な発生が難しい
GuardDuty
のようなサンプル生成 API
が欲しい…
！
48
Slide 49
Slide 49 text
おわりに
49
Slide 50
Slide 50 text
まとめ
DevOps Guru
はAWS
アプリケーションの運用問題を自動検出・予測するマネ
ージド監視サービス
事後的インサイト、予測的インサイトがある
従量課金で気軽に始められる
全リソーススキャンには注意
使ってみた感想
関連するメトリクスやイベントを良い感じに並べてくれる
推奨事項も出してくれる
→
マネージドCloudWatch
アラームみたいな感じで良さそう
50
Slide 51
Slide 51 text
参考情報
What is Amazon DevOps Guru? - Amazon DevOps Guru
Amazon DevOps Guru | Pricing
AWS
上のアプリの障害監視をAI
に任せる(DevOps Guru + Chatbot
のカス
タム通知) - Zenn
CloudFormation
を使って DevOps Guru (
タグで分析対象を指定)
を有効
化する | DevelopersIO
51
Slide 52
Slide 52 text
聞いていただき、ありがとうございます！
52