🤖

Q Developer で Ops できるかな

2025/11/01に公開

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井亮です。

日常業務やコーディングでは AI が大活躍していると思います。
AI による改善や効率化が向いている分野とそうでない分野は確実にあると考えています。

個人的な観測ではありますが、IT Ops においては AI 活用が慎重なように感じます。
やはり人間による判断が依然不可欠であることと、ハルシネーションを許容できるウィンドウが狭いことに起因しているのでしょう。
ただ、将来的には AI が IT Ops 業務を担うことも十分に考えられます。
ということで、今回は Q Developer CLI を使って AWS 上のシステムの Ops を体験してみます。

2025/10/21(火) に Ops-JAWS でハンズオンを開催しました。
そこで使用した資料を基に Q Developer CLI を使った Ops 体験の内容を紹介します。

ハンズオン環境の構築

オブザーバビリティを体験するハンズオンでは定番の PetClinic を少しだけカスタマイズした環境を使用します。
以下のリポジトリの1〜2章を実行してください。

Q Developer おすすめ設定

Q Developer CLI では、特定のユースケースやワークフローに合わせて設定をカスタマイズしたエージェントを作成できます。
自分たちが管理するシステムに合わせたツールやコンテキストを事前に設定しておくことで、Q Developer CLI の応答の精度と関連性を向上させることができます。

詳細は User Guide に記載されています。

mcpServers

Q Developer CLI が使う MCP Server を指定します。
MCP Server 無しでは Ops できないと言っても過言ではないくらい便利です。
本ハンズオンでは Core MCP Server という様々な AWS MCP Server のプロキシとなるものを使用しています。
他の MCP Server を使ってみたい方は Welcome to AWS MCP Servers を参照してください。

	"mcpServers": {
		"awslabs.core-mcp-server": {
			"command": "uvx",
			"args": [
				"awslabs.core-mcp-server@latest"
			],
			"env": {
				"FASTMCP_LOG_LEVEL": "ERROR",
				"AWS_PROFILE": "opsjaws-handson",
				"AWS_REGION": "ap-northeast-1",
				"aws-foundation": "true",
				"solutions-architect": "true",
				"security-identity": "true",
				"monitoring-observability": "true"
			},
			"autoApprove": [],
			"disabled": false
		}
	},

tools

利用可能なツールを指定します。
"*" とすることで、MCP Server を含む全てのツールが利用可能になります。

Q Developer CLI には以下のようなビルドインツールが用意されています。
どのツールを使わせるかの選択がここで可能です。例えば、読み取り専用にしたいので fs_write や execute_bash を外すといった使い方が想定されます。

fs_read - Read files, directories, and images
fs_write - Create and edit files
execute_bash - Execute shell commands
use_aws - Make AWS CLI API calls
knowledge - Store and retrieve information across sessions
introspect - Provide information about Q CLI capabilities

MCP Server で使用するツールを厳選したい場合もここで指定します。

	"tools": [
		"*"
	],

allowedTools

プロンプトで使用許可有無を聞かれることなく使えるツールを指定します。
毎回プロンプトで実行の確認をしたほうが安全ではありますが、煩わしいと感じたときはここで指定します。

  "allowedTools": [
    "fs_read"
  ]

resources

Q Developer CLI が参照するリソースを指定します。
AmazonQ.md はいわゆる指示書や Agents.md のような存在です。

1.19.0 (2025-10-23) のアップデートで PDF ファイルをナレッジとして読み込むことが可能になりました。
Well-Architected のドキュメントや AWS サービスのユーザーガイドを読み込ませることで、より高度な Ops を実現できるかもしれません。

	"resources": [
		"file://AmazonQ.md",
		"file://resources.md"
	],

リソース

Q Developer CLI が参照する AWS リソースを列挙しています。
ここを充実させることで、Q Developer CLI の回答の精度が向上します。

ただ単に「データベースの負荷を調べて」だけでは正しい調査をしてくれることはありません。
Q Developer CLI にははっきりと明確な指示を出したいのでリソースを列挙することにしました。
上で紹介したハンズオンでは CDK でリソースを作成していますので、CloudFormation のアウトプットをここに書くような手順にしています。

toolsSettings

特定のツールに対する設定を指定します。
以下の例だと、execute_bash ツールで実行できないコマンドを指定しています。

  "toolsSettings": {
	"execute_bash": {
		"allowedCommands": [],
		"deniedCommands": [
			"git commit .*",
			"git push .*",
			"rm -rf .*",
			"sudo .*",
			"shutdown .*",
			"reboot .*"
		],
		"allowReadOnly": true
	}
  }

やってみた

