AMI を作成する=バックアップをとる、ではないのかもしれない
バックアップ大事です。リストア確認も大事です。那須です。
結構時間がたってしまいましたが、Amazon Data Lifecycle Manager (Amazon DLM) が出てきましたね。 docs.aws.amazon.com
EBS スナップショット作成をスケジューリングしたり世代管理したりできるようになっています。 ここで皆さん思ったはずです。なんで AMI は対象外なのか? 同じバックアップなので簡単にできるんじゃないの? 案外すぐに AMI も対応するんじゃないの? つーか東京リージョンに来てくれ!
私も実際そう思いました。
でもふと立ち止まってちょっとドキュメントをいろいろ読み返してみたんです。そしたら気づいたんです。AWS さんはそもそも AMI をバックアップとは見ていないんじゃないかって。
定期的に Amazon EBS スナップショットを使用して EBS ボリュームをバックアップし、インスタンスから Amazon Machine Image (AMI) を作成して、それ以降にインスタンスを起動するためのテンプレートとして設定を保存します。
スナップショットは明確にバックアップ用途と書いてるけど、AMI はあくまでテンプレート扱いでどのページにもバックアップとしての記載がないんですよね(どこかにはあるのかな?見つけられてないだけで
というわけで、あえて運用中の EC2 インスタンスから AMI を作成せずにスナップショットだけでバックアップ&リストア対応できるかどうかやってみました!
とりあえずリストア
既にスナップショットでバックアップはとってあるものとして話を進めます。下の画像の test が運用中の EC2 インスタンス (Windows Server 2016) のイメージです。test のルートボリュームで障害が発生したので、test1 として新規に AWS さんから公開されている Windows Server の AMI からリストアするイメージで EC2 インスタンス (Windows Server 2012) を起動しました。本来は同じ OS のはずですが、わかりやすく見せるためにあえて OS バージョンを変えてます。
RDP で確認しました。確かに Windows Server 2012 です。id も i-0d630f0bbf6b5a05b です。
リカバリ開始
ではここからリカバリしていきます。まず、リストアした EC2 インスタンスを停止します。
ステータスが stopped になりましたね。
バックアップとして作成していたルートボリュームのスナップショットから EBS ボリュームを作成します。これで準備は OK です。
では、リカバリしていきましょう。リストアした test1 のインスタンスからルートボリュームをデタッチします。
先ほど作成した EBS ボリュームを test1 のインスタンスにアタッチします。
デバイスは、もともとのデバイス名である /dev/sda1 を指定します。
test1 のインスタンスのルートデバイスとして今アタッチした EBS ボリュームの id が見えてます。
そして test1 のインスタンスを起動します。
はい、起動しましたね。
RDP で確認してみましょう。インスタンス ID は間違いなく test1 のもの、でも OS バージョンが Windows Server 2016 になってますね。自分たちで AMI を作成しなくても Windows Server の EC2 インスタンスを復旧できました。ひとまず EBS スナップショットだけでバックアップ&リストア運用はできそうです。
あとはスクリプト化が必要かな
この流れを手作業でやってもいいんですが、オペミスや作業時間の長期化を避けるためにも aws cli 等で簡単に自動化しておくのが現実的だと思います。管理コンソールは画面が変わることがあるので、そのたびに手順書の画像を変えるのも大変でしょうし。 Systems Manager だけでなんとかできそうな気もしますね。
この手順が使えることを検証で確認できれば、Amazon DLM が東京リージョンにやってきた際にすぐにバックアップ運用に取り入れることができますね。
これからは AWS サービスの用途とか背景を想像してみる
AMI ≠ バックアップ という前提があってるかどうかはさておき、AMI はバックアップだ!という前提を疑うことでバックアップ&リストア運用の手段が増えたのが今回の収穫でした。 他にもこんなことがあるのかどうかわかりませんが、これからも考えを巡らせるクセはつけようと思います。