Amazon Q Developer が統合された CloudWatch の運用調査機能を使ってみた
2024.12.09いわさです。
AWS re:Invent 2024 で Amazon Q Developer の運用調査機能というものがリリースされました。
ワークロードで問題が発生した際、様々な関連メトリクスを調査したり時系列の整理などを行って行って根本原因の特定を行う必要がありますが、Amazon Q Developer がそれらを支援してくれるというものです。
今回、簡単なワークロードで問題を発生させこちらの調査機能を試してみましたので使い方などを紹介します。
なお、プレビュー期間中は東京リージョンがサポートされていないので、バージニア北部リージョンで試しています。
設定
まず、調査グループというものを作成します。
このグループで Amazon Q Developer が使用する IAM ロールや、調査結果を何日保持するかなどの設定を行います。
追加のオプションで IAM Identity Center インスタンスを接続し、Amazon Q Developer Pro ユーザーの場合はパーソナライズされた提案を受けることが出来るようになるようです。
ドキュメント上の情報が不足している感が少しありますが、どうやら Q による提案を個々の Pro ユーザーへ行うために Identity Center の ID 伝播機能が構成されるようです。
その結果何がどう変わるのか、正直全然わからないので、これはまた別で検証したいと思います。
今回はこちらのオプションはオフでいきます。
IAM ロールの作成なども行っていきます。
今回は推奨でもあるロールの自動作成を選択します。AIOpsAssistantPolicyポリシーなどが自動でアタッチされるようです。
Amazon Q Developer の付与する権限を絞り込みたい時はカスタムロールを個別指定するのが良さそうです。
作成出来ました。
ただし、この時点では基本構成を行っただけで、まだ何も調査出来るものがありません。
調査の開始方法としてはワークロードの CloudWatch メトリクスや CloudWatch アラームが必要になります。
そのあたりをやっていきますか。
サンプルワークロードの用意
Q Developer の運用調査機能で調査出来る AWS サービスは以下です。
基本的な Web アプリケーションワークロードのコアなサービスはサポートされていそうです。
ELB の記載がないのですが、ELB + EC2 環境をデプロイし、ELB で 5xx エラーを発生させてみます。
次をデプロイして EC2 を停止させました。
こんな感じで 5xx 系のサーバーエラーが発生するようになりました。
% curl http://hoge-web-alb-96108201.us-east-1.elb.amazonaws.com/
hoge
% curl http://hoge-web-alb-96108201.us-east-1.elb.amazonaws.com/
<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>
調査を行う
調査を開始するにはいくつか方法があります。
メトリクス画面に次の「Investigate」ボタンが追加されているので、メトリクスを選択してそちらから手動開始することも出来ます。
あるいは CloudWatch アラームのアクションとして「調査アクション」というものが追加されており、こちらを使うとアラームがトリガーされたときに自動で調査が作成されます。
手動あるいは自動で調査を作成すると、AI オペレーションメニューの調査一覧に表示されます。
Investigation state は調査ステータスで、Open になっているものは Amazon Q Developer が調査し続けている状態となります。プレビュー時点では本機能の料金は発生しないように見受けられましたが、GA 時には無駄に Open 状態のものが存在していないか気をつけたほうが良いかもしれません。
調査を開いてみると、時系列で調査された内容が Feed 一覧に並んでいます。
上部の Suggestions ボタンを押すと右側に Amazon Q の提案がリストアップされます。
この「提案」が何かというと、Amazon Q Developer が自動で、関連しそうなメトリクス、CloudWatch Trail イベント、X-Ray トレース情報など様々な情報を収集してくれます。
それらの提案をユーザーが関連しそうか、しなさそうかを判断することで、簡単に問題に対する関連メトリクスを集めて調査内容をまとめることが出来るというものになってます。
あとは Q Developer の提案以外に手動でユーザーが個別のメトリクスを追加することも出来ますし、あるいはメモの追加も可能です。
提案された調査を追加してみる
少し待つといくつか提案項目が表示されたのでそれらを Accept してみます。
ここでは 5xx エラーカウントをターゲットにした調査だったのですが、まず「この RequestCount メトリクスが同じ時間に増えてるけど、どう？」ということで Q Developer が提案してくれています。
さらに、その延長で「一時的にスパイク発生してたんじゃない？」という仮説を伝えてくれています。
このように Q Developer が Observation（観察）と Hypothesis（仮説）の提案をいくつか行ってくれるので、これをヒントに迅速なトラブルシューティングが出来ますよという感じでしょうか。
提案項目をひとつづつ Accept することで Feed に追加されていきます。Discard すると追加されません。
今回は仮説が提案されたのみでしたが、推奨アクションが表示される場合があります。
推奨されるアクションはいくつかあるようで、ドキュメント表示あるいは Systems Manager の Automation Runbook を使った修復アクションの実行などが行えるようです。
調査の終了
一通り問題が解決したら、調査を終了させることが出来ます。
調査が終了すると、ステータスがアーカイブとなり、コンテンツの編集や追加ができなくなります。
また、これ以上の提案も生成されなくなります。
なお、必要に応じてアーカイブされた調査を再開することも出来ます。
さいごに
本日は Amazon Q Developer を使った CloudWatch の運用調査機能を使ってみました。
今回は非常にシンプルな ALB のエラーメトリクスのみで試してみましたが、分散アプリケーションだったりより複雑な構成だとこの機能の恩恵はかなり高くなりそうです。
本機能がサポートしている調査・提案内容は以下に記載されていまして、X-Ray や Application Signals などはもちろんのこと、AWS Health イベントもサポートされているようです。
何か問題があって CloudWatch ダッシュボードを見に行き、調査を開始した時に Q Developer が「AWS Health 側で基盤の問題が起きていたみたいだよ」とか「アプリケーションで大量に例外が発生していたよ」みたいなのをすぐに提案してくれるのは、確かに迅速な問題解決が出来そうですごく良さそうです。
なお、本機能に関連したレポートが上がっていました。こちらも是非見てみてください。
![[レポート] AWS の取り組みと生成 AI の最新機能がもたらす開発者体験について学ぶ「Reimagining the developer experience at AWS」 #DOP220](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