ハンズオン環境が完成したら30〜60分ほど待機します。
トラフィックが生成され、シグナルが蓄積されます。

Q Developer CLI でのプロンプトと回答を紹介します。

あえてざっくりとした命令を出します。障害が起きてそうだが、人間により調査は何もしていない想定です。

命令

[opsjaws] > 直近30分で一部の顧客からpetが表示されていないという問い合わせが複数ある。サービスが稼働しているかを調べて報告して。

回答

> ## Pet Clinicサービス稼働状況報告

調査時刻: 2025年11月1日 09:24 (JST)  
調査対象期間: 直近30分間 (08:54-09:24)

### 📊 サービス稼働状況

✅ 全サービス正常稼働中

1. ECSサービス状況:
   • pet-clinic-customers-service: ACTIVE (1/1 running)
   • pet-clinic-visits-service: ACTIVE (1/1 running) 
   • pet-clinic-api-gateway: ACTIVE (1/1 running)
   • 全サービスが期待数通りに稼働中

2. Application Signals監視:
   • 6つのサービス全てが健全状態
   • SLO違反なし
   • 直近30分間で問題検出なし

3. ロードバランサー:
   • API Gatewayのターゲットグループ: healthy
   • ターゲット (10.0.5.103:8080) が正常応答中

4. CloudWatchアラーム:
   • アクティブなアラームなし

### 🔍 追加調査が必要な点

顧客からの「petが表示されない」問題について、インフラレベルでは異常が検出されていません。以下の調査を推奨します：

1. アプリケーションログの確認
2. データベース接続状況の確認
3. 特定の顧客環境やブラウザ固有の問題
4. CDNやキャッシュの問題

現時点では、AWS基盤レベルでのサービス障害は確認されていません。

現時点ではサービス障害なしとの回答でした。深堀りしてみましょう。

命令

[opsjaws] > サービスのエンドポイントごとの可用性を調査、98%未満のエンドポイントをリストして

回答

> ## 📊 エンドポイント可用性調査結果

調査期間: 直近1時間 (08:26-09:26 JST)  
可用性基準: 98%未満のエンドポイントをリスト

### ✅ 98%未満の可用性エンドポイント: なし

全サービスの可用性計算結果:

| サービス                     | 平均エラー率 | 可用性 | 状況      |
| ---------------------------- | ------------ | ------ | --------- |
| pet-clinic-customers-service | 5%           | 95.0%  | ⚠️ 98%未満 |
| pet-clinic-api-gateway       | 6%           | 94.0%  | ⚠️ 98%未満 |
| pet-clinic-visits-service    | 0%           | 100%   | ✅ 正常    |
| pet-clinic-vets-service      | 0%           | 100%   | ✅ 正常    |
| pet-clinic-billing-service   | 0%           | 100%   | ✅ 正常    |
| pet-clinic-insurance-service | 1%           | 99.0%  | ✅ 正常    |

### 🚨 98%未満の問題エンドポイント

1. pet-clinic-customers-service (95.0%可用性)
   • 主要エンドポイント:
     • GET /diagnose/owners/{ownerId}/pets/{petId} (pet情報取得)
     • GET /owners/{ownerId} (オーナー情報取得)
     • POST /owners/{ownerId}/pets (pet登録)

2. pet-clinic-api-gateway (94.0%可用性)
   • 主要エンドポイント:
     • GET /api/customer/diagnose/owners/{ownerId}/pets/{petId} (pet診断情報)
     • GET /api/gateway/owners/{ownerId} (オーナー情報)
     • POST /api/customer/owners/{ownerId}/pets (pet登録)

### 💡 推奨アクション

customers-serviceと**api-gateway**で5-6%のエラー率が発生しており、これが「petが表示されない」問題の原因と考えられます。

1. 即座の対応:
   • customers-serviceのログ詳細調査
   • データベース接続状況確認
   • API Gateway → customers-service間の通信確認

2. 根本原因調査:
   • pet情報取得エンドポイントの詳細エラー分析
   • 特定時間帯のエラースパイク調査

pet-clinic-api-gateway の可用性が低いと報告されました。このサービスにフォーカスしてみます。

命令

[opsjaws] > pet-clinic-api-gateway の障害発生箇所をログから特定して

回答

> ## 🚨 pet-clinic-api-gateway 障害発生箇所の特定結果

調査期間: 2025年11月1日 08:30-09:34 (JST)

### 📍 主要障害箇所

#### 1. customers-serviceとの接続障害
• **障害パターン**: PrematureCloseException: Connection prematurely closed BEFORE response
• **接続先**: pet-clinic-customers-service-DNS.ecs-pet-clinic/10.0.4.144:39421
• **発生頻度**: 直近1時間で991件のエラー

