AWSマネージドサービスのみで障害対応の自動化

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 Certiﬁcations 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

AWSマネージドサービスのみで障害対応の自動化

AWSマネージドサービスのみで障害対応の自動化

Atsushi Satou

More Decks by Atsushi Satou

Other Decks in Technology

Featured

Transcript