Failure Analysis Assistant – AIOps で障害分析を効率化してみよう –

システムやサービスを提供する上で、障害はつきものです。障害を迅速に分析し対処することがユーザビリティやサービス信頼性を向上し、結果顧客満足度につながります。一方で近年システムは複雑さを増しており、障害特定が従来に比べて難しくなっています。したがって障害分析の効率化や高度化が重要になっています。
従来の手動による障害分析では、膨大なログデータの中から問題の根本原因を特定するのに多大な時間と労力を要し、ダウンタイムの長期化やサービス品質の低下につながる可能性がありました。そこで注目されているのが、人工知能 (AI) や機械学習 (ML) を活用した障害分析です。 AI/ML による高度な分析技術を用いることで、障害の早期発見、迅速な原因特定、さらには予防的な対策まで可能になりつつあります。
本記事では、汎用的に利用できる大規模言語モデル (Large Language Models 、以下 LLM) を活用した障害分析の高度化についてご紹介します。障害分析の課題から LLM で障害を分析するメリット、 AWS サービスを利用した障害分析サポートソリューションの紹介、そして導入に向けた課題と対策について詳しく解説します。障害分析にまだ慣れていない方から、障害分析プロセスの効率化を検討しているアーキテクトや SRE(Site Reliability Engineer) の方々まで、幅広い読者を対象としています。

従来の障害分析の課題

従来の障害分析では、以下のような課題がありました。

膨大なログデータの処理に時間がかかる
複雑な障害パターンの把握が困難
人的リソースへの依存度が高い
分析結果の再現性や一貫性の確保が難しい

これらの課題により、障害対応の遅延や見落としが発生し、結果としてサービスの信頼性低下につながる可能性があります。

LLM を活用した障害分析

LLM による障害分析の概要

ここでいう LLM を活用した障害分析とは、ログやトレース、メトリクスなどシステムから取得できるテレメトリデータを LLM に渡すことで、LLM がテレメトリデータを元に分析を行い、分析結果を自然言語でユーザーにフィードバックすることを指します。これにより、複数のテレメトリデータを元にシステムがどういった状態になっているのか、いつ、なにが、どうして起こったのかを、自然言語で理解することができるようになります。

LLM による障害分析の特徴

LLM を活用した障害分析では、以下のような特徴を持ちます。

大量のデータを高速に処理
パターン認識による異常の検出
人間には気づきにくい微細な変化の検出

これらの特徴により、従来の手法では困難だった高度な障害分析を行うことができます。

LLM を活用した障害分析のメリット

LLM を障害分析に導入することで、以下のようなメリットが期待できます。

1. 障害特定の迅速化

LLM を利用することで、膨大なログデータやメトリクスを短時間で解釈し、状態や事象の因果関係、障害の有無について分析し、自然言語で表現することができます。これにより、人間による分析では見逃しがちな微細な変化や、複雑な相関関係を素早く分析することができます。
例えば、ネットワークトラフィック、CPU使用率、メモリ消費量など、複数の指標を同時に監視し、それらの相関関係から異常を検出し、原因を特定することができます。

2. 属人化からの脱却

従来の障害分析では、ノウハウが暗黙知になったり、学習機会が少なく初心者の立ち上げが難しいなど、分析の効率や速度が属人化している状況にありました。 LLM を利用して膨大なデータを瞬時に分析し、自然言語で要約することができるため、これまで障害分析の経験がない初心者でも短時間で分析が可能となります。

3. 様々なシステムで利用できる

過去の障害に関するデータを元にモデルを作成することで、そのシステムに適した障害分析の高度化を実現することができますが、多くの時間と労力を要します。一方で LLM を利用した障害分析であれば、必要なものはテレメトリデータと一般的な LLM のみで分析することができます。したがって様々なシステムやサービスで今すぐ活用することが可能です。

AWSサービスを活用した LLM による障害分析ソリューション

ここからは AWS を利用し LLM によって障害分析を行う方法を紹介します。

概要

AWS では LLM を利用するためのサービスが複数ありますが、今回は Amazon Bedrockを利用します。大枠の流れとしては、まずチャットから AWS Lambda を起動します。このLambdaの中で、下図③のテレメトリデータ（ログ、トレース）の収集、下図④の収集したテレメトリデータをプロンプトに埋め込み Amazon Bedrock を利用して要約、の順で処理を行います。ユーザーにはチャット上で障害の概要や各テレメトリデータを読み取った結果、それらを踏まえ障害の根本原因として考えられる事象を確認することができるものとなっています。また利用しているサービスは全てサーバレスで提供されるものを利用しており、サーバの管理、運用は必要ありません。

