運用イベント対応への生成AIの活用 with Failure Analysis Assistant

© 2024, Amazon Web Services, Inc. or its affiliates. All
rights reserved. Yozo Suzuki アマゾンウェブサービスジャパン合同会社パブリックセクター技術統括本部ソリューションアーキテクト運⽤イベント対応への⽣成AIの活⽤ with Failure Analysis Assistant AW S 秋の O B S E R VA B I L I T Y 祭り ~ 明⽇使えるアセット祭り ~ 1

rights reserved. ⾃⼰紹介鈴⽊陽三アマゾンウェブサービスジャパンソリューションアーキテクト公共領域のお客様へプロトタイプを提供し、クラウドの利活⽤をご⽀援

rights reserved. Failure Analysis Assistant (FA2) 概要開発背景デモまとめアジェンダ

rights reserved. • 障害発⽣時のテレメトリデータを LLM が分析するサンプル実装 § これまで時間がかかっていた、ログの障害分析を LLM で⽀援するアプローチ Failure Analysis Assistant (FA2) Blog: https://aws.amazon.com/jp/blogs/news/failure-analysis-assistant-aiops/ Github: https://github.com/aws-samples/failure-analysis-assistant/ 提供範囲

rights reserved. 開発背景 5

rights reserved. 障害対応の難しさ初学者育成の難しさそもそも学習機会が少なく、初学者を教育しづらいいつも経験者が対応してしまうノウハウ共有の難しさ障害分析の流れや勘所の⾔語化がされておらず、いつも同じ⼈が担当情報連携の難しさ⼀⼈でシステムは運⽤できない他チームとの協⼒が必要で、コミュニケーションコストがかかる

rights reserved. 障害分析のフローと課題イベント内容から、ログ取得の時間範囲を検討ログやメトリクスなどを収集収集した情報の依存関係を整理障害原因の推測・検証ログの場所がわからない他チームへ取得依頼ログの読み⽅がわからないそもそも何から⼿をつける︖ 原因の仮説が⽴てられない

rights reserved. 障害分析のフローと課題イベント内容から、ログ取得の時間範囲を検討ログやメトリクスなどを収集収集した情報の依存関係を整理障害原因の推測・検証ログの場所がわからない他チームへ取得依頼ログの読み⽅がわからないそもそも何から⼿をつける︖ 原因の仮説が⽴てられない収集から原因仮説の構築は機械的に実施エラー概要と時間範囲を⼊⼒するだけ

rights reserved. デモ

rights reserved. • アプリログはCloudWatchに出⼒ • ALBのアクセスログをS3に出⼒ • CloudTrailを設定し、S3に出⼒ • X-Rayは設定済み § サンプリングはデモ⽤に100% • メトリクスはALB, ECS, Fargate, DynamoDBから取得対象システム最低限、CloudWatch Logs にログが出⼒されていれば始められます︕

rights reserved. Amazon CloudWatch (Metrics) Amazon CloudWatch (Logs, Metrics) AWS X-Ray 対象システム収集収集収集運⽤者 Amazon Simple Notification Service (Amazon SNS) AWS Chatbot ①障害通知 ②障害分析 ③収集収集 Amazon Simple Storage Service (Logs) Amazon Athena 障害原因の仮説候補を提案する Amazon Bedrock ④要約 AWS Lambda AWS FIS を利⽤し、対象システムのVPCから DynamoDBへのコネクション障害を起こす結果、外形監視のメトリクスに設定されたアラームが通知される

rights reserved. Amazon CloudWatch (Metrics) Amazon CloudWatch (Logs, Metrics) AWS X-Ray 対象システム収集収集収集運⽤者 Amazon Simple Notification Service (Amazon SNS) AWS Chatbot ①障害通知 ②障害分析 ③収集収集 Amazon Simple Storage Service (Logs) Amazon Athena 障害原因の仮説候補を提案する Amazon Bedrock ④要約 AWS Lambda エラーの発⽣している時刻を元に、ログなどを取得する時間範囲を確認し、エラーの概要とともに、 AWS Lambda へのリクエストに含める

rights reserved. 障害原因の仮説候補を提案する 13 アラームの内容を端的に⼊⼒発⽣時間も⼊れるとベターログ取得の時間範囲を⼊⼒発⽣時間から逆算する

