開発中のAWS基盤のシステムでAuroraを利用しており、Auroraのバージョンアップグレードの運用を検討した。
検討過程で調べた内容（AWSサポートへ問い合わせて確認した内容を含む）や、決めた方針をメモとして残しておく。
利用しているAuroraの情報
- Auroraのエディション：Aurora MySQL互換
- Auroraのエンジンバージョン：Aurora(MySQL 5.7) 2.10.2
- バックアップ・リストア関連で有効化している機能
検討ポイント①：運用保守でアップグレードする範囲をどうするか
Auroraのバージョン表記は major.minor.patchとなっている。
パッチバージョンは主に重要な問題修正のために提供されるバージョン、マイナーバージョンは追加機能が提供されるバージョン（互換性あり）、メジャーバージョンはMySQLのコミュニティ版のメジャーバージョンに対応するバージョンになっている。
詳細はこちら。
参画中の案件では、マイナーバージョンまでのアップグレードを運用保守作業での対応範囲とした。
メジャーバージョンのアップグレードは、Auroraを利用するアプリケーションの影響調査・改修が必要になる可能性が高いと判断し、対応が必要な場合は通常の運用保守作業とは別に移行作業を計画することとした。
検討ポイント②：アップグレードを自動化するかどうか
Auroraには以下のような自動アップグレードの機能がある。
- 新しくリリースされたマイナーバージョン、パッチバージョンの変更を自動で適用する
- Auroraのクラスター作成時に設定したメンテナンスウィンドウの期間中に実施する
- 詳細はこちら
参画中の案件では、自動アップグレードによるバージョンアップグレードも検討したが、アップグレードのタイミングでアプリケーションの動作に影響がないかの検証が必要ということで、手動のアップグレードを実施することとした。
手動のアップグレードの頻度は既存の別システムの運用に合わせ3ヶ月おきとし、実施時間帯はAuroraにアクセスするアプリケーションが動作しない計画停止時間帯とした。
検討ポイント③：手動アップグレードのアップグレード先をどうするか
Auroraの新しいエンジンバージョンのリリースサイクルは不定期だが、前のバージョンから数週間で新しいバージョンがリリースされることもある。
そのため、手動アップグレードの作業時にはアップグレード先の候補が複数存在することも考えられる。
そこで、参画中の案件では、手動アップグレードの直前にAuroraのリリースノートを確認し、Auroraを利用するアプリケーションに影響が出そうな変更を含まない最新バージョンをアップグレード先として選定する方針とした。
検討ポイント④：アップグレード後に不具合があった場合にどうするか
運用検討にあたっては、さらに以下のようなケースでバージョンのアップグレード後のリカバリーが可能かを確認した。
-
アップグレード直後にアップグレード前にテーブルの誤操作があったことが発覚し、エンジンバージョンはそのままにテーブルの断面をアップグレード前の状態に戻したいケース
-
アップグレード後にAuroraのクラスターやAuroraにアクセスするアプリケーションで問題が発生し、Auroraのバージョンをアップグレード前に戻したいケース
1. に関してはバックトラックの制限事項に「バックトラック対応クラスターで Aurora MySQL バージョン 1 からバージョン 2 へのインプレースアップグレードを実行する場合、アップグレードを実行する前の時間にバックトラックすることはできません。」と書いてある。
念のため、マイナーバージョンやパッチバージョンのアップグレードであればバックトラックでの巻き戻しは可能なのかをAWSサポートに問い合わせたところ、「バックトラックによってマイナーバージョンのアップグレード前の特定の時刻まで巻き戻すことは可能で、その場合、テーブル作成や行の挿入といった操作は巻き戻されるが、エンジンバージョン自体は巻き戻らない動作だ」という回答をもらった。
そのため、1. のケースが発生した場合はバックトラック機能を利用して、テーブル断面を巻き戻す運用とすることとした。
一方、2. に関しては、Auroraのアップグレード後にアップグレード前のエンジンバージョンに戻れるかを実際にコンソールで試してみたところ、エンジンバージョン変更時にはその時点より上位のバージョンしか変更先の候補として表示されなかった。
Auroraの機能上、以前の古いバージョンに戻ることはサポートされていないのかをAWSサポートに確認したところ、「現時点より古いエンジンバージョンに変更することは現時点でできない。もし古いバージョンに戻りたい場合はバージョン変更以前に取得したスナップショットを使って新しいAuroraのクラスターとして復元することになる」という回答を得た。
そのため、2. のケースが発生する可能性は低いものの、万が一に備えてバージョンアップグレード直前にスナップショットを取得する運用手順とし、2. のケースが発生し解決に時間がかかる場合にはアップグレード直前時点のスナップショットによる復元（つまり、新しいAuroraのクラスター作成）を検討する運用とした。
検討ポイント⑤：スナップショットの取得方法をどうするか
前項に書いた通り、「アップグレード後にAuroraのクラスターやAuroraにアクセスするアプリケーションで問題が発生し、Auroraのバージョンをアップグレード前に戻したいケース」に備え、スナップショットをアップグレード直前に取得することとした。
スナップショットはデフォルトで有効になっている自動バックアップ機能により、1日に1回決まった時間に取得される。
しかし、手動アップグレードの作業時間帯が運用検討期間中には未確定で、自動バックアップ機能によるスナップショット（以降、自動スナップショット）取得と手動アップグレード作業の間にAuroraのDB更新が発生する可能性も考えられた。
そのため、アプリケーションが止まる計画停止時間帯に入ってから、手動アップグレードの直前に手動でスナップショットを取得するという運用手順とした。
なお、手動スナップショットの取得を試したところ取得完了までに10分以上かかるため、スナップショット取得が完了する前にAuroraのマイナーバージョンのアップグレードを開始しても問題ないかをAWSサポートに確認したところ「現時点のAuroraの仕様として、スナップショット取得中にアップグレードは実施できないため、スナップショットの取得完了を待つ必要がある」とのことだった。
検討ポイント⑥：手動スナップショットの保管期間をどうするか
日次で取得される自動スナップショットは保管期間が1日～35日で設定可能なのに対し、手動アップグレード時に取得予定の手動スナップショットは明示的な削除を行わない限り残存し続ける。
そのため、手動スナップショットの保管バージョン数が増えるとストレージ利用料金が余計にかかるので定期的に削除する運用の検討が必要だと考えた。
しかし、Amazon Auroraのスナップショット取得にかかる時間について教えてくださいを読むと、手動スナップショットは2回目以降の取得時は前回からの増分スナップショットになると書かれており、古いバージョンを消してしまうとデータの復元ができるのかが心配になった。
そこで、AWSサポートに問い合わせたところ、「最新の手動スナップショットのみでAuroraクラスターを復元可能」という回答があった。
手動スナップショットを何バージョンも保管し続ける必要がないと分かったので、手動アップグレードが完了した後に、作業日より前に作成した古い手動スナップショットは削除する運用手順とした。
以上。