DB Replicationパターン
オンラインDBの複製
目次[非表示] |
解決したい課題
システムにとって重要なデータを守る基本的な方法はデータベースに格納すること。さらに最近ではデータベースのレプリケーション機能を使うことも増えている。 レプリケーションは比較的よく行われるが、従来はコストの関係上、一つのデータセンター内に閉じることが多かった。 しかしながら東日本大震災のような大規模な災害が現実に起こり、データセンターごと損傷を受けるケースを想定しなければならない。
クラウドでの解決/パターンの説明
地理的ロケーションをまたいだレプリケーションを行うパターン。このパターンによりデータロストを防ぎ、データアクセスの可用性を担保する。 クラウド以前からもあったパターンであるが、クラウドを用いることで安価に複数の地理的ロケーションを利用できるようになり、現実的な選択肢となった。
実装
AWSには「リージョン」「アベイラビリティーゾーン（AZ）」という考え方がある。リージョンの方が広い概念で、東京リージョンに複数のAZがあるという関係である。 この点を考慮すれば、異なるデータセンターに透過的にEC2を配置でき、データベースのレプリケーションを行うことができる。 AZ間のレプリケーションは、RDSのMulti-AZを利用すると容易に実現できる。もちろん、EC2にデータベースをインストールして実現しても良い。
- 2台のEC2を地理的ロケーションの異なるAZに配置する。
- それぞれのEC2にRDBMSをインストールし、レプリケーション設定を行う。
- AZ間のレプリケーションは、RDSのMulti-AZを利用することで容易に実現できる。またRDS for Auroraでは、３つのアベイラビリティーゾーンに６個のレプリケーションが作成されるため、高い耐障害性を実現することができる。
構造
利点
- 災害や障害が発生しても、データをロストすることなく業務を継続できる。
- DBにパッチを適用する際、レプリケーションしているデータベースにアクセス先を切り替えることでシステムを止めなくてもよくなる。
注意点
- マスターDBで障害が起きた際に、スレーブにフェイルオーバーできるが、フェイルオーバーに必要なダウンタイムに注意する。
その他
- ディザスターリカバリーを目的とする場合は、地理的に大きく離れた場所（別リージョン）のDBに対してレプリケーション設定を行う。
- 別リージョンのデータベースへレプリケーションを行う場合、同期型のレプリケーションを使用するとパフォーマンスが低下するケースがある。その場合、非同期レプリケーションや定期的なレプリケーションを検討する。
関連ブログ