rights reserved. Amazon CloudWatch (Metrics) Amazon CloudWatch (Logs, Metrics) AWS X-Ray 対象システム収集収集収集運⽤者 Amazon Simple Notification Service (Amazon SNS) AWS Chatbot ①障害通知 ②障害分析 ③収集収集 Amazon Simple Storage Service (Logs) Amazon Athena 障害原因の仮説候補を提案する Amazon Bedrock ④要約 AWS Lambda 情報収集結果例 Amazon CloudWatch Logsのログ抜粋

rights reserved. Amazon CloudWatch (Metrics) Amazon CloudWatch (Logs, Metrics) AWS X-Ray 対象システム収集収集収集運⽤者 Amazon Simple Notification Service (Amazon SNS) AWS Chatbot ①障害通知 ②障害分析 ③収集収集 Amazon Simple Storage Service (Logs) Amazon Athena 障害原因の仮説候補を提案する Amazon Bedrock ④要約 AWS Lambda プロンプト例 ``` AWS上で稼働するワークロードを監視・運⽤するエージェントです。必ず⽇本語で回答してください。あなたが担当するワークロードは、CloudFront、ALB、ECS on EC2、 DynamoDBで構成されており、ECS on EC2上にSpringアプリケーションがデプロイされています。現在、運⽤管理者から ${errorDescription} という事象が発⽣したとの連絡がありました。あなたは、<logs>タグに与えられたログと<metrics>タグに与えられたメトリクス、<traces>タグに与えられたトレースを確認し、発⽣した事象の根本原因を推測してください。根本原因を記述する際に、参考にしたログやメトリクスの内容についても記載し、運⽤管理者が実際のログやメトリクスを確認しやすくしてください。 <logs> <ApplicationLogs>${取得したアプリケーションログ}ApplicationLogs> <ALBAccessLogs>${取得したALBのログ}</ALBAccessLogs> <CloudTrailLogs>${取得したCloudTrailのログ}</CloudTrailLogs> </logs> <metrics>${取得したメトリクス}</metrics> <XrayTraces>${取得したトレース情報}</XrayTraces> 発⽣した事象の根本原因 : ```

