はじめに
こんにちは！ yu-Matsuです。
今年のre:Inventもワクワクする発表が目白押しでしたね！ 私は幸いなことに今年は現地参加することができたのですが、参加したハンズオンセッションの中で特に面白いと感じた AWS DevOps Agent について記事にしたいと思います！
AWS DevOps Agent
AWS DevOps Agent は、re:InventのKey Noteの2日目にて発表された、Frontier Agents になります。
DevOps Agentは、常時稼働する自律型のエージェントで、インシデントが発生すると、メトリクスやログから最近のコードデプロイまで、DevOps全体のデータを自動的に分析してくれます。 そこから根本的な原因を特定し、対象を絞った緩和策を提案してくれるので、平均解決時間（MTTR）の短縮にも繋がります。
また、過去のインシデント全体にわたるパターンを分析し、インシデントを予防案も提供してくれるとのことです。
私が受けたハンズオンでは以下のような説明がありました。
-
DevOps Agentは Team Player である：
- ServiceNow や PagerDuty などの既存のツールからのインシデントチケットやアラームに自動応答してくれる上に、調査をして行く上で分かったことに関して、チケットを更新したりSlack等に通知してくれます
- また、Dynatrace Davis のような他のエージェントサービスとも連携できます
-
DevOps Agentは、Telemetry Expert である：
- Amazon CloudWatch、Datadog、Dynatrace、New Relic、Splunk などと連携して可観測性データを収集できます。また、MCPサーバーを通して、組織独自のカスタムツールや、専門プラットフォーム、GrafanaやPrometheusなども統合できます
- アラート、メトリクス、ログ、トレースをクエリして根本原因分析（RCA）を実施し、可観測性態勢の改善を推奨してくれます
-
DevOps Agentは、Pipline Pro である：
- GitHub や GitLab と統合でき、インシデントの原因となったコードデプロイを特定し、ロールバックの手順を提供してくれます
- インシデントを防止するためのパイプライン改善策も提案してくれます
-
DevOps Agentは、あなたのアプリを知っている
- 詳細なアプリケーションのトポロジグラフを構築・維持し、タスクの実行を通知・誘導してくれます
- SteeringファイルとRunbookから組織の実務慣行やプロセスを学習します
実際に試してみた
今回は、私が受けたハンズオンの一部を変更して再現してみたいと思います。
インシデントシナリオとして、「API Gatewayで5xxエラーが発生した」ケースを想定します。
1. インシデントを発生させる準備
まず、適当な API Gateway + Lambda でAPIを作成します。DevOps Agentは現状バージニア北部で利用可能であるので、リージョンはバージニア北部（us-east-1） を選択してください。
（手順は省略。Lambdaは単純に"Hello World!"を返すもので大丈夫です）
監視アラームを設定しておく必要があるため、CloudWatch Alarmにてアラームを作成します。メトリクスは 5XXError を選択。画像を省略していますが、アラーム名は「ApiGateway5xxAlarm」とします。
監視の閾値はテストのため一回でもエラーが出たら発報されるようにします。
これで準備は完了！
2. DevOps Agent のエージェントスペースを作成
次に、DevOps Agentの設定をしていきます。
まずは、DevOps Agentのコンソールを開いて、エージェントスペースを作成していきます。画面の「Begin setup」を押下します。
作成画面が開きますので、適当なスペース名をつけます。
「Give this Agent Space AWS resouce access」は、「Auto-create a new DevOps Agent role」を選択します。こちらはエージェントがAWSのリソースにアクセスするための権限です。
「Enable web app」も、「Auto-create a new DevOps Agent role」を選択。こちらは後述するDevOps Agent用のWebアプリの権限になります。これで設定が一通り終わりなので「create」を押下。
すると、エージェントスペースの画面に遷移します。しばらく待つと、画像下部のように「Topology」にアカウント内のリソースの検出結果が表示されます。（指定しているリージョン以外のリージョン情報も含まれます。）
Topologyの「Topology graph」タブを開くと、検出されたリソースの関係性がトポロジーグラフで表示されます。下画像例は私用アカウントのため結構リソースが多くぐちゃぐちゃですが、ご容赦を...
こちらもアカウント内の全リージョンのリソースのトポロジーグラフが表示されます。
us-east-1のエリアをよくみると、今回の対象のAPIも検出されていることが分かります。
これでDevOps Agentのエージェントスペースの作成は完了です！
3. インシデントを発生させる
まずはインシデントを発生させましょう。
シナリオとして「API Gatewayで5xxエラーが発生した」ケースを想定するので、今回はLambdaの同時実行回数を0にすることでスロットリングを発生させ、APIの実行が失敗するようにします。手順は省略しますが、Lambdaの詳細画面の「設定」タブから「予約された同時実行」を0に設定できます。
実際にインシデントを発生させます。Webブラウザでもcurlでも良いので、APIのエンドポイントを叩いてみます。すると上手くいっていれば以下のように「Internal server error」が発生します。
しばらく待って、CloudWatch Alarm から先ほど作成したアラームを確認してみます。
すると、こちらも問題なくアラームが「アラーム状態」になっています。
これでインシデントを発生させることができました。
4. DevOps Agent にインシデント調査をさせてみる
それでは、実際にインシデント調査をさせてみたいと思います。
まずは、エージェントスペースの画面で「Operator access」を押下します。
すると、以下のような DevOps Agent のWebアプリが開きます。
デフォルトで開かれている「Incident Response」タブにて、インシデント調査を行なって行くことになります。「Start an investigation」の「Start investigation」を押下してみます。
すると、以下のように investigation の設定画面が開くので、必要情報を入力していきます。「Investigation details」には、エージェントに調査させたい内容を入力します。今回はアラーム名を指定しています。
Investigation details は今のところ日本語に対応していなさそうなので、英語で指定するのが無難かと思います。
「Name your investigation」は適当に設定。
ここまで設定できたら、「Start investigating...」を押下して、調査を開始させます。
すると、インシデント調査が開始します。
「Investigation timeline」にエージェントが調査している過程が順に表示されていきます。
まずは、User Requestを見る限り正しく要求を理解してくれていることが分かります。
これからinvestigationのタイムラインが大量に続くので、必要に応じて読み飛ばしてください
アラームの状態変化の履歴を見ているようです。
アラームからAPIの情報を取得しています。
APIとその裏のLambdaに関して調査を始めました。
しばらく経つと、Lambdaの予約実行数が0になっていることを発見しました！
以降、さまざまな角度から調査を行い、Lambdaの設定に原因があることを確認しています。
そのうち、Lambdaのエラーは発生していないのに、スロットリングが発生していることに気づきました。
そこからエージェントがインシデント調査のまとめにかかります。
２枚目の画像では、Lambdaの予約実行数が0であることを「Root Cause」であると決定しました。
調査が完了したので「Finding」ステータスLambdaの予約実行数が0であることが原因だと表示しています。
最後に「Root cause」ステータスで、最終的な調査結果が表示されています。
これで調査が完了となります。
問題なくエラー原因を突き止めてくれました！🎉
5. 調査結果を確認し、緩和策を提案してもらう
タイムラインの「Root cause」における「Go to root cause」を開くと、調査結果のサマリが表示されます。
内容を確認した上で、緩和策を提案してもらいましょう。「Generate mitigation plan」を押下します。すると、新たに「Mitigation Plan」タブが生えまして、緩和策が生成され始めます。
しばらく待つと、以下のような緩和策が生成されました！
現状のLambdaの状態とアラームの設定を確認し、予約実行数を正しい値に修正するまでの手順がかなり丁寧に説明されていますし、CLIのコマンドまで紹介してくれているので、このままコマンドをコピペ貼り付けで対応できそうですね！
6. インデント予防策を提案してもらう
最後に、今回のインシデントを踏まえての予防策を提案してもらおうと思います。
エージェントのWebアプリ上部の「Prevention」タブを開きます
すると以下のような画面が表示されますので、画面右上の「Run now」を押下します。
しばらく経つと生成が完了し、画面が以下のように変わります。「Agent summary」では提案内容のサマリが記載されています。
AWS Configでlambdaの予約実行回数の変更を検知して不適切であればSNS等で通知するように提案していますね。
「Recommendations」から提案内容の詳細を見ることもできます。
提案内容は「Overview」「Background」「Next Steps」「Considerations」の４つで構成されるようです。
以上が DevOps Agent の簡単なデモになります！
実際のハンズオンでは、これ以降にDynatraceと統合する例もあったのですが、それはまた機会があれば...
さいごに
今回は、先日発表されたばかりの AWS DevOps Agent を実際に試してみた記事でした！ ドキュメントだけだとなんとなく凄いことはわかりますが、re:Inventのセッションで実際に自分で動かす機会があったのは感じがつかめてかなり良かったです！
所感としては、今までからよく言われていた「生成AI（エージェント）がチームの一員になる」が誇張表現ではなくなってきたのを感じました。正しくDevOps Agentの説明にもあった「Team Player」を体現しているのではと思います。
今回のインシデントは単純なものだったのでまだなんとも言えませんが、もし複雑なインシデントでも同様の精度で調査してくれるのであれば、今まで我々が頑張ってログやモニターを見て調査していたストレスが解消されるのではと感じました。
Mitigation案を生成した際に、案を出すだけでなく実際に実行までしてくれるとさらに良いなぁ（コマンドまで出してくれてるので...）、と思いましたが、まだPreview版ということもあり、今後に期待ですね！
本記事はこれで以上になります。最後までご精読いただきありがとうございました！