RDSをMulti-AZ構成で構築する

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をレプリケーション

ハックノートをフォローして
最新情報をチェックしよう

AWS構築サービスの全てをまとめた資料を公開中

ハックノート(TOWN株式会社)では、AWSの導入や構築支援を行っています。AWS導入メニューやサービス詳細、構成例や費用を掲載した資料をダウンロードできます。

AWSの新規導入やAWSへの移行を検討の際は、ぜひご参考ください。


APNコンサルティングパートナー

TOWN株式会社はAmazon公認コンサルティングパートナーです。