その運⽤、まだ⼈が抱えますか？ - AWS DevOps Agentの価値 クラスメソッド株式会社 クラウド事業本部運⽤イノベーション部 ⼤野育海∕礒松和佳奈 

運用監視現場のリアル 2 あなたの現場でも起きていませんか？ 大量のアラート地獄 夜間対応 慢性化した人手不足 本当に拾うべき1件が 深夜のモニタールームで 度重なる人員交代による ノイズアラートの中に埋もれていく 鳴り響くアラート通知音 ナレッジ不足と属人化 

アジェンダ 1. AWS DevOps Agentとは 2. AWS DevOps Agentの活用 3. AWS DevOps Agent ユースケース 4. まとめ 5. 事例紹介 3 

AWS DevOps Agentとは 

AWS DevOps Agent インシデントを 調査(根本原因特定)・解決策を提示・予防する フロンティアエージェント 特徴 1 インシデント内容と解決策を提示 インシデントを調査し、根本原因の特定を支援。 「常時稼働の自律的オンコールエンジニア」として 24×365で稼働。 特徴 2 将来のインシデント予防 過去のインシデントのパターンを学習し、"次に同じ障害を起こさないためにどうすべきか"を提案。 監視の強化・インフラの改善・デプロイの安全性向上・障害からの復旧力強化の4つの観点で、具体的な改善策 を示してくれる 4 

AWS DevOps Agent 5 既存ツールと 統合 オブザーバビリティ ツールと統合 デプロイ履歴を活用した 原因調査 チャットツールと連携 Amazon CloudWatch、 GitHub や GitLab のコードリ ServiceNow / PagerDuty / Dynatrace、Datadog、New ポジトリ、CI/CD パイプライ Slackに調査結果・根本原因・ Relic、Splunkと標準で統合。 ンと統合。コード変更やデプ 推奨アクションを共有。 画面キャプチャを貼り付けず ロイ履歴をテレメトリと関連 独自MCP サーバも接続でき、 に、各ツールの監視データや 付けて、障害やパフォーマン 社内ツールなどにまで拡張可 アラートを直接読み取ること ス低下の原因調査に活用でき 能。 ができる。 る。 

AWS DevOps Agentの活用 

費用対効 果 6 Webアプリの[API Error]をAWS DevOps Agentに調査させてみた結果・・・ DevOps Agent が裏でやっていたこと CloudTrail から 5回 のデプロイ履歴を時系列で取得 CloudTrail：3 min 51 sec Lambda関数のログを横断クエリ・エラー突合 Logs Insights：8 min 17 sec Lambda Errors / API Gateway 4XX・5XX を 期間比較 CloudWatch Metrics：7 min 21 sec DynamoDB 2 テーブル の PutItem 失敗を特定 DynamoDB：2 sec 関係する API エンドポイント 4 本 を逆引き API Gateway：10 sec CloudFormation ChangeSet と 原因コミット を関連付け CloudFormation：6 min 26 sec 調査時間合計：約 12 min 並列実行 

費用対効 果 7 Webアプリの[API Error]をAWS DevOps Agentに調査させてみた結果・・・ これを人力でやるとしたら、どれくらいかかりますか？ DevOps Agent が裏でやっていたこと CloudTrail から 5回 のデプロイ履歴を時系列で取得 CloudTrail：3 min 51 sec Lambda関数のログを横断クエリ・エラー突合 Logs Insights：8 min 17 sec Lambda Errors / API Gateway 4XX・5XX を 期間比較 CloudWatch Metrics：7 min 21 sec DynamoDB 2 テーブル の PutItem 失敗を特定 DynamoDB：2 sec 関係する API エンドポイント 4 本 を逆引き API Gateway：10 sec CloudFormation ChangeSet と 原因コミット を関連付け CloudFormation：6 min 26 sec 調査時間合計：約 12 min 並列実行 

ベストプラクティス 8 STEP 1 本番環境と非本番環境を分ける Agent Spaceを Agent Spaceはエージェントが調査できる範囲。 まずは運用監視チームの責任範囲に合わせてスコープを設計し、本番環境とステージング／開発環境を 分けて管理する。 攻略しよう ポイント 調査に必要な情報を含めつつ、対象を広げすぎない STEP 2 IaCで設定を標準化する * Agent Space IAMロール・外部統合、タグをCDK / Terraformでテンプレート化。 ・AWS DevOps Agentが調査できる範囲を決める 複数アカウントの場合でも一貫した設定で展開できる。 単位 ポイント ・対象となる AWS アカウント、外部ツール連携、 手作業(GUI操作)ではなく、同じ品質で横展開できる状態を作る 調査参加メンバーをまとめて管理 ・AWS DevOps Agentの運用において、 核 となるリソース STEP 3 調査データを繋ぐ CloudWatch／Datadog／New Relic／GitHub／Slackなどを繋ぎ、対象環境の調査範囲 を拡げることで、原因調査の精度を向上させる。 ポイント エージェントが見られる情報を増やすことで、調査の精度が上がる 

9 アラート重要度で 線を引く 運用が AWS DevOps Agent のコストを正当化する High アラート重要度 Amazon CloudWatch チケット管理ツール (ex. PagerDuty) Midium Low 

