AWS RDSのメンテナンスをフェイルオーバーで対応する手順
AWSからRDSのメンテナンス通知で「RDSメンテナンス」のお知らせが届きました。それに伴いRDSでメンテナンス作業を行いました。
フェイルオーバーで対応する方法は、インスタンスタイプの変更する際にも使える方法です。
手順
- DBクラスタへリードレプリカを追加
- マスタ(書き込み)のDBインスタンスをフェイルオーバーしてリードレプリカをマスタへ昇格
クラスタでレプリケーションは Blue/Green Deployments で行うことができます。
関連記事：RDSのメンテナンスをフェイルオーバーで対応する手順
参考記事
RDSのメンテナンス対応の手順について
RDSのメンテナンス対応を行うときにDBを再起動する必要があります。
そのためシステムがDBに接続することができないダウンタイムが発生します。
ダウンタイムを「気にするか」「気にしないか」で大きく対応方法が変わってきます。
- ダウンタイムを気にしない場合
→Amazon RDS コンソールで変更して[すぐに適用] - ダウンタイムを気にする場合
→フェイルオーバーでリードレプリカをマスタへ切り替え
今回はダウンタイムを気にする場合の「フェイルオーバーでリードレプリカをマスタへ切り替えする手順」を紹介します。
フェイルオーバーでリードレプリカをマスタへ切り替えて対応※ダウンタイムを気にする場合
システム運営中の場合は、極力ダウンタイムを少ない時間で対応する必要があります。
こうしたダウンタイムを気にする場合の方法として「フェイルオーバを発生させてリードレプリカをマスタへ切り替えて対応」する手順を紹介します。
リードレプリカをクラスタへ追加する
まずはRDSのマネージメントコンソールを開きます。
(Amazon RDS コンソール：https://console.aws.amazon.com/rds/)
メンテナンス対象のDBクラスターを選択します。そして[アクション]の[リーダーの追加]を行います。
これでリードレプリカをDBクラスタへ追加されます。
インスタンスタイプの変更などは、上記で作成したリードレプリカに対して行っておきます。
マスタ(書き込み)のDBインスタンスをフェイルオーバーする
DBクラスタに紐づいているマスタ(書き込み)となっているDBインスタンスを選択します。そして[アクション]の[フェイルオーバー]を選択します。
これでフェイルオーバーを手動で発生させます。
注意ですが、フェイルオーバーすると数秒ダウンタイムが発生します。
数秒するとリードレプリカがマスタへ昇格して切り替わります。
不要になったらDBインスタンスを削除
ファイルオーバーが完了したらリードレプリカとなったDBインスタンスを削除します。
これで作業は完了となります。
フェイルオーバーで発生するダウンタイムについて
フェイルオーバーでリードレプリカをマスタへ昇格させて切り替える際にダウンタイムが発生します。
ダウンタイムは、大体30秒くらい発生します。
ちなみにDBインスタンスのデータ量によってダウンタイムの時間が変動するかと予想していましたが、あまり関係はしないようです。
AWSのヘルプで解説された記事
AWSのヘルプでもRDSメンテナンス時の対応方法について解説されていました。
Amazon Relational Database Service (Amazon RDS) DB インスタンスの 1 つにメンテナンスが必要であるというメンテナンス通知を受け取りました。ダウンタイムを最小限に抑えるにはどうすればいいですか?
■ハードウェアのメンテナンス
メンテナンスがスケジュールされる前に、スケジュールされたハードウェアメンテナンスウィンドウに関する E メール通知がユーザーに送付されます。これには、メンテナンスの時間と影響を受けるアベイラビリティーゾーンが記載されています。シングル AZ 配置は、ハードウェアのメンテナンス中に、数分間利用できなくなります。アベイラビリティーゾーンがメンテナンスの影響を受けている場合、インスタンスがフェイルオーバーするのにかかる時間 (通常は約 60 秒) の間、マルチ AZ 配置は利用できません。セカンダリアベイラビリティーゾーンのみが影響を受ける場合は、フェイルオーバーもダウンタイムもありません。
■OS のメンテナンス
次のメンテナンスウィンドウに OS のメンテナンスがスケジュールされたら、適切なメンテナンスウィンドウの調整を行うことでメンテナンスを延期することができます。メンテナンスは、Actions ドロップダウンから Defer Upgrade を選択して延期することも可能です。ダウンタイムを最小限に抑えるには、Amazon RDS DB インスタンスを変更して、マルチ AZ 配置にします。マルチ AZ 配置では、OS のメンテナンスが最初にセカンダリインスタンスに適用されます。次に、セカンダリインスタンスがフェイルオーバーして、その後プライマリインスタンスが更新されます。ダウンタイムはフェイルオーバー時に発生します。詳細については、「マルチ AZ 配置のメンテナンス」を参照してください。
■DB エンジンのメンテナンス
データベースエンジンレベルにアップグレードするには、ダウンタイムが必要です。RDS DB インスタンスがマルチ AZ 配置を使用している場合でも、プライマリ DB インスタンスとスタンバイ DB インスタンスの両方が同時にアップグレードされます。このため、アップグレードが完了するまでダウンタイムが発生することになります。ダウンタイムの長さは、DB インスタンスのサイズに応じて異なります。詳細については、「DB インスタンスのエンジンバージョンのアップグレード」にある、お使いの DB エンジンに関するセクションを参照してください。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/rds-required-maintenance/
RDSのメンテナンスについて
RDSのメンテナンスについては、AWSから通知メールが送られます。
Dear Amazon Aurora Customer,
(Amazon Auroraのお客様へ、)We are contacting you to inform you that one or more of your Amazon Aurora DB instances are scheduled to receive maintenance on the underlying hardware between 2022-03-18 07:00 UTC (Friday) and 2022-03-25 06:59 UTC (Friday). The exact time of the maintenance will be determined by the DB instance’s maintenance window.
(1つ以上のAmazonAuroraDBインスタンスが、2022-03-18 07:00 UTC（金曜日）から2022-03-25 06:59 UTC（金曜日）の間に基盤となるハードウェアのメンテナンスを受けるようにスケジュールされていることをお知らせします。メンテナンスの正確な時間は、DBインスタンスのメンテナンスウィンドウによって決定されます。)For clusters with a single instance, the cluster and the instance will be unavailable for a few minutes in the instance’s maintenance window.
(単一のインスタンスを持つクラスターの場合、クラスターとインスタンスは、インスタンスのメンテナンスウィンドウで数分間使用できなくなります。)省略
If you have any questions or concerns, contact AWS Premium Support.
https://aws.amazon.com/support
簡単にいうと「DBインスタンスのハードウェアメンテナンスを 2022年3月18日に行います。」という(今回は)内容でした。
メンテナンス種類
RDSのメンテナンスは3つあります。
- ハードウェアのメンテナンス
- OS のメンテナンス
- DB エンジンのメンテナンス
ハードウェアのメンテナンス
メンテナンスがスケジュールされる前に、スケジュールされたハードウェアメンテナンスウィンドウに関する E メール通知がユーザーに送付されます。これには、メンテナンスの時間と影響を受けるアベイラビリティーゾーンが記載されています。シングル AZ 配置は、ハードウェアのメンテナンス中に、数分間利用できなくなります。アベイラビリティーゾーンがメンテナンスの影響を受けている場合、インスタンスがフェイルオーバーするのにかかる時間 (通常は約 60 秒) の間、マルチ AZ 配置は利用できません。セカンダリアベイラビリティーゾーンのみが影響を受ける場合は、フェイルオーバーもダウンタイムもありません。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/rds-required-maintenance/
OS のメンテナンス
次のメンテナンスウィンドウに OS のメンテナンスがスケジュールされたら、適切なメンテナンスウィンドウの調整を行うことでメンテナンスを延期することができます。メンテナンスは、Actions ドロップダウンから Defer Upgrade を選択して延期することも可能です。ダウンタイムを最小限に抑えるには、Amazon RDS DB インスタンスを変更して、マルチ AZ 配置にします。マルチ AZ 配置では、OS のメンテナンスが最初にセカンダリインスタンスに適用されます。次に、セカンダリインスタンスがフェイルオーバーして、その後プライマリインスタンスが更新されます。ダウンタイムはフェイルオーバー時に発生します。詳細については、「マルチ AZ 配置のメンテナンス」を参照してください。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/rds-required-maintenance/
DB エンジンのメンテナンス
データベースエンジンレベルにアップグレードするには、ダウンタイムが必要です。RDS DB インスタンスがマルチ AZ 配置を使用している場合でも、プライマリ DB インスタンスとスタンバイ DB インスタンスの両方が同時にアップグレードされます。このため、アップグレードが完了するまでダウンタイムが発生することになります。ダウンタイムの長さは、DB インスタンスのサイズに応じて異なります。詳細については、「DB インスタンスのエンジンバージョンのアップグレード」にある、お使いの DB エンジンに関するセクションを参照してください。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/rds-required-maintenance/
RDSメンテナンス内容の確認方法
AWSマネージメントコンソールでメンテナンスの詳しい内容を確認することができます。
AWSマネージメントコンソールでRDSメンテナンスを確認する方法
画面上部にあるツールメニュのベル – 予定された変更をクリックします。
すると、RDSメンテナンスがスケジューリングされている日程や内容を(英語だけど)確認することができます。
RDSメンテナンスで何もしない場合
RDSメンテナンスがスケジューリングされた日程までにメンテナンス対応を行わないとスケジューリングされた日程でAWSが自動でメンテナンス対応が行われます。
そして再起動が自動で行われます。
つまりシステム運営ができない時間（ダウンタイム）が発生することになります。
再起動が自動でされたくない場合は、スケジューリングされた日程より前に手動でメンテナンス対応を行う必要があるということです。
まとめ
今回は定期的に発生するRDSのメンテナンスで行う対応方法について紹介しました。
フェイルオーバーの手順は、インスタンスタイプの変更やバージョンアップする際も利用できます。
運営中のシステムだとダウンタイムが発生しないようにしたいです。なんせ企業によっては売上に直結してしまったりするで。。。またトラブルが発生しにくい方法であることも重要です。
関連記事
Blue/Green Deployments でレプリケーション
クラスタ間でレプリケーションできる Blue/Greem Deployments の手順をまとめました。
https://uteee.com/system/8885/RDS SSL/TLS証明書をrds-ca-2015からrds-ca-2019へ更新
RDSのSSL/TLS証明書の更新をフェイルオーバーで対応しました。そのときのことをブログへ残しました。
Webプログラマ兼ブロガー | プログラミング基礎知識を発信｜Webプログラマ歴は10年以上｜JavaScript,PHP.HTML | 「人生の時間は有限。悪いことをしている時間はない」
→プロフィール