COLUMN

今回の流れ

今回は、以下の流れで進めたいと思います。

• MCP Server追加
• 現況システム調査
• アラーム状態にしたのち、原因と対処をAIにて実施

AWSを使った生成AIの活用に関するお問い合わせはこちら！

前提条件

今回事前に下記のような環境の準備を行いました。

• Javaベースのサンプルアプリケーションを東京リージョンのEC2上に構築
• CloudWatchは、CloudWatchエージェントを使って主に下記のメトリクスを送信
  • CPU
  • メモリ
  • ディスク
  • ネットワークインターフェース
• CloudWatch アラームはCPUUtilizationのみ設定（閾値50％）
• ログファイルは下記をCloudWatch Logsへ送信。
  • CloudWatchエージェントログ
  • Syslog
  • Kernelログ
  • Bootログ
  • アプリケーションログ
• CloudWatch Application Signalsはデフォルト設定で取得
• CloudWatch Syntheticsは設定しない
• EC2インスタンスは、Systems Managerで操作可能な状態にしておく

構築が終わったら、正常時のメトリクスをためておくため、2～3日ほど起動したままにしておきます。

MCP Server追加

次に、手元のPCのAmazon Q Developer CLIの設定を行います。Amazon Q Developer CLIの最新版へのアップデート、MCP Serverに必要なパッケージのアップデート、AWS CLIの最新化およびアクセスキー/シークレットアクセスキーの設定を行います。これらの設定手順は前回までの記事を参考にしてください。

次にMCP Serverの設定を行います。jsonファイルを修正し、下記2種類のいずれかに保存します。

• `C:\Users\${User}\.aws\amazonq`フォルダの場合、PCすべてに適用
• ワークスペースのルートにある.amazonq/ディレクトリの場合、対象のワークスペースにのみ適用

CloudWatch/CloudWatch Logs/CloudWatch Application Signalsの3つのMCP Serverのみを利用する場合は、下記のようになります。

{
  "mcpServers": {
    "awslabs.cloudwatch-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.cloudwatch-mcp-server@latest"
      ],
      "env": {
        "AWS_REGION": "ap-northeast-1",
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "autoApprove": [],
      "disabled": false,
      "timeout": 60,
      "transportType": "stdio"
    },
    "awslabs.cloudwatch-logs-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.cloudwatch-logs-mcp-server@latest"
      ],
      "env": {
        "AWS_REGION": "ap-northeast-1",
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "autoApprove": [],
      "disabled": false,
      "timeout": 60,
      "transportType": "stdio"
    },
    "awslabs.cloudwatch-appsignals-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.cloudwatch-appsignals-mcp-server@latest"
      ],
      "env": {
        "AWS_REGION": "ap-northeast-1",
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "autoApprove": [],
      "disabled": false,
      "timeout": 60,
      "transportType": "stdio"
    }
  }
} 