AWS DevOps Agent ユースケース 

ユースケースと動作フロー 1. Lambda実行時にエラーが発生！ 2. CloudWatch Alarmで検知、SNSに配信 3. SNSからPagerDutyにAPI経由で連携 4. PagerDutyでイベント整形/フィルタリングを実施の上で、インシデント起票 5. DevOpsAgentがキックされ、インシデントの内容をもとに調査を開始 6. エラーログおよび、連携しているGitHubリポジトリを含め包括的に調査実施 7. GitHubのコミット履歴から、最終更新時のコードソースにバグがあることを発見 8. 調査結果をPagerDutyのインシデント（メモ）に追記 10 

全体図 - Lambdaのエラー調査 

マルチアカウント対応 ● セカンダリアカウント側でIAMロールを作成し、信頼関係を設定するこ とで、プライマリアカウントの調査対象にできる ● メンバーアカウントで発⽣するリソースやセキュリティの問題を、管理 アカウント側で横断的に調査することが可能 ● 前提条件 ○ プライマリアカウントの AWS DevOps エージェントコンソールへの アクセスが可能 ○ セカンダリ AWS アカウントへの管理アクセスが可能 ○ セカンダリアカウントでロールを作成するIAMアクセス許可がある 13 

全体図 -マルチアカウント- 

まとめ 

まとめ（ベストプラクティス） 15 ● スコープとパフォーマンスのトレードオフを理解する ○ 自組織において最適な、Agent Spaceの分割範囲を考える ○ アプリ単位、環境単位（本番/環境）、チーム単位etc… ● 適切なアクセス制御を設定する ○ 調査の閲覧、サポートケースの起票、Agent Spaceなど、誰がどこまで操作して良 いのかを明確にして、ポリシーによる制御を実施する ● 接続する機能を増やす ○ 各種監視ツールやコードリポジトリなどデータソースが多いほど、根本原因分析の 精度向上が期待できる ● 調査結果に基づいて設定値を調整する ○ 調査結果に応じてAgent Spaceのスコープ見直しを実施する 

まとめ（機能⾯） ● DevOpsAgentの強み（＝価値） ○ 周辺ツールとの豊富なネイティブ連携 ○ 第一歩の敷居が低い （GUIで導入可能） ○ CDK、Terraformを利用したIaCでのデプロイも可能 ○ マルチアカウント設定 による、組織内アカウントの横断的な調査 16 

まとめ（機能⾯） 強みを引き出すためのオススメの使い方 ● 渡すデータ（イベント）の前処理をしてあげる ○ 必要なイベントやアラートだけ調査させる ○ 監視設定や、ノイズ削減について見直す ○ 重要インシデントの見逃し軽減、利用料金の削減、Agentの学習の効率 化、など効果が期待できる 上記は一例です 環境に応じたベストな使い方を模索しましょう！ 17 

事例紹介 (運用支援について ) 

事例紹介（株式会社ミラクル経理 様） 18 クラスメソッドマネージドサービス ご⽀援ポイント ⼈員不⾜、ノウハウ不⾜により課題となって いたインフラ運 ⽤ 監 視に対して、24/365の MSPをご提供。 インシデント発⽣時の確認や対応をオフロー ドいただくことで、インフラ運⽤の負荷を⼤ 幅に低減。 豊富なナレッジに基づき、弊社からの改善提 案を適宜実施。 before after • ⾃社開発のSaaSを⽴ち上げたいが、AWS基盤の運⽤ノウハウが不⾜ • ローンチまでにインフラ運⽤までを内製するのは現実的でない • 継続的な監視‧運⽤による負荷を軽減したい • • • • 解決策として「クラスメソッドマネージドサービス」をご提供 AWSインフラ基盤に対する24/365のインシデント監視 インシデント発⽣時の⾃動通知、対応状況の可視化 インシデントの内容に基づき、プロアクティブな改善のご提案 お客様の声 「軽微なアラートが⾃動でクローズされ、そ の内容が共有される仕組みは⼤きな助けに なっています。状況の把握や対応⽅針につい て整理された情報を受け取れる点は、⼤きな 安⼼材料になっています。すべてを⾃分たち で追い続ける必要がなくなりました。」 

事例紹介（某⼤⼿⼩売事業会社 様） [Before] ・CCoEチームを立ち上げたものの、 将来像や活動範囲の定義が無く、 活動が個人の場当たり的な対応に。 19 [After] ・クラスメソッドの知見を元にした ガイドラインやサービスカタログを整備。 ・運用の属人化により、スキルの標準化が 図れておらず、運用品質がバラバラ。 セキュリティ運用の穴も不安な状態。 CCoEチーム ・お客様業務を理解の上で、組織目標や役割等 を提案・再定義。業務が回るまで伴走支援。 → スキル平準化による運用品質向上と、 ガバナンス/セキュリティの強化を実現。 CCoEチーム コスト 削減 クラウド 利用促進 サーバー運用 セキュリティ 運用 クラスメソッド オペレーション成熟化支援 チーム 組織目標 ガイドライン サービスカタログ SLA/KPI の検討・定義 中長期目標・計画策定 etc.. ルールひな型・標準化 

No content