Amazon Q Developerを使って障害調査を高速化！
この記事はJAWS-UG（AWS Users Group – Japan） Advent Calendar 2024の17日目の記事です。
はじめに
12/1-12/6に行われたre:Invent2024にて、とあるアップデートが発表されました。
それが、こちらのAmazon Q Developerが運用調査機能を追加(プレビュー)というものです。
このタイトルだけではあまりイメージが付きにくいかと思いますが、実は結構面白くてインパクトのある内容です。なので簡単に現時点(2024/12/15 プレビュー段階)での機能をご紹介したいと思います。
今後のAWS運用が大きく変わるかもしれません。
Amazon Q Developerとは
ここでは説明不要かもしれませんが、簡単に。
re:Invent2023でプレビュー発表された、AWSによる生成AIアシスタント機能の総称です。今年のre:InvnetではこのAmazon Q Developerに関するアップデートが、CEO Keynoteでも多数発表されていました。
以下は一例です。
- Unit Test作成
- ドキュメント作成
- コードレビュー
など多数の、開発者アシスタントとしての機能が発表されています。
これらの機能については他の方も多数記事にしていただいているので、そちらを参照いただくのが良いかと思います。
そんな中、AWSでのOperationに関わるセッション(Building the Future of cloud operations at any scale(COP202))で紹介されていたのが、今回ご紹介するAmazon Q Developer adds operational investigation capabilityです。
このセッションはYoutubeにも公開されているので、こちらも見ていただきつつ、このセッションサマリーはAWSさんからブログとしても発表されています(日本語訳もしてくださっています。)。
どんなもの？
一言でいうと、AWS上での障害調査を、AIが関連情報を提案しながら、よりスピーディに解決まで伴走してくれる機能です。
これまでAWS上で障害が発生した場合、CloudWatch Alarmがトリガーされユーザーに通知が来ます。そこからアラームの元となったメトリクスやログを追い、必要に応じてサーバーへのログインやECSサービスの切り戻しなどを行っていたと思います。
今回のアップデートでは、Alarmがトリガーされた時に自動で関連するメトリクスやログを提示するだけでなく、テレメトリやデプロイメント、AWS Healthイベントなどを含めAWS全体のデータを元に、障害の根本原因を解決するために必要なデータを提示してくれるという素晴らしい機能が発表されました。
さらにこれに付随して、障害調査の記録をマネジメントコンソール上で残すことができます。Amazon Qが提示した情報が正しければ、それを障害調査記録としてワンクリックで調査記録として保存できます。
現状はバージニア北部リージョン(us-east-1)でのみ、プレビュー利用が可能です。また、ワークロードがなくても、サンプルとして調査アシスタントの機能を実行することが可能です。
触ってみる
今回は簡単に触ってみた点をまとめていこうと思います。
サンプル操作
まずはサンプルの調査対応を見てみます。
バージニア北部にてCloudWatchのサービスページに遷移します。AIオペレーション機能が追加されているのが分かります。
この右側のTry a sample investigationを選択するとサンプル調査シナリオを体験することができます。以下サンプルです。
右側のパネルがQ Developerの提示した障害に関係のあるメトリクスや操作記録になっています。
ここから分かるのは一定期間DynamoDBのスロットリングが起きていて、その原因として提示されているのが、Observation for AWS DynamoDB DeploymentでDynamoDBに対して変更が行われた記録です。これが根本原因として正しければ、右側のパネルのAcceptをクリックすると左側の記録にFeedとして追加されます。
有効化
実際にアカウントで機能を利用するためには、アカウントで機能を有効化する必要があります。
Configure for this accountから設定していきます。
ロググループの設定やログの保持期間、ユーザーのアクセス権限を設定します。が、今回はデフォルトで進めます。
Amazon Q DeveloperへのIAM権限や、管理するアプリケーションのタグ選択、CloudTrailイベントを統合するか、X-Rayを利用した全体マッピング、AWS Healthとの統合を設定します。
チケットシステムとの統合も可能です。現状はJiraとServiceNowが選択可能です。
また、SNSと統合することでChatbotを利用して通知から調査の連携が可能になっています。
これでアカウントで利用するまでの設定は完了です。
検証
今回検証用に利用するのはOpsJAWSでApplication Signalsハンズオンを実施した際のリポジトリです。
任意のメトリクスがアラート状態になるようなCloudWatchアラームを作成します。
アラームアクションに調査アクションという項目があるので、ここに作成した調査グループを設定します。
アラーム状態になるとInvestigationsにOpen状態のものが作成されます。
開いてみると、現状はまだ何もSuggestされていません。
Amazon Q logsを開いてみると、このアラームが設定されてからQがどのような調査をしたかを確認することができます。
各サービスに対して関連するメトリクスを調査している様子が分かります。
QからのSuggestが全然来ないので、若干今回の例は悪かったかもしれません。
メトリクス側からInvestigatonに追加することも可能です。
X-Rayの画面からメトリクスを選択し、既存の調査に追加を選択するとInvestigation側にFeedが追加されています。他にもCloudWatchアラームからも既存の調査に追加するためのプルダウンが存在するので、こちらからもFeedに追加していくことができます。
また、Add noteからコメントを追加することもできるので、障害調査の記録を全て時系列順にまとめていくことができます。
こうすることで、これまでチームごとに障害調査の記録を残す方法がSlackやナレッジツールに散らばることがなく、かつ、メトリクス情報も簡単に残しながらAWSで完結することができます。
これによってナレッジツールとしてAWSを活用するような利用方法も考えられます。
通知情報
Slackに通知設定を入れていましたので、Slackの方でも確認ができます。
さらに、Slack側からもNoteを追加することもできますが、ここはChatbotに書き込み権限が必要になるので必要に応じて権限を設定してください。ChatOpsに近い体制が取れるので設定してみてください。
最後に
今回のアプリケーション例は良くなかったですが、AWS内で全ての障害調査を記録を残しながら完結するという部分はお伝えできたかと思います。
今後は別のアプリケーションでQからSuggestしてもらえるような検証をしてみたいです。
ナレッジ管理に困っている方や、AWS以外のプラットフォームが使いにくい環境な方には非常に有益なアップデートになっているかと思いますし、スキルトランスファーが難しい障害対応に対して、Qがサポートしてくれるこのアップデートは激アツだと個人的には感じています。
ぜひ東京リージョンでのサポートとGAを待ちたいと思います。
Discussion