Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
AWSマネージドサービスのみで 障害対応の自動化
Search
Atsushi Satou
September 03, 2023
Technology
3.6k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
AWSマネージドサービスのみで 障害対応の自動化
インフラ技術基礎勉強会 #4
https://infra365.connpass.com/event/286297/
Atsushi Satou
September 03, 2023
More Decks by Atsushi Satou
See All by Atsushi Satou
AWS ECSでサービス間通信についておさらい
atsuw0
1
150
図で理解するAWS Network Firewallのアーキテクチャ
atsuw0
0
510
CLIで構築した方が良いもの一覧.pdf
atsuw0
0
190
HCP Terraformを使ったら AWSやGCPの環境構築が捗った話
atsuw0
0
330
HashicorpCloudについて.pdf
atsuw0
0
40
HCP Terraform について
atsuw0
0
1.9k
HashicorpCloudについて.pdf
atsuw0
0
44
AWS サーバレス設計 Tips集
atsuw0
0
140
AWS re:Invent 2023 ストレージ EFSレプリケーションのフェイルバック機能を試してみた
atsuw0
0
450
Other Decks in Technology
See All in Technology
AI時代の「技術的負債」の変質ー概念の終焉と再解釈、エージェントと共に向かう先
nwiizo
1
2.9k
なぜ「決定性」が 決定的に重要なのか? Durable Execution 基盤の数理的理解 #serverlessjp / ServerlessDays Tokyo 2026
ytaka23
3
730
SREへの勘違いに気づいた後の話
tomodakengo
0
110
エージェントはローカル、検証はMicroVM — Lambda MicroVMsでつくるServerless CI
fujioka6789
3
370
ADKで始める業務改善 - AIエージェント開発時の考えと設計
harappa80
2
220
Deployment の 先にある AI Agent 基盤 - kagent vNext、Agent Substrate、Hermes から読み解く Agent Runtime の現在地 / k8s-matsuri-2-ai-agent-platform-amsy810
masayaaoyama
4
670
EventBridge に「合流」はない ― サーバーレスのワークフローを育てるということ / No Join in EventBridge
yusukeshimizu
2
160
CLIライブラリ開発を支える技術
htnabe
0
130
その Lambda、8分で 管理者権限まで奪われます
k1nakayama
6
3.1k
AIエージェントの一手は 誰も見ていない - Falco拡張OSS「Prempti」とeBPFで サーバーレス実行基盤を二層防御する
keitah
0
220
Cloudflare Workers 向けアプリを C# で構築する ~WASM Native AOT への道~
nenonaninu
1
450
AI de Idea
kawaguti
PRO
2
130
Featured
See All Featured
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.9k
VelocityConf: Rendering Performance Case Studies
addyosmani
331
25k
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
490
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.6k
Are puppies a ranking factor?
jonoalderson
2
3.9k
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
440
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.4k
New Earth Scene 8
popppiees
4
2.6k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.6k
Code Review Best Practice
trishagee
74
20k
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
530
How to Get Subject Matter Experts Bought In and Actively Contributing to SEO & PR Initiatives.
livdayseo
0
200
Transcript
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