CloudWatch MCP Serverの公式ドキュメント(https://github.com/awslabs/mcp/tree/main/src/cloudwatch-mcp-server)を見ると、envセクションでAWS Profileを設定するようになっていますが、AWS CLIのデフォルトプロファイルを使用する場合は設定不要です。今回はAWS CLIのデフォルトプロファイルを使用するため設定しませんでした。

パッケージとコンフィグファイルの保存が終わったら、Amazon Q Developer CLIを起動します。

今回はWindowsのPCで実行しているため、WSL上でバージョン確認とAmazon Q Developer CLIの起動を行います。

バージョン確認

q --version

起動コマンド

q chat

MCPサーバーが初期化され起動すれば成功です。

このスクリーンショットを見るとCloudWatch/CloudWatch Logs/CloudWatch Application Signalsの各MCPサーバーが起動中の状態に見えますが、最初のプロンプトを打ち込んでいるうちに起動します。心配であれば最初にこのようなプロンプトを入れて確認することができます。

AWSを使った生成AIの活用に関するお問い合わせはこちら！

現況システム調査

それでは、現行のアプリケーションの運用状況の調査をお願いしてみましょう。

現況調査を行う場合のプロンプトの基本は、下記のとおりです。

• 必要なメトリクス・ログ・トレースはどのリージョンにあるかを明記
• サービス名やインスタンスIDなど、調査対象を明確化
• 調査期間（直近1時間、何年何月何日何時から何年何月何日何時まで、など）を明示

これらの調査のヒントになる情報がないと、狙った調査を行うことができません。

このような概要が示されています。

詳細のファイルにはレイテンシーやエラー率の統計、トレースからの主なオペレーション、推奨される対応事項が示されています。

今回、CloudWatch LogsのロググループがAmazon Q Developer側で確認できなかったので、調査対象となるCloudWatch Logsのロググループも指定する必要がありそうです。このあたりは、都度プロンプトで入力するのではなく、AI向けの保守ドキュメントを作成しておくことで、プロンプトを簡略化できるかもしれません。（システム概要や設定されているメトリクス・ログ・トレース情報などの事前情報）

アラーム状態にしたのち、原因と対処をAIにて実施

それでは、次に障害調査を行ってみましょう。

EC2にログインし下記のコマンドを実行し、5分程度待機してCPUUtilzationがアラーム状態になることを確認します。

CPUに負荷を与えるコマンド例

dd if=/dev/zero of=/dev/null bs=1000M count=100000

アラーム状態になったことを確認したら、次のプロンプトを入力し障害原因の調査を開始します。

これも、調査の対象サービスやログを指定することで効果的な調査を行うことができます。

ログからEC2内部に入り、アラームの原因となったコマンド実行の特定と、対象プロセスの終了による対処まで完了しています。

AWSを使った生成AIの活用に関するお問い合わせはこちら！

この結果からわかるAWS運用作業における現在地の考察

これまでの記事と同様に、一連の動作からAmazon Q Developerを用いた運用作業の現在地について考察してみたいと思います。あくまで現時点におけるデモ利用をもとにした考察のため、今後の基盤モデルの進歩や、ツール・コンテキスト・プロンプトの工夫などで大きく変わる可能性もあります。

事前準備

事前の準備については、通常の保守運用業務と同様に必要なメトリクス・ログ・トレースを取得し、調査対象となるリソースなどの基礎情報をまとめておくことが大切です。人手で行う場合も監視設定や保守ドキュメントを整えておくことは重要ですが、AIが運用作業を行う場合も同様となります。

保守作業を行うためのAmazon Q Developer CLIに必要な権限

Amazon Q Developer CLIに与える権限も、最小限とすべきです。必要以上に大きな権限を付与し、意図しない作業（リソースの追加や削除）については制限しておく必要があります。特に、Systems ManagerについてはEC2内部のリモートコマンド実行が可能となるため、権限を付与するかどうかは運用設計の際に検討すべき項目と考えます。

今回の調査や一次対応においては、次のような権限があるとよいかと思います。

CloudWatch権限

• cloudwatch:DescribeAlarms
• cloudwatch:DescribeAlarmHistory
• cloudwatch:GetMetricData
• cloudwatch:ListMetrics

CloudWatch Logs権限

• logs:DescribeLogGroups
• logs:DescribeQueryDefinitions
• logs:ListLogAnomalyDetectors
• logs:ListAnomalies
• logs:StartQuery
• logs:GetQueryResults
• logs:StopQuery

CloudWatch Application Signals 権限

• application-signals:ListServices
• application-signals:GetService
• application-signals:ListServiceLevelObjectives
• application-signals:GetServiceLevelObjective
• application-signals:BatchGetServiceLevelObjectiveBudgetReport
• xray:GetTraceSummaries
• xray:BatchGetTraces

EC2権限

• ec2:DescribeInstances
• ec2:StartInstanes
• ec2:StopInstances

Systems Manager権限

• ssm:SendCommand
• ssm:GetCommandInvocation
• ssm:DescribeInstanceInformation

対処の実行について

今回は、EC2内部の作業も自動で行うように設定しましたが、自律的な対処を行ってくれるようになる反面、意図しない作業や不注意による承認なども含めて対応方針を検討する必要があります。特に本番環境で実行する場合、コマンド実行による影響度も加味したうえでの承認が必要となるため、現実的には対処案の提示までにとどめ、実行は人手やツールで行うなどのルール付けが必要になります。

まとめ

今回はMCP Serverを活用してAWSの保守運用作業をより簡易にできないか試してみましたが、AWSだけにとどまらずEC2内部のOSやアプリケーションレイヤの調査まで踏み込むなど、実際の運用者に近いところまでの調査や対処を行っていたように思います。これからもこうした作業にAIを活用してより高い品質での業務ができればと思います。

NTT東日本では、AWSの構築保守だけではなく、ネットワーク設計なども含めたエンドツーエンドでのソリューション提供をおこなっております。

経験値豊かなメンバーがご担当させていただきますので、是非お気軽にお問い合わせください！

AWSを使った生成AIの活用に関するお問い合わせはこちら！