元オンプレエンジニアがAWSを使ってみた(RDS高可用性編)

リードレプリカは読み取り専用のレプリカDBを構築できる機能です。こちらもクリックだけで構築できます。

MySQL、MariaDB、PostgreSQLで利用可能です。Auroraはディスクレベルで複数のレプリカが構成されるのが標準なのでリードレプリカを意識して構築する必要はありません。

更新はマスタにのみ行い、読み込みはリードレプリカに対してアクセスすることで負荷分散、スケールアウトを図ることができます。

レプリカは最大５つまで作成可能で、さらにレプリカのレプリカを作ることもできます。

なお、リードレプリカへのレプリケーションは非同期のため、マスタとレプリカ間のタイムラグを考慮したアプリケーション構築が必要です。

また、レプリカをマスタに昇格させることや、リージョンまたぎ（例えばAWSの東京リージョンとオレゴンリージョン）のレプリケーションも可能で被災時業務継続にも利用可能です。

レプリカ機能はオンプレのDBでも機能はあります。しかし構成や管理が大変だったり、追加のパッケージが必要だったり、なかなか手間がかかりますが、RDSなら簡単に構成することができます。

自動スナップショットとPoint-in-Timeリカバリ

RDSでは標準で１日１回スナップショットが自動で取得されます。

特定時刻までのリカバリ機能であるPoint-in-Timeリカバリも提供されています。

５分前以前の任意のタイミングまでDBを巻き戻すことができます。この機能もマネジメントコンソールから利用可能です。リストアファイルを選んで、適用するアーカイブログを決めて、といった作業は不要で、時間を指定すればその時点に戻すことができます。

今回はRDSにおける高可用性の実現方法について見ていきました。

マルチ構成、自動リカバリ、読み取り専用レプリカがマネージドサービスとして提供され、簡単に実現できることがお分かりいただけたかと思います。

オンプレでもこれらの機能は利用できますが、構成が大変だったり、複雑な構成ゆえにトラブルの原因となったりしましたが、RDSだと手軽に構築することができます。

AWSを知れば知るほどシステムを手軽に構築できすぎるという驚きがある一方、インフラエンジニアの食い扶持が減らされている気もして複雑な気分です。

引き続き、次回も元オンプレエンジニアシリーズ RDS編をお届けします。

次回はRDSでのRDBMSに付属するユーティリティに利用について取り上げます。

お楽しみに！