こんにちは、hacknoteのohnoです。
AWSのRDSを作る際、「DB 詳細の指定」の中にマルチ AZ 配置という項目があります。
今回はこちらに関して説明して、実際にRDSのマルチ AZ 配置を行ってみます。
マルチAZについて
同じリージョン内でもアベイラビリティゾーンが複数存在しています。これらは自然災害やデータセンター単位の障害などビジネスに影響を与えるリスクを最小化するよう地理的に影響を受けない十分離れた場所にあります
アベイラビリティゾーンが違う＝別のデータセンターへ置くことで、もしそのデータセンターが災害で壊れた場合でも、他のデータセンターで運用が可能です。
このように配置したものをMulti-AZ構成と呼び、災害などに備える事が可能です。
また、災害が発生していなくても、メンテナンスやバックアップ時にメリットがあります。
RDSのマルチAZ構成を実際につくってみる。
マルチAZに関してのメリットを説明しましたが、ここから実際の構築方法を説明し、動作確認まで行います。
今回はRDSのみのマルチAZ構成の構築します。
構成は上のようになります。実際に運用するのであれば、EC2インスタンスもゾーンを跨いだほうがいいですが、RDSの説明のため今回は上記の構成を作ります。
基本的には通常のRDSの作成と同じように作成をしていき、
ここの「別ゾーンにレプリカを作成します」にチェックを入れます。以上です。
この機能は複雑な設定はなく、これで完了してマルチAZ配置が可能です。
設定して配置した場合には詳細画面から、項目が確認できます。
アベイラビリティーゾーン
ap-northeast-1a
こちらがマスターとして動くRDSが配置されているゾーンです。スレーブ側は
セカンダリゾーン
ap-northeast-1c
と書かれていますので、ゾーンCで動作中のようです。
サーバー側は普通のRDSと同じくエンドポイントを参照させれば問題ありません。
フェイルオーバーが発生中でもエンドポイントは変わりませんので、サーバー側へなにかする必要がないのです。
フェイルオーバー動作確認
有効になっているか、試しにフェイルオーバーを発生させて動作を確認してみます。
フェイルオーバーは壊れた場合以外に、スペックアップなどを行った場合も、バックアップ側からスペックアップを行い、フェイルオーバーさせるのでこちらを利用してみます。
まずはスペックアップ直後
変更中の保存へt2.smallが入りました。暫く待つと、ログに以下出力と共に、画面が変化します。
Fri Aug 10 14:37:28 GMT+900 2018 Multi-AZ instance failover completed Fri Aug 10 14:36:52 GMT+900 2018 DB instance restarted Fri Aug 10 14:36:48 GMT+900 2018 Multi-AZ instance failover started Fri Aug 10 14:35:47 GMT+900 2018 DB instance shutdown
アベイラビリティゾーンが切り替わりました。スペックアップの完了したスレーブ側がマスターへと昇格し、
保留中の変更にまだt2.smallがあることから今度は元マスターのスペックアップが行われているものと思われます。ここから更に暫く待つと
アベイラビリティゾーンがそのままの状態で保留中の変更がなくなりました。完了後、フェイルバックは自動でせず、元々からマスターとスレーブは変更されたままで動作します。
構成を元に戻したい場合には再起動することで可能です。
待機系から戻す場合もフェイルバックコマンドが有るわけではなく、再度フェイルオーバーさせて戻します。
元の構成に戻りました。
これで、よっぽどの災害、東京マグニチュード8.0やゴジラが来ない限りDBは大丈夫でしょう。
東京リージョン全崩壊が起きたケースまで考えるのであれば、リードレプリカなどで別リージョンへ置くことになります。
リードレプリカを用いてAmazon RDSをレプリケーション
おまけ
アベイラビリティゾーンがwebサーバーと異なる場合、別データセンターとの通信となるためレイテンシが大きくなります。
速度重視の場合には気にしておいたほうがいいでしょう。
webサーバーと異なるアベイラビリティゾーンに置いた(Multi-AZ利用)RDSの速度検証
また、アカウントが異なる場合にはアベイラビリティゾーンは分散のため、同じ名前だとしてもアカウントごとに別の場所に置かれる可能性があります。
アベイラビリティーゾーンは各 AWS アカウントの名前に個別にマップされます。たとえば、ご使用の AWS アカウントのアベイラビリティーゾーン us-east-1a は別の AWS アカウントのアベイラビリティーゾーン us-east-1a と同じ場所にはない可能性があります。
