Amazon Web Services ブログ

Amazon Bedrock Insights による CloudWatch アラームへの対応

概要

クラウド上で複雑な分散型システムを運用する際、問題の根本原因を迅速に特定し、インシデントを解決することは大変な作業です。トラブルシューティングでは、複数の AWS サービスからのメトリクス、ログ、トレースをチェックする必要があり、問題を包括的に把握することが必要ですが、容易ではありませんが困難です。効果的なインシデント解決に必要な時間と手間をどのように軽減できるでしょうか?

この問題の解決方法として、このブログでは、Alarm Context Tool (ACT) を紹介します。これは、Amazon CloudWatch Alarms に追加のコンテキストを提供し、トラブルシューティングと分析を支援するソリューションです。AWS LambdaAmazon CloudWatchAWS X-RayAWS HealthAmazon Bedrock などの AWS サービスを活用し、メトリクス、ログ、トレースを集約、分析し、有意義な洞察を生成します。ACT はトラブルシューティングプロセスを簡素化し、運用コストを削減し、AWS 環境のオブザーバビリティを向上させます。

主な利点

トラブルシューティングの簡素化

ACT は、CloudWatch、X-Ray、Amazon RDS Performance InsightsCloudWatch Container Insights などさまざまな情報源から関連データを自動的に収集、分析します。これにより、根本原因を特定し、トラブルシューティングに要する時間を削減できます。異なる AWS サービスからのデータを統合することで、ACT はシステムの状態とパフォーマンスの包括的な状況を提供し、インシデントの迅速な解決を可能にします。

コスト効率

アラーム通知内に詳細なコンテキストと洞察を提供することで、ACT は手動によるデータ収集と解析に関連する運用上のオーバーヘッドとコストを削減します。オペレーターは複数の AWS サービスを深く確認することなく、問題を素早く理解できます。これにより、問題の診断に必要な時間と労力が削減され、運用コストが低減し、リソースの活用が向上し、平均修復時間 (MTTR) が短縮されます。

拡張されたオブザーバビリティ

ACT は Amazon Bedrock の生成 AI 機能を活用して、所見の要約、潜在的な根本原因の特定、関連するドキュメントへのリンクの提示を行います。これにより、AWS 環境のオブザーバビリティが高まり、保守やオペレーション作業が簡素化されます。AI で強化されたインサイトの統合により、オペレータは実行可能な情報を受け取ることができ、ログやメトリクスの分析ではなく、問題の解決に集中できるようになります。

アーキテクチャ

このソリューションは、AWS Lambda 関数、CloudWatch Alarms、X-Ray トレーシング、Amazon Bedrock の AI 機能を組み合わせて構築されています。アーキテクチャの概要は次のとおりです。

Alarm Context Tool Architecture Diagram

図1. アーキテクチャ図

  1. CloudWatch Alarms は、Amazon SNS トピックに通知を送信します。
  2. Lambda 関数 は、SNS トピックをサブスクライブします。
  3. Lambda 関数 は、CloudWatch メトリクスとログ、X-Ray トレース、RDS Performance Insights、Container Insights、AWS Health などのソースからデータを集約します。
  4. Amazon Bedrock は、集約されたデータを処理し、要約、インサイト、根本原因を生成します。
  5. Amazon SES は、処理された情報を電子メールで関係者に送信します。
  6. X-Ray トレーシング は、Powertools for AWS Lambda (Python) から Tracer を使用することで、Lambda 関数の実行の詳細なトレースを提供し、関数のパフォーマンスと動作の深い可視化を実現します。

事例シナリオ: ACT の実用例

シナリオの概要

CloudWatch Synthetics Canary の障害により、アラームがトリガーされます。これは、マイクロサービス API の間欠的なエラーまたは高い待ち時間の兆候です。ACT Lambda 関数が呼び出されて、追加のコンテキストを収集し、問題の詳細な分析を提供します。ACT がこのシナリオでトラブルシューティングを簡素化する方法は次のとおりです。

Trace Map

図2. Alarm Context Tool のトレースマップ

データの収集と分析

アラームがトリガーされると、ACT Lambda 関数は以下のデータ収集のステップを実行します:

  1. CloudWatch メトリクス: この関数は、エラー率、レイテンシー、リクエスト数などの関連メトリクスを CloudWatch から収集します。
  2. CloudWatch Logs: この関数は、今回の Canary 実行に関連する関連ログを CloudWatch Logs から収集します。
  3. X-Ray トレース: API の実行フローの中で、失敗の正確な場所を特定するために、詳細なトレースが取得されます。たとえば、トレースデータは films-prod-APILambdaFunction-LulvbCzjxHFb Lambda 関数が Movies DynamoDB テーブルへのクエリ中に問題が発生したことを示しています。
  4. ヘルスイベント: この関数は、特定のサービスに影響を与える可能性のある関連イベントについて AWS Health にクエリします。
  5. アラーム履歴: この関数はアラームの履歴を検査し、今回の場合は、これが継続的に発生している問題であると判断します。
  6. リソース情報: この関数は、特定のリソースである CloudWatch Synthetics Canary の詳細を取得します。
  7. Amazon Bedrock 分析: Amazon Bedrock は集約されたデータを分析し、判明事項の概要を生成します。

