概要

AWS DevOps Agentは、生成AIを活用して運用業務を支援するサービスです。障害発生時の調査から解決までを自律的にサポートしてくれます。

以前、下記ブログで紹介していただいたように、ログを分析する仕組みを自前で構築しました。DevOps Agentを使用すると、こういった仕組みをマネージドサービスとして利用できます。

今回は障害発生から調査までの流れや、AWSサポートへの起票、マルチアカウントでの使用を試してみたいと思います。その前に、DevOpsエージェントの基本について以下に記載します。

DevOps エージェントの構成

DevOps エージェントの設定はマネジメントコンソールから行います。

まず、エージェントスペースを作成します。エージェントスペースはDevOpsエージェントがアクセスできる範囲を定義する論理的なコンテナです。例えば、マルチアカウントで使用したい場合は、アクセス対象のAWSアカウントを追加します。

実際の運用はDevOps エージェントウェブアプリから行います。このウェブアプリにはエージェントスペース作成後、上記マネジメントコンソールの「オペレータアクセス」のリンクからアクセスできます。

ここからは、エージェントアプリ内の主要コンポーネントを見ていきます。

トポロジ

エージェントスペース内のリソースとその関係性を自動検出し、トポロジグラフとして可視化する機能です。リソースの検出はCloudFormationスタックとAWS Resource Explorerを通じて行われ、関係性の検出は構成データ、リソースタグ、CI/CDパイプライン、観測性ツールのデータを分析して行われます。トポロジページでは、構成図のように環境全体を俯瞰できます。

スキル

エージェントに提供する手順をSKILL.mdなどのマークダウンファイルで作成する仕組みです。これにより、同様の指示を繰り返す必要がなくなり、特定の専門知識を持ったエージェントを構成できます。

スキルには2種類あります。1つ目がユーザーが調査手順やドメイン知識をSKILL.mdに記述して作成するカスタムスキルです。

2つ目はDevOpsエージェントが自動生成する構造化知識ファイルである学習スキルです。学習スキルの1つにAgent Space Understanding（エージェントスペース理解）があります。これは、接続されたクラウドアカウント、コードリポジトリ、テレメトリインテグレーションを分析し、リソースと関係性のマップを構築します。新しいエージェントスペースのトポロジ検出完了時に自動生成され、トポロジページの視覚表示にも使用されます。

エージェントの指示

スキルがSKILL.mdのdescriptionに記載された条件に一致した場合にオンデマンドで読み込まれるのに対し、エージェントの指示はAGENTS.mdファイルとして保存され、各セッションの開始時にシステムプロンプトに無条件で挿入されます。つまり、条件によるスキップが発生せず、確実に指示が組み込まれます。

エージェントの指示には2種類あります。すべてのエージェントに適用されるグローバル指示と、チャット、インシデントトリアージなど特定のマネージドエージェントに対して適用されるエージェント固有の指示です。

DevOpsエージェントの利用方法

DevOpsエージェントには3つの利用方法があります。

1つ目は自律型インシデント対応です。モニタリングツールやチケットシステムとの連携、ウェブフックからの通知をきっかけにエージェントが自律的に調査を開始します。手動でインシデントを起票して開始することも可能です。

2つ目はオンデマンドDevOpsタスクです。チャットインターフェースを通じてエージェントと対話しながら作業を進めます。調査中のインシデントを見ながら「このログをもっと詳しく調べて」「別の仮説を検証して」といった指示も可能です。

3つ目はプロアクティブインシデント防止です。過去のインシデント履歴を分析し、再発防止のための改善提案を定期的に生成します。

DevOpsエージェントの検証

ここからは実際に自律型インシデント対応を試してみます。シンプルな例として、EC2を停止し、誰がどういった状況で停止したかの情報を調査します。

エージェントスペースの設定

まずエージェントスペースを作成します。ここはエージェントスペース名やIAMロールの設定のみなので割愛します。

今回はマルチアカウントでの検証ということで、もう一つのアカウントをDevOpsエージェントの管理対象にします。設定方法はこちらのドキュメントにあります。

手順は以下のとおりです。

DevOpsエージェントを設定したアカウント（プライマリアカウント）でAWS DevOps エージェントコンソールからセカンダリリソースの追加を行う

ロール名を指定する。ここで表示される信頼ポリシーとインラインポリシーをメモしておく

接続先のアカウント（セカンダリアカウント）で、前の手順でメモしたロール名と信頼ポリシーを使用してIAMロールを作成する。許可ポリシーにはAWSマネージドポリシーのAIDevOpsAgentAccessPolicyをアタッチし、さらに前の手順でメモしたインラインポリシーを追加する

プライマリアカウントに戻って設定を完了する。セカンダリリソースのステータスがアクティブになることを確認する

スキルの作成

SKILL.mdを作成します。自分で記述することもできますが、今回はチャットを使用して作成しました。

壁打ちが完了すると下記のようにスキルが作成されます。指示はかなり細かく作成されていますが、ここでは一部のみを記載しています。

インシデント調査

インシデントレスポンスから「調査を開始」を選択し、「本日EC2が停止した理由を調査して」と入力します。

下記のように自律的に調査が開始されていきます。下記の箇所で、先ほど作成したスキルが使用されていることが確認できます。

下記の箇所で「両方のアカウントでイベントがあったか確認します」と表示されており、マルチアカウントでの調査ができていることが確認できます。

調査の結果が表示され、手動で停止されたことが特定できました。

なお、今回は実際にクリックしていませんが、「ヒューマンサポートを依頼」をクリックするとAWSサポートへのサポートケースを作成できます。こちらのマニュアルに記載のように、サポートケース作成時には、以下の情報が自動的にAWSサポートに共有されます。

調査タイムライン：DevOpsエージェントの分析の時系列レコード
リソース情報：影響を受けるAWSリソース
オブザーバビリティデータ：統合されたモニタリングツールからの関連するメトリクス、ログ、トレース
最近の変更：コードのデプロイ、インフラストラクチャの変更、設定の更新
修復の試行：DevOpsエージェントが推奨したアクション
影響評価：インシデントの範囲と重大度

まとめ

今回はAWS DevOps Agentを使用して、EC2停止のインシデント調査をマルチアカウント環境で実施しました。エージェントスペースの作成からセカンダリアカウントの接続、スキルの作成、そしてインシデント調査までの一連の流れを確認できました。

スキルをチャットで作成できる手軽さ、自然言語での指示だけで自律的に調査が進む点、マルチアカウントをまたいだ調査がシームレスに行える点は運用負荷の軽減に直結すると感じました。