🎃

Aurora が自動マイナーバージョンアップで強制再起動された話

に公開
AWS
RDS
Aurora
tech

🌱 はじめに

Aurora MySQL クラスターで、マイナーバージョンアップグレードの設定を「無効」にしていたのに、自動でアップグレードが実行され、DBが再起動したことがありました。

今回は、そのときの設定状況と、混乱したポイントを整理してみます。

💡 勘違いしていたポイント

  1. 自動マイナーバージョンアップを「無効」にしていても、自動でアップグレードされることがある
  2. クラスターと各インスタンスのメンテナンス時間はずらせない

⚡️自動アップグレードが「無効」でも実行された理由

AWS CLI でクラスター・インスタンス両方の AutoMinorVersionUpgrade の設定値は、すべて false となっており、設定上は自動アップグレードが「無効」の状態でした。

確認コマンド
❯ aws rds describe-db-clusters \
  --query 'DBClusters[].{DBClusterIdentifier:DBClusterIdentifier,ClusterAutoMinorVersionUpgrade:AutoMinorVersionUpgrade}' \
  --output table
-----------------------------------------------------------------------------
|                    DescribeDBClusters                                    |
+---------------------------------+-----------------------------------------+
| ClusterAutoMinorVersionUpgrade  |           DBClusterIdentifier           |
+---------------------------------+-----------------------------------------+
|  False                          |  sample-project-aurora-cluster          |
+---------------------------------+-----------------------------------------+

❯ aws rds describe-db-instances \
  --query 'DBInstances[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,InstanceAutoMinorVersionUpgrade:AutoMinorVersionUpgrade}' \
  --output table
----------------------------------------------------------------------------------------------------------------------
|                         DescribeDBInstances                                |
+---------------------------+----------------------------+-------------------+
|   DBClusterIdentifier     |   DBInstanceIdentifier     | InstanceAutoMinorVersionUpgrade |
+---------------------------+----------------------------+-------------------+
|  sample-project-aurora-cluster |  sample-project-aurora-inst-1   | False    |
|  sample-project-aurora-cluster |  sample-project-aurora-inst-2   | False    |
+---------------------------+----------------------------+-------------------+

RDSイベントを確認すると、以下のように自動でマイナーバージョンが上がったログが残っていました。

Database cluster engine minor version upgrade complete. Previous version: 8.0.mysql_aurora.3.07.0. New version: 8.0.mysql_aurora.3.08.2

実は、「自動マイナーバージョンアップグレード」をOFFにしていても、重大なセキュリティ問題発生時やサポート終了バージョンの場合は強制的にアップグレードが適用されることがあります。

公式ドキュメントにも次のように記載されています👇

重大なセキュリティ問題が発生した場合、またはバージョンがサポート終了日に達すると、マイナーバージョン自動アップグレードオプションを有効にしていない場合でも、Amazon Aurora はマイナーバージョン自動アップグレードを適用することがあります。

引用：Amazon Aurora DB クラスターのアップグレード

🙅‍♀️クラスターと各インスタンスのメンテナンス時間は「ずらせない」

自動アップグレードの挙動を確認する中で、メンテナンスウィンドウの設定についても少し混乱がありました。

アップグレードによるサービス停止時間を最小限に抑えるため、クラスターとインスタンスでメンテナンスウィンドウをずらして設定していました。

ほとんどのメンテナンスイベントは 30 分のメンテナンスウィンドウ中に完了しますが、大規模なメンテナンスイベントは 30 分以上かかる場合があります。

引用：Amazon Aurora DB クラスターのメンテナンス

設定は以下の通りです。

  • クラスター：sat:15:15-sat:15:45
  • インスタンス：sat:17:15-sat:17:45
確認コマンド
❯ aws rds describe-db-clusters \
    --query 'DBClusters[].{DBClusterIdentifier:DBClusterIdentifier, ClusterMaintenanceWindow:PreferredMaintenanceWindow}' \
    --output table
-----------------------------------------------------------------------
|                         DescribeDBClusters                          |
+---------------------------+-----------------------------------------+
| ClusterMaintenanceWindow  |           DBClusterIdentifier           |
+---------------------------+-----------------------------------------+
|  sat:15:15-sat:15:45      |  sample-project-aurora-cluster          |
+---------------------------+-----------------------------------------+

❯ aws rds describe-db-instances \
    --query 'DBInstances[].{DBInstanceIdentifier:DBInstanceIdentifier, InstanceMaintenanceWindow:PreferredMaintenanceWindow, DBClusterIdentifier:DBClusterIdentifier}' \
    --output table
----------------------------------------------------------------------------------------------------------------
|                                              DescribeDBInstances                                             |
+-----------------------------+----------------------------+-----------------------------+
|   DBClusterIdentifier        |   DBInstanceIdentifier     | InstanceMaintenanceWindow    |
+-----------------------------+----------------------------+-----------------------------+
|  sample-project-aurora-cluster  |  sample-project-aurora-inst-1   |  sat:17:15-sat:17:45        |
|  sample-project-aurora-cluster  |  sample-project-aurora-inst-2   |  sat:17:15-sat:17:45        |
+-----------------------------+----------------------------+-----------------------------+

ところが実際には、メンテナンスイベントはすべてクラスター側で設定していた時間帯に発生していました。

下記はインスタンスのRDSイベントのログ画面です。

この挙動も、ドキュメントでしっかり説明されています。

DB クラスター内の個々の DB インスタンスのメンテナンスウィンドウがクラスターメンテナンスウィンドウと異なる場合は、クラスターメンテナンスウィンドウが優先されます。

引用：Aurora MySQL マイナーバージョン間の自動アップグレードの有効化

つまり、クラスターのメンテナンスウィンドウが優先されるため、インスタンスごとのメンテナンス時間をずらして設定しても実際の適用は同時に行われます。

🤔そもそも Auroraにおける「クラスター」と「インスタンス」の違い

Aurora は、共有ストレージを複数のDBインスタンスで利用する構造で動作しています。

そのため、

  • ストレージの整合性・フォーマット・暗号化など、永続データに関わる設定は クラスター単位で統一
  • 一方で、CPUやメモリ、接続数など処理レイヤーに関わる設定は インスタンス単位で個別に最適化 できます。

この設計により、Aurora は「データの一貫性を保ちながら、計算リソースを柔軟にスケールさせる」ことが可能になっています。


引用：Amazon Aurora DB クラスター

仕組みを理解すると、クラスターとインスタンスで分かれている設定項目や、クラスターの設定値が優先される理由にも納得できました😌

🚀まとめ

今回の対応として、RDSイベント通知をNew Relic経由でSlackに自動連携する仕組みをTerraformで実装しましたので、ご興味のある方は下記記事もご覧ください。

https://zenn.dev/azunyan/articles/7c29771b8d7309

この記事がどなたかの参考になれば幸いです。
えみり〜でした|ωΦ)ฅ

Discussion