RDSを使ったシステム開発をする際、
「パッチ適用ってどうするんだろう？」って気になりますよね。
RDSはAWSのマネージドサービスなので、
「AWSの方でRDSを止めずに、裏でいい感じにやってくれているだろう」
と、タカをくくる方がいらっしゃいますが、そう安直に考えてしまうと結構痛い目をみることがあります。
RDSは確かにマネージドサービスです。
なので、メンテナンスもAWSの方でやってくれます。
ただし、RDSを強制的に停止（またはフェイルオーバー）して行うパッチ適用も中にはあります。
今回はRDSのパッチ適用はどのような仕組みとなっているのか解説していきます。
RDSのメンテナンスとは？
RDSの”メンテナンス”と一口に言っても、メンテナンスには以下のように様々な種類があります。
- OS等の修正プログラム（パッチ）の適用
- データベースエンジンのバージョンアップ（メジャーバージョン、マイナーバージョン）
- インスタンスタイプの変更
- パラメタグループの変更
インスタンスタイプやパラメタグループの変更等は利用者起因によってなされるメンテナンスになりますので、ハンドリングがしやすいですが、パッチ適用については、AWS起因となりますので、中にはハンドリングできないものもあります。
RDSにおけるパッチ適用の優先度
RDSのパッチ適用には、優先度が異なる2種類のパッチがあります。
- Available(利用可能)
- Required(必須)
1は、「適用できるパッチがあるよ」程度の優先度がそこまで高くないパッチです。
即座に適用してもいいですし、最悪、無期限に延期することも可能です。
2については、セキュリティ上の問題などにより、絶対適用しなくてはならないパッチとなります。
2は、基本的にはメンテナンスウインドウ(※)中に行われるものですが、
中にはメンテナンスウインドウ内で行われないパッチ適用もあります。
これが上記で述べた「ハンドリングできないパッチ適用」というやつです。
※メンテナンスウィンドウについては下記で説明します
以下、AWS公式ドキュメント「DB インスタンスのメンテナンス」からの引用となります。
セキュリティやインスタンスの信頼性に関連するパッチのみ、必須のパッチ適用として自動的にスケジューリングされます。このようなパッチは頻繁に発生するものではありません (通常数ヵ月ごとに一度です)。またお客様のメンテナンスウィンドウのごく一部以外を使用する必要があることは稀なはずです。
ちょっと日本語訳がイケてないですが、上記引用の強調部分の通り、必須のパッチ適用の場合は、稀ではあるがメンテナンスウィンドウ以外も使うことがあるよ、と記載されています。
メンテナンスウィンドウとは？
さて、上記でさんざん触れたメンテナンスウィンドウについてご説明させていただきます。
メンテナンスウィンドウとは、毎週決まった時間帯（最小30分〜最長12時間）をメンテナンス時間として設定するスケジュール枠です。
もちろんメンテナンスがなければ、メンテナンスウィンドウが使われることはありませんが、
パッチ適用などのメンテナンスがあれば、このメンテナンスウィンドウ枠で行われるため、最悪サービスが停止してもリスクの少ない時間帯を設定するのが重要です。
注意しなくてはならないのが、
最小時間30分と設定したら、必ず30分以内でメンテナンスが終わるのかというとそうではありません。
AWS公式ドキュメントにもある通り、その設定した時間枠はあくまでも目安のようなものであり、メンテナンスをこの時間内で必ず終わらせる、というような強制力はありません。
以下、AWS公式ドキュメント「DB インスタンスのメンテナンス」からの引用となります。
メンテナンス時間は、保留中のオペレーションを開始する時刻を指定しますが、オペレーションの合計所要時間は制限されません。メンテナンスオペレーションは、メンテナンスウィンドウが終了するまでに完了するかどうかは保証されておらず、指定終了時間を超える場合もあります。
メンテナンスウィンドウでダウンタイムを最小限にする方法
メンテナンスウィンドウを30分と指定したとしても30分を越える場合もあり、そもそもメンテナンスウィンドウ自体が使われないケースもある、そんないつ起こるかわからないパッチ適用があると、実サービスでは使いづらいと思われるかもしれません。
ここで打てる手立てとしては２つあります。
- EC2でデータベースを構築する
- マルチAZ（クラスタ構成）にしてダウンタイムを最小限にする
1については言うまでもありません。
そんなリスクが高いRDSは使わずにEC2で自らデータベースを構築してしまえばいいんです。
AWSの人もそのようにアナウンスされております。
で、2について。
これはどういうことかというと、
RDSインスタンスを２台に冗長化することで、稼働していないRDSをメンテナンスし、フェイルオーバーして稼働メインで稼働するサーバーを切り替えて、もう片方のサーバをメンテナンスするという方法です。
こうすることで、メンテナンスによってダウンする時間はフェイルオーバー時の1,2分ということになります。
RDSを極力止めたくないという場合は、このマルチAZ化がオススメです。
※AWS公式ホームページでも同様のことが述べられています。
参照先：必要な Amazon RDS のメンテナンス中にダウンタイムを最小化するにはどうすればよいですか?
いかがでしたでしょうか？
メンテナンスはリリース後のことだし、開発中はあまり目が向かいことではありますが、
開発時においても非常に重要な設計ポイントの一つです。
地味な部分ではありますが、重要なことですのでしっかりと押さえておきましょう。
以上、hidesanでした！