#### 2. エラー発生時間帯の集中
| 時間帯      | エラー数 | 状況         |
| ----------- | -------- | ------------ |
| 00:30-00:35 | 346件    | 🔥 最大ピーク |
| 00:00-00:05 | 251件    | 🔥 高頻度     |
| 00:20-00:25 | 89件     | ⚠️ 中程度     |
| 23:30-23:35 | 73件     | ⚠️ 中程度     |

#### 3. 具体的なエラーパターン

A. 接続エラー
reactor.netty.http.client.PrematureCloseException: Connection prematurely closed BEFORE response


B. HTTP 503/500エラー
503 Service Unavailable from UNKNOWN
500 Server Error for HTTP POST "/api/visit/owners/8/pets/10/visits"


C. 接続警告
[632c13a5-3, L:/10.0.5.103:34044 ! R:pet-clinic-customers-service-DNS.ecs-pet-clinic/10.0.4.144:39421] The connection observed an error


### 🎯 根本原因

1. API Gateway → customers-service間の接続不安定
   • customers-service (10.0.4.144:39421) への接続が頻繁に切断
   • 特に00:30頃に集中的な障害発生

2. 影響を受けるエンドポイント
   • POST /api/visit/owners/{ownerId}/pets/{petId}/visits (visit登録)
   • GET /api/customer/diagnose/owners/{ownerId}/pets/{petId} (pet診断情報)

### 💡 推奨対応

即座の対応:
1. customers-serviceの健全性確認
2. ネットワーク接続の安定性調査
3. customers-serviceのリソース使用状況確認

根本対策:
1. 接続プールの設定見直し
2. リトライ機構の強化
3. サーキットブレーカーの実装

この接続問題が「petが表示されない」顧客問題の直接的な原因です。

どうやら customers-service が疑われています。健全性を確認してみます。

命令

[opsjaws] > customers-serviceの健全性確認して

回答

> ## 🔍 customers-service 健全性確認結果

調査時刻: 2025年11月1日 09:39 (JST)

### 📊 ECSサービス状況

✅ インフラレベル: 正常
• **サービス状態**: ACTIVE
• **タスク状況**: 1/1 running (期待通り)
• **デプロイ状況**: COMPLETED (08:22完了)
• **ネットワーク**: 10.0.4.144:39421 (正常接続)

### 📈 リソース使用状況

⚠️ メモリ使用率: 高負荷
• **CPU使用率**: 3-16% (正常範囲)
• **メモリ使用率**: 88-93% (⚠️ 高負荷状態)
  • 開始時: 88% → 現在: 93%
  • **継続的な上昇傾向**

### 🚨 アプリケーションレベルの問題

❌ 重大な問題発見

#### 1. 無効なOwner ID エラー
ERROR: Invalid owner id provided: -1

• **発生頻度**: 直近1時間で218件
• **影響**: pet情報取得の失敗
• **原因**: 不正なowner_id (-1) がリクエストされている

#### 2. メモリリーク疑い
• メモリ使用率が88% → 93%に継続上昇
• 512MB制限に対して93%使用 (約476MB)
• **メモリ不足による接続切断の可能性**

### 🎯 根本原因分析

1. メモリ不足による接続問題
   • 高メモリ使用率 (93%) がAPI Gatewayからの接続切断を引き起こしている
   • PrematureCloseException の直接的原因

2. アプリケーションバグ
   • 無効なowner_id (-1) の処理でエラー多発
   • エラーハンドリング不備がメモリリークを助長

### 💡 緊急対応推奨

即座の対応:
1. メモリ制限の増加 (512MB → 1024MB)
2. タスクの再起動 (メモリリーク解消)
3. 無効ID検証の強化

根本対策:
1. メモリリーク調査とコード修正
2. エラーハンドリングの改善
3. リソース監視アラートの設定

customers-serviceの高メモリ使用率とアプリケーションエラーが、API Gatewayとの接続問題を引き起こし、「petが表示されない」問題の根本原因となっています。

pet-clinic-api-gateway から他サービスへ POST しているリクエストで影響を受けているエンドポイントがあるので、こちらも調査してみます。

命令

[opsjaws] > 'POST /api/visit/owners/{ownerId}/pets/{petId}/visits (visit登録)' は visits サービスが応答している。visits サービスに異常はないか？

回答

> ## 🔍 visits-service 健全性確認結果

調査時刻: 2025年11月1日 09:44 (JST)

### 📊 ECSサービス状況

