障害発生時、Single-AZ構成のDBインスタンスを簡単に手早く復旧したい

こんにちは。暑い日が続くし台風までやって来そうですね。 快適な環境で脱ひよっ子を目指し日々精進しておりますAWS事業本部のしろたです。 頭もお尻もまだまだ殻付きです。ピヨ。

それにしても、パフォーマンスが高まる頃合いで業務が出来るクラスメソッドって会社は凄いなぁ！ この夏は何でも、めっちゃ速さを感じられる説明会とかやってるんだって？ やっぱりスピード感に定評のある(私調査)会社はやる事が違いますね！風を感じる！

さて。ダイレクトマーケティングも済みましたところで、本題に入りたいと思います。

DBをなるたけ簡単に、手早く復旧したい

安く・早く・手軽に……全てを実現するのは非常に難しい事です。 自分が重きを置くポイントをしっかりと定め、より良い環境を構築しようとすれば、自ずと有用な環境というものは構築されていくものではないかと思います。 ただ、世の中どんなに頑張っても不慮の事態が避けられないものです。 可用性を求めたり(RDSならMulti-AZ構成などが正にそれですよね)、様々な水際対策を考えておく事は可能でしょう。

ただ、今回考えていきたいのはSingle-AZ構成のDBインスタンスに障害が発生した時。 起こってしまった事は仕方ありません。 問題は、ここから「いかに早く・簡単に現状復帰できるか」という事ではないでしょうか。

▲これは現状復帰のイメージです。現状復帰は分かり易く、楽で早く出来るのに越した事はないですよね

今回の想定環境

• Single-AZ構成のSQL Server Express Edition
• 1日1回、任意の時間にスナップショットを自動作成(7日間保存可能)
• インスタンスタイプはdb.t2.micro
• ストレージは汎用SSDで20GiB

所謂、無料使用枠で作成できる範疇になるべく納めたSQL Serverと言った設計です。 RDSでDBインスタンスを立てた事はあるけどリストアはした事が無い……という方も、良かったらこの記事を読みながら一緒に手を動かしてみて下さい。

今回重点を置いたこと

簡単にやる

• AWSコンソール上(GUIベース)で作業を完結させたい

早くやる

• 障害発生時と言う前提の元で迅速に出来得る限りの現状復帰をしたい
• ダウンタイム発生は許容する。その上で待ち時間発生頻度を減らす

早く本題に入りたいのでサクッと環境を構築する

障害が起きたよ！って仮定のDBインスタンスが無いとそもそもお話になりませんよね。 サクッと立ててみましょう。AWSコンソールを使えば、数ポチ数カタカタでDBインスタンスが作れます。 また、サクッと立てたら今度はサクッとスナップショットを取っておきましょう。 こういう時に、今回の本題では無いVPCやサブネットなどから構築しないとならないのは若干手間が掛かります。 そう感じ、現在は鋭意CloudFormationの勉強中です。 幸い、弊社のブログにはCloudFormation関連の記事が沢山あるので、資料探しの時間は大分短縮出来そうです。 濱田さんのこの記事、実は入社前から目を付けていたのでこの機に読み込んで手を動かしてみたいと思っております。

環境が整ったところで、本題に

さて。今回のようなDBインスタンスを復旧するに当たってやるべき事を箇条書きに整理してみました。

• 障害発生前の中でより最新の自動スナップショットからDBインスタンスを復元する
• 復元したものが元のDBインスタンスと差異が無いことを確認する
• 確認が取れたら障害が発生した元DBインスタンスを削除・復元したDBインスタンスを使用する

この際に、気を付けるポイントが数点あります。

同じ名前のDBインスタンスが共存する状態は作れない

DBインスタンス識別子の値は、EC2と接続する為のエンドポイントのprefixを兼ねています。 分かり易く説明すると、「DBインスタンスに付けた名前でDBインスタンスを見分けているから、同一の名前が存在する事はご法度」といった所でしょうか。 つまり、ここで考えられる手段は

