[アップデート] SSM Incident Manager でインシデントの潜在的な根本原因となる更新が自動検出出来るようになったので使ってみた

#AWS Systems Manager Incident Manager

#AWS

いわさ

2023.11.21

いわさです。

AWS Systems Manager の機能のひとつにインシデント管理を行うための Incident Manager という機能があります。
今朝のアップデートで Incident Manager の診断機能が強化されました。

インシデントの原因を特定出来るようになり、それによって解決時間の短縮が見込めるということ。
アナウンスだけ見るとすごいやんという感じですが、実際の使い勝手がどうなのかがわからなかったので確認してみました。
アナウンスを見る限りだと根本原因として取り扱えるのは CloudFormation と CodeDeploy の情報のように読み取れます。

変更点

変更前後のユーザーインターフェースを比較してみると、若干の変更点を確認することが出来ました。
先に見ておきましょう。

アップデート前

以下はアップデート前のコンソールです。
赤枠で囲われているタブが「メトリクス」でした。

SSM Incident Manager のインシデントは、CloudWatch アラーム発生時にインシデントを自動作成し追跡することが可能です。
これによって対象インシデントと CloudWatch メトリクスが関連付けられ、時系列の発生状況などを診断することが出来ました。

アップデート後

アップデート後は「診断」タブに変更されており、その中で従来のメトリクスタブ相当の機能を使うことが出来ます。
そして、今回追加された「検出結果」機能も表示されています。

どうやらインシデントが発生した際に、この診断タブを確認することでメトリクスと検出された関連デプロイを確認することで、インシデントの解決に役立てることが出来るという仕組みのようです。

実際にインシデントを発生させ検出結果を確認してみた

では、実際にインシデントを発生させて検出される様子を確認してみましょう。
重要な点として、今回の検出機能は追加料金なしで Incident Manager の標準料金内で利用可能ですが、オプトイン操作が必要です。

オプトイン

具体的には、Incident Manager の設定画面から検出結果機能を使うためのサービスロールを作成します。

サービスロールの作成ボタンを押すと、自動で作成されるロールのアクセス許可内容を確認することが出来ます。
このポリシー内容からも、検出結果機能でアクセス出来るサービスは CloudFormation と CodeDeploy であることがわかります。

サービスロール作成操作を確定させると次のように関連付けされます。
オプトイン操作としてはこれで終わりです。あとは自動で検出結果機能が動作します。

ただし、画面に記載のとおりクロスアカウントで Incident Manager を使う場合には追加の設定が必要です。
公式より CloudFormation テンプレートと手順が提供されているので、次のドキュメントを参照してください。

インシデントを発生させてみる

では何か適当なインシデントを発生させてみましょう。
今回は次のような SAM テンプレートで Lambda 関数をデプロイしました。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: ---
Resources:
  HogeFunction:
    Type: AWS::Serverless::Function 
    Properties:
      FunctionName: HogeFunction
      Handler: index.handler
      InlineCode: |
        const { setTimeout } = require('timers/promises')
        exports.handler = async (event) => {
            await setTimeout(5000);
            return 'hogehoge';
        };
      Runtime: nodejs18.x
      Timeout: 30
      Events:
        ScheduleEvent:
          Type: ScheduleV2
          Properties:
            ScheduleExpression: "rate(1 minute)"

適当な感じですけども、内容としては 5 秒スリープするだけの関数を EventBridge Scheduler で 1 分毎に実行しているだけのものです。

Lambda 関数のタイムアウト値が 30 秒で設定されています。
このタイムアウト値を 5 秒以下に更新することで、Lambda 関数でタイムアウトが発生しエラーを検出した CloudWatch アラームがインシデントを自動作成してくれる、というシナリオです。

デプロイ後に関数の動作確認をしました。
5 秒で正常に終了することを確認しています。

CloudWatch アラームからインシデントを自動作成するように構成します。
対象関数の Errors メトリクスをトリガーにします。

Incident Manager と統合する際のポイントとして、CloudWatch アラームのアクションで Systems Manager アクションにてインシデントが作成されるように構成します。
レスポンスプランの選択も必要です。

アラーム構成の作成直後はまだ Lambda 関数が成功する状態なので正常状態です。

そして Incident Manager でもインシデントは発生していないことが確認出来ます。

ここで、次のように SAM テンプレートの関数タイムアウト値を変更し、スタックを更新しましょう。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: ---
Resources:
  HogeFunction:
    Type: AWS::Serverless::Function 
    Properties:
      FunctionName: HogeFunction
      Handler: index.handler
      InlineCode: |
        const { setTimeout } = require('timers/promises')
        exports.handler = async (event) => {
            await setTimeout(5000);
            return 'hogehoge';
        };
      Runtime: nodejs18.x
      Timeout: 3
      Events:
        ScheduleEvent:
          Type: ScheduleV2
          Properties:
            ScheduleExpression: "rate(1 minute)"

しばらく観察していると、アラームが発生したことが確認出来ました。

Incident Manager を確認してみると、オープン状態の新しいインシデントが自動作成されていることが確認出来ます。良いですね、素晴らしい。
実際の運用時には対応プランやエスカレーションプランに設定した内容でインシデントを検出するところから始まるのですが、今回はそのあたりは割愛したいと思います。

診断機能を確認する

では本題である、診断機能を確認してみましょう。
対象インシデントを開き、診断タブを選択します。

次のようにインシデントのトリガーとなっている監視メトリクスを確認することが出来ます。
また、検出結果エリアにはどうやら関連する CloudFormation スタックのデプロイ情報がリスト表示されています。

インシデントよりもだいぶ前にデプロイした正常なスタック作成・更新についても列挙されていますね。
関数 ARN など、何かしらの情報と紐づけがされているのかもしれない。

このように、検出結果エリアではこのインシデントに関連する CloudFormation デプロイ履歴を確認することが出来ます。
これによって、問題が発生する以前のデプロイ履歴から更新があったことをすぐに把握することが出来るようになりました。

なお、今回のアップデートで確認出来るのはここまでとなってます。
上記の「CloudFormation で表示」を選択すると対象スタックのコンソール画面へ遷移するだけです。
そこからイベント履歴を確認し、更新されたパラメータを特定し、などについては実施する必要があります。

仮に CloudFormation の問題を特定してデプロイしなおした場合は次のように診断結果のメトリクスが正常状態となります。

ただし、アラームが正常状態になってもインシデントは自動で解決済みとはなりません。
問題の対処後に追加で必要な措置（テストや確認など）があれば実施し、クローズする必要があります。

さいごに

本日は SSM Incident Manager でインシデントの潜在的な根本原因となる更新が自動検出出来るようになったということで、実際の使い勝手を確認してみました。

従来だと「CloudFormation でこのタイミングで更新されたんだな。影響あったのかもな。」に到達するまでに、CloudTrail を解析したりと Lambda コンソールから履歴情報などを確認したりと少し特定の時間が必要だったと思いますが、今回のアップデートですぐに影響ありそうなイベントがわかるようになったので、関連するデプロイ情報が表示されることで少し便利になったのではないでしょうか。

本日時点でサポートされている関連サービスが CloudFormation と CodeDeploy のみということなので、こちらは今後サポート範囲がさらに増えていくともっと便利になりそうです。
特に、問題が発生したリソースから CloudTrail イベントまで関連付けされて、Amazon Detective の Incident Manager 版のようなレベルで使えると最高ですね。

コンソールの検出結果の説明欄には「Currently」という記載があったので、今後のサポート範囲拡大も見込まれているのではないかと期待しています。