⚠️ タスク再起動が発生
• **サービス状態**: ACTIVE
• **タスク状況**: 1/1 running
• **重要**: 09:30にタスクが再起動 (新タスクID: b64e35ccf9e34bd9921fc1a9d57fdf05)
• **前回タスク**: 5738edb2954345338be157de99fdae34 (08:20-09:30)

### 📈 リソース使用状況の異常

🚨 深刻なリソース問題

#### **CPU使用率の異常スパイク**
• **通常時**: 1-8% (正常)
• **00:26-00:32**: 79% → 99% (🔥 異常スパイク)
• **現在**: 20-22% (やや高め)

#### **メモリ使用率の危険レベル**
• **00:26**: 98.8%
• **00:28**: 99.6% (🚨 限界値)
• **00:30**: 12% (タスク再起動後)
• **現在**: 89% (再び上昇中)

### 🔍 ログ分析結果

✅ アプリケーションエラーなし
• 直近1時間でERROR/Exceptionログなし
• customers-serviceとは対照的に健全

### 🎯 根本原因分析

#### 1. メモリ不足によるタスク強制終了
• 00:28に99.6%のメモリ使用率到達
• 00:30にタスクが強制終了・再起動
• **OOMKiller (Out of Memory Killer) による強制終了の可能性**

#### 2. visits-serviceの問題
• **メモリリーク**: 継続的なメモリ使用率上昇
• **CPU負荷**: 異常なCPUスパイク (99%)
• **リソース不足**: 512MB制限に対して99%使用

### 💡 visits-serviceの影響

visits-serviceも問題あり:
1. メモリリーク: customers-serviceと同様の症状
2. タスク再起動: 09:30に強制再起動発生
3. POST /api/visit/owners/{ownerId}/pets/{petId}/visits エンドポイントの不安定性

### 🚨 結論

visits-serviceにも異常あり:
• **メモリ不足による強制再起動**が09:30に発生
• **customers-serviceと同様のメモリリーク問題**
• **両サービスともリソース不足**が根本原因

推奨対応:
1. 両サービスのメモリ制限増加 (512MB → 1024MB)
2. メモリリーク調査
3. リソース監視強化

visits-serviceも customers-serviceと同様に、メモリ不足とリソース問題を抱えており、visit登録機能の不安定性の原因となっています。

少々納得いかないので深堀りを依頼します。

命令

[opsjaws] > POST /api/visit/owners/{ownerId}/pets/{petId}/visits エンドポイントの不安定性なのに、ログに何も出ていないのは不思議だ。ログの検索パターンを変化させながら深堀りして。

回答

> ## 🔍 visits-service ログ深掘り調査結果

調査時刻: 2025年11月1日 09:49 (JST)

### 🎯 重要な発見

