AWS障害復旧後すぐにやったEC2インスタンスへの暫定処置 #AWS

前書き

先日発生したAWS Tokyoリージョンの大規模障害。

東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要
https://aws.amazon.com/jp/message/56489/

私もこの障害により、運用中のEC2インスタンスが一部ダウンしました。
が、幸いにも復旧に無事成功し、ほぼ事なきを得たのは不幸中の幸いでした。

こうした事案を踏まえて認識せねばと思ったことは２つ。

1.クラウドだって物理のマシンなんだ
2.だからダウンする時だってあるんだ

内心どこかで「国内のAWSリージョンは落ちない」みたいな妄想は持っていたと。
それが間違いだと痛感する機会となってしまいました。。。

その上で障害復旧後に「すぐにやったこと」をまとめました。

すぐにやったこと

1. 復旧したインスタンスをスナップショットで立ちあげ直す
2.一部のインスタンスは手動でなく定期でスナップショットを取得する

1. 復旧したインスタンスをスナップショットで立ちあげ直す

今回の障害についてのAWSの公式見解は、以下の通りでした。

日本時間 2019年8月23日 12:36 より、
東京リージョン (AP-NORTHEAST-1) の単一のアベイラビリティゾーンで、
オーバーヒートにより一定の割合の EC2 サーバの停止が発生しました。
この結果、当該アベイラビリティゾーンの EC2 インスタンスへの影響及び
EBS ボリュームのパフォーマンスの劣化が発生しました。

サーバが熱でやられたんだ、と認識しました。
だから、今割り当てられているサーバにも物理的な故障が生じている可能性がある。
このまま利用する前に、一度安全な環境でインスタンスを立て直した方が良さそうとも判断しました。

一度インスタンスを止めて、スナップショットから別のインスタンスを立ち上げます。

手順

スクショはいずれも、記事用にテストで立てたものを使っています。
不要な情報は一応マスキングしていますのでご了承ください。

(1) 該当インスタンスを「stopped」にしてから「説明タブ」の「ブロックデバイス」を選択します

(2) 立ち上がる小ウィンドウ内から「EBS ID」を選択します

(3) ボリュームの設定が立ち上がるのでここから「スナップショット」を選択します

(4) スナップショットの一覧が立ち上がるので「スナップショットの作成」を選択します

(5) スナップショットを作成します

- Select resource type は「Volume」を選択
- ボリュームは「当該インスタンスのID」を指定
- 説明は「それらしい情報」を入力, 全角非対応なので注意
- タグは検索や履歴管理で役立つので「任意に設定」しておく

(6) スナップショットの作成に成功しました

(7) スナップショットの一覧に作成したスナップショットが表示されました

(8) これを選択して「アクション」から「ボリュームの作成」を選べば「EC2インスタンス」を立てていけます

IPやセキュリティグループ、VPC等、現在利用中のインスタンスの設定を加味しながら立ち上げ直しましょう。
~~（じゃないとあとで設定変更できないやんとインスタンスを作り成す羽目にあったりorz）~~

これで復旧がひとまず完了。
動作検証をかけて問題なければ利用できる状態として良さそうです。

2.一部のインスタンスは手動でなく定期でスナップショットを取得する

記事の冒頭にも書いた通り、私は、
内心どこかで「国内のAWSリージョンは落ちない」みたいな妄想は持っておりました。

そんなわけでスナップショットを定期取得する、といった運用も行えておらず・・・。
これを機に、障害対策の一環で定期でスナップショットを作成するのも良いかと考えました。

手順

(1) EC2インスタンスの左メニューより「ライフサイクルマネージャー」を選択します

(2) スナップショットのライフサイクルポリシーを作成します

- 説明は「それらしい情報」を入力, 全角非対応なので注意
- Select resource type は「Volume」を選択
- これらのタグを持つターゲットは「該当するターゲットのタグ」などを選択
- スケジュール名は「それらしい情報」を入力, 全角非対応なので注意
- ポリシーを次の時間ごとに実行するは「生成頻度の時間」を入力
- 開始時刻は「該当時刻」を入力, UTC基準なので時差に注意
- 保持ルールに「スナップショット生成数の上限数」を入力