Strands Agentsを用いたハイブリッドクラウド構成全体の障害自動調査についての構成検討
はじめに
エンタープライズ企業のWebシステムにおいて、AWSとオンプレミスを組み合わせたハイブリッドクラウド構成は依然として主流のアーキテクチャパターンの一つです。フロントエンドやアプリケーション層はAWS上に構築しつつ、データベースは既存のオンプレミス環境でOracleDBを継続利用するといった構成は、多くの企業で採用されています。
しかし、このようなハイブリッド構成においては、障害が発生した際の原因調査の複雑さが大きな運用課題となります。AWS側ではCloudWatchやX-Rayといった豊富な可観測性ツールが利用できる一方、オンプレミスのデータベースサーバーやネットワーク機器の状態確認には別の手段が必要であり、障害の原因がAWS側にあるのか、オンプレミス側にあるのか、あるいはその間のネットワークにあるのかを切り分ける作業は、熟練した運用担当者でも時間を要します。
既存のAWS環境における障害自動調査
私のチームでは、既にAWS環境内でStrands Agentsを用いた障害自動調査の仕組みを構築・運用しています。API GatewayやALBでHTTPレスポンスコード5xx系のエラーが検知された際に、Strands AgentsがCloudWatch LogsやECSタスクの状態を自律的に調査し、障害の原因を特定するワークフローです。
本記事で提案する拡張
この記事では、この既存のAWS環境向けの障害自動調査の仕組みをオンプレミス環境にまで拡張し、ハイブリッドクラウド構成全体を対象とした障害自動調査を実現する方法を解説します。
具体的には、API GatewayやALBで5xx系エラーを検知した際に、Strands Agentsが以下の全領域を自律的に調査する仕組みを構築します。
- AWS側: API Gatewayのログ、ALBのターゲットヘルスチェック、ECSタスクの稼働状態、CloudWatch Logsのアプリケーションログ
- オンプレミス側: OracleDBの稼働状態とセッション情報、ネットワーク機器の状態
- Datadog（横断的な可観測性）: Datadog MCP Serverを介して、AWS・オンプレミス双方のメトリクス、ログ、トレース、NW機器の監視データを統合的に分析
Strands Agentsとは
概要
Strands Agentsは、AWSが公開しているオープンソースのAIエージェントフレームワークです。大規模言語モデル（LLM）を頭脳として、ユーザーが定義したツール群を自律的に使い分けながら、複雑なタスクを実行する能力を持っています。
Strands Agentsの特徴
| 特徴 | 詳細 |
|---|---|
| オープンソース | Apache 2.0ライセンスで公開されており、自由に利用・カスタマイズが可能 |
| モデル非依存 | Amazon Bedrock（Claude、Nova等）をはじめ、様々なLLMをバックエンドとして利用可能 |
| ツール拡張性 | Pythonの関数をデコレーターで簡単にツールとして定義でき、エージェントの能力を自在に拡張可能 |
| 自律的な推論 | 与えられた指示とツール群をもとに、エージェント自身が最適な調査手順を組み立てて実行 |
| MCPサポート | Model Context Protocol（MCP）に対応しており、外部のMCPサーバーをツールとして統合可能 |
エージェントの動作原理
Strands Agentsは以下のループで動作します。
- 指示の解釈: ユーザーからの指示（例：「5xxエラーの原因を調査して」）を受け取る
- 推論: 利用可能なツール群を把握し、どのツールをどの順番で使うべきかを推論する
- ツール実行: 推論結果に基づいてツールを実行し、結果を取得する
- 結果の分析: ツールの実行結果を分析し、追加の調査が必要かどうかを判断する
- 繰り返しまたは回答: 必要に応じてステップ2〜4を繰り返し、最終的な回答を生成する
この仕組みにより、事前に調査手順をハードコードすることなく、エージェントが状況に応じて柔軟に調査を進めることが可能です。
想定するシステム構成
対象システムのアーキテクチャ
本記事で想定するシステム構成は以下の通りです。
[エンドユーザー]
↓ (HTTPS)
[Amazon API Gateway / ALB]
↓
[Amazon ECS (Fargate) - アプリケーション]
↓ (Direct Connect経由)
[オンプレミス NW機器 (FW/Router/Switch等)]
↓
[オンプレミス Oracle Database]
この構成では、Webシステムの通信の入り口としてAmazon API GatewayまたはALBが配置されており、その後段にECS（Fargate）上で稼働するアプリケーションが存在します。アプリケーションはDirect Connect経由でオンプレミスのネットワークに接続し、オンプレミス上のOracleDBにアクセスします。
障害発生時の課題
このハイブリッド構成において、API GatewayやALBで5xx系エラーが発生した場合、原因は以下のいずれかに存在する可能性があります。
| 障害の発生箇所 | 具体的な原因例 |
|---|---|
| API Gateway / ALB | 統合タイムアウト、バックエンド接続エラー、ヘルスチェック失敗 |
| ECS (Fargate) タスク | アプリケーションの例外、OOM（メモリ不足）によるタスク停止、コンテナヘルスチェック失敗、DBコネクションプールの枯渇 |
| Direct Connect | Direct Connect接続の障害、帯域逈迫 |
| オンプレミス NW機器 | ファイアウォールルールの変更、ルーティング障害、NW機器の故障 |
| オンプレミス OracleDB | リスナーの停止、テーブルスペース枯渇、セッション数上限到達、デッドロック |
手動での障害調査では、これらの各レイヤーを順番に確認していくことになりますが、AWS環境とオンプレミス環境で利用するツールが異なるため、調査に時間がかかり、復旧が遅延するリスクがあります。
構成概要
障害自動調査アーキテクチャの全体像
本記事では、Strands Agentsを中核とした以下のアーキテクチャで障害自動調査を実現します。
障害検知から調査完了までの全体フロー
- 障害検知: CloudWatch AlarmがAPI Gateway/ALBの5xxエラー率の閾値超過を検知
- イベント通知: Amazon EventBridgeがCloudWatch Alarmの状態変更イベントを受信
- エージェント起動: EventBridgeルールによりLambda関数が起動し、ECSタスク（Strands Agentsエージェント）を起動
- AWS側調査: Strands AgentsがAWS SDK系のツールを使用してAPI Gateway、ALB、ECSタスクの状態を調査
- Datadogによる横断的分析: Datadog MCP Server経由でログ・メトリクス・APMトレース・NW機器の状態を横断的に分析
- オンプレミス側調査: Strands AgentsがAWS Systems Manager（SSMハイブリッドアクティベーション）経由でオンプレミスのOracleDBサーバーやNW機器の状態を調査
- 結果集約: 調査結果を集約し、障害の根本原因と推奨対処をレポートとして出力
利用するサービス・技術と役割
| サービス・技術 | 配置場所 | 役割 |
|---|---|---|
| Amazon CloudWatch Alarm | AWS | API Gateway/ALBの5xxエラー率を監視し、閾値超過時にアラームを発報 |
| Amazon EventBridge | AWS | CloudWatch Alarmの状態変更イベントを受信し、後続のLambda関数をトリガー |
| AWS Lambda | AWS | EventBridgeイベントを受信し、Strands Agentsが稼働するECSタスクを起動 |
| Amazon ECS (Fargate) | AWS | Strands Agentsエージェントの実行環境として使用 |
| Amazon Bedrock | AWS | Strands Agentsのバックエンド LLM（Claude等）を提供 |
| AWS Systems Manager | AWS + オンプレミス | ハイブリッドアクティベーションにより、オンプレミスサーバーへのリモートコマンド実行を実現 |
| SSM Agent | オンプレミス | OracleDBサーバーおよびNW機器管理用踏み台サーバーにインストールし、SSM Run Commandの受信を可能にする |
| Datadog MCP Server | Datadog (リモート) | Datadogに蓄積されたログ・メトリクス・トレース・NW機器監視データへのMCPプロトコル経由でのアクセスを提供 |
| Strands Agents | AWS (ECS上) | AIエージェントフレームワークとして、各種ツールおよびDatadog MCPツールを自律的に使い分けて障害原因を調査 |
オンプレミス環境との接続方式
AWS Systems Manager ハイブリッドアクティベーション
Strands Agentsがオンプレミス環境を調査するための手段として、AWS Systems Manager（SSM）のハイブリッドアクティベーションを採用します。この機能により、オンプレミスのサーバーをSSMのマネージドインスタンスとして登録し、AWS側からリモートでコマンドを実行できるようになります。
SSMハイブリッドアクティベーションの仕組み
[AWS] [オンプレミス]
Strands Agents (ECS) OracleDBサーバー
↓ ↑
SSM Run Command API SSM Agent
↓ ↑
AWS Systems Manager ←── (HTTPS ポーリング) ── SSM Agent
── (コマンド/結果) ──→
※ SSM Agentが定期的にAWSへHTTPSポーリングを行い、
コマンドを取得・実行する方式（Pull型）
※ ネットワーク接続を開始するのは常にオンプレミス側
※ オンプレミス側でインバウンドポートの開放は不要
利点
| 利点 | 詳細 |
|---|---|
| セキュリティ | SSM AgentからのアウトバウンドHTTPSポーリングのみで動作するPull型アーキテクチャのため、オンプレミス側でインバウンドポートの開放が不要 |
| 閉域網対応 | 本構成ではDirect Connectが既に敷設済みのため、VPCエンドポイント（PrivateLink）とDirect Connectを組み合わせ、SSM制御通信を含む全通信を閉域網内に閉じる構成とする。具体的には、SSM用VPCエンドポイント（ssm、ssmmessages、ec2messages）を作成し、Route 53 Resolver（インバウンドエンドポイント）経由でオンプレミスからプライベートに名前解決させることで、インターネットを一切経由しない |
| 一元管理 | AWS側からオンプレミスサーバーの管理が可能になり、Strands Agentsのツールとしてシームレスに統合可能 |
| 監査証跡 | SSM Run Commandの実行履歴がCloudTrailに記録され、セキュリティ監査に対応可能 |
セットアップ手順
- アクティベーションの作成: AWS Systems Managerコンソールからハイブリッドアクティベーションを作成し、アクティベーションコードとIDを取得
- SSM Agentのインストール: オンプレミスのOracleDBサーバーにSSM Agentをインストールし、取得したアクティベーション情報で登録
- IAMロールの設定: SSMマネージドインスタンスに適切なIAMサービスロールを関連付け
- 疎通確認: AWS側からSSM Run Commandが正常に実行できることを確認
ネットワーク機器の調査方式
ネットワーク機器は一般的にSSM Agentを直接インストールすることができないため、踏み台サーバー経由でのアクセスを行います。
[AWS] [オンプレミス]
Strands Agents (ECS) 踏み台サーバー (SSM Agent導入済)
↓ ↓ SSH/Telnet/SNMP
SSM Run Command ────────→ NW機器 (FW/Router/Switch)
踏み台サーバーにSSM Agentを導入し、SSM Run Command経由で踏み台サーバー上のスクリプト（SSH接続やSNMP問い合わせ）を実行することで、NW機器の状態を確認します。
技術的な特徴・アーキテクチャ設計
エージェントの実装方式
Strands Agentsのエージェントは、以下の3つの要素で構成されます。
1. エージェント本体
Strands Agentsの Agent クラスを使用し、Amazon Bedrockのモデル（Claude等）をバックエンドLLMとして設定します。エージェントにはシステムプロンプトとして障害調査の方針を指示し、利用可能なツール群を登録します。システムプロンプトには、調査の優先順位（まずAPI Gateway/ALBのログ → ECSタスク → Direct Connect → OracleDB → NW機器）を記述しつつ、各ステップの結果に応じて柔軟に判断するよう指示します。
2. ツールの定義
各調査ツールはPythonの関数として実装し、Strands Agentsの @tool デコレーターを付与することでエージェントに認識させます。各ツールには関数名・引数・戻り値の説明をdocstringとして記述し、エージェントが適切なタイミングで適切なツールを選択できるようにします。
- AWS側ツール: boto3を使用してAWSのAPIを呼び出す関数群
- オンプレミス側ツール: boto3のSSM Run Command APIを使用し、オンプレミスサーバー上でコマンドを実行して結果を取得する関数群
3. エージェント起動の仕組み
EventBridgeから起動されるLambda関数が、ECSタスク（Strands Agentsエージェント）を起動します。Lambda関数はCloudWatch Alarmの詳細情報（アラーム名、発生時刻等）をECSタスクの環境変数として渡し、ECSタスク上のエージェントスクリプトがその情報をもとにプロンプトを構成してエージェントの調査を開始します。
エージェントの調査フロー例
ケース1: OracleDBのテーブルスペース枯渇による障害
以下は、Strands Agentsが実際にどのように自律的に調査を進めるかの例です。
[エージェントの思考と行動]
1. 「5xxエラーが発生しているので、まずAPI Gatewayのログを確認します」
→ API Gatewayの実行ログを取得
→ 結果: "502 Bad Gateway" が多数発生、バックエンドからのタイムアウト
2. 「バックエンドのタイムアウトが原因のようです。ECSタスクの状態を確認します」
→ ECSタスクの稼働状態とアプリケーションログを取得
→ 結果: タスクは全て稼働中だが、ログにDB接続タイムアウトのエラーが多数
3. 「ECSタスクは稼働していますが、DB接続でタイムアウトしています。OracleDBの状態を確認します」
→ SSM Run Command経由でOracleDBリスナーの稼働状態を確認
→ 結果: リスナーは正常稼働中
4. 「リスナーは正常です。セッション状態を確認します」
→ SSM Run Command経由でOracleDBのアクティブセッション情報を取得
→ 結果: 多数のセッションが "ACTIVE" で待機イベント "db file sequential read" が多い
5. 「I/O待ちが発生しています。テーブルスペースの使用率を確認します」
→ SSM Run Command経由でテーブルスペースの使用状況を取得
→ 結果: SYSTEMテーブルスペースが99.8%使用
6. 「テーブルスペースが枯渇しています。アラートログも確認します」
→ SSM Run Command経由でOracleDBのアラートログを取得
→ 結果: "ORA-01653: unable to extend table" エラーが多数記録
7. 「原因が特定できました。調査結果をレポートとして出力します」
→ 障害の根本原因と推奨対処をまとめた調査結果レポートを生成
エージェントが生成する調査結果レポート例：
■ 障害調査結果レポート
━━━━━━━━━━━━━━━━━━━━
【発生事象】API Gateway/ALBにおける5xx系エラーの多発
【根本原因】オンプレミスOracleDBのSYSTEMテーブルスペース枯渇
- SYSTEMテーブルスペースの使用率: 99.8%
- ORA-01653エラー（テーブル拡張不可）が多数発生
- これによりDBへのINSERT/UPDATE処理が失敗
- ECSタスクからのDB接続タイムアウトが発生し、API Gatewayが502を返却
【影響範囲】
- API Gateway: 502 Bad Gatewayエラーが直近30分で1,247件
- ECSタスク: 全タスク稼働中だがDB関連処理が全て失敗
- OracleDB: テーブルスペース枯渇によりデータ書き込み不可
【NW機器】異常なし
【推奨対処】
1. 即時対応: SYSTEMテーブルスペースにデータファイルを追加し領域を拡張
2. 恒久対応: テーブルスペースの自動拡張設定の見直し、使用率監視の閾値設定
━━━━━━━━━━━━━━━━━━━━
ケース2: Direct Connect接続障害
[エージェントの思考と行動]
1. API Gatewayのログを確認 → 504 Gateway Timeoutが多発
2. ECSタスクの状態を確認 → タスクは稼働中、ログに「Connection timed out」
3. Direct Connectの接続ステータスを確認 → 接続がダウン
4. 「Direct Connect接続に問題があります」→ 調査結果をレポートとして出力
→ NW機器やOracleDBの調査は不要と判断し、Direct Connect障害として報告
ケース3: コネクションプール枯渇による障害
データベース側は正常であるにもかかわらず、アプリケーション側のDBコネクションプールが枯渇しているケースです。エージェントが「DB側に問題がない」ことを確認した上で、アプリケーションログやAPMトレースから原因を特定する点が特徴です。
[エージェントの思考と行動]
1. API Gatewayのログを確認 → 502 Bad Gatewayが多発
2. ECSタスクの状態を確認 → タスクは全て稼働中、ログに「Cannot get a connection, pool exhausted」
3. 「アプリケーションログにDBコネクションプールの枯渇エラーがあります。DB側の問題かアプリ側の問題かを切り分けます」
4. SSM Run Command経由でOracleDBリスナーを確認 → 正常稼働中
5. SSM Run Command経由でOracleDBのアクティブセッション数を確認 → セッション数はDB側の上限に対して余裕あり
6. SSM Run Command経由でテーブルスペースを確認 → 正常、アラートログにもエラーなし
7. 「DB側は全て正常です。アプリ側のコネクションプールが原因と判断します」
→ 障害の根本原因と推奨対処をまとめた調査結果レポートを生成
→ DB側の異常がないことを確認した上で、アプリケーション側のコネクションプール枯湇と判断
推奨対処: プールサイズの拡大、コネクションリークの調査、アイドルタイムアウト設定の見直し
このケースは、エージェントがDB側の正常性を確認した上で「原因はDBではなくアプリケーション側である」と推論する点が特徴的です。従来のルールベースの自動化では、「DB接続エラー = DB障害」と単純に判定しがちですが、Strands AgentsはDB側の調査結果を踏まえて「消去法」でアプリケーション側の問題であることを特定できます。
このように、Strands Agentsは各ステップの結果に応じて次に調査すべき対象を自律的に判断します。これが従来のルールベースの自動化との大きな違いであり、事前に全ての障害パターンを網羅したフローチャートを用意する必要がありません。
実装時の注意点・ベストプラクティス
セキュリティに関する考慮事項
SSM Run Commandの権限管理
Strands Agentsが使用するIAMロールには、必要最小限の権限のみを付与します。
| 権限 | 対象 | 目的 |
|---|---|---|
ssm:SendCommand |
特定のマネージドインスタンスIDのみ | OracleDBサーバーと踏み台サーバーへのコマンド実行 |
ssm:GetCommandInvocation |
上記コマンドの結果取得 | 実行結果の確認 |
logs:GetLogEvents |
特定のロググループのみ | CloudWatch Logsの参照 |
ecs:DescribeTasks |
特定のクラスターのみ | ECSタスク状態の確認 |
elasticloadbalancing:DescribeTargetHealth |
特定のターゲットグループのみ | ALBヘルスチェックの確認 |
重要: SSM Run Commandで実行するコマンドは読み取り系の操作に限定し、データベースの変更やシステムの再起動など、環境に変更を加える権限は一切付与しません。
SSM Run Commandで実行するコマンドの制限
SSM Documentを独自に作成し、実行可能なコマンドを限定することを推奨します。具体的には、カスタムSSM Documentのパラメータに allowedValues を設定し、listener、sessions、tablespace、alertlog といったチェック種別のみを受け付けるように定義します。各チェック種別に対応するシェルコマンドをDocument内にあらかじめ記述しておくことで、エージェントは「どのチェックを実行するか」のみを選択でき、任意のコマンドを実行することはできなくなります。
このようにSSM Documentでコマンドをホワイトリスト化することで、Strands Agentsが意図しないコマンドを実行するリスクを排除できます。
運用面での考慮事項
エージェントの実行時間とコスト
| 考慮事項 | 対応方針 |
|---|---|
| LLM呼び出しコスト | 1回の障害調査で複数回のLLM推論が発生するため、Bedrockの利用料を事前に見積もる |
| ECSタスクの実行時間 | 調査のタイムアウト時間を設定し、無限ループを防止する（推奨: 10〜15分） |
| SSM Run Commandのタイムアウト | 各コマンドに適切なタイムアウトを設定し、応答のないサーバーで処理が滞留しないようにする |
| 同時実行の制御 | 同一のアラームに対して複数のエージェントが同時起動しないよう、DynamoDBなどでロック機構を実装する |
ログと監査
エージェントの全ての行動（ツール呼び出し、LLM推論結果）をCloudWatch Logsに記録し、事後の監査やエージェントの改善に活用します。Strands Agentsはデフォルトでエージェントの思考プロセスをログ出力する機能を備えているため、これを活用します。
Datadog MCP Serverの活用
ここまで、Strands Agentsが自作のツール群（AWS SDK呼び出しやSSM Run Command経由のオンプレミス調査）を使って障害調査を行う方式を解説してきました。この章では、これに加えてDatadog MCP Serverを統合することで、エージェントの調査能力をさらに強化する方法を解説します。
Datadog MCP Serverとは
Datadog MCP Serverは、Datadogが提供するオブザーバビリティデータとAIエージェントを接続するためのModel Context Protocol（MCP）サーバーです。MCPはAIエージェントと外部データソースを繋ぐオープンな標準プロトコルであり、Strands AgentsはこのMCPをネイティブにサポートしています。
Datadog MCP Serverを利用することで、エージェントは標準化されたプロトコルを通じて、Datadogに蓄積されたログ、メトリクス、トレース、モニター、インシデント情報などに直接アクセスできるようになります。
なぜDatadog MCPが有効なのか
前章までの方式では、AWS側の情報はCloudWatch等のAWS APIから、オンプレミス側の情報はSSM Run Command経由で個別に取得していました。しかし、運用現場ではDatadogのようなオブザーバビリティプラットフォームでAWSとオンプレミスの両方のテレメトリを統合管理しているケースが多くあります。
DatadogではAWS環境のメトリクスやログだけでなく、オンプレミスのサーバーやNW機器のSNMPデータもDatadog Agentを通じて収集・管理できます。つまり、Datadogに集約された情報をMCP経由でStrands Agentsに提供することで、以下のメリットが得られます。
| メリット | 詳細 |
|---|---|
| 環境横断の統合ビュー | AWSのCloudWatchメトリクスとオンプレミスのSNMPデータが統合されたDatadog上のデータに、エージェントが一元的にアクセス可能 |
| 相関分析の高度化 | エージェントが「オンプレミスのNW機器のパケットロス増加」と「ECSタスクのレイテンシ悪化」の相関を、Datadogのデータから直接把握可能 |
| 調査手段の多様化 | 自作ツール（SSM経由のコマンド実行）とDatadog MCPツール（メトリクス・ログ・トレースの検索）を組み合わせることで、より多角的な調査が可能 |
| 既存のモニター・ダッシュボードの活用 | Datadogで既に設定済みのモニターやダッシュボードの情報をエージェントが参照でき、運用チームが蓄積したナレッジを調査に活用 |
| NW機器の監視統合 | Datadog Network Device Monitoring（NDM）で監視しているNW機器の状態を、踏み台サーバー経由のコマンド実行に加えて、メトリクスベースでも確認可能 |
Strands AgentsへのDatadog MCP Server統合方式
Strands AgentsはMCPクライアントの機能を標準で備えており、エージェントの初期化時にMCPサーバーの接続先を指定することで、Datadog MCP Serverが提供するツール群を自動的にエージェントのツールとして取り込むことができます。
接続方式
Datadog MCP ServerはDatadogがホストするリモートMCPサーバーとして提供されており、OAuth認証（DatadogのAPIキーとアプリケーションキー）を経て接続します。エンドポイントURLにはToolsets（後述）をクエリパラメータとして指定し、必要なツール群のみを取得します。
Toolsetsによるツール範囲の制御
Datadog MCP Serverは、利用可能なツールをToolsetsという単位でグループ化しており、エージェントのコンテキストウィンドウを効率的に使うために、必要なツールセットのみを選択して接続できます。本アーキテクチャで特に有効なToolsetsは以下の通りです。
| Toolset | 提供されるツール | 本アーキテクチャでの活用場面 |
|---|---|---|
| core | ログ検索・分析、メトリクス取得、トレース取得、モニター状態確認、インシデント情報取得、ホスト情報検索、サービス依存関係の確認 | 障害調査の基本情報収集。API Gatewayのログ分析、ECSサービスのメトリクス確認、関連モニターのアラート状態確認 |
| apm | APMトレースの詳細分析、スパン検索、Watchdogインサイト、レイテンシボトルネック分析、トレース比較 | ECSタスク上のアプリケーションのリクエストトレースを分析し、どのスパン（DB接続、外部API呼び出し等）で遅延やエラーが発生しているかを特定 |
| networks | Cloud Network Monitoringの分析、Network Device Monitoring（NDM）のデバイス検索・インターフェース状態確認 | オンプレミスNW機器の状態をDatadog NDM経由で確認。再送率やパケットロスなどのネットワーク品質メトリクスを分析 |
| dbm | Database Monitoringのクエリプラン検索、クエリサンプル分析 | OracleDBのスロークエリやクエリプランの分析（DatadogのDBM機能でOracleDBを監視している場合） |
Datadog MCP統合後の調査フロー
Datadog MCP Serverを統合した場合、エージェントは自作ツールとDatadog MCPツールの両方を利用可能になり、状況に応じてより適切な手段を選択できるようになります。
[Datadog MCP統合後のエージェントの調査フロー例]
1. 「5xxエラーの状況を確認します」
→ Datadog MCP経由: 関連モニターのアラート状態を一覧確認
→ Datadog MCP経由: API Gatewayのエラーログを検索・分析
→ 結果: 502 Bad Gatewayが多発、バックエンドタイムアウト
2. 「アプリケーションのトレースを確認します」
→ Datadog MCP経由（APM）: エラーが発生しているスパンを検索
→ Datadog MCP経由（APM）: レイテンシのボトルネックを分析
→ 結果: DB接続スパンで大幅な遅延が発生
3. 「NW機器の状態をDatadogで確認します」
→ Datadog MCP経由（NDM）: 監視対象NW機器・インターフェースの状態を確認
→ Datadog MCP経由（Networks）: ネットワークフローの異常を分析
→ 結果: NW機器は正常、ネットワーク品質にも異常なし
4. 「OracleDBの詳細を確認します」
→ Datadog MCP経由（DBM）: スロークエリとクエリパフォーマンスを分析
→ SSM Run Command経由: テーブルスペース使用率を直接確認
→ SSM Run Command経由: アラートログの最新エラーを確認
→ 結果: テーブルスペース枯渇によりORA-01653エラーが発生
5. 「原因が特定できました。調査結果をレポートとして出力します」
→ 障害の根本原因と推奨対処をまとめた調査結果レポートを生成
このように、Datadogで俯瞰的に状況を把握した上で、SSM経由の直接コマンドで詳細を確認するという段階的な調査アプローチが可能になります。
Datadog MCP活用における考慮事項
| 考慮事項 | 対応方針 |
|---|---|
| Datadogの権限管理 | Datadog MCP Serverの利用には MCP Read パーミッションが必要。調査用途では読み取り権限のみを付与し、MCP Write は付与しない |
| Toolsetsの選定 | 全てのToolsetsを有効にするとコンテキストウィンドウを圧迫するため、障害調査に必要なToolsets（core、apm、networks、dbm）のみを有効化 |
| 自作ツールとの使い分け | Datadogで収集できない情報（OracleDBの内部コマンド実行等）は引き続きSSM経由のツールを使用。Datadogで取得可能な統合メトリクス・ログはDatadog MCPを優先 |
| 監査証跡 | Datadog MCP Serverの全ツール呼び出しはDatadog Audit Trailに記録されるため、エージェントの行動をDatadog側でも追跡可能 |
| 前提条件 | Datadog Agent がオンプレミス環境のサーバーやNW機器からテレメトリを収集済みであること。未導入の場合はDatadog Agentのセットアップが事前に必要 |
まとめ
本記事では、Strands Agentsを用いたハイブリッドクラウド構成全体の障害自動調査アーキテクチャを紹介しました。
記事のポイント
- 既存のAWS障害調査の拡張: AWS環境向けに構築済みのStrands Agentsによる障害自動調査を、SSMハイブリッドアクティベーションを活用してオンプレミス環境にまで拡張
- 自律的な調査: Strands AgentsのAIエージェントとしての推論能力により、事前に全ての障害パターンをハードコードすることなく、状況に応じた柔軟な調査を実現
- SSMハイブリッドアクティベーションの活用: オンプレミスサーバーへのインバウンドポート開放なしに、AWS側からセキュアにリモートコマンドを実行
- NW機器の間接的な調査: SSM Agent導入が困難なNW機器に対しては、踏み台サーバー経由でのアクセスにより状態確認を実現
- Datadog MCP Serverによる調査の高度化: Datadogに集約されたAWS・オンプレミス横断のオブザーバビリティデータを、MCPプロトコル経由でエージェントに統合し、相関分析やAPMトレース分析など多角的な調査手段を提供
- セキュリティの確保: 読み取り専用権限の原則、SSM Documentによるコマンドのホワイトリスト化、IAMポリシーによる最小権限の実装
ハイブリッドクラウド環境の障害調査は、AWS環境とオンプレミス環境の両方に精通した人材が必要とされる領域です。Strands Agentsを活用することで、この調査プロセスを自動化し、障害の平均復旧時間（MTTR）の短縮に貢献できます。さらにDatadog MCP Serverを組み合わせることで、エージェントはDatadogに蓄積された豊富なオブザーバビリティデータをもとに、より精度の高い根本原因分析を行えるようになります。本記事のアーキテクチャパターンを参考に、ぜひ自社のハイブリッド環境に合わせた障害自動調査の仕組みを検討してみてください。