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