備えあれば憂いなし！ルートボリュームをリストアする AWS Systems Manager ドキュメントをやってみよう！！
園部です。
障害による影響へのリカバリ作業はいつになっても手に汗握るものです。手順が想定出来るものであれば事前に用意しておきたいものです。それも出来ることならシンプルな手順を。
今回は AWS Systems Manager ( 以下、SSM ) のドキュメントにサンプルとして紹介されている ルートボリュームを最新スナップショットから復元するカスタムドキュメントをやっていきます。SSM ドキュメントを作成しておくことで ランブックとして Automation から実行することが出来ます。パラメータの利用や使い方を記載すれば、いざという時に実施するハードルを下げることが可能です。
やってみる
検証パターン
- スナップショット取得済みインスタンスで実施
- AMI 取得済みインスタンスで実施
- 複数世代スナップショット取得済みインスタンスで実施
SSM ドキュメント作成
AWS Systems Manager >>> ドキュメント >>> オートメーションを作成 を選択します
任意の名前を入力します
エディタ >>> 編集 を選択します
OK を選択します
サンプルで記載されている内容を削除し、ドキュメント - Restore a Root Volume from the Latest Snapshot で紹介されている YAML をコピーして、貼り付けます。
オートメーションの作成 を選択します。
準備完了です。
検証 1. スナップショット取得済みインスタンスで実施
以下のような EC2 を作成しました。
- インスタンス ID: i-02692d49d6949fa10
- EBS
- ルートボリューム（ /dev/xvda ）: vol-02ac20d5f5808997d
- ボリューム（ /dev/sdb ）: vol-059a3712b75f6f71a
- スナップショット
- ルートボリューム: snap-0fba322d45cdb9915
AWS Systems Manager >>> 自動化 >>> オートメーションの実行 >>> 自己所有 >>> 先に作成したドキュメント を選択 >>> 次へ を選択します
SSM と EC2 に関するポリシーがアタッチされたロールと対象となるインスタンスID を指定 >>> 実行 を選択します
Automation で処理が実行されます
処理が成功したので、結果を確認していきます。先ほど取得したスナップショットから新しい EBS ボリュームが作成されています。
そして、インスタンスにアタッチされているルートボリュームが先ほど確認した EBS ボリュームに変更となっています
無事、スナップショットから EBS ボリュームを作成し、ルートボリュームを切り替えることでリストアすることに成功しています！それでは次は同じ要領で AMI のケースをやっていきます。
検証 2. AMI 取得済みインスタンスで実施
今度は、以下のような EC2 を作成しました。
- インスタンス ID: i-07f1f82dfdae49329
- EBS
- ルートボリューム（ /dev/xvda ）: vol-00cec603356fbb90c
- ボリューム（ /dev/sdb ）: vol-089d2a5df3675121e
- AMI ID: ami-078b04dd00cce46fd
- スナップショット
- ルートボリューム: snap-0b0628bbd1b5ce6b8
- ボリューム: snap-01a3b97544b3a95cb
先ほどと同じ方法で Automation を実行します
処理が成功したので、結果を確認していきます。先ほど取得したスナップショットから新しい EBS ボリュームが作成されています。
そして、インスタンスにアタッチされているルートボリュームが先ほど確認した EBS ボリュームに変更となっています
AMI の場合でも同様の動作でリストアすることが可能でした！ 最後にスナップショットを削除してしまったケースを二つほどやってみます。
検証 3. 複数世代スナップショット取得済みインスタンスで実施
おそらく問題ないと考えますが、念の為以下2つのケースを実施します。やはりどんなに信頼できるソースのものでも本番に利用するのであれば不安な部分があれば検証をすることをお勧めします。
- スナップショットが１つ（1世代）の状況で、そのスナップショットを削除した場合
- 予想： スナップショットが存在しないので処理は実行されない
- スナップショットが2つ（2世代）の状況で、最新のスナップショットを削除した場合
- 予想： 存在している最新として初回に取得したスナップショットからリストアされる
スナップショットが１つ（1世代）の状況で、そのスナップショットを削除した場合
以下のような EC2 を作成しました。
- インスタンス ID: i-0823b187e2817459b
- EBS
- ルートボリューム（ /dev/xvda ）: vol-0e8974281f9d5dfac
- ボリューム（ /dev/sdb ）: vol-0615127a0f2766f0e
- スナップショット
- ルートボリューム: snap-0f8b79580e045a873
先ほど作成したスナップショットを削除します
この状況で、先ほどと同じ方法で Automation を実行します。4つ目の処理が終了すると以降の処理が「保留中」のままとなっています。
最後に終了したステップを確認すると入力パラメータに NoSnapshotFound と表示されています。
つまり取得したスナップショットを削除したことで、スナップショットがない状況となっているので処理は実行されないという予想と同じ結果が得られました。いやいやそれは普通でしょ？と思われる方が多いと思います。
ですが Automation 自体は成功となるため、スナップショットが未取得であることやスナップショットを整理し削除したことを失念していると、実行したのにリストアがされない状況が起こり得ます。普段であればすぐ気付く内容であっても、障害対応時の緊迫した状況では見落としてしまう可能性もあるので、事前に把握し wiki に記載するなどして明記するとリスクを軽減することが出来ます。
スナップショットが2つ（2世代）の状況で、最新のスナップショットを削除した場合
以下のような EC2 を作成しました。
- インスタンス ID: i-0823b187e2817459b
- EBS
- ルートボリューム（ /dev/xvda ）: vol-0e8974281f9d5dfac
- ボリューム（ /dev/sdb ）: vol-0615127a0f2766f0e
- スナップショット
- ルートボリューム（初回）: snap-01e782ed8614469ff
- ルートボリューム（2回目）: snap-0c45d718f484b96f4
2回目に作成したスナップショットを削除します
この状況で、先ほどと同じ方法で Automation を実行します。最後まで処理が成功しました。
先ほど取得したスナップショットから新しい EBS ボリュームが作成されています。
インスタンスにアタッチされているルートボリュームが先ほど確認した EBS ボリュームに変更となっています
こちらも予想通りの結果を得ることが出来ました！
さいごに
今回、公式ドキュメントで良さそうなサンプル SSM ドキュメントを見かけたため紹介したく取り上げました。実際に障害対応を実施している時は平常時より注意を向けるべきものも多く視野は狭くなりがちです。また頻繁には実施しない作業が多いためミスは起こり得ます。そのため、こういったいざという時のために利用できる内容をランブックとして準備・整備しておくことは非常に重要な運用タスクではないかと個人的には思います。
