AWS Systems Manager Incident Manager を紹介
概要
Technology & Design Department SREチームで内定者インターンをしている若林と申します。 今年4月からインターンを開始し、様々な経験をしながら日々成長を感じています。 本記事では、AWS Systems Manager Incident Manager(以下、Incident Manager)についてまとめ、AWS初心者ながらも、これからの使用を検討している方、もしくは使用しているがまだあまり理解ができていない方にむけて共有ができれば、と感じております！
チームとしてIncident Managerをどう扱っていくか
SREチームではでインシデントの管理や分析のより良い方法を探し続けています。
また、今年からポストモーテムを導入しており効率的な管理方法も求めています。
その中で Incident Manager がインシデント管理とポストモーテム作成を行えるとの情報を目にしたため、SREチームとして導入できそうか調査を行いました。
本記事では Incident Manager がどういった仕組みで動いているのか、どういったメリットデメリットがあるのか、を紹介します。
インシデント管理ツールを選ぶにのあたり、重要になってくる項目として
- 値段
- 機能
- 汎用性
などがあると思います。 そのため本記事では Incident Manager の上記項目を中心にご紹介できれば、と思っております！
Incidentとは
インシデント、と聞いたときどういったものが頭に浮かびますでしょうか。私は真っ先に「事故、故障」などが思い浮かびました。では実際にインシデントはどういったものなのかを調べると
3.1.122
incident
event (3.1.96) that can be, or could lead to, a disruption (3.1.75), loss, emergency (3.1.87) or crisis (3.1.60)
と記述されていました。
直訳すると 混乱（3.1.75）、喪失、緊急事態（3.1.87）、または危機（3.1.60）である可能性がある、またはそれらにつながる可能性のあるイベント（3.1.96） ということになります。
要するに「とあるページが画面遷移しなくなった」など、提供しているサービスやシステムがなんらかの理由で停止してしまったり、品質が低下してしまうと、それはインシデントになる、ということですね。
上記の引用先に飛び 3.1.75 などを検索してみると、混乱が何を指すのかなども記載されておりますので興味のある方は見てみてください。
Incident Manageとは
インシデントが何かわかったところで、それを管理するものはどういったことを表すのでしょうか。 「画面遷移が行われない」という上記の例でいきますと、このインシデントを管理するので
- プログラムを修正
- 正常に作動するか確認
- インシデント解決
あたりだけに注目しがちですが、実際には
- インシデントの検出
- インシデントの分類
- インシデントの解消
・担当者によるインシデントの解消対応
・担当者からエスカレーションし、管理者やマネージャがインシデント解消対応 - インシデントの記録/分析
- 終了
と、細分化した手順を行って管理する必要があります。
こうやってみると意外と面倒だな...という印象かもしれませんが、インシデント管理をすることによってさまざまなメリットがあります。
いくつか紹介しますと、
- 過去に発生したインシデントからその知見を活かし、迅速な対応が可能
- 発生したインシデントを分析することにより、システムやサービスの品質向上
- トラブル発生から解決までの時間短縮
などがあげられます。 現代においてたびたびAWSの障害がインターネット上でニュースになるように、インシデントが発生しないということはありえません。こういったメリットがあるならば、インシデント管理はやるに越したことはありませんね。
また、このインシデント管理の考え方自体はインフラ監視だけではなく、日頃の様々に業務にも応用できますのでぜひ意識してみてください。
それでは、ここからはタイトルにも記載してあります Incident Manager のご紹介をさせていただきます。
Incident Managerとは
Incident ManagerはAWSが2021年5月10日にリリースした、まだまだ新参者のツールです。 しかしこのリリースにより今まで苦労していたインシデント管理がAWS内で一括管理できるかもしれない！という期待の眼差ししまくりのツールでした。 ここから Incident Manager がどういった機能を持ち合わせており、どのように設定を行うかをご紹介します。
まず、 Incident Manager は、AWS Systems Managerの新機能としてリリースされました。では、AWS Systems Managerにはどういった機能が備わっているのでしょうか。本記事のメインではないので軽くご紹介しますと、
AWS Systems Manager は、AWS の運用上のハブです。
Systems Manager は、統合されたユーザーインターフェイスを備えており、AWS のアプリケーションとリソース全体の運用上の問題を一元的に追跡および解決できます。Systems Manager を使用すると、Amazon EC2 インスタンスまたは Amazon RDS インスタンスの運用タスクを自動化できます。
また、アプリケーションごとにリソースをグループ化し、監視とトラブルシューティングのための運用データを表示、事前に承認された変更ワークフローを実装し、リソースのグループの運用変更を監査することもできます。Systems Manager によって、リソースとアプリケーションの管理が簡略化され、運用上の問題の検出と解決までにかかる時間が短縮されます。また、大規模なインフラストラクチャの運用と管理を簡単に行えるようになります。
とAWS公式では紹介されていました。ざっくり掻い摘みますと、オンプレミス/AWS両環境で運用に必要な作業の実施を助けるサービス、ということになります。
このAWS Systems Managerの新機能としてリリースした Incident Manager ですが、どういった機能を持ち合わせているのか、ご紹介いたします。
(参照：AWS Systems Manager の Incident Manager のご紹介)
- インシデントが発生した際の対応プランの作成
- エンゲージメントプランとエスカレーションプランの作成
- AWS Chatbotとの統合
- インシデントの追跡
- インシデントの分析
等がメインの機能として紹介されておりました。 次項から実際に Incident Managerを設定しながら機能などを紹介していきます。
事前準備
Incident Managerを設定、使用するにあたり、必要なものは下記になります。
- AWS アカウント
- AWSアカウントに関して、本記事ではルートユーザを用いて設定、準備を行っております。
- インシデントを発生させる機能(本記事ではAWS EC2を使用しています)
- 発生させたインシデントは、EC2サーバのCPU使用率を基準に設定いたしました。ある閾値を設定し、閾値を超えたらアラートを出しインシデントが発生する、という流れになります。
- 連絡先
- 連絡先はインシデントが発生した際に誰に、どの手段で連絡するか、を設定する際に必要ですので、ご準備ください。本記事では記事を書いている若林と同SREチームの先輩の連絡先を設定しました。
- AWS Chatbotの設定
- AWS Chatbotの設定などは、様々なサイトで紹介されていますので、割愛させていただきます。
参考：Slack と AWS Chatbot で ChatOps をやってみよう
- AWS Chatbotの設定などは、様々なサイトで紹介されていますので、割愛させていただきます。
実際に Incident Managerを設定、使用
ここからは Incident Managerを使用するための設定を行っていきます。
Incident Manager実装までの手順
- レプリケーションの設定
- 連絡先の設定
- エスカレーションプランの設定
- 対応プランの作成
上記の手順を踏むことにより、Incident Manager側の設定は完了、となります。
Incident Managerを初めて開く際にAWSが丁寧に紹介してくれるので、そこまで迷子になることはない、と思われます。
迷子になったらAWSが悪いです。
1. レプリケーションの設定
まずレプリケーションの設定を行います。ここでは、使用しているリージョンが何らかの理由でダウンした際に備え、インシデントデータの複製先を設定します。デフォルトでは Incident Managerを設定しているリージョンが選ばれていますので、もし必要ない場合はデフォルトのままで構いません。本記事ではデフォルトのまま進めさせていただきます。
2. 連絡先の設定
レプリケーションの設定で作成を選択しますと、次は連絡先の設定を行います。 インシデントが発生した際に、誰に、どの手段で、連絡をするかを設定します。 本記事作成者の意見ではありますが、連絡先は複数作成することを推奨します。理由はエスカレーションプランで説明させていただきます。 連絡先の設定では
- 連絡先の詳細
- 連絡先チャンネル
- エンゲージメントプラン
の3つの設定を行います。下記ではそれぞれの詳細をご紹介させていただきます。
2-1. 連絡先の詳細
ここでは、連絡先の名前を設定します。電話帳などに出てくる名前ですね。
注意：ここでは、連絡先の名前を人物の名前にしていますが、決して人の名前にする必要はありません。例えば役職の名前や、グループ名などに設定することも可能です。
2-2. 連絡先チャネルの設定
連絡先チャネルでは、Incident Managerが誰に、どの手段で連絡をするかを設定します。 記入するものとしては
- タイプ
- どの手段で連絡をするかを設定します。Eメール、SMS、音声メッセージの3つから選択が可能です。
- チャネル名
- 連絡手段の名前を記入します。下記の画像にもあるように、タイプによって名前を区別するのを推奨いたします。
- 詳細
- 電話番号やメールアドレスなどを記入します。
- 注意 電話番号を使用する際には、国番号を指定する必要があります。もし日本の電話番号をご使用の場合、先頭に+81をつけ、電話番号を記入してください。
- 電話番号が090-1234-5678の場合、+819012345678と記載
- 電話番号が090-1234-5678の場合、+819012345678と記載
2-3. エンゲージメントプランの設定
エンゲージメントプランでは、インシデントが発生後、連絡先チャネルで登録した連絡先にどのタイミングで連絡するかを設定します。 本記事ではインシデントが発生直後にEメールを、インシデントが発生から５分後に音声メッセージを送るように設定しました。
以上で連絡先の設定が完了、となります。 記載はしていませんが、同じ手順により同SREチームの先輩の連絡先も設定いたしました。
3. エスカレーションプランの設定
エスカレーションプランでは、連絡先をどのような優先度で連絡するかを設定します。 例：連絡先で、チームA、チームBの連絡先を設定したとします。この時、チームAの担当箇所でインシデントが発生
- チームAの担当箇所なので、最優先で連絡
- チームAが対応しなかった場合、もしくは対応不可の場合、チームBに連絡
といった形でインシデントの対応の保険をかけることができます。
エスカレーションプランでは連絡する優先度をステージと呼びます。ステージにはステージ1、ステージ2とあり、ステージ数が後になれば優先度は低くなります。ステージ間の時間を設定可能で、最小1分から設定可能です。 本記事では下記のように設定しました。
- ステージ1 → 若林
- ステージ2 → 同SREチームの先輩
- ステージ1からステージ2に移行するまでの時間 → 2分
以上でエスカレーションプランの設定は完了です。
4. 対応プランの作成
対応プランとは、インシデントが発生した際に
- どういったインシデントで、影響はどれくらいなのか
- インシデントの概要はどういったものか
- どのエスカレーションプランを使用するか
を設定します。この対応プランはアラートに紐付き、アラートが発生次第 Incident Managerに通知されます。 それでは、具体的に対応プランを作成していきます。
4-1. 対応プランの詳細の設定
対応プランの名前と表示名を入力し、設定します。 入力する名前には下記のような制約があります。
- 1 ~ 200文字
- 有効な文字：A ~ Z、a ~ z、0 ~ 9、ハイフン、アンダーバー
表示名はオプションですが、本記事では記入しました。表示名を記入しない場合は対応プランの名前が表示されます。
4-2. インシデント作成の詳細の設定
ここでは、下記の設定を行います。
- インシデントのタイトルの入力
- インシデントの一覧に表示されるようになるので、識別できるようにしておきましょう。
- インシデントの影響度をリストから選択
- 影響は「影響なし、低、中、高、重大」から選択します
- 概要では、インシデントの概要を入力
- マークダウンで入力します。どういったインシデントなのか、どういった対応が望ましいのか、などを記入し、誰が見ても対応に困らないようにしておくことを推奨します。
4-3. チャットチャネルの設定、エンゲージメントプランの選択 - オプション
インシデント対応時の関係者連絡をするためのチャットチャネルを指定します。 ここでは事前準備であらかじめAWS Chatbotを設定します。 本記事ではSlackのチャネルを設定しました。 エンゲージメントプランの選択も行います。 先ほど作成したエンゲージメントプランを選択しました。
以上で、対応プランの作成が完了します。
テスト環境での実施
Incident Managerの設定が完了しましたので、あとはインシデントが発生した際の動作確認を行うだけです。さすがに本番環境でインシデントが発生するのを待つのは怖いので、本記事ではテスト環境として以下のような環境を用意しました。
- AWS EC2を使用し、CPU使用率を監視するアラートを作成
- CPU使用率が閾値を超えた場合、アラートが発生し、Incident Managerで作成した対応プランが動作
それでは、アラートに対応プランを紐付けするところから行きましょう。 アラートはAWS CloudWatchで設定をしています。アラート作成画面の遷移中、System Manager アクションの設定があります。そこで先ほど作成した対応プランを指定します。
それでは、アラートを発火してみましょう。
今回はCPU使用率の監視設定を1%以上に設定することでアラートを発生させました。
Incident Managerを用いたインシデント対応
インシデント管理の手順に沿って対応方法をご紹介します。
1. インシデント検出
インシデントが発生しますと、Incident Manager / Slack / 対応プランに登録した連絡先 に通知が来ます。それぞれの通知は下記の通りです。
Incident Manager
Slack
メールアドレス
音声メッセージ
音声メッセージに関しては、内容として
- インシデントのタイトル（対応プランの名前）
- 影響の大きさ
が英語でループされます。ものすごく焦らせてきます(汗)
2. インシデントの分類
Incident Managerの通知を選択しますと、以下のような画面に遷移します。
(アカウントIDは伏せています)
ここではインシデントの概要、メトリクス、タイムライン、エラー文などが記載されており、インシデント発生から何分経過したのかも見ることが可能になっています。
これらの情報を元に、過去同様のインシデントが発生していないかなどを調査します。
3. インシデント解決
インシデントの解決方法自体はインシデント毎に異なるため、今回は解決できたこととします。
インシデントが解決しましたら、右上にあるインシデントを解決を押します。 インシデントが解決することにより、インシデントを分析することが可能になります。 インシデントが解決したことSlackのチャネルにも通知されるので、関係者も解決したことを知ることができます。
4. インシデントの記録/分析
インシデントの分析を開始しますと、分析のタイトル記入と、分析に用いるテンプレートを選択します。 本記事ではAWSのテンプレートを選択し、分析を作成しました。
分析では、
- インシデントの概要
- タイムライン
- インシデントに関しての質問
- アクション項目(どういった対応をしたのかを記入する場所)
などを記入します。この記入項目を自由に設定できますが、AWSのテンプレートがインシデント管理の「お約束」といえる項目を用意してくれているため、そのまま利用できます。
4-1. インシデント分析 - 概要
概要では、インシデントの内容、なぜ発生したのか、どう対応したのか、インシデントが発生したことによりどういった影響が出たのか、をマークダウンで記入することが可能です。
4-2. インシデント分析 - タイムライン
タイムラインでは、どの時刻に、なにが起こったのかを時系列で表示してくれます。 タイムラインには任意で追加が可能になっており、下記の画像のように反映されます。
対応した時間、作業内容などを記入します。本記事では「テスト」と記入しました。
タイムライン上に「テスト」が追加され、どの時間にどういったことを行ったのかが可視化されて分かりやすくなっています。
4-3. インシデント分析 - インシデントに関しての質問
AWSが所有している質問のテンプレートに対し回答していきます。テンプレートが質問してくる項目としては
- 検出
- 診断
- 緩和策
- 防止
があり、それぞれを回答していくことにより今後の対応策などが見えてきます。
4-4. インシデント分析 - アクション項目
アクション項目では、インシデントが発生した際に、どういったアクション（対応、行動）を取ったのかを記入し、まとめることができます。 アクション項目に記入する項目としては、 * アクションのタイトル * アクションの説明 * アクションの優先度 * アクションの作業量（サイズ）
でした。
5. インシデント分析 - まとめ
Incident Manager の分析を用いることにより、下記の利点がある、と感じました。
- インシデントへの対応の明確化
- インシデントの根本原因を理解
- インシデントの影響の分析
- 組織内での学習と、共有
インシデントをただ解決するのでなく、そのインシデントが二度と発生しないための対策までを行うので、分析を使わない手はない、と強く思います。
Incident Manager の料金
やはりここまで便利な機能を持ち合わせている Incident Manager なので、料金は発生します。 料金は下記の通りです。
- 1 か月でアクティブな対応計画の数に基づいて課金
- 1 か月あたり最大 100 件の SMS または音声メッセージが含まれる
- 追加のメッセージは、受信者の国に応じて課金されます。
参考：料金 - AWS Systems Manager | AWS
対応プランの数により、基本的な料金が変わってきます。対応プラン１つの料金は月$7となっています。 参考先リンクに、料金例も記載してありますので、気になる方はそちらもご確認ください。
また、複数のAWSアカウントを利用している場合、例えば10個のAWSアカウントを所持しており、それぞれのアカウントが2つの対応プランを作成した場合、月額としては 10アカウント × 2プラン × 7ドル となり、月に $140 となります。
DataDogなど他のインシデント管理ツールと比較した際に、アカウントを所持すればするほどお金がかかってしまうのがIncident Managerなので、どのインシデント管理ツールを使用するか、悩みどころですね。。。
まとめ
以上で Incident Manager の流れになります。 Incident Manager を使用することにより、インシデント発生からインシデントの分析までを行うことが可能です。
しかし、AWS以外のインシデント管理ツールにあって、Incident Manager にない機能などは様々あると思います。ただし、 Incident Manager は2021年の5月にリリースされたばかりなので、まだこれから様々な機能が追加されると予想されています。今後の AWS Systems Manager Incident Manager に期待しましょう！
