RDSやFSxなどAWSリソースで設定するメンテナンスウィンドウはメンテナンス開始の時間枠であってメンテナンス終了までを含めた時間枠ではない

RDSやFSxなどAWSリソースで設定するメンテナンスウィンドウはメンテナンス開始の時間枠であってメンテナンス終了までを含めた時間枠ではない

メンテナンスウィンドウを高IOが発生する処理の前やミッションクリティカルな処理が動作する前に配置することを避けよう
2026.02.28

RDSのメンテナンスウィンドウは30分で設定したのでメンテナンスは30分以内に終わるんだろう

こんにちは、のんピ(@non____97)です。

皆さんは「RDSのメンテナンスウィンドウは30分で設定したのでメンテナンスは30分以内に終わるんだろう」と思ったことはありますか?

それは危険です。必ずしもそうではありません。

すでにご存知の方も多いと思いますが紹介します。

メンテナンスウィンドウとは

メンテナンスウィンドウとはメンテナンス開始の時間枠です。メンテナンス終了までを含めた時間枠ではありません。

つまり、30分間のメンテナンスウィンドウを設定したとしても、30分以内にメンテナンスが完了するとは限りません。

RDSやRedshiftのメンテナンスウィンドウのドキュメントが特にわかりやすいです。

メンテナンスイベントを特定の週に予定した場合、そのイベントはユーザーが指定した 30 分のメンテナンスウィンドウ中にスタートされます。ほとんどのメンテナンスイベントは 30 分のメンテナンスウィンドウ中に完了しますが、大規模なメンテナンスイベントは 30 分以上かかる場合があります。

DB インスタンスのメンテナンス - Amazon Relational Database Service

メンテナンスイベントが特定の週に予定されている場合、割り当てられた 30 分のメンテナンスウィンドウ中に開始されます。メンテナンスの実行中、Amazon Redshift で実行中のクエリまたはその他のオペレーションは終了します。計画的なメンテナンス中に発生したダウンタイムは、Amazon Redshift サービスレベルアグリーメントでは、毎月のダウンタイムや利用不能とは見なされません。ほとんどのメンテナンスは 30 分のメンテナンスウィンドウ中に完了しますが、メンテナンスタスクの一部はウィンドウが終了した後も実行を続ける場合があります。スケジュールされたメンテナンスウィンドウの間に実行されるメンテナンスタスクがない場合、クラスターは次にスケジュールされたメンテナンスウィンドウまで通常どおり稼働します。

Amazon Redshift でプロビジョニングされたクラスターを使用する際の考慮事項 - Amazon Redshift

「Single-AZのRDS DBインスタンスをお使いで、メンテナンスウィンドウが30分の場合、メンテナンスウィンドウ開始時間から30分以上経過をしてもメンテナンスをしていることがあり得る」ということです。

複数ノードで構成されているサービスのメンテナンスウィンドウ

特に複数ノードで構成されているサービスのメンテナンスウィンドウは注意が必要です。

Amazon FSx for NetApp ONTAP(以降FSxN)はSingle-AZであっても2つ以上のノードで動作をしています。

https://dev.classmethod.jp/articles/amazon-fsx-for-netapp-ontap-file-system-single-az-structure-is-not-a-single-node/

FSxNでメンテナンスが行われる際は各ノード最大1時間のメンテナンスが発生し得ます。

パッチ適用はまれで、通常は数週間に 1 回行われます。パッチ適用が発生すると、ファイルシステムの各ファイルサーバーに一度に 1 つずつパッチが適用され、各ファイルサーバーにパッチを適用するのに通常最大 1 時間かかります。HA ペア内でファイルサーバーにパッチを適用する前に、ファイルシステムは自動的にファイルサーバーの HA パートナーにフェイルオーバーします。

Amazon FSx メンテナンスウィンドウでのパフォーマンスの最適化 - FSx for ONTAP

例えば、「メンテナンスウィンドウが 毎週日曜日 AM 7:00 - AM 7:30 の場合」としている場合、最も時間がかかるケースは以下のようなタイムラインになります。

  • 日曜日 AM 7:00 : メンテナンスウィンドウ開始)
  • 日曜日 AM 7:30 : プライマリノードからセカンダリノードへフェイルオーバー (IOの停止発生)
    • メンテナンスウィンドウ終了のタイミングでようやくメンテナンスが開始
  • 日曜日 AM 7:30 : プライマリノードのパッチ適用開始
  • 日曜日 AM 8:30 : プライマリノードのパッチ適用終了
  • 日曜日 AM 8:30 : セカンダリノードからプライマリノードへフェイルオーバー (IOの停止発生)
  • 日曜日 AM 8:30 : セカンダリノードのパッチ適用開始
  • 日曜日 AM 9:30 : セカンダリノードのパッチ適用終了

図示すると以下のようになります。

メンテナンスイメージ.png

要するにメンテナンスウィンドウはとうの前に過ぎているのにIO停止が発生したということが起こり得ます。以下記事でFSxNのフェイルオーバーをするときの挙動は確認していますが、高IOが発生するワークロードでは注意が必要と考えます。

https://dev.classmethod.jp/articles/amazon-fsx-for-netapp-ontap-smb-failover-behavior/

SSM Maintenance Windowではメンテナンスウィンドウの終了前にスケジュールされたタスクが開始されることを停止する時間が指定できる

私が知り得る中で基本的にAWSリソースで設定するメンテナンスウィンドウにおいて、いつまでにメンテナンスを完了させる必要があるかを指定することはできません。

ただし、SSM Maintenance Windowではメンテナンスウィンドウの終了前にスケジュールされたタスクが開始されることを停止する時間が指定できます。

これはつまり、実行するタスクの終了時刻がメンテナンスウィンドウの終了枠からオーバーすることを防ぐための機能です。先ほどの例に挙げたようにメンテナンスウィンドウ終了直前にメンテナンスタスクを実行されても困りますからね。

Blackbeltにわかりやすい図がありましたので紹介します。

1.SSM Maintenance Window.png

抜粋 : AWS Systems Manager Maintenance Windows 編 - AWS Black Belt Online Seminar

メンテナンスウィンドウを高IOが発生する処理の前やミッションクリティカルな処理が動作する前に配置することを避けよう

RDSやFSxなどAWSリソースで設定するメンテナンスウィンドウはメンテナンス開始の時間枠であってメンテナンス終了までを含めた時間枠ではないことを紹介しました。

メンテナンスウィンドウを高IOが発生する処理の前やミッションクリティカルな処理が動作する前に配置することを避けた方が無難です。

2時間など余裕を持たせておきたいところです。

この記事が誰かの助けになれば幸いです。

以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!

この記事をシェアする

FacebookHatena blogX

関連記事