rights reserved. FA2によるエラー原因の仮説: 与えられたログ、メトリクス、トレースから、根本原因を以下のように推測します。 - ECSタスクに実装されたSpringアプリケーションがDynamoDBにアクセスする際、DynamoDBエンドポイントへの接続がタイムアウトしていることが原因と考えられます。 - アプリケーションログでは、下記のようなエラーメッセージが出⼒されています。 Request processing failed; nested exception is com.amazonaws.SdkClientException: Unable to execute HTTP request: Connect to dynamodb.us-east-1.amazonaws.com:443 [dynamodb.us-east-1.amazonaws.com/...] failed: connect timed out - トレースログからも、DynamoDBへのリクエストで接続タイムアウトが発⽣していることが分かります。 FaultRootCauses: [ { Services: [ { Exceptions: [ Unable to execute HTTP request: Connect to dynamodb.us-east-1.amazonaws.com:443 [...] failed: connect timed out" ], Name: "DynamoDB" } ] } ] - 特定のIPアドレス(52.119.224.212、3.218.182.157など)に対して接続がタイムアウトしていることから、DynamoDBクラスターのパーティションの⼀部でネットワーク問題が発⽣している可能性があります。 - ALBのメトリクスを⾒ると、この時間帯でTargetResponseTimeが若⼲上昇しているため、アプリケーションの応答時間に影響を与えている可能性もあります。アプリケーションログやトレースから、DynamoDBへの接続がタイムアウトしていることが事象の根本原因と推測されます。対処としてはAWSサポートに問い合わせ、DynamoDBのネットワーク状況を確認する必要があるでしょう。 LLMの回答

rights reserved. ただし、回答をそのまま信頼できるわけではない • ⽣成 AI のハルシネーションにより、誤った内容を含む可能性がある • もし、誤った内容を受け⼊れてしまうと、重⼤なミスになりかねない • 回答はあくまで参考情報として、⾃分で確認することが求められる例えば、 LLM の回答抜粋︓ 「X-Rayのトレースが空であることから、アプリケーション内でエラーが発⽣している可能性があります。」そもそもアプリケーションに到達していない場合でもトレースは出⼒されない。トレース設定不備の可能性もあり、アプリケーション内のエラーだけがエラー原因の候補ではない

rights reserved. • 傾向分析/パフォーマンス分析⽀援 • テレメトリデータから傾向分析やパフォーマンスチューニングの⽀援を⾏う • Findings レポート作成 • Security Hub と GuardDuty の Findings を LLM による解説つきのレポートにする 18 FA2 の障害分析以外の機能 v1.1.0 v1.1.0 今後も要望⾼そうな機能を追加していけたらと思いますので、ぜひフィードバックお願いします︕

rights reserved. コスト試算（障害分析⽀援）⾒積もり前提 • イベントは1⽇ 10 回発⽣するものとし、イベント発⽣時には、必ず FA2 を実⾏する • 1ヶ⽉は 30⽇とする • CloudWatch Logs に対し1回あたりスキャンするログデータは、1 GB とする • Athena がクエリごとに参照するログデータは、それぞれ 50 GB とする • CloudWatch のメトリクスは、1リクエストあたり、10メトリクス取得されるとする • トークン数は次に⽰す表の値と仮定する（ここは取得されるログの量に依存する） • ログ（CW、Trail、S3）やメトリクス（CW）、トレース（X -Ray）の記録にかかる料⾦、通知にかかる料⾦など、既存ワークロードで発⽣済みの料⾦は含めない 19

rights reserved. コスト試算（障害分析⽀援）サービス名⽉額コスト⽤途 AWS Lambda 1.50 USD ログ収集と bedrock の実⾏⽤ AWS Lambda 0.00 USD Slack App のバックエンド⽤ Amazon API Gateway 0.00 USD Slack App のバックエンド⽤ Amazon CloudWatch 2.31 USD ログとメトリクスの取得 Amazon Athena 148.44 USD ログの取得 AWS X-Ray 0.52 USD Trace の取得 Amazon Bedrock 132.1 USD メトリクス選定、障害の原因仮説、アーキテクチャ図の⽣成の3つの推論合計 284.87 USD 1回あたり、約0.95USD。150円/$換算で、約142円/回。 20 項⽬ In Out メトリクス選定（Tokens） 1,500 50 障害の原因仮説（Tokens） 90,000 1,000 アーキテクチャ図の⽣成（Tokens） 40,000 2,000 ⽉間リクエスト数（Tokens） 300 300 ⽉の総トークン数（Tokens） 39,450,000 915,000 Claudeの単価（USD） 0.003 0.015 ⾦額（USD） 118.4 13.7 bedrockの詳細

rights reserved. • ⽣成 AI を活⽤することで、障害分析を効率化できる”可能性”がある • ログなどの整理や、原因調査の⼿掛かり探しには、役⽴つ可能性がある • ⽣成 AI はハルシネーションを起こすため、裏どりは必要になる • 現状では補助的に利⽤していくのが望ましい • 補助的に使う分には、さまざまな⽤途で LLM を利⽤できるまとめお⾒せできなかった機能のデモが⾒たい⽅、開発時の⼯夫やカスタマイズについてのQAは、デモブースでお伺いいたします︕

rights reserved. Thank you!

rights reserved. 後半｜各ソリューションのデモ体験 23

rights reserved. How To Deploy ３つの機能実装のポイント後半

rights reserved. How To Deploy 25

rights reserved. How To Deploy 26 Slack Appの作成 • Slack App の作成 • Signing Secret / Oauth Token の発⾏・登録 FA2のデプロイ • パラメータ設定 • プロンプトの確認・調整 • CDK デプロイ Slack Appの設定 • Interactivity の設定 • Event Subscription の設定 • OAuth Permissions の設定 • App のチャンネル参加 • Slash Command の設定* ＊オプション機能のため、説明は省きます

rights reserved. Slack App の作成 Slack App の管理画⾯から、[Create New App]をクリックし、必要情報を⼊⼒する 27

rights reserved. • Slack App を作成すると表⽰される Basic Information から、Singing Secret を確認する • READMEのコマンドを⽤いて、 Secrets Managerに登録する 28 Slack App の作成

rights reserved. 1. [OAuth & Permissions] の画⾯を開く 2. [Scopes] で次のScopeを追加する § channels:read § chat:write § files:write 3. [OAuth Tokens] の [Install to {workspace名}] がクリックできるようになるので、クリックし、アプリをインストールする Slack App の作成

rights reserved. Slack App の作成インストールが終わると、[OAuth Tokens] に Tokenが表⽰されるので、 README のコマンドを⽤いて、Secrets Manager に登録する 30

rights reserved. FA2 のデプロイ 31 必要に応じて設定するパラメータ ※なくても利⽤できますご⾃⾝の環境に合わせ、変える必要があるパラメータ envはなくてもOK それ以外もデフォルトでよければ、変更の必要はありません

rights reserved. FA2 のデプロイ 32 必要に応じて変更くださいデフォルトでよければ、変更不要です

rights reserved. FA2 のデプロイ通常の CDK アプリと同様にデプロイ⼀点違うのは、Layer 向けのスクリプトが追加されている点 33

rights reserved. Slack App の設定 Interactivity を On に変更し、 API Gateway のエンドポイントを Request URL に設定する 34 URLの末尾に、/slack/events を忘れないでください

rights reserved. • [Enable Events] を On に設定し、 [Request URL] に先ほどと同じ URLを設定します § Verified にならない場合は、 API Gateway や Lambda、 Secrets Manager の設定を確認してください • [Subscribe to bot events] に [message.channels] を追加します 35 Slack App の設定

rights reserved. Slack App の設定 Event Subscriptions を有効にすると、ページ上部に次のような通知が来るので、 [reinstall your app] をクリックし、アプリを再インストールしてください 36

rights reserved. • Slack の AWS Chatbot が導⼊されているチャンネルに、FA2 を追加します § 稀に、[Add apps] をクリックし、FA2 を探しても、⾒つからない場合があります。アプリを登録した直後だと起きやすい感覚です。少し時間をおいて試すと⾒つかるようになります 37 Slack App の設定

rights reserved. FA2 は現在3つの機能を提供 38 障害分析⽀援アラームの内容、ログの取得期間から、アラームに対する原因仮説を構築する機能メトリクス分析⽀援メトリクスに関する質問に、⾃律的にメトリクスを選択し、回答する機能 Findings レポート Security Hub と GuardDuty の Fidningsを解説するレポートを作成する機能オプションオプション

rights reserved. メトリクス分析⽀援 39 アカウントのメトリクス⼀覧を API で取得質問の回答に必要なメトリクスを抽出、クエリを⽣成回答に必要なメトリクスデータを取得メトリクスデータを元に、⽣成 AI が質問へ回答 LLMでクエリを⽣成

rights reserved. Findings レポート 40 Security Hub のフィルタ条件 GuardDuty のフィルタ条件⽣成 AI がFindings の内容をサマリ＆解説

rights reserved. 実装のポイント 41

rights reserved. 動的なメトリクスの選定 Athena フォーマットから CSV への変換 Slack App を CDK で Lambda へデプロイする実装のポイント 42

rights reserved. 動的なメトリクスの選定 43 アカウント内のメトリクスを全て取得ユーザからの質問をもとに、必要なメトリクスを LLMに選択させ、GetMetricsDataのクエリを⽣成⽣成したクエリを⽤いて、GetMetricData APIを実⾏クエリフォーマットを指定すると、 LLM がうまく⽣成しやすくなりました（SQL などの⽣成も得意なので、その応⽤となります）アクティブなメトリクスだけを選ぶため、 RecentlyActive パラメータに、 PT3Hを指定する

rights reserved. Athena フォーマットから CSV への変換 44 GetQueryResults APIのレスポンスフォーマット冗⻑な形式なので、トークンを浪費してしまう変換 ALBのログをCSV形式に変換したもの

rights reserved. • Slack App の Framework である、 Bolt.js を利⽤するためには、 SigningSecretとTokenが必要 • これらクレデンシャルを、セキュアに扱うために、top level await を利⽤し Secrets Manager からの取得が必要 • top level await はECMAScript モジュールでのみ利⽤できる • CDK で ESM を bundling させるために、 powertools-lambda-typescript の ESM Support? を参考にした 45 Slack App を CDK で Lambda へデプロイする https://docs.powertools.aws.dev/lambda/typescript/2.0.2/upgrade/#esm-support

rights reserved. デモ 46

rights reserved. Thank you! 47

運用イベント対応への生成AIの活用 with Failure Analysis Assistant

運用イベント対応への生成AIの活用 with Failure Analysis Assistant

Other Decks in Technology

Featured

Transcript