はじめに
最近、Auroraのメンテナンスや再起動の挙動を意識することがあったので違いをまとめていきます。
1.MultiAZ構成の基本（おさらい）
まずは、MultiAZ構成をとった場合の障害時の挙動をおさらいとして記載します。
RDSの場合
これは、言わずもがなですが、Primary、Secondaryの２台構成で通常時は同期処理が行われており、障害が発生した場合は、Secondaryへの切り替えが発生します。DNSのエンドポイントの切り替えが発生するため、３０秒程度のダウンタイムがあります。
Auroraの場合
こちらもほぼ同様ですね。
Auroraの場合、ストレージがAZをまたいだクラスタ構成になっており、書き込みが可能なライターインスタンスと、読み込み専用のリーダーインスタンスで構成されます。（リーダーは複数構成可能だったり、GlobaｌDatabaseなどの構成もありますが、今回は割愛します。）
障害が発生すると、リーダーインスタンスがライターインスタンスへ昇格します。こちらもDNSのエンドポイントの切り替えが発生するため、３０秒程度のダウンタイムが発生します。
2.メンテナンス時の挙動
パッチ適用や設定変更等を実施した場合の挙動を記載します。
※メンテナンス内容によっては下記に示すフェールオーバーが使用できないケースもあります。（DB エンジンのメンテナンス等、全台同時に実施されるようなものは不可）
https://aws.amazon.com/jp/blogs/news/amazon-rds-online-seminar-20211111/
RDSの場合
最初にSecondaryで変更、パッチ適用などが実施されます。その後フェールオーバーを実施し、旧Primary側で変更を実施、完了となります。
Auroraの場合
Auroraの場合も、クラスタ全体への変更が伴うような変更では、RDSのようなローリングアップデートは不可能です。
また、RDSのように自動的にフェールオーバーすることもないため注意が必要です。
まず、各種インスタンスに対して必要な変更を実施します。その後、最初にリーダーインスタンスを再起動します。
リーダーインスタンスの再起動完了後、手動でのフェールオーバーを実施します。
その後ライターインスタンスで再起動を実施し完了となります。
この順番や手順を間違えると、ライターインスタンスの再起動が発生してしまうため、ダウンタイムが長時間となる可能性があります。このあたり、Auroraのほうがちょっと気を使いますね。
３.再起動時の挙動
RDSの場合
２．メンテナンス時の挙動に記載したものと同様の動きです。※明確にフェールオーバーありを選択する必要があります。
Auroraの場合
Auroraの場合ライターインスタンスを再起動すると、自動でリーダーインスタンスが再起動します。
特にフェールオーバーは実施されないので、注意が必要です。
逆にリーダーインスタンスを再起動しても、ライターインスタンスは再起動されないため、この仕組を利用し、
最初にリーダーインスタンスを再起動、フェールオーバーを実施し、旧ライターインスタンスを再起動といった順番で実施するとダウンタイムが最小限となります。
Tips
Auroraにはゼロダウンタイムのパッチ適用の機能があります。対象のバージョンが限定されているので注意が必要なのと、必ず利用できるものではありませんが、１分程度のスループット低下でパッチ適用が可能という、すごい機能なので、是非活用してみるとよいかと思います。
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.PostgreSQL.html#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp
まとめ
RDSとAuroraのメンテナンスや挙動の違いって結構あるものだなぁと思いました。
運用時に気をつける必要が結構あるなぁと
参考