Multi-AZの役割

前回の記事でMulti-AZについてふれましたが、その続きです。

今回は自分の整理のために、Multi-AZが設定されている場合と無い場合で 障害が起こった際にどういった復旧手順の違いがでてくるか考察します。

Multi-AZを設定していない場合

Multi-AZが設定されてないので、一つのAZにのみMaster RDB 1台がある想定です。またその下に２つReadReplicaが並んでいます。 MasterとReadReplicaが1:1だと、ReadReplicaにそこそこ参照系のクエリが飛んでいて、ReadReplicaが落ちた場合に 全てのクエリがMaster 1台に飛んでしまい、Masterも道連れで落ちてしまうため可能性がでるため、ReadReplicaは2台という想定にしています。

ここでMasterのRDSインスタンスの障害で、参照も更新もできない状態になってしまったとします。 ここからの復旧作業だと、おそらく次の手順をする必要があるのかなと思います。

1. メンテナンスにいれる
2. ReadReplicaをMasterに昇格させる
3. Masterから新しいReadReplicaを作成する
4. DBの状態が最新かbinログ?をみて確認する
5. 問題なければメンテナンスを空ける

みたいな手順になるかなとおもいます。 実際にそんな障害にあったことないので、正確な手順としては色々かけてそうですが、だいたいこんな感じのことをするのかなという想像。

Multi-AZを設定していた場合

Multi-AZが設定されていると次のような図になると思います。

設定していない場合との違いは、別のAZにMasterのDBの複製を常に作っています。 もしこの状態で、今のAZまたはRDSインスタンスに障害が起こった場合に、自動的に別のAZにスタンバイしているインスタンスにフェイルオーバーします。 公式ドキュメントによると 1～2 分間完了するらしいです。 また同じRegionにあり、endpointが変わらないのでApp側のRDSの接続設定とか書き換えないでそのまま使えるます。 フェイルオーバー完了までにかかった時間 = ダウンタイムと考えると、Multi-AZを設定していない場合と比較してかなりはやく復旧できそうです。 手順でいうと

1. 自動フェイルオーバー
2. ReadReplica作成

ぐらいで、こちらでするのはReadReplicaを作成し直す作業かな。

以上がMulti-AZを設定していない場合としていた場合の大きな違いになると思います。 ただMulti-AZ配置にするとやっぱり２つインスタンス立ててる状態になるので、料金も高かった。 費用対効果を考えて、使うかどうか判断しないとですね。

記事を書くにあたって色々調べつつ、他の方に聴きつつまとめました。 自分の理解が及んでいなく、間違っている部分が多々あるかもしれません。 間違いなどありましたら、ご指摘いただけますと幸いです。