AWSマネージドサービスのみで 障害対応の自動化 インフラ技術基礎勉強会 #4 https://infra365.connpass.com/event/286297/ Sato Atsushi

自己紹介 名前: 佐藤 淳 ( Atsushi Sato ) 会社: アイレット株式会社 クラウドインテグレーション 所属 Qiita: https://qiita.com/atw0_0w 好きなAWSサービス: Systems Manager, Lambda, CDK (主に自動化やIaC周り) 2023 Japan AWS All Certifications Engineers 2

アジェンダ 1. 障害対応に必要なもの 2. インシデント管理とは? 3. デモ環境構築 4. 障害デモンストレーション 5. まとめ 6. 終わりに 付録: 対応プラン作成 3

障害対応の自動化に必要なものとそれを解決する AWSサービス - 障害のあるメトリクスを検知したい → CloudWatch Alarm - 障害があったら通知したい → AWS Chatbot - 復旧コマンドをテンプレート化 → SSM Document - 復旧コマンドを実行 → SSM Automation - インシデント管理をしたい → SSM Incident Manager 上記AWSマネージドサービスを使用してインシデント管理する方法について解説 1. 障害対応に必要なもの 4

2. インシデント管理とは？ Q. インシデント管理とは？ A. サービスの中断または停止時に、原因の調査 /対応手順/復旧結果/意思決定などを時 系列に沿って記録/管理するもの。 > 参考 … https://www.atlassian.com/ja/incident-management 5

Q. インシデント管理の目的 A. 障害によるサービス品質の低下を防ぐこと そのためには。。。 →「 誰が,いつ,どのような対応をしたか」や「成功/失敗したか」,「分析結果」,「意思決定」を記録。 → インシデント対応プロセスに則って、対応しているか。 > https://www.atlassian.com/ja/incident-management/incident-response → ランブックを設定して、一次対応など障害対応の自動化ができているか。 > https://www.atlassian.com/ja/incident-management/incident-response/how-to-create-an-incident-response-playbook#incident-response-lifecycle → オンコール体制は整備されているか。 > https://www.atlassian.com/ja/incident-management/on-call 6

Q. AWSでインシデント管理できるマネージドサービスはある？ A. SSM Incident Managerがある!! AWS マネージドサービスだけで全て解決できる !! → 「対応プラン」で解決 → 「対応プラン」内からSSM Automationを実行 → 「エスカレーションプラン」と「オンコールスケ ジューリング」で解決 → インシデント管理 7

Incident Manager用語集 機能名 解説 対応プラン インシデント発行時のテンプレートのようなもの。 ランブック(SSM Automation)やコラボレーション(Chatbotへの通知)、オンコール体制(エスカ レーションプランなどを定義。 CloudWatch AlarmやEventBridgeのアクションとして呼び出される。 エスカレーション プラン 「連絡先」や「オンコールスケジューリング」で設定した連絡先へ、エスカレーションの順番を設 定。 オンコール スケジューリング 「連絡先」で設定したコンタクト情報のシフト表を作成。 連絡先 電話、SMS、Eメールなどのコンタクト情報を登録。 インシデント発生時オンコールされる。 設定 インシデントを実行するリージョン (レプリケーションセット )を選択。 選択したリージョンで共通のインシデント管理、対応プランの実行が可能。 8

インシデント発行時の流れになります。 9

3. デモ環境構築 今回デモで実施するリソースは以下の通り . - EC2(AmazonLinux2023) - CloudWatch Agent 10

今回デモで実施する監視項目は以下の通りとする。 AWSサービス 監視項目 監視メトリクス アラーム条件 ランブック 内容 EC2 CPU使用率 CPUUtilizations > 90 % vmstatコマンドで確認 インスタンス障害 StatusCheckFailed_Instance > 0 EC2の再起動 CloudWatch Agent プロセス数監視 (CWAgentのプロセス名) <= 0 プロセス再起動 CloudWatch Alarm 11

Incident Manager 対応プランの作成 本当はAWSサービス(EC2, RDS, etc ...)、影響度(重大, 高, 中, 低, ..)ごとに対応プランを作ったほうがいい。。 ↓ ただし、対応プラン1個につき月額で 7 USD > https://aws.amazon.com/jp/systems-manager/pricing/#Incident_Manager (流石に個人で検証するにはちょっと、、、 ) ↓ 今回は、1個の対応プランでEC2とCloudWatch Agent の復旧用のランブックを実施 12

1個の対応プランでEC2とCloudWatch Agent の復旧用のランブック(↓もしよければGitHub参考にmm) https://github.com/atsw0q0/aws_ssm_documents_templates/blob/0243f6ef3cc1f8d142f40cd67c4af7b0521a3c7a/template s/ssm-im/lt_20230903/im_runbook.yaml 13

4. 障害デモンストレーション 14 AWSサービス 監視項目 監視メトリクス アラート発生コマンド EC2 CPU使用率 CPUUtilizations $ yes > /dev/null インスタンス障害 StatusCheckFailed_Instance $ networkctl down 「リンク名」 CloudWatch Agent プロセス数監視 (CWAgentのプロセス名) $ systemctl stop 「プロセス名」 以下のコマンドを実行し、 CloudWatch Alarmをアラート状態にする。

インシデント 画面 15

インシデント クローズ画面 16

メトリクス、タイムラインも確認可 17

Slack画面 ← インシデント作成 ← OpsItems追加 ← オンコール ← インシデント クローズ 18

インシデント分析 ← OpsItems追加 ← オンコール ← インシデント クローズ 19

5. まとめ 【便利なところ】 - インシデント起票〜復旧までを自動化。 - 24h365dの運用体制をスケジューリングできる。 - 画面ぽちぽちで簡単にセットアップすることができた。 (付録 参考) 【不便なところ】 - 対応プランでの細かい制御ができない。 - オートリゾルブ機能 - 復旧した場合、オンコールしないなどの条件分岐 20

ご清聴ありがとうございました

付録: 対応プラン作成 GUIでIncident Manager 対応プランを簡単に構築するこ とができる。 インシデントタイトル名の設定。デフォルトでは タイトル名 [ CWAlarm名] となる 22

チャットチャネルには、 AWS Chatbotのチャンネル名を指定する 23

エンゲージメントには、 事前にアクティベートした連絡先 を指定する 24

ランブックの作成 ・AWS Document「test-im-runbook」を指定。 「test-im-runbook」は以下のリンクを参照。 ・SSM Document上で使用するパラメータ 「IncidentRecordArn」では「インシデントArn」を指定するこ とで、適宜自動生成された Arnがパラメータ値に代入され る。 25 https://github.com/atsw0q0/aws_ssm_documents_templates/blob/0243f6ef3cc1f8d142f40cd67c4af7b0521a3c7a/template s/ssm-im/lt_20230903/im_runbook.yaml

続き ・Automation実行用のロールのパラメータ 「AutomationAssumeRole」のロールは 新規で作成する。 ・ランブックを実行するロールも新規で作成する。 ・ロール「test-role-im-runbook-assume-role」にはAWS Documentを実行する上で必要なロールを右のポリシー意外に も追加。 (EC2ReadOnlyAccessなど) 以上で対応プランの出来上がり !! 26