導入
AuroraやRDSの設計・運用をしているとメンテナンスウィンドウという設定項目を一度は目にすると思います。一方で実案件ではこのメンテナンスウィンドウに対して、危うい認識が持たれているケースがありました。
実際にある案件であったのが、「メンテナンスウィンドウを定めなければ、メンテナンス自体は実行されない」という認識です。上記のような話は利用している製品のバージョンを塩漬けにしたい案件などでよく見られる光景だと思います。
しかしながら、これは明確な誤解になります。メンテナンスウィンドウを設定しない場合でも、AuroraやRDSのメンテナンスは実行されることになります。しかも、その実行タイミングはメンテナンスウィンドウを定めない場合、AWSが定めている任意の時間帯で実行されるようになります。
本記事ではメンテナンスウィンドウに関わる内容を整理していきます。
メンテナンスウィンドウとは
AuroraやRDSにおけるメンテナンスウィンドウは、AWSが計画メンテナンスを実行してよい時間帯をユーザ側で指定するための設定になります。
このメンテナンスウィンドウの間では以下の内容が、必要に応じて実施されます。
- OSやハイパーバイザの更新
- データベースエンジンのパッチ適用
- ストレージ関連のメンテナンス
- フェイルオーバーを伴う更新
実施される時間帯について、公式ドキュメントでは以下に記載があります。
例えば、明示的にメンテナンスウィンドウを設けない場合、東京リージョンであれば22:00 ~ 6:00の時間帯の中から、任意の30分間で実行される可能性があるとの記載があります。
メンテナンスウィンドウを明示的に定める必要性
メンテナンス実施時については公式ドキュメントによると以下の記載があります。
メンテナンスの適用中は、RDS で DB インスタンスのリソースの一部が使用されます。
わずかながらパフォーマンスに影響が出る場合があります。
DB インスタンスでは、まれに、メンテナンスによるアップデートを完了するために
マルチ AZ フェイルオーバーが必要になる場合があります。
— Amazon RDS ユーザーガイド
再起動を伴わないにしろ、性能劣化はあり得ると考えておくのが良いでしょう。
例えば、夜間にバッチ処理が動作するようなシステムでは、一見すると業務時間外であってもDBに対して夜間に負荷がかかるケースも存在します。
このような状況下でメンテナンスが実行された場合、バッチ処理の遅延など業務影響に直結する事象が発生することも考えられます。
そのため、業務時間外の性能劣化についても厳しい要件を持っているシステムを担当される際には、メンテナンスが実施される時間帯や影響について、事前に顧客と合意しておくことが重要です。
Aurora利用時のメンテナンスウィンドウの設定で気をつけること
Aurora利用時はさらに注意すべきことが増えてきます。
Auroraの場合メンテナンスウィンドウをクラスター側、インスタンス側の両方で別々に定める必要があります。
全てデフォルトで作成したい場合、以下のようになっています。
クラスター側のメンテナンスウィンドウ
ライターインスタンス側のメンテナンスウィンドウ
リーダーインスタンス側のメンテナンスウィンドウ
全て異なる時間帯でメンテナンスウィンドウが設定されていることがわかります。
そのため、どちらか一方だけを確認していると想定外の時間帯にメンテナンスが実行される場合もありえます。
メンテナンスの影響範囲が異なるので、当然のことなのですが意外と抜け落ちる可能性があるので必ずチェックしましょう。
終わりに
今回はメンテナンスウィンドウの話を書きました。
こうした設定値周りの落とし穴や考慮漏れは、誰かが意図的に見落としているというわけではなく、単に気づかれていないだけというケースが多い印象です。
しかし、こうした小さな見落としが後々運用トラブルや業務影響として顕在化し、別の誰かが対応に追われることも珍しくありません。
設計やレビューの段階で今すぐ問題にならなそうな点であっても将来的なリスク考慮も含めて丁寧に潰しておくことが重要だと思っています。
本記事がそうした気づきにくい地雷を取り除くきっかけになれば幸いです。