今年、経済産業省が謳っていた2025年の崖と言われていた年になりました。IT人財不足が至る所で言われています。効率化を進めて、より価値を生む分野に人財を投入しようという流れになっていますね。
私個人としては、ここ数年、クラウドネイティブの運用を学んでいく中で、オンプレミス・レガシーシステムの運用はつらいと改めて感じています。従来の運用を続けていくと担当してくれる人がいなくなってしまうのでは、と不安にもなります。
様々な場面で非効率な部分を改善する手段として生成AIの活用も進んでおり、昨今の生成AIのムーブメントにAIOpsという運用に関わるキーワードも混ざっていますね。
AIOpsの1つとして、運用の効率化に期待されるAmazon Q Developer Operational Investigations（運用調査）について取り組んでみましたので、備忘として残すと共に、これからの運用について考えてみました。
re:Invent2024でCEOのMatt氏から発表されました。
ドキュメントの冒頭に以下が書かれています。Amazon Q Developer の運用調査機能は、システム内のインシデントへの対応に役立つ生成 AI を活用したアシスタントです。生成 AI を使用してシステムのテレメトリをスキャンし、問題に関連する可能性のある提案をすばやく表示します。
テレメトリをスキャンして問題の原因特定に協力してくれるというものです。
現在、バージニアとオレゴンでプレビュー中となります。
それでは、設定方をみていきましょう。
利用可能な環境はus-east-1かus-west−2になりますので、ご注意ください。
私はus-east-1を使用しました。
Slack連携用のSNSトピックを作成しておきます。
すでに作成済みの方、Slackへの連携を行わない方は本項目を読み飛ばしていただいて大丈夫です。
Amazon SNSの画面で、SNSトピックを作成していきます。
スタンダードタイプで大丈夫です。
名前を設定して、他はデフォルトでトピックの作成をクリックします。
サブスクリプションの作成をクリックして、作成したトピック内にサブスクリプションを作成していきます。
プロトコルはHTTPS、エンドポイントはhttps://global.sns-api.chatbot.amazonaws.comとなります。その他はデフォルトのままサブスクリプションの作成をクリックします。
サブスクリプションができました。
続いてAmazon Q Developer in chat applicationsの設定です。
検索バーでAmazon Q Developer in chat applications（旧称：AWS Chatbot）を入力して開きます。
新しいクライアントを設定を選択します。
ポップアップ画面でSlackを選択し、設定をクリックします。
続いてSlackのサイトに遷移しますので、連携したいワークスペースを選択し、ワークスペースにアクセスする権限を許可します。
するとSlackワークスペースがAmazon Q Developer in chat applicationsに表示されます。
次に新しいチャネルを設定を選択して、チャネルを追加していきます。
設定名はお好きな名称を入力していただいて、Slackチャンネルはプライベートを選択し、SlackのチャンネルIDを入力します。
チャネルIDはSlackチャンネルの詳細ページで確認できます。
今回、アクセス許可はロール名を設定した以外に以下を設定しました。
ポリシーテンプレート：Amazon Qオペレーションアシスタントのアクセス許可 を追加
チャネルガードポリシー：AIOpsOperatorAccess を追加
通知の項目で先ほど作成したus-east-1のSNSトピックを選択します。設定をクリックして完了させます。
チャネル設定が完了しました。
設定済みチャネルの項目にあるテストメッセージを送信をクリックすると、Slackに通知が入り、Amazon Qが登場しました。
いよいよ、AI Operationsの設定を行っていきます。
Cloudwatchの画面にAIオペレーションがあります。
まずは設定を選択して始めていきます。
ステップ1では、保持期間の指定などができます（デフォルト値90日）が、そのまま次へをクリックします。
続いてステップ2でIAMロールの作成やX-Rayとの統合、Application Signalsとの連携もできるようになっています。今回はデフォルトのまま進めていきます。
最後にステップ3で、チケット発行システム統合（JiraとServiceNowが選べる）、チャット統合（Slack、Teams、chimeが選べる）が設定できるようになっています。
SNSトピックを選択をクリックして先ほど作成したトピックを選択します。セットアップを完了を選択して完了です。
とてもシンプルです。
Web3層構造をECSとAuroraの組み合わせで実現した形です。
フロントのALBの後ろにフロントエンドのコンテナタスク、内部ALBの後ろにバックエンドのコンテナタスク、さらにその後ろにAuroraがあるといった構成です。
Amazon CloudwatchメトリクスでAlarmを検知したことを契機にAmazon Q Developerを起動して自動で調査を開始するというものです。
調査開始の契機とするためのAlarmを作成します。
Cloudwatch Alarmの設定画面の最下段に「調査アクション – プレビュー」ができています。
「調査アクションの追加」をクリックすると、グループ選択の項目が出てきます。
ここで、DefaultInvestigationGroupを選択するのみです。
あとはこれまで通りのAlarm設定を行います。
それでは動作検証を始めていきます。
踏み台インスタンスからバックエンドのコンテナタスクに高負荷を掛けて、ユーザー側でリクエストに対するレスポンスを遅くしました。
ALB側のターンアラウンドタイムで閾値を超過したことを契機に、Cloudwatch Alarmが発報されました。
調査の画面に遷移するとAlarm発報を契機にすでに調査が始まっていました。
中身を見てみると以下の図のようなフィード欄（左側）と提案欄（右側）が表示されます。
右側の提案欄に表示された情報を「承諾」するか「破棄」するか、ボタン選択で決めていきます。
承諾した情報はフィード欄に表示される形となります。
面白かった点として、全く関係ないリソースも提案に含まれてきました。
（画像は私が以前作って、同一リージョンで消し忘れていたDynamoDBのリソースです）
さて、10分弱で最初の分析結果が表示されました。
以下、Google翻訳の結果です。
内部の Application Load Balancer で TargetResponseTime が大幅に増加し、5 秒のしきい値を超えてアラームがトリガーされました。これは、さまざまなレイテンシー メトリック (InsertLatency、CommitLatency、SelectLatency) の急上昇とスループット メトリック (WriteIOPS、StorageNetworkReceiveThroughput) の低下によって証明された、RDS クラスターのパフォーマンス低下が原因でした。RDS ログでの接続の中止と ConnectionAttempts の急上昇が示すように、この問題は接続の問題によって悪化した可能性があります。このデータベース パフォーマンスの問題はバックエンド サービスに影響を及ぼし、システム全体の応答時間の増加を引き起こしました。
中々、良い線をいっていますが、バックエンドのECSクラスタに関する言及はありませんでした。
さらに15分ほど経過した時点で追加の調査結果が表示されました。
アーキテクチャ図は提供していませんが、ECSのバックエンドサービスの高負荷について言及される形となりました。
以下、Google翻訳の結果です。
ECS バックエンド サービスでは、データベース接続プールの飽和によりパフォーマンスが低下しました。これは、トラフィックの急激な増加によって RDS インスタンスへの接続試行が急増したことが原因と考えられます。この問題は、データベース操作のレイテンシの増加として現れ、挿入、コミット、および選択のレイテンシがすべて急増しました。ECS タスクではメモリ使用率とネットワーク受信バイトが増加し、RDS インスタンスでは書き込み IOPS が低下し、アクティブなトランザクションが増加しました。これらのパフォーマンスの問題により、イングレスおよび内部アプリケーション ロード バランサーの両方でターゲット応答時間が大幅に増加し、内部 ALB は 5 秒のしきい値を超えるとアラームをトリガーしました。
ここまで最初のアラーム発生から30分弱です。
オンプレの場合、夜間に電話連絡をもらって、出社の準備をして家を出ようとする頃には調査結果が出てくることになります。すごいですよね。
Amazon Q Developer in chatbot経由でSlackとの連携ができます。
先ほど実施したSNSトピックを経由してAmazon Q Developerからマネコンと同じ提案がSlackに投稿されます。
SlackでAmazon Q Developerから投稿された内容をAcceptかDiscardで選択していくのみです。とても簡単です。
ドキュメントを確認したところ、運用調査機能はクロスリージョン推論であることが明記されていました。
東京でクロスリージョン推論となる場合は、シドニーやムンバイとセットになります。
エンタープライズで国内リージョンの縛りがある方は気になるところですね。今後の国内リージョンでのクロスリージョンに期待です。
プレビュー中のため、利用料金は不明です。
色々ログを読み取って、都度、推論が行われていると考えられますので、トークン量が少々心配です。
Amazon Q Developer for CLIのようにある一定までは無料というと始めやすいかなと感じています。
また、利用料課金となる場合でも、一般的なアラームは調査の対象外として、未知の障害、大規模障害に限定するなど使い所を考えれば課金も怖くないのではと考えています。
現時点で全て英語なのが、運用担当者としてはハードルが高くなりますね。
Amazon Q Developer が順次日本語対応し始めていますので、東京でGAされる頃には日本語対応されることを期待しています。
運用調査機能を扱ってみましたが、ログやメトリクスを読み取り、分析をして原因調査まで一連の運用担当者の作業を支援してくれます。使いこなせば、夜間の緊急経路対応の日も安心です。
また、今回、AWS内のリソースを対象に実施しましたが、オンプレのリソースもCloudwatch Agentを利用してログやメトリクスを取得して、AWS上で監視を実施すれば、ある程度活用ができるのではないかと考えました。たとえシステムがオンプレにあったとしても、監視でAWSを利用することで効率化できるはず。あらゆる効率化の手段、可能性は考えていきたいですよね。
オンプレ運用担当の方、諦めないでください。これから、まだまだ改善していく余地はあります。
Operational Investigationsについては、東京での早期GAを待ちたいと思います。
この内容がオンプレ運用担当で悩むどなたかの参考になれば、幸いです。
Be the first to comment
