⚡ TL;DR
- DevOpsAgentのmonitorsメモリは月次バッチのような低頻度障害は調査し直しになる
- 過去の調査結果をManagedKBに保存し意味検索で類似障害を引き当てさせてみた
- ログを見れば一発で原因がわかる単純な障害には効果なし
- 候補が多く絞り込みが必要な複雑な障害には効果あり
📝 1. はじめに
DevOpsAgentには「メモリ」という機能があり、障害の再発パターンを自動的に要約して記憶してくれます。保持期間は最大2週間ですが、期間内に同じ事象が再発すると延長される仕組みです。
月次バッチのような処理や頻繁に発生しない事象は、過去類似の事象が起きていてもまた一から調査することになります。そこで、調査結果をManagedKBにベクトルとして保存しておき、意味検索で過去の類似事象を引き当てて障害発生箇所をピンポイントに特定できればこの「はじめまして問題」を解消して高速化できるのではないかと考え検証してみました。
DevOps AgentとManaged KBの概要についてはこちらの素晴らしい記事をご参照ください。
🏗️ 2. アーキテクチャ
2.1 AgentCore Gateway経由のMCP呼び出しで検索する
- DevOps Agentのエージェントは直接Managed KBへアクセスできず、MCP(Model Context Protocol)ツールとして提供する形に統一されています。そのためAgentCore Gatewayを介してMCPツール化する必要があります
参考定義
Managed KB専用コネクタ(bedrock-knowledge-bases)をRetrieveツールとして公開します
IAMロールの信頼ポリシー
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": { "Service": "aidevops.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "aws:SourceAccount": "<account-id>" },
"ArnLike": { "aws:SourceArn": "arn:aws:aidevops:us-east-1:<account-id>:service/*" }
}
}]
}
register-serviceコマンド
aws devops-agent register-service \
--service mcpserversigv4 \
--service-details '{
"mcpserversigv4": {
"name": "dam-kb-gateway",
"endpoint": "https://dam-kb-gateway-<gateway-id>.gateway.bedrock-agentcore.us-east-1.amazonaws.com/mcp",
"authorizationConfig": {
"region": "us-east-1",
"service": "bedrock-agentcore",
"mcpRoleArn": "arn:aws:iam::<account-id>:role/dam-kb-mcp-sigv4-role"
}
}
}' \
--region us-east-1
associate-serviceコマンド
aws devops-agent associate-service \
--agent-space-id <agent-space-id> \
--service-id <service-id> \
--configuration '{
"mcpserversigv4": {
"tools": ["dam-kb-managed-kb-target___Retrieve"]
}
}' \
--region us-east-1
2.2 EventBridge経由のLambda呼び出しで調査結果を保存する
ManagedKBへの調査結果の反映は調査完了イベントをEventBridgeルールで検知しLambda関数が調査サマリーを取得してS3に格納してから同期するという流れで書き込みを実現しています。
🧪 3. 検証設計
3.1 検証の前提条件
| 項目 | 内容 |
|---|---|
| リージョン | us-east-1 |
| monitorsメモリ | 常に無効化(KB単体の効果を切り分けて計測するため、検証を通じて一貫してオフにする) |
| Managed KB | 本実験とは無関係な単純エラー5種のダミーの調査結果取り込み済み |
| 試行回数 | DevOpsAgentの非決定的な動きを考慮し3回実施 |
3.2 AGENTS.mdの制御
3.3 検証方法
2種類の障害を想定して過去に類似事象ありなしの4パターンで検証します。
| --- | 類似障害あり | 類似障害なし |
|---|---|---|
| 未存在ファイル参照 | 検証1 | 検証2 |
| ネットワークエラー | 検証3 | 検証4 |
[未存在ファイル参照]
Lambda関数(単一ファイル)の実行時にFileNotFoundErrorが発生する障害を用意しました。原因はLambdaの一時ストレージ(/tmp)に存在しないconfig.jsonを読み込もうとしている実装ミス。
[ネットワークエラー]
NACL(ネットワークACL)からS3へのアクセスを遮断しているパターンの障害です。
アクセスエラーは見るべき箇所が多数あり、ここをピンポイントで見れるかどうかが調査時間に影響します。
🔍 4. 検証結果 未存在ファイル参照
| 状態 | 所要時間 | 備考 |
|---|---|---|
| 類似障害なし | 2分28秒 | 原因を正しく特定できた(/tmp/config.json欠如と一致) |
| 類似障害なし | 2分46秒 | 原因を正しく特定できた(/tmp/config.json欠如と一致) |
タイムライン比較
| 経過時間(初回) | 類似障害なし | 経過時間(再発) | 類似障害あり |
|---|---|---|---|
| +21s | monitorsメモリ確認(エントリ無し) | +61s | monitorsメモリ確認(エントリ無し) |
| +21s | Managed KB検索 → 未発見(最高スコア0.43、無関係な背景ノイズのみ) | +61s | Managed KB検索 → 発見(スコア0.70、初回の調査結果がヒット) |
| +34s | ログクエリ実行 | +79s | ログクエリ実行 |
| +38s | ログクエリ結果取得 | +83s | ログクエリ結果取得 |
| +52s | Lambda関数情報取得(lambda:GetFunction) |
+93s | Lambda関数情報取得(lambda:GetFunction) |
| +88s | 対応方針の検討をサブエージェントに委任 | +124s | 対応方針の検討をサブエージェントに委任 |
| +88s | 調査サマリー確定 | +128s | 調査サマリー確定 |
| 2分28秒 | 完了 | 2分46秒 | 完了 |
直接ログを参照すれば原因に容易に行き着くことが可能なため、過去障害情報を参照しても速度は早くならないという結果が出ました。3回実施しましたが同等の結果となりました。
🌐 5. 検証結果 ネットワークエラー
| 状態 | 所要時間 | 備考 |
|---|---|---|
| 類似障害なし | 2分52秒 | 原因(NACLによるS3遮断)を正しく特定できた |
| 類似障害あり | 1分43秒 | 原因(NACLによるS3遮断)を正しく特定できた |
タイムライン比較
| 経過時間(初回) | 類似障害なし | 経過時間(再発) | 類似障害あり |
|---|---|---|---|
| +12s | monitorsメモリ確認(エントリ無し) | +7s | monitorsメモリ確認(エントリ無し) |
| +12s | Managed KB検索 → 未発見(最高スコア0.39、無関係な背景ノイズのみ) | +17s | Managed KB検索 → 発見(スコア0.62、初回の調査結果がヒット) |
| +22s | Lambda関数情報取得(lambda:GetFunction) |
+17s | Lambda関数情報取得(lambda:GetFunction) |
| +35s〜52s | ログクエリを2セット実行 | +31s〜36s | ログクエリを1セット実行 |
| +81s〜125s | Lambda設定・セキュリティグループ・VPCエンドポイント・ルートテーブル・NACLを直接確認 | +65s | VPCエンドポイント・ルートテーブル・NACL・サブネットを直接確認 |
| +172s | 調査サマリー確定 | +103s | 調査サマリー確定 |
| 2分52秒 | 完了 | 1分43秒 | 完了 |
過去障害記録(Managed KB)の情報を足がかりに候補の絞り込みそのものを省略して速度改善が見られました。また、manageDKBからの類似障害情報を鵜呑みにせずに独自の裏付け調査を行なっていることもわかります。こちらも３回やって同じような結果となりました。
[実際の画面]
💡 6. 発展的な活用方法
調査結果への「事後情報」の追記
- 調査結果はS3にMarkdownファイルとしてそのまま格納される構成になっているため、対応後の顧客アクション等の情報を付与してmanagedKBに蓄積することで以降の類似発生時にサジェストとして対応の提案をさせることもできそうです。
プロジェクト名によるメタデータフィルタリング
- 対象リソースにプロジェクト名などのタグが設定されている場合、そのタグ値をS3格納時のメタデータ(metadata.json)に含めておくことで、Managed KB側のメタデータフィルタとして使えそうです。
- 検索時にプロジェクト名で絞り込めば、無関係な他プロジェクトの類似事例がノイズとして混ざるのを防ぎ、同一プロジェクト内の類似事例に絞った、より精度の高い検索が可能になります
🍜 7. 締め
調査候補が実質1つしかない軽微な障害ではManaged KBの有無によって調査速度に有意な差は出ませんでした。一方で、候補が複数あるような込み入った障害で可能性を潰していくようなパターンでは類似障害によるショートカット調査ができると思われます。managedKBの類似障害の情報を鵜呑みにせず独自で裏採りをするという点はとても良い動きでした。
DevOpsAgentの検証はエージェントが非決定的な動きをするため、同一条件で本当に検証できてるか？という部分に注意を払いました。サブエージェントを読んだりcloudtrailを見たりcloudwatchを見たりするのでAGENT.mdで調査方針をしっかり定義してあげることも大事だなと感じました。