DevOps AgentからAurora MySQLを安全に調査できるようにした話 〜 AgentCore Gateway + Lambda構成 〜 投稿日
サイバーアゴットは、AWS Bedrock AgentCore Gateway と Lambda を組み合わせることで、DevOps エージェントが Aurora MySQL データベースを安全かつ効率的に調査・分析できる仕組みを実装した。
キーポイント
AgentCore Gateway の活用によるセキュリティ強化
DevOps Agent が直接データベースに接続するリスクを回避するため、Bedrock AgentCore Gateway を経由してアクセス制御を行う構成を採用している。
Lambda による調査ツールの実装
AWS Lambda を実行環境として利用し、DB 調査用ツールを実行することで、スケーラビリティとコスト効率を両立させたアーキテクチャを構築した。
Service Reliability Group (SRG) の実装事例
メディア統括本部の SRG グループが、既存サービスの改善や OSS 貢献の一環として、この安全な調査環境を実際に運用している。
体系的な調査ワークフローの確立
CloudWatch/RDSメトリクス、Performance Insights、およびMCPツールを活用した4フェーズ（健全性把握→負荷クエリ特定→詳細分析）の標準化された調査手順を定義しました。
必須確認メトリクスの網羅
接続数、CPU、I/O レイテンシ、メモリ/ストレージ残量に加え、レプリケーション遅延やデッドロック発生数など、Aurora MySQL特有の健全性を判断する8つの必須メトリクスを調査項目に含めました。
特定スキルの実装
'investigate-rds-aurora-performance'というスキルを作成し、パフォーマンス劣化や接続エラー発生時に自動的にこの体系的な調査ワークフローを実行できるようにしました。
CPU や接続数などによる判断基準の明確化
CPU 80%超え、接続急増、レイテンシ上昇、レプリカラグ、デッドロック発生などの指標に基づき、クエリ最適化や設定確認が必要なタイミングを判定する。
重要な引用
AWS DevOps Agent から Aurora MySQL の調査を安全におこなえるように、Bedrock AgentCore Gateway と Lambda を使って DB 調査用ツールを作ってみた話です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS 貢献などを行っているグループです。
Systematic investigation workflow for RDS Aurora performance issues using CloudWatch metrics, Performance Insights, and the rds-inspector MCP tool.
まず、Aurora クラスターの全体的な健全性を把握します。以下のメトリクスを **use_aws** で確認
CPU > 80% が継続 → クエリ最適化が必要
AAS が継続的に高い（> 1.0）クエリ、実行回数が多い頻繁なクエリ、1 回あたりの実行時間が長いクエリを重点調査
影響分析・編集コメントを表示
影響分析
この記事は、生成 AI をインフラ運用に組み込む際の最大の懸念事項の一つである「データベースへのアクセス権限管理」に対する実用的な解決策を示しています。特に大規模なメディアサービスにおいて、AI エージェントが自律的に調査を行う際のパターンとして、Gateway と Lambda を活用したサンドボックス化アプローチは、他の組織でも即座に適用可能なベストプラクティスとなる可能性があります。
編集コメント
AI エージェントの運用において、セキュリティと利便性の両立は常に課題ですが、Gateway を介在させるこのアプローチは非常に堅牢で参考になります。特に Lambda との組み合わせによるコスト効率の高さは、実運用での採用ハードルを下げる重要なポイントです。
2026/4/28 21:202026/5/2 9:16
投稿日
2026/5/2
タグ
AWS
Aurora
DevOps
執筆者
メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、AWS DevOps AgentからAurora MySQLの調査を安全におこなえるように、Bedrock AgentCore GatewayとLambdaを使ってDB調査用ツールを作ってみた話です。
なにかの役に立てば幸いです。
DevOps AgentからAurora MySQLを調査したい全体の構成Aurora MySQL MCPサーバーではなく、AgentCore Gateway+Lambdaを採用した理由Amazon Bedrock AgentCore GatewayとはLambdaで実装した機能安全にDB調査するためにやったことGatewayの認証はCognito JWTで制限DBユーザーは読み取り専用SQL validatorで危険なSQLをブロックDevOps AgentへのMCPサーバー追加とSkillsの作成DBインシデント調査をさせてみた結果終わりに
DevOps AgentからAurora MySQLを調査したい
DevOps Agentは2026年3月31日にGAリリースされた機能で、CloudWatchやAWSリソースの情報をもとに、インシデントの原因調査や復旧提案をしてくれる機能です。
詳しくは過去にブログ記事で取り上げているのでご参照ください。
DevOps AgentはAWS内のリソースを隈無く調査してくれるのですが、DBの中のデータまでは確認することはできません。
ただ、実際の障害調査ではAWSリソースの状態だけでなくDBの中も見たいケースがよくあります。
例えば、Aurora MySQLを利用しているアプリケーションのエラーやレイテンシ悪化が発生しているときに、以下のようなことを確認したくなります。
- 対象DBにどんなテーブルがあるか
- テーブルの構成は？インデックスが適切に貼られているか
- 問題になっているSELECTのEXPLAINがどうなるか
- テーブルサイズや行数の傾向がどうなっているか
DevOps AgentにはMCPの連携機能があるため、Aurora MySQLに接続できるMCPがあれば実現することができます。
全体の構成
まずは今回作成した全体の構成図を紹介します。
ざっくりした流れは以下のとおりです。
- DevOps Agentへユーザーが調査指示を出す
- DevOps AgentがAgentCore GatewayにMCPリクエストを送信
- AgentCore GatewayがJWTを検証
- AgentCore GatewayがGateway用IAM RoleでLambdaをInvoke
- Lambdaがツール名と引数をもとにAurora MySQL調査用処理を実行
- LambdaがRDS Data API経由でAurora MySQLにクエリを実行
- 結果をAgentCore Gateway経由でDevOps Agentへ返却
Aurora MySQL MCPサーバーではなく、AgentCore Gateway+Lambdaを採用した理由
最初は、AWS labsのAurora MySQL MCP サーバー を利用すれば簡単に実現できるのでは？と考えていました。
しかし、DevOps Agentから追加するMCPサーバーは、remote MCP endpointとして到達できる必要があります。
一方、AWS LabsのMySQL MCP ServerはローカルMCPクライアントからstdioで利用する前提の構成だったため、そのままでは利用できませんでした。
また、仮にMySQL MCP Serverが利用できたとしても、このMCPサーバーはread-only制御や一部の危険パターン検出はありますが、任意SQLを受け取るrun_queryが中心です。
そのため、高負荷なSELECT、巨大なJOIN、LIMITなしの大量取得など、読み取りクエリによる負荷影響を用途別に制限する仕組みまではありません。
今回の用途では、本番Aurora MySQLに対して障害調査の初動で使うことを想定していたため、汎用的なSQL実行ツールではなく、調査用途に絞ったツールだけをAgentCore Gateway + Lambdaで公開する構成にしました。
Amazon Bedrock AgentCore Gatewayとは
Amazon Bedrock AgentCore Gateway(以下、AgentCore Gateway)は、Agentから見ると1つのMCPエンドポイントとして振る舞ってくれるマネージドなゲートウェイです。LambdaやAPIなどをTargetとして登録すると、GatewayがそれらをMCP互換のtoolとして公開してくれます。
AgentCore Gatewayは、MCP endpointを全公開するだけの仕組みではなく、入口に認証を設定できます。今回は、このAgentCore GatewayのMCP endpointにCognito JWT認証を付け、DevOps Agentからの正当なリクエストだけを受け付ける構成にしました。
Lambdaで実装した機能
Aurora MySQL調査用LambdaをAgentCore GatewayのTargetとして登録します。
今回は rds-inspector というLambda関数を作成し、以下のようなツールを実装しました。
Tool機能
*list_databases*DB 一覧
list_tablesテーブル一覧
show_create_tableテーブル構造表示
show_indexesインデックス表示
explain_selectEXPLAIN SELECTの実行計画表示
table_statsinformation_schema.TABLES から 概算行数・データ/インデックスサイズ等表示
AgentCore GatewayのLambda Targetでは、ツールのinputSchemaを定義しておきます。
例えば、show_create_table なら以下のようなイメージです。
{
"name": "show_create_table",
"description": "指定されたAurora MySQLのテーブル定義を確認する",
"inputSchema": {
"type": "object",
"properties": {
"database": {
"type": "string",
"description": "対象のdatabase名"
},
"table": {
"type": "string",
"description": "対象のtable名"
}
},
"required": ["database", "table"]
}
}JavaScript
ツール定義をAgentCore Gatewayに登録すると、DevOps AgentからはMCP toolとして見えるようになります。
安全にDB調査するためにやったこと
今回の構成では、DevOps AgentからAurora MySQLを調査できるようにしていますが、Agentが自由にSQLを実行できる状態にはしていません。安全に扱うために、いくつかのレイヤーで制限をかけています。
Gatewayの認証はCognito JWTで制限
AgentCore Gatewayはパブリックに公開することもできますが、今回はDBを扱うためCognitoが発行したJWTを必須にしました。
DBユーザーは読み取り専用
RDS Data APIでクエリを実行するのですが、その際に利用するDBユーザーは調査対象のスキーマだけ許可した読み取り専用ユーザーとしています。
SQL validatorで危険なSQLをブロック
explain_selectツールでは、EXPLAINを実行するだけのツールですが、生成されたクエリが万が一でもそのまま実行されないよう、Lambda側でSQLを必ず検査するようにしました。以下のような制御を入れています。
- SELECT以外は拒否
- DDL/DMLは拒否
- INTO OUTFILE は拒否
- FOR UPDATE / LOCK IN SHARE MODE は拒否
- SLEEP()やBENCHMARK()は拒否
DBユーザーが読み取り専用でも、巨大なSELECTやロックを伴うSQLはサービス影響につながる可能性があるため、SQL validatorでも制御するようにしました。
DevOps AgentへのMCPサーバー追加とSkillsの作成
まずはDevOps Agentに今回作成したAgentCore GatewayをMCPサーバーとして登録します。
認証フローではOAuthクライアント認証を選択肢、クライアントIDやシークレットを登録します。
次にDevOps AgentがうまくDB調査をできるようにSkillsを整えます。
SkillsはGAリリースの際に追加された機能で、DevOps Agentが調査をする際に調査するコンポーネントやツールを指定したりすることで、調査精度の再現性を高くすることができます。
Skillsは直接追加することができます。
DevOps Agentのチャットでの対話でもSkillsを作成可能なので、こちらの方法で作成します。
ヒアリングされた項目に以下のように回答しました。
ツールの使い方と、DBのメトリクスなどを調査する順番を指定しています。
- rds-inspectorというMCPを連携済み
提供機能(ツール) ツール名:入力:出力
list_databases:なし:業務 DB 一覧 (システム DB は除外)
list_tables:database:テーブル一覧
show_create_table:database, table:CREATE TABLE ... DDL
describe_table:database, table:カラム定義 (DESCRIBE 出力)
show_indexes:database, table:インデックス一覧
explain_select :database, select_query:EXPLAIN <SELECT> の実行計画 (実データは返らない)
table_stats:database, table (任意):information_schema.TABLES から 概算行数・データ/インデックスサイズ等。table 省略時は DB 内全テーブルを件数降順で返す
- 調査の流れについて
2-1. CloudWatch/RDSメトリクスで、接続数、CPU、Read/Write Latency、FreeStorageSpace、ReplicaLag、Deadlock/Lock waitを確認する
2-2. パフォーマンスインサイト、もしくはそれに準ずる機能で、AASが高く負荷影響が高そうなクエリをいくつか特定する
2-3. 各SQLについて、MCPの各ツールを活用して詳細調査を行う
- Aurora MySQLクラスタであれば全般的に調査Python
これによって作成されたSkillsは以下のとおりです。
スキル名:
- investigate-rds-aurora-performance
Description
Systematic investigation workflow for RDS Aurora performance issues using CloudWatch metrics, Performance Insights, and the rds-inspector MCP tool. Use when users report Aurora database performance degradation, slow queries, high CPU, connection issues, or replication lag. Covers metric analysis, query identification, SQL deep-dive with schema inspection, and Aurora MySQL-specific checks.Python
SKILL.md
RDS Aurora パフォーマンス調査
このスキルは、RDS Aurora（特にAurora MySQL）のパフォーマンス問題を体系的に調査するためのワークフローを提供します。
いつ使用するか
- Auroraのパフォーマンス劣化が報告された
- データベース接続エラーが発生している
- スロークエリやタイムアウトが頻発している
- CPU使用率やレプリケーション遅延が高い
- Performance Insightsでアラートが発生している
調査の4フェーズ
Phase 1: メトリクス確認（CloudWatch/RDS）
まず、Aurora クラスターの全体的な健全性を把握します。以下のメトリクスを use_aws で確認：
必須メトリクス：
DatabaseConnections- 接続数の推移CPUUtilization- CPU使用率ReadLatency/WriteLatency- I/O レイテンシFreeableMemory- 利用可能メモリFreeLocalStorage- ストレージ容量AuroraReplicaLag- レプリケーション遅延（リードレプリカがある場合）Deadlocks- デッドロック発生数EngineUptime- 再起動の有無確認
調査時間範囲：
- 問題発生時刻を中心に前後2〜4時間のデータを取得
- 比較のため、正常時（1週間前の同時刻など）のデータも取得
判断基準：
- CPU > 80% が継続 → クエリ最適化が必要
- Connections が急増 → 接続プール設定確認
- ReadLatency/WriteLatency が急上昇 → ストレージI/O問題またはクエリ問題
- ReplicaLag > 数秒 → レプリカの負荷分散確認
- Deadlocks > 0 → トランザクション競合の調査が必要
Phase 2: クエリ特定（Performance Insights）
Performance Insights または CloudWatch Logs Insights を使用して、負荷の高いクエリを特定します。
Performance Insights での確認項目：
- AAS (Average Active Sessions) が高いクエリ
- Top SQL ランキング上位のクエリ
- Wait イベントの内訳（CPU、I/O、Lock など）
重点的に調査するクエリ：
- AAS が継続的に高い（> 1.0）クエリ
- 実行回数が多い頻繁なクエリ
- 1回あたりの実行時間が長いクエリ
問題のあるクエリを2〜3個特定したら、Phase 3 へ。
Phase 3: SQL詳細分析（rds-inspector MCP使用）
特定した問題クエリについて、rds-inspector MCP ツールを使って詳細分析を実施します。
#### 3-1. データベース構造の把握
# 業務データベース一覧を取得（システムDBは除外される）
rds-inspector___list_databases()
# 対象データベースのテーブル一覧を取得
rds-inspector___list_tables(database="your_db")
# 全テーブルの概算サイズと行数を確認（大きなテーブルを把握）
rds-inspector___table_stats(database="your_db")#### 3-2. 問題クエリが使用するテーブルの調査
Performance Insights で特定したクエリに含まれるテーブルについて調査：
テーブル構造（カラム定義）を確認
rds-inspector___describe_table(database="your_db", table="problem_table")
インデックス設定を確認
rds-inspector___show_indexes(database="your_db", table="problem_table")
CREATE TABLE DDL を取得（必要に応じて）
rds-inspector___show_create_table(database="your_db", table="problem_table")
テーブルの詳細統計（行数、データサイズ、インデックスサイズ）
rds-inspector___table_stats(database="your_db", table="problem_table")
#### 3-3. クエリ実行計画の分析
SELECT クエリの実行計画を取得（実データは返さない）
rds-inspector___explain_select(
database="your_db",
select_query="SELECT * FROM orders WHERE customer_id = 12345"
)
EXPLAIN 結果の読み方：
type: ALL→ フルテーブルスキャン（大きなテーブルで発生すると問題）type: index→ インデックスフルスキャン（改善の余地あり）type: range,ref,eq_ref→ インデックスが効いている（良好）rows: 大きい数値→ 多くの行を走査しているExtra: Using filesort→ ソート処理が重いExtra: Using temporary→ 一時テーブルを使用（重い処理）possible_keys: NULL→ 使用可能なインデックスがない
改善提案の判断基準：
- WHERE句のカラムにインデックスがない → インデックス追加を推奨
- フルテーブルスキャンが発生 → インデックス追加、クエリ改善
- テーブルサイズに対してrowsが大きすぎる → 複合インデックスの検討
- JOINでインデックスが使われていない → 結合キーへのインデックス追加
Phase 4: Aurora MySQL 全般チェック
Aurora MySQL クラスター固有の設定と状態を確認：
パラメータグループ確認：
max_connections- 接続数上限innodb_buffer_pool_size- バッファプールサイズ（メモリの大部分を占める）slow_query_log- スロークエリログが有効か
Aurora固有機能：
- Aurora Serverless を使用している場合、スケーリングイベントを確認
- バックトラック が有効な場合、利用状況を確認
- クローン機能 を使った本番データでのクエリテストを提案
レプリカ構成：
- リードレプリカの数と分散状況
- 読み取り負荷がリードレプリカに適切に分散されているか
- レプリカのエンドポイント設定が正しいか
調査結果のまとめ方
調査完了後、以下の形式で結果をまとめます：
1. 問題の症状
- どのメトリクスに異常があったか
- いつから発生しているか
2. 根本原因
- 特定された問題クエリとそのパフォーマンス特性
- インデックス不足、テーブル設計、クエリロジックのどれが原因か
3. 推奨される対策
- 即座に実施できる対策（接続数制限、クエリ改善など）
- 中長期的な改善（インデックス追加、テーブル設計変更など）
- Aurora固有機能の活用提案
4. 追加調査が必要な項目
- より詳細なログ分析が必要か
- アプリケーション側のコード確認が必要か
注意事項
- rds-inspector の EXPLAIN は実データを返さないため、本番環境でも安全に実行可能
- table_stats は
information_schema.TABLESから取得した概算値（InnoDB では 10〜50% の誤差がある） - 実際のインデックス追加やパラメータ変更は、メンテナンスウィンドウで実施することを推奨
- 大規模な ALTER TABLE は長時間ロックを伴う可能性があるため、本番実施前に検証環境でテスト
関連リソース
DBインシデント調査をさせてみた結果
調査指示: 「現在Aurora MySQLの負荷は高くないですが、負荷が高かったと想定してXXX-clusterについて調査してください」
しっかりと作成したSkillsにしたがって調査が開始されました。
指示通り、CloudWatchのメトリクス全体を見ながら、パフォーマンスインサイトやスローログの分析をし、見つかった遅いクエリに対して、テーブル構造の確認をMCPのツールをつかって確認していることが確認できます。
そして、現在の原因の仮説を検証するために、MCPのツールを問題のクエリの詳細分析を開始しています。
最終的に特定テーブルへのインデックス不足を原因として結論付けています。
終わりに
DevOps AgentにAurora MySQLのDBデータを調査させる能力を追加することで、より実務で役に立つインシデント調査エージェントになりました。
今回はDevOps Agentに追加するAgentCore GatewayのMCPサーバーの認証方式としては、Cognitoが発行したJWTを検証するOAuth認証にしていましたが、実はAgentCore Gateway側では既にSigV4 / IAM認証 が対応されています。
しかし、DevOps Agent側が現時点で対応しておらず、今回のCognitoによるJWTの方式を選択せざるをえませんでした。DevOps Agent側でSigV4/IAM認証へ対応してもらえると、IAMロールによる制御が可能になり、全体の構成をさらにシンプルにすることが可能です。この件はサポートへ機能要望として連絡しましたので、今後の進化に期待しています。
みなさんもドンドンDevOps Agentを使っていきましょう！
SRGにご興味ありましたらぜひこちらからご連絡ください。
原文を表示
2026/4/28 21:202026/5/2 9:16
投稿日
2026/5/2
タグ
AWS
Aurora
DevOps
執筆者
鬼海雄太
メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、AWS DevOps AgentからAurora MySQLの調査を安全におこなえるように、Bedrock AgentCore GatewayとLambdaを使ってDB調査用ツールを作ってみた話です。
なにかの役に立てば幸いです。
DevOps AgentからAurora MySQLを調査したい全体の構成Aurora MySQL MCPサーバーではなく、AgentCore Gateway+Lambdaを採用した理由Amazon Bedrock AgentCore GatewayとはLambdaで実装した機能安全にDB調査するためにやったことGatewayの認証はCognito JWTで制限DBユーザーは読み取り専用SQL validatorで危険なSQLをブロックDevOps AgentへのMCPサーバー追加とSkillsの作成DBインシデント調査をさせてみた結果終わりに
DevOps AgentからAurora MySQLを調査したい
DevOps Agentは2026年3月31日にGAリリースされた機能で、CloudWatchやAWSリソースの情報をもとに、インシデントの原因調査や復旧提案をしてくれる機能です。
詳しくは過去にブログ記事で取り上げているのでご参照ください。
DevOps AgentはAWS内のリソースを隈無く調査してくれるのですが、DBの中のデータまでは確認することはできません。
ただ、実際の障害調査ではAWSリソースの状態だけでなくDBの中も見たいケースがよくあります。
例えば、Aurora MySQLを利用しているアプリケーションのエラーやレイテンシ悪化が発生しているときに、以下のようなことを確認したくなります。
- 対象DBにどんなテーブルがあるか
- テーブルの構成は？インデックスが適切に貼られているか
- 問題になっているSELECTのEXPLAINがどうなるか
- テーブルサイズや行数の傾向がどうなっているか
DevOps AgentにはMCPの連携機能があるため、Aurora MySQLに接続できるMCPがあれば実現することができます。
全体の構成
まずは今回作成した全体の構成図を紹介します。
ざっくりした流れは以下のとおりです。
- DevOps Agentへユーザーが調査指示を出す
- DevOps AgentがAgentCore GatewayにMCPリクエストを送信
- AgentCore GatewayがJWTを検証
- AgentCore GatewayがGateway用IAM RoleでLambdaをInvoke
- Lambdaがツール名と引数をもとにAurora MySQL調査用処理を実行
- LambdaがRDS Data API経由でAurora MySQLにクエリを実行
- 結果をAgentCore Gateway経由でDevOps Agentへ返却
Aurora MySQL MCPサーバーではなく、AgentCore Gateway+Lambdaを採用した理由
最初は、AWS labsのAurora MySQL MCP サーバー を利用すれば簡単に実現できるのでは？と考えていました。
しかし、DevOps Agentから追加するMCPサーバーは、remote MCP endpointとして到達できる必要があります。
一方、AWS LabsのMySQL MCP ServerはローカルMCPクライアントからstdioで利用する前提の構成だったため、そのままでは利用できませんでした。
また、仮にMySQL MCP Serverが利用できたとしても、このMCPサーバーはread-only制御や一部の危険パターン検出はありますが、任意SQLを受け取るrun_queryが中心です。
そのため、高負荷なSELECT、巨大なJOIN、LIMITなしの大量取得など、読み取りクエリによる負荷影響を用途別に制限する仕組みまではありません。
今回の用途では、本番Aurora MySQLに対して障害調査の初動で使うことを想定していたため、汎用的なSQL実行ツールではなく、調査用途に絞ったツールだけをAgentCore Gateway + Lambdaで公開する構成にしました。
Amazon Bedrock AgentCore Gatewayとは
Amazon Bedrock AgentCore Gateway(以下、AgentCore Gateway)は、Agentから見ると1つのMCPエンドポイントとして振る舞ってくれるマネージドなゲートウェイです。LambdaやAPIなどをTargetとして登録すると、GatewayがそれらをMCP互換のtoolとして公開してくれます。
AgentCore Gatewayは、MCP endpointを全公開するだけの仕組みではなく、入口に認証を設定できます。今回は、このAgentCore GatewayのMCP endpointにCognito JWT認証を付け、DevOps Agentからの正当なリクエストだけを受け付ける構成にしました。
Lambdaで実装した機能
Aurora MySQL調査用LambdaをAgentCore GatewayのTargetとして登録します。
今回は rds-inspector というLambda関数を作成し、以下のようなツールを実装しました。
Tool機能
*list_databases*DB 一覧
list_tablesテーブル一覧
show_create_tableテーブル構造表示
show_indexesインデックス表示
explain_selectEXPLAIN SELECTの実行計画表示
table_statsinformation_schema.TABLES から 概算行数・データ/インデックスサイズ等表示
AgentCore GatewayのLambda Targetでは、ツールのinputSchemaを定義しておきます。
例えば、show_create_table なら以下のようなイメージです。
{
"name": "show_create_table",
"description": "指定されたAurora MySQLのテーブル定義を確認する",
"inputSchema": {
"type": "object",
"properties": {
"database": {
"type": "string",
"description": "対象のdatabase名"
},
"table": {
"type": "string",
"description": "対象のtable名"
}
},
"required": ["database", "table"]
}
}JavaScriptツール定義をAgentCore Gatewayに登録すると、DevOps AgentからはMCP toolとして見えるようになります。
安全にDB調査するためにやったこと
今回の構成では、DevOps AgentからAurora MySQLを調査できるようにしていますが、Agentが自由にSQLを実行できる状態にはしていません。安全に扱うために、いくつかのレイヤーで制限をかけています。
Gatewayの認証はCognito JWTで制限
AgentCore Gatewayはパブリックに公開することもできますが、今回はDBを扱うためCognitoが発行したJWTを必須にしました。
DBユーザーは読み取り専用
RDS Data APIでクエリを実行するのですが、その際に利用するDBユーザーは調査対象のスキーマだけ許可した読み取り専用ユーザーとしています。
SQL validatorで危険なSQLをブロック
explain_selectツールでは、EXPLAINを実行するだけのツールですが、生成されたクエリが万が一でもそのまま実行されないよう、Lambda側でSQLを必ず検査するようにしました。以下のような制御を入れています。
- SELECT以外は拒否
- DDL/DMLは拒否
- INTO OUTFILE は拒否
- FOR UPDATE / LOCK IN SHARE MODE は拒否
- SLEEP()やBENCHMARK()は拒否
DBユーザーが読み取り専用でも、巨大なSELECTやロックを伴うSQLはサービス影響につながる可能性があるため、SQL validatorでも制御するようにしました。
DevOps AgentへのMCPサーバー追加とSkillsの作成
まずはDevOps Agentに今回作成したAgentCore GatewayをMCPサーバーとして登録します。
認証フローではOAuthクライアント認証を選択肢、クライアントIDやシークレットを登録します。
次にDevOps AgentがうまくDB調査をできるようにSkillsを整えます。
SkillsはGAリリースの際に追加された機能で、DevOps Agentが調査をする際に調査するコンポーネントやツールを指定したりすることで、調査精度の再現性を高くすることができます。
Skillsは直接追加することができます。
DevOps Agentのチャットでの対話でもSkillsを作成可能なので、こちらの方法で作成します。
ヒアリングされた項目に以下のように回答しました。
ツールの使い方と、DBのメトリクスなどを調査する順番を指定しています。
1. rds-inspectorというMCPを連携済み
提供機能(ツール) ツール名:入力:出力
list_databases:なし:業務 DB 一覧 (システム DB は除外)
list_tables:database:テーブル一覧
show_create_table:database, table:CREATE TABLE ... DDL
describe_table:database, table:カラム定義 (DESCRIBE 出力)
show_indexes:database, table:インデックス一覧
explain_select :database, select_query:EXPLAIN <SELECT> の実行計画 (実データは返らない)
table_stats:database, table (任意):information_schema.TABLES から 概算行数・データ/インデックスサイズ等。table 省略時は DB 内全テーブルを件数降順で返す
2. 調査の流れについて
2-1. CloudWatch/RDSメトリクスで、接続数、CPU、Read/Write Latency、FreeStorageSpace、ReplicaLag、Deadlock/Lock waitを確認する
2-2. パフォーマンスインサイト、もしくはそれに準ずる機能で、AASが高く負荷影響が高そうなクエリをいくつか特定する
2-3. 各SQLについて、MCPの各ツールを活用して詳細調査を行う
3. Aurora MySQLクラスタであれば全般的に調査Pythonこれによって作成されたSkillsは以下のとおりです。
スキル名:
- investigate-rds-aurora-performance
Description
Systematic investigation workflow for RDS Aurora performance issues using CloudWatch metrics, Performance Insights, and the rds-inspector MCP tool. Use when users report Aurora database performance degradation, slow queries, high CPU, connection issues, or replication lag. Covers metric analysis, query identification, SQL deep-dive with schema inspection, and Aurora MySQL-specific checks.PythonSKILL.md
# RDS Aurora パフォーマンス調査
このスキルは、RDS Aurora（特にAurora MySQL）のパフォーマンス問題を体系的に調査するためのワークフローを提供します。
## いつ使用するか
- Auroraのパフォーマンス劣化が報告された
- データベース接続エラーが発生している
- スロークエリやタイムアウトが頻発している
- CPU使用率やレプリケーション遅延が高い
- Performance Insightsでアラートが発生している
## 調査の4フェーズ
### Phase 1: メトリクス確認（CloudWatch/RDS）
まず、Aurora クラスターの全体的な健全性を把握します。以下のメトリクスを **use_aws** で確認：
**必須メトリクス：**
- `DatabaseConnections` - 接続数の推移
- `CPUUtilization` - CPU使用率
- `ReadLatency` / `WriteLatency` - I/O レイテンシ
- `FreeableMemory` - 利用可能メモリ
- `FreeLocalStorage` - ストレージ容量
- `AuroraReplicaLag` - レプリケーション遅延（リードレプリカがある場合）
- `Deadlocks` - デッドロック発生数
- `EngineUptime` - 再起動の有無確認
**調査時間範囲：**
- 問題発生時刻を中心に前後2〜4時間のデータを取得
- 比較のため、正常時（1週間前の同時刻など）のデータも取得
**判断基準：**
- CPU > 80% が継続 → クエリ最適化が必要
- Connections が急増 → 接続プール設定確認
- ReadLatency/WriteLatency が急上昇 → ストレージI/O問題またはクエリ問題
- ReplicaLag > 数秒 → レプリカの負荷分散確認
- Deadlocks > 0 → トランザクション競合の調査が必要
### Phase 2: クエリ特定（Performance Insights）
Performance Insights または CloudWatch Logs Insights を使用して、負荷の高いクエリを特定します。
**Performance Insights での確認項目：**
- **AAS (Average Active Sessions)** が高いクエリ
- **Top SQL** ランキング上位のクエリ
- Wait イベントの内訳（CPU、I/O、Lock など）
**重点的に調査するクエリ：**
1. AAS が継続的に高い（> 1.0）クエリ
2. 実行回数が多い頻繁なクエリ
3. 1回あたりの実行時間が長いクエリ
問題のあるクエリを2〜3個特定したら、Phase 3 へ。
### Phase 3: SQL詳細分析（rds-inspector MCP使用）
特定した問題クエリについて、`rds-inspector` MCP ツールを使って詳細分析を実施します。
#### 3-1. データベース構造の把握
業務データベース一覧を取得（システムDBは除外される）
rds-inspector___list_databases()
対象データベースのテーブル一覧を取得
rds-inspector___list_tables(database="your_db")
全テーブルの概算サイズと行数を確認（大きなテーブルを把握）
rds-inspector___table_stats(database="your_db")
#### 3-2. 問題クエリが使用するテーブルの調査
Performance Insights で特定したクエリに含まれるテーブルについて調査：
# テーブル構造（カラム定義）を確認
rds-inspector___describe_table(database="your_db", table="problem_table")
# インデックス設定を確認
rds-inspector___show_indexes(database="your_db", table="problem_table")
# CREATE TABLE DDL を取得（必要に応じて）
rds-inspector___show_create_table(database="your_db", table="problem_table")
# テーブルの詳細統計（行数、データサイズ、インデックスサイズ）
rds-inspector___table_stats(database="your_db", table="problem_table")
#### 3-3. クエリ実行計画の分析
# SELECT クエリの実行計画を取得（実データは返さない）
rds-inspector___explain_select(
database="your_db",
select_query="SELECT * FROM orders WHERE customer_id = 12345"
)
**EXPLAIN 結果の読み方：**
- `type: ALL` → フルテーブルスキャン（大きなテーブルで発生すると問題）
- `type: index` → インデックスフルスキャン（改善の余地あり）
- `type: range`, `ref`, `eq_ref` → インデックスが効いている（良好）
- `rows: 大きい数値` → 多くの行を走査している
- `Extra: Using filesort` → ソート処理が重い
- `Extra: Using temporary` → 一時テーブルを使用（重い処理）
- `possible_keys: NULL` → 使用可能なインデックスがない
**改善提案の判断基準：**
1. WHERE句のカラムにインデックスがない → インデックス追加を推奨
2. フルテーブルスキャンが発生 → インデックス追加、クエリ改善
3. テーブルサイズに対してrowsが大きすぎる → 複合インデックスの検討
4. JOINでインデックスが使われていない → 結合キーへのインデックス追加
### Phase 4: Aurora MySQL 全般チェック
Aurora MySQL クラスター固有の設定と状態を確認：
**パラメータグループ確認：**
- `max_connections` - 接続数上限
- `innodb_buffer_pool_size` - バッファプールサイズ（メモリの大部分を占める）
- `slow_query_log` - スロークエリログが有効か
**Aurora固有機能：**
- **Aurora Serverless** を使用している場合、スケーリングイベントを確認
- **バックトラック** が有効な場合、利用状況を確認
- **クローン機能** を使った本番データでのクエリテストを提案
**レプリカ構成：**
- リードレプリカの数と分散状況
- 読み取り負荷がリードレプリカに適切に分散されているか
- レプリカのエンドポイント設定が正しいか
## 調査結果のまとめ方
調査完了後、以下の形式で結果をまとめます：
### 1. 問題の症状
- どのメトリクスに異常があったか
- いつから発生しているか
### 2. 根本原因
- 特定された問題クエリとそのパフォーマンス特性
- インデックス不足、テーブル設計、クエリロジックのどれが原因か
### 3. 推奨される対策
- 即座に実施できる対策（接続数制限、クエリ改善など）
- 中長期的な改善（インデックス追加、テーブル設計変更など）
- Aurora固有機能の活用提案
### 4. 追加調査が必要な項目
- より詳細なログ分析が必要か
- アプリケーション側のコード確認が必要か
## 注意事項
- **rds-inspector の EXPLAIN** は実データを返さないため、本番環境でも安全に実行可能
- **table_stats** は `information_schema.TABLES` から取得した概算値（InnoDB では 10〜50% の誤差がある）
- 実際のインデックス追加やパラメータ変更は、メンテナンスウィンドウで実施することを推奨
- 大規模な ALTER TABLE は長時間ロックを伴う可能性があるため、本番実施前に検証環境でテスト
## 関連リソース
- [AWS Aurora Performance Insights ユーザーガイド](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.html)
- [Aurora MySQL クエリ最適化](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.BestPractices.html)PythonDBインシデント調査をさせてみた結果
調査指示: 「現在Aurora MySQLの負荷は高くないですが、負荷が高かったと想定してXXX-clusterについて調査してください」
しっかりと作成したSkillsにしたがって調査が開始されました。
指示通り、CloudWatchのメトリクス全体を見ながら、パフォーマンスインサイトやスローログの分析をし、見つかった遅いクエリに対して、テーブル構造の確認をMCPのツールをつかって確認していることが確認できます。
そして、現在の原因の仮説を検証するために、MCPのツールを問題のクエリの詳細分析を開始しています。
最終的に特定テーブルへのインデックス不足を原因として結論付けています。
終わりに
DevOps AgentにAurora MySQLのDBデータを調査させる能力を追加することで、より実務で役に立つインシデント調査エージェントになりました。
今回はDevOps Agentに追加するAgentCore GatewayのMCPサーバーの認証方式としては、Cognitoが発行したJWTを検証するOAuth認証にしていましたが、実はAgentCore Gateway側では既にSigV4 / IAM認証 が対応されています。
しかし、DevOps Agent側が現時点で対応しておらず、今回のCognitoによるJWTの方式を選択せざるをえませんでした。DevOps Agent側でSigV4/IAM認証へ対応してもらえると、IAMロールによる制御が可能になり、全体の構成をさらにシンプルにすることが可能です。この件はサポートへ機能要望として連絡しましたので、今後の進化に期待しています。
みなさんもドンドンDevOps Agentを使っていきましょう！
SRGにご興味ありましたらぜひこちらからご連絡ください。
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み