こんにちは。SCSK1年目の渡辺です。
今年の re:Invent、皆さんご覧になられたでしょうか。
今年も例年どおり多くの発表があり、かなり盛り上がっていましたね。
私はリアルタイムでの参加はできず、いくつかアーカイブを視聴した程度ですが、
現地に行かれた方の話を聞く機会があり、来年は絶対行ってやる！！と思いました。
会場の熱量など、日本とは別世界なんだな、と改めて感じました。
（kiroのぬいぐるみ欲しかった、、、）
前置きはこのあたりにして、今回の re:Invent の中でも、特に注目を集めていたサービスの一つが AWS DevOps Agent だったと思います。
社内外を含めて「今回の目玉はAWS DevOps Agent」と言っている方も多く、
実際のところどんなことができて、運用業務でどこまで使えそうなのかが気になりました。
そこで今回は、
AWS DevOps Agent を実際に触ってみて、管理画面や挙動を確認しながら、運用目線での所感を整理してみました。
本記事では、「サービス概要の紹介」と、「実際に触ってみてどう感じたか」
といった観点でまとめています。
AWS DevOps Agentとは
AWS DevOps Agent は、インシデント発生時の初動対応や原因調査を、AI エージェントが支援するためのサービスです。
CloudWatch をはじめとした監視・可観測性の情報をもとに、影響範囲の特定や原因候補の洗い出しを自動で行い、運用担当者の判断をサポートします。
従来の運用では、アラートを受け取った後に
「どのリソースが影響を受けているのか」
「直前に何が変更されたのか」
「どこから調査を始めるべきか」
といった点を、人が個別に確認する必要がありました。
AWS DevOps Agent は、こうした作業を横断的に整理し、インシデントの状況をまとめて提示してくれます。
また、単に障害の原因を示すだけでなく、
過去の事例や検知したパターンをもとに、再発防止のための改善案（監視設定や構成見直しの提案など）を提示してくれます。
「調査して終わり」ではなく、次のアクションまでを意識した設計になっている点は、実運用を強く意識したサービスだと感じました。
また幅広い他ツールとの連携も特徴の一つで、New RelicやDatadogなどの監視ツールや、ServiceNowなどのチケット管理ツールなどと連携することができ、従来の運用フローを大きく変更することなく、DevOps Agentを導入することが出来ます。
AWS DevOps Agent は、運用を完全に自動化するものではなく、あくまで 人の判断を前提とした支援ツール という位置づけです。
インシデント対応のスピード向上や、調査観点の標準化といった点で、運用業務の負荷軽減に貢献するサービスになっています。
インシデントを発生させてみる
それでは早速、アラートを発砲させてみましょう！
今回はEC2インスタンスのCPU使用率が80%を越えるとアラートを発砲するようにアラームを作成し、SSMでインスタンスに接続、CPU負荷コマンドを実行しました。コマンド実行からしばらく置いてから、AWS DevOps Agentに調査を依頼しました。
実行コマンド
stress --cpu 1 --timeout 300 --load 50
調査プロンプト
#Please investigate the incidents that occurred within the last 24 hours.実際の調査画面
さて、、どのように調査を進めてくれるでしょうか、、、、
見ていきましょう！
1.調査開始→アラート検知
こんな感じの画面で調査が進みます。
画面中央には調査対象リソースが表示され、画面下部で調査の進捗が確認できます。
画面右側はAIチャットエリアになっており、調査を進めながらAIと対話をすることが出来ます。
無事今回のアラートを検知してくれましたね！
2.障害調査
アラート前後で発生した事象や、アラートが発生したと同時に何が起こっていたかなどを、調査しながら、グラフを用いて説明してくれています。
情報が多く載せきれないですが、直近のログや、AWS環境内の細かな変化など、かなり様々な角度から調査をしてくれます。
3.根本原因特定→対応策提示
調査開始から5分ほどで根本原因まで特定し、
「今回はSSM接続でCPU負荷をかけるコマンドが実行された」と結論付けてくれました。
大正解！！ですね。
対応策も見てみると、「とりあえずは必要ありません。今回は意図的にCPう負荷コマンドが実施されただけなので」と言っており、場合にもよりますが、テストまで見抜けるのはさすがだなと感じました。
終わりに
ということで、今回は AWS DevOps Agent を実際に触って検証してみましたが、いかがだったでしょうか。
個人的には、想像していた以上に多角的な観点から分析を行ってくれる点が印象的でした。
アラート発生時の初動対応や、原因のあたりを付ける段階において、
「まず DevOps Agent に調査させてみる」という使い方は十分に有効だと感じました。
一方で、実運用するうえで課題になりそうな点も感じました。
今回の検証は構成が非常にシンプルだったため、調査はシンプルに完了しましたが、
リソース数が多い環境や、アラートが複雑に組み合わさったケースでは、調査時間が長くなってしまったり、思わぬ部分で意外とコストが重なってしまった。ということになる可能性があると感じました。
また、現時点ではプレビュー段階ということもあり、
バージニア北部リージョン（us-east-1）のみ対応、UI が英語のみといった制約もあります。
日本語対応の日が待ち遠しいですね！！
今回はDevOps Agentの管理画面内で完結する形で検証しましたが、Lambda と連携してアラート発生時に自動で調査を開始したり、
Slackなどと連携して調査結果を随時通知するといった使い方など、運用フローに組み込む余地は多く、活用の幅はかなり広そうです。
まだ発展途上のサービスではありますが、
運用効率化の観点から、一度は実際に触ってみる価値のあるサービスだと感じました。
興味のある方は、ぜひ実際に触ってみてください！！