#### 1. POST /visits エンドポイントは正常動作中
INFO: Reaching Post api: owners/*/pets/{petId}/visits for petId: 8
INFO: Saving visit Visit(id=null, date=Tue Aug 01 00:00:00 UTC 2023, description=low-traffic-visit-25, petId=11)
INFO: Reaching DdbService.putItems()

• **POST リクエストは正常に受信・処理されている**
• **DynamoDB書き込みも正常実行**

#### 2. サイレント障害の可能性
• **アプリケーションログにエラーなし**
• **WARNログも設定関連のみ (LoadBalancer cache)**
• **DynamoDBエラーなし**

#### 3. タスク再起動の証拠
Started VisitsServiceApplication in 136.896 seconds (JVM running for 196.745)

• **09:30頃にタスク再起動発生**
• **起動に136秒かかっている** (通常より長い)

### 🚨 問題の本質

#### **サイレント障害 (Silent Failure)**
1. アプリケーションレベルでは正常
   • POST処理は成功
   • DynamoDB書き込みも成功
   • エラーログなし

2. インフラレベルで問題
   • **メモリ不足 (99.6%)**
   • **CPU異常スパイク (99%)**
   • **OOMKillerによる強制終了**

3. 接続レベルで障害
   • API Gateway → visits-service間の接続が不安定
   • **レスポンス返却前に接続切断**
   • クライアントには503/500エラーとして見える

### 💡 なぜログにエラーが出ないのか

#### **メモリ不足による接続切断メカニズム**
1. リクエスト受信: visits-serviceは正常にPOSTを受信
2. 処理実行: DynamoDB書き込みまで正常完了
3. レスポンス送信前: メモリ不足でタスクが強制終了
4. 接続切断: API Gatewayへのレスポンス送信失敗
5. クライアント側: 503/500エラーを受信

#### **ログが出ない理由**
• **アプリケーション処理は成功** → ERRORログなし
• **OOMKillerによる強制終了** → ログ出力前に終了
• **インフラレベルの問題** → アプリケーションログに記録されない

### 🎯 結論

visits-serviceの「不安定性」の正体:
1. 機能的には正常動作 (POST処理、DB書き込み成功)
2. リソース不足による接続切断 (メモリ99.6%、CPU99%)
3. サイレント障害 (アプリケーションログにエラーなし)
4. クライアント側でのみエラー検出 (API Gatewayで503/500)

これが「ログに何も出ていない」理由です。

推奨対応:
1. メモリ制限増加 (512MB → 1024MB)
2. リソース監視強化 (メモリ/CPU使用率アラート)
3. ヘルスチェック改善 (リソース状況を含む)

根本原因の確証がまだ得られていないように感じるのですが、 OOMKiller による強制終了は私も確認しています。これは対応が必要な事象です。

命令

[opsjaws] > 推奨対応の 1 を実施して

回答

> Perfect! I have successfully implemented the memory increase for the visits-service. Here's what has been accomplished:

## Memory Increase Implementation Complete

Based on our previous analysis where we identified memory exhaustion as the root cause of the connection issues between API Gateway and the services (with memory usage reaching 99.6%), I have:

### ✅ Task Definition Updated
• **Created new revision 10** of the pet-clinic-visits-service task definition
• **Increased total memory from 512MB to 1024MB** (100% increase)
• **Main container memory**: 512MB → 896MB
• **CloudWatch agent memory**: Maintained at 128MB
• **Preserved all existing configuration** (environment variables, networking, logging, etc.)

### ✅ Service Deployment Initiated
• **Updated ECS service** to use the new task definition (revision 10)
• **Rolling deployment in progress** - ECS is safely transitioning from the old task to the new one
• **Zero downtime deployment** - the old task continues running until the new one is healthy

### 🎯 Expected Impact
This memory increase should resolve the issues we identified in our previous analysis:
• **Eliminate memory-induced connection failures** that were causing the PrematureCloseException errors
• **Prevent OOMKiller interventions** that were forcing task restarts
• **Improve service stability** and response reliability
• **Reduce the 991 connection errors** we found in the API Gateway logs

The deployment is currently in progress. Once the new task with increased memory is running and healthy, the old task will be terminated, completing the rolling deployment. This should resolve the silent failure mechanism where services were 
processing requests successfully but failing to return responses due to resource exhaustion.

ECS タスク定義を更新し、デプロイまでを Q Developer CLI に実施してもらいました。確認しましょう。

命令

[opsjaws] > 更新したECSタスクが正常に起動しているかを確認して

回答

> ## ✅ 更新されたECSタスクが正常に起動しています

### 📊 タスクステータス
• **タスクID**: 042a6b04588d40e2a3657e0faf023fbb
• **ステータス**: RUNNING (正常稼働中)
• **タスク定義**: pet-clinic-visits-service:10 (新しいリビジョン)
• **開始時刻**: 09:56:11 (約1分前に起動完了)

### 🔧 メモリ設定確認
• **総メモリ**: 1024MB (512MB → 1024MB に増加)
• **メインコンテナ**: 896MB (512MB → 896MB に増加)
• **CloudWatchエージェント**: 128MB (変更なし)

### 🚀 デプロイメント状況
• **新しいタスク**: 正常に起動し、RUNNING状態
• **古いタスク**: 既に停止済み (DRAINING完了)
• **ローリングデプロイメント**: ほぼ完了（最終段階）

### 📍 ネットワーク情報
• **プライベートIP**: 10.0.4.178
• **サブネット**: subnet-02c26bd4b434d30c4
• **接続状態**: CONNECTED

結論: メモリを2倍に増加させた新しいタスクが正常に起動し、以前のメモリ不足による接続エラーの問題が解決される見込みです。

おわりに

AI による Ops がミドル以上のエンジニアと同等の調査能力を発揮するかと言われると、現時点では未だでしょう。
しかし、AI を Ops に使う側のノウハウが溜まってくれば一気にブレイクするはずです。

開発領域では SDD (Specification Driven Development) により:

仕様作成
開発計画作成
タスク自動分解
コーディング
自動テスト実行および修正

という自動化チェーンが一般化しつつあります。
Ops においても

状態スナップショット収集 (メトリクス / ログ / 構成)
逸脱検出 (閾値 / 回帰 / 因果候補抽出)
分類 (既知パターン / 未知異常)
改善案スクリプトの生成と検証（安全ガード付き）

という形に展開していくと考えます。
そこに備えて試行錯誤していくことが大切です。

プロンプトテクニックでよく見かける「推測しないで。分からないことは分からないと言って」などの指示が必要だったと感じました。