利用サービス

Amazon Bedrock

サーバーレスな API サービスで基盤モデルを使用し、生成 AI アプリケーションを構築することができます。サービスの詳細についてはこちらをご確認ください。
今回は収集したテレメトリデータを要約し、自然言語で障害発生時の事象や障害の根本原因について要約する際に利用します。

AWS Lambda

サーバーをプロビジョニングまたは管理することなくアプリケーションを構築するために使用できるコンピューティングサービスです。サービスの詳細についてはこちらをご確認ください。
今回はチャットアプリケーションによって起動され、ログを Amazon CloudWatch Logs 、 Amazon Simple Storage Service (Amazon S3) 、トレースを AWS X-Ray から取得し、それらを Amazon Bedrock を利用して要約する一連の流れを実行します。

構築手順

ソースコードは、Failure Analysis Assistant (FA2) にあるので、ご利用ください。
またこちらは、 AWS Summit Japan 2024 のブースで展示されていた、「AIOps で障害分析を効率化してみよう」のソースコードとなります。Summit 期間中気になっていた方は、ぜひこちらのサンプルをお試しください。

1. パラメータ設定

parameter.sample.ts をコピーし、parameter.ts を作成、利用したい環境に合わせ、値を変更します。
CloudWatch のロググループは利用に必須です。しかし、S3 に保存される ALB のアクセスログや CloudTrail のログ、X-Ray のトレースは任意の設定項目となります。

// 例: Slack App 版で、Claude 3 Sonnet を利用し、CloudWatch Logs、Athena、X-Ray、を検索対象とした場合の設定
export const devParameter: AppParameter = {
env: {
    account: "123456789012",
    region: "us-east-1",
},
language: "ja",
envName: "Development",
clientType: "SLACKAPP",
modelId: "anthropic.claude-3-sonnet-20240229-v1:0",
cwLogsLogGroups: [
    "ApiLogGroup", "/aws/ecs/containerinsights/EcsAppCluster/performance"
],
cwLogsInsightQuery: "fields @message | limit 100",
databaseName: "athenadatacatalog",
albAccessLogTableName: "alb_access_logs",
cloudTrailLogTableName: "cloud_trail_logs",
xrayTrace: true,
};

2. CDKデプロイ

通常の CDK のデプロイと同じようにデプロイします。

$ npm install
$ npx cdk bootstrap --profile {your_profile}
$ npx cdk deploy --all --profile {your_profile} --require-approval never

3. Slack App の設定

FA2 の Slack App を設定します。細かくはGithubのREADME.mdを参照いただければと思いますが、行うことは以下のようなタスクです。

Slack App を利用したいワークスペースへ登録
API Gateway のエンドポイントを Slack App のエンドポイントとして設定
Slack App の Token と Signing Secret をコピーし、parameter.ts を更新
Slack 上で動作させるために必要な権限を付与

利用手順

アラート受信後に表示される FA2 のフォームに、[アラートの概要]、[ログの取得開始日時]、[ログの取得終了日時]を入力し、ボタンをクリックします
リクエストが受け付けられると表示が変わるので、少し待ちます
テレメトリデータ（ログ、トレース）の収集とLLMによる推論を終えると、回答が表示されます

構築および LLM を利用した障害分析を始めるにあたっての Tips

1. ログの設計が重要

ログ設計が正しく行われていないと、LLM も理解することができません。適切なログ設計が解析のポイントとなります。
例：誤ったログレベルで出力している、適切なログメッセージになっていない、フォーマットが統制されていない、分析に必要な情報が出力されていない

2. 障害分析のトリガーとなるアラームは必須

アラームによる通知から、イベントの発生時間を判断し必要なログやトレースの収集を行うことになります。アラームや通知がない場合にはテレメトリデータの収集を行えないため、アラームと通知は必須です。

3. 取得するテレメトリデータの種類は様々であり試行錯誤が必要

ログだけで見ても、アプリケーションログ、CloudFront、ALB が出力するアクセスログ、 CloudTrail のログ、セキュリティサービスの検知結果など、障害分析に向けて利用できるものは多くあります。どのログを利用するか、どのログを利用することで障害を特定することができるかはシステムによって異なるため、適したログを選択する必要があります。
追加のテレメトリデータが必要になった場合でも、AWS では API や SDK を利用することで容易に追加で取得することができます。