1. A(障害発生中のDBインスタンス)をリネームしてA'に
2. B(リストアしたDBインスタンス)をリネームしてAに
3. A'を削除

とか、

1. A(障害発生中のDBインスタンス)を削除
2. B(リストアしたDBインスタンス)をリネームしてAに

といったものがあるのでは無いでしょうか。 今回、私は後者の手段を取ってDBインスタンスの復旧をする事にしました。 理由は、

• 作業手順自体が少ない事(ヒューマンエラーのリスクが低い)
• リネームする度にダウンタイムが生じるので、リネーム回数が少ない方を選びたい

この二点で選びました。 上の方法だと、切り戻しが楽になったりするのが利点ですが、今回は削除するDBインスタンスの最終スナップショットを取る事でその辺りをリカバリーして行く事に致しました。 他に気を付けた点は、

インスタンスを復旧する時点では設定出来ないものがある

基本的には、復元に用いるスナップショットからDBインスタンスへは殆どの情報が踏襲されます。 新規に入力・選択し直ししたものと言えば、

• DBインスタンス識別子
• アベイラビリティーゾーン(サブネットグループ・パブリックアクセシビリティはここから紐付いて入力された)

この二つくらいでした。 この際に、踏襲もされず設定も出来なかった項目が一箇所ありました。 それが、セキュリティグループです。 踏襲されなかった設定はどうするのか？ インスタンス一覧から復元したDBインスタンスの名前のリンクをクリックしてみましょう。 そのまま下にスクロールしていくと……[詳細]と言う、先ほど復元の際に設定したものやスナップショットから踏襲した設定事項が見られるページが出てきます。 そこの右上に、[変更]と言うボタンがあります。 そこから、詳細欄に載っている項目を変更する事が出来ますので、ここでセキュリティグループの設定をしちゃいましょう。 私がAWSの存在すら知らなかった昔は、後から変更出来なかった項目も多かったみたいですね。 日進月歩、すごい早さで便利になっていくこの時代に感謝しなければいけません。

度々待ち時間が発生する

設定内容を切り替える際に、今回のような障害時の復旧作業を想定している場合では、定期メンテナンスと違い変更を[すぐに適用]するのでは無いかと思います。 その際、どうしても発生してしまうダウンタイム等に依る待ち時間。 既に障害が発生している事からダウンタイムを全く発生させない事は不可能なのですが、

1. DBインスタンスをリストア(スナップショットからの復元)
2. B(リストアしたDBインスタンス)にセキュリティグループの設定変更を適用
3. A(障害発生中のDBインスタンス)を削除
4. B(リストアしたDBインスタンス)をリネームしてAに

ざっと数えてみても、復旧作業が完了するまでに4回は「待ち」になるタイミングがありました。 逆に言えば、これだけは最低でも待ち時間が発生してしまう事を意識して復旧作業に臨めば、「こんなに待つ事になるの？大丈夫？」と焦る事は無くなるのではないでしょうか。

復旧できるようになったところでおさらい

さて、最後に今までの話を総括しておきます。

• 最新の自動スナップショットからDBインスタンスを復元する
• 殆どの設定はスナップショットから踏襲されるが、そうでない項目の設定を忘れない(復元時に入力・編集するものと復元後の詳細変更から選択するものと)
• DBインスタンスを識別する為に使われるのがDBインスタンス識別子。一対一対応の存在
• 待ち時間が度々発生するが、障害DBインスタンスと同じ設定のインスタンスが立ち上げられたら、障害データベースを削除→復元したデータベースをリネームと進めると待ち時間発生箇所が少ない

可用性が良くなり、障害発生率も少なくなっていくこの時代ですが、いざと言う時の対応を知っておくに越した事はありません。 これらを意識して、Single-AZ構成のDBインスタンスに障害発生した時に対応すると、少し気持ちが穏やかになれるのではないでしょうか。