生成 AI によるインサイト

Amazon Bedrock は収集したデータを分析し、調査結果の要約を生成します。この例では、DynamoDB テーブルで読み取りトラフィックが高くなり、プロビジョンドスループットを超過しているため、Bedrock はこれをルート要因と特定しています。

通知と報告

この関数は、調査結果を要約し、潜在的な解決策を示して関係者に電子メールを送信します。この電子メールには以下の内容が含まれています。

  • Root Cause Analysis (根本原因分析): 収集されたデータに基づき、DynamoDB テーブルがプロビジョンドスループットを超えていることなどの主要な問題を特定します。
  • Alarm Frequency and Immediacy(アラームの頻度と緊急性): アラームの過去のデータを分析して、その起動頻度を判断し、根本的な問題が再発するか、断続的か、一回限りのものかを特定に役立ちます。
  • Additional Metrics Analysis (追加のメトリクス分析): 失敗したカナリア実行やサーバーサイドエラーなど、関連するメトリクスからの洞察。
  • Potential Solutions (潜在的な解決策): DynamoDB のプロビジョンドスループットを増やすこと、パーティションキーの設計を最適化すること、アプリケーションコードで指数関数的バックオフを実装することなどの推奨事項。
  • AWS Health イベント: システムに影響を与える可能性のある、メンテナンスイベントや変更の予定。

例の概要 (抜粋)

Root Cause Analysis (根本原因分析)
この問題は、DynamoDB テーブルの Movies がプロビジョニングされたスループット容量を超えていることに関連しているようです。films-prod-APILambdaFunction-LulvbCzjxHFb Lambda 関数が Movies DynamoDB テーブルをクエリしているときに、ProvisionedThroughputExceededException が発生しました。

Alarm Frequency and Immediacy (アラームの頻度と緊急性)
アラームは過去数時間に複数回トリガーされており、問題が繰り返し発生していることを示しています。OK 状態と ALARM 状態が頻繁に切り替わることから、問題はトラフィックの急増に関連していることがわかります。

Additional Metrics Analysis (その他のメトリクス分析)

  • Failed メトリクスの値は 1 で、最近の Canary 実行 の失敗を示します。
  • 5xx メトリクスの値は 1 で、サーバー側のエラー(502 Bad Gateway)を示唆しています。
  • SuccessPercent メトリクスは、Canary 実行が失敗した場合は 0% と表示されます。

Potential Solutions (潜在的な解決策)
問題を解決するには、次の手順を検討してください。

  • Movies DynamoDB テーブルのプロビジョニングされたスループット容量を増やします。
  • パーティションキー設計のベストプラクティスを実装する。
  • アプリケーションコードにジッターを伴うエクスポネンシャルバックオフを実装します。

Relevant Documentation (関連ドキュメント)

結論

このブログでは、Amazon CloudWatch Alarm をより豊富な文脈と洞察によって強化し、トラブルシューティングと分析を支援するソリューションである Alarm Context Tool (ACT) を紹介しました。ACT は複数の AWS サービスと Amazon Bedrock の生成 AI 機能を活用しています。これにより、インシデント解決プロセスを簡素化し、運用コストを削減し、AWS 環境のオブザーバビリティを向上させます。

ACT について、さらに学び、使用を開始するには GitHub リポジトリ のセットアップ手順に従ってください。

ACT の使用ついての質問や改善の提案、問題がある場合は、GitHub リポジトリ で気軽に Issue を作成してください。皆様のフィードバックと貢献を大切にし、ACT をより良いものにしていきます。

著者について

Alex Livingstone

Alexは、Amazon CloudWatch、AWS X-Ray、Amazon Managed Service for Prometheus、Amazon Managed Grafana、AWS Distro for OpenTelemetry などのAWS オブザーバビリティツールに焦点を当てた Principal Solution Architect です。彼は、お客様がクラウドで運用し、アプリケーションに関する洞察を得るのを支援することが大好きです。ぜひ、LinkedIn (/aelivingstone) で彼を探してください 。

本記事は、Respond to CloudWatch Alarms with Amazon Bedrock Insights を翻訳したものです。翻訳は テクニカルアカウントマネージャー の 日平 が担当しました。