4. 大きなコンテキストウィンドウを持つ LLM の利用を推奨

プロンプトとして LLM に渡すテレメトリデータが多くなる傾向になるため、コンテキストウィンドウが大きい LLM が必要になります。
例えば、Claude モデルは 200,000 トークンのコンテキストウィンドウを持ちます。
Amazon Bedrock を利用することで、大きなコンテキストウィンドウの新しい LLM が出た際にも簡単に LLM を切り替えることができます。

LLM を活用した障害分析の導入に向けた課題と対策

LLM を活用した障害特定で考えられる主な課題とその対策について解説します。

1. 誤った分析結果の提供

課題:

現時点での LLM ではハルシネーションのリスクがあり、分析結果が必ずしも正しくない可能性があるの現状です。
対策:

LLM を利用した障害分析はあくまで支援ツールであり、最終判断は人間が行うという原則を徹底する
- ログ検索に利用したクエリを回答メッセージの補足に含め、最終判断をしやすくする
- 今回は利用していませんが、さまざまなメトリクスをダッシュボードとして表現し、 LLM の出力結果とダッシュボードとの比較を行い、妥当性を判断する
定期的に分析結果を元に LLM の精度や性能を評価し、モデルの切り替えを検討する

2. データの質と量の確保

課題 :

利用する LLM の性能に加えて、プロンプトとして渡すログやトレースの量と品質によって、分析の精度が大きく影響します。十分な量の高品質なデータがなければ、精度の高い分析は困難です。

対策:

ログ、メトリクス、トレースなど、多様なデータソースを統合する
データクレンジングや正規化のプロセスを設け、データの品質を向上させる

3. プライバシーとセキュリティの確保

課題:

障害データには機密情報が含まれる可能性があり、データの取り扱いには注意が必要です。
対策:

データの匿名化や暗号化を徹底する
アクセス権限の厳格な管理を行う

LLM を活用した障害分析ソリューションのさらなる拡張

上記ソリューションではチャットをインターフェースとし、人が分析条件を定義してきましたが、機能を拡張することによってさらに高度化することができます。

1. マルチクラウド・ハイブリッド環境での統合分析

クラウド、オンプレミス、エッジコンピューティングなど、環境を跨いだログやトレースを収集することで、複雑化するIT環境全体を統合的に分析するシステムを構築することができます。これにより、環境の違いを超えた一貫性のある障害分析と対応を実現することができます。

2. 自然言語処理によるインタラクティブな対応

上記ソリューションでは単一の AWS Lambda を利用してログやトレースの取得を行いましたが、Agents for Amazon Bedrock を導入し異なる処理を行う複数の AWS Lambda の使い分けを LLM に委ねることによって、より柔軟な障害分析をシームレスに進められるようになります。これにより、LLM の分析結果から追加で質問を投げることによってより詳細に分析するなど、高度な分析が可能となり、迅速な意思決定につながります。

3. 将来的な自己修復システムの実現

障害を検知し、その原因を特定するだけでなく、適切な修復アクションを自動的に実行する「自己修復システム」の実現が期待されています。これにより、人間の介入なしに多くの障害が自動的に解決され、システムの可用性が飛躍的に向上する可能性があります。現時点では LLM の要約を人が判断し、復旧に向けたアクションを定義する必要がありますが、今後 LLM や AI/ML の精度が向上することでより自動化の範囲を広げることができると考えられます。

結論

AI/ML を活用した障害分析は、ITシステムの複雑化と大規模化に伴う課題に対する強力なソリューションとなります。迅速な障害検知、効率的な根本原因分析、予知保全の実現など、多くのメリットをもたらす一方で、データの質と量の確保、プライバシーとセキュリティの問題、人材育成など、導入に向けてはいくつかの課題も存在します。
しかし、これらの課題に適切に対処することで、AI/ML は障害分析の強力な味方となり、システムの信頼性向上と運用コストの削減に大きく貢献します。さらに、将来的には自己修復システムの実現など、さらなる進化が期待されています。
すでに取得を開始しているログやトレースを LLM を使って分析するだけでも障害分析を効率化、高度化することは可能です。事前学習やサーバ管理など不要な手段で今すぐ取り掛かっていただければと思います。

Amazon Web Services ブログ