AWSのAurora Serverless v1からv2へバージョンアップ

RDSのServerless v1が2024年12月31日でサポート終了です。

なんかAWSからアナウンスはあったけど、まだ先だからいいやーと先延ばしにしてきたんですが、気がつけばもう3ヶ月ぐらいになってるではありませんか！

DB クラスターを Aurora Serverless v1 から Aurora Serverless v2 にアップグレードってクラスターの変更で切り替えるぐらいでしょ？

と思ってたら、そんな簡単な話ではありませんでした。

Aurora Serverless v1 から Aurora Serverless v2 に直接変換できないようなので、面倒くさいのですが、やっていきたいと思います。

ちなみに2024年末にAurora Serverless v1のサポートが終了した際に自動でv2に変換されるとのことです。データベース単体で使っているならそれでも良いのですが、システムの一部として使ってることがほとんどだと思います。そうなるとやはり事前に切り替えのテストを実施しておかないと正月返上で対応に迫られてしまうので、手動で検証しながら切り替えしておいた方がよいでしょう。

Serverless v1とv2の違いは、公式ドキュメントで説明されています。

いろいろ書いてありますが、一言で言ってしまうと、別物です。

準備
1. Serverless v1を作成する
データベースを複製する
1. Aurora Serverless v1のスナップショットを取得
2. Aurora Serverless v1のスナップショットを復元
MySQL 5.7から8.0へバージョンアップ
ProvisionedインスタンスをServerless v2へ変更
1. 接続用のエンドポイントを変更したくない場合
2. 新旧両方のデータベースを残せる
まとめ

準備

Serverless v1を作成する

MySQL5.7からMySQL8.0系へのバージョンアップ実験も兼ねて、データベースエンジンはサポート終了間近のMySQL 5.7を使ってみます。

Serverless v1はマネジメントコンソールからはもう作れないですが、CLIを使えばまだ作れます。セットアップのやり方はこちらご覧ください。⇒AWS CLIセットアップ方法

aws rds create-db-cluster --db-cluster-identifier test-db-cluster ^
    --engine aurora-mysql --engine-version 5.7 ^
    --engine-mode serverless ^
    --scaling-configuration MinCapacity=2,MaxCapacity=4,SecondsUntilAutoPause=1000,AutoPause=true ^
    --master-username username ^
    --master-user-password password123

LinuxやMacの方は、 ^　を \ に変換してください。

サブネットグループ指定する時

次のオプションを追加

--db-subnet-group-name test-db-subnet-group

Windowsの場合は、コマンドプロンプトを起動して、コピペします。

強制的に貼り付けして大丈夫です。

コマンドが成功すると、このように表示されて、クラスターの生成が始まります。

C:\>aws rds create-db-cluster --db-cluster-identifier test-db-cluster ^
More?     --engine aurora-mysql --engine-version 5.7 ^
More?     --engine-mode serverless ^
More?     --scaling-configuration MinCapacity=2,MaxCapacity=4,SecondsUntilAutoPause=1000,AutoPause=true ^
More?     --master-username username ^
More?     --master-user-password password123
DBCLUSTER       1       True    1       2024-09-18T07:30:30.515000+00:00        False   False   arn:aws:rds:ap-northeast-1:771722137126:cluster:test-db-cluster test-db-cluster default.aurora-mysql5.7 default cluster-N4YTTEY5IB7XFVSEV2QOCE2HQE      False   test-db-cluster.cluster-cqf3lwdabwtc.ap-northeast-1.rds.amazonaws.com   aurora-mysql    serverless      5.7.mysql_aurora.2.11.4 Z24O6O9L7SGTNB  False   False   arn:aws:kms:ap-northeast-1:771722137126:key/d59d55de-fdca-4563-8daa-64034d8a882e        username        False   IPV4    3306    16:35-17:05     sun:17:07-sun:17:37     test-db-cluster.cluster-ro-cqf3lwdabwtc.ap-northeast-1.rds.amazonaws.com        creating        True
AVAILABILITYZONES       ap-northeast-1c
AVAILABILITYZONES       ap-northeast-1a
AVAILABILITYZONES       ap-northeast-1d
VPCSECURITYGROUPS       active  sg-bdbf8cf3

マネジメントコンソールのRDS画面で確認すると、ステータス「作成中」で作成されています。

ステータスが「利用可能」になればクラスター作成完了です。

データベースを複製する

Aurora Serverless v1のスナップショットを取得

Serverless v1からv2に直接変更することができないのですが、一度スナップショットを作成してそこから新しいクラスタを復元する方法で迂回することができます。

DBクラスターを選択し、対象のクラスター名をプルダウンリストから選んで、スナップショットの名前を付けます。

スナップショット一覧画面に戻ると、ステータスが「作成中」で表示されますので、しばらく待ちます。

ステータスが「利用可能」になると、スナップショットの取得は完了です。

Aurora Serverless v1のスナップショットを復元

先ほど作成したスナップショットからデータベースクラスターを復元します。

キャパシティタイプは「プロビジョニング済み」を指定します。

利用可能なバージョンはデフォルト（スナップショットを取得した時のバージョン）のままで良いです。

ちなみに違うバージョンでリストアしようとするとエラーになります。

The engine version you requested for your restored DB cluster (8.0.mysql_aurora.3.07.1) is not compatible with the engine version of the DB cluster snapshot (5.7.mysql_aurora.2.11.4).

インスタンスの設定、db.r6g.2xlargeというのが初期選択されていて、意外と大きいサイズになっているので、ちょっと注意が必要です。金額調べていないですが、個人が勉強で使うには高価でオーバースペックです。

テストでお試しするなら、一番小さいサイズが無難です。私は、db.r5.large にしました。

復元の設定が終わったら、DBクラスターを復元ボタンを押します。

データベース一覧に新しくクラスターが登場します。

ステータスが「利用可能」になれば復元完了です。

MySQL 5.7から8.0へバージョンアップ

MySQLのバージョンアップは、DBクラスターの変更画面で実行できます。

MySQL5.7とMySQL8.0は一部のSQLの結果に違いがあったと思うのでシステムで使っている場合は影響調査を忘れないでくださいね

MySQLのバージョンを5.7から8.0に変更します。

変更のスケジュールを指定してクラスターの変更をするとバージョンアップできます。

今回はすぐに適用してみました。一覧画面のステータスがアップグレード中の表示に切り替わります。

しばらく待つとステータスが利用可能になったら、MySQLのバージョンアップは完了です。

ProvisionedインスタンスをServerless v2へ変更

MySQL8.0にバージョンアップできれば、Serverless v2を利用することができます。

DBクラスターではなく、DBインスタンスの方を選択して、変更ボタンを押します。

インスタンスの設定画面で、DBインスタンスクラスの部分に「Serverless v2」が追加されていると思いますので、これを選択します。

Serverlessの場合は、データベースのサイズをインスタンスタイプではなく、ACUという単位で指定します。

今回は最小構成（最小キャパシティ：0.5ACU、最大キャパシティ：1.0ACU）としました。

DBインスタンスクラスがとキャパシティのところが切り替え内容が確認できます。

Servlessに変更には時間がかかりますので、しばらく待ちましょう。

ステータスが利用可能になれば、Serverless v2への変換が完了です。

接続用のエンドポイントを変更したくない場合

ここまで作業が完了すると、古いクラスター(v1)と新しいクラスター(v2)ができあがった状態になります。データベースへの接続先を新しいクラスターのエンドポイントに変更すれば新しい方に接続できます。

アプリ側の変更をしたくないからエンドポイントはそのままがいい、という場合は、古いクラスターの識別子を変更して、新しいクラスターに古いクラスター識別子をつければ解決です。

旧：db-prod
新：db-prod-new

古いクラスター名を変更：db-prod ⇒ db-prod-old
新しいクラスター名を変更：db-prod-new ⇒ db-prod

使い終わったDBは消す

RDSはAWSのコンポーネントの中でも高価です。しかもServerlessは完全停止ができず、停止しても一定期間経過すると自動で起動して課金が始まりますので、要注意です。

そんなわけで、今回は完全に消します。

新旧両方のデータベースを残せる

この方式だと旧データベースもそのまま残りますので、切り替え後になにか不具合が生じた場合でも古いデータベースに接続することで切り戻しができますし、調査もやりやすいです。

その場合、古いデータベース（Serverless v1）をそのまま残しておくと課金されてしますが、データベースへのアクセスがない時に停止することができる設定があるので紹介します。

Serverless v1のクラスタの設定変更で、ACUを指定するセクションに、「クラスターがアイドル状態の時に容量を0ACUにスケールする」というチェックボックスがあります。

これにチェックを付けるとデータベースへのアクセスがなくなって一定期間経つと、データベースが停止します。停止中は課金されませんし、ここがゼロの状態でシステムできちんと稼動すれば、旧データベースにはアクセスせずに動作している確認にもなりますので、オススメです。

ちなみにServerless v2にはこのモードが廃止されため、完全停止はできなくなりました。代わりに最低ACUが1ではなく、0.5が指定できるようになりました。

AWS側もACUを0で放置されるとお金取れないので変更したんでしょうね。

まとめ

みなさん、無事にServerless v2に移行できましたか？

最後にポイントだけ整理して終わりにします。

Serverless v1のサポート終了日は、2024年12月31日
延長サポートはなく、サポート終了と同時にServerless v2に強制アップグレード
放っておいても自動でv1からv2にアップグレードされる
システムで使っているデータベースなら自動は危険、事前に手動でアップグレード確認して影響がない確認しておいたほうがよい
Serverless v1からServerless v2へのダイレクト変換はできない
Serverless v1のMySQL5.7を使っている場合は、MySQL 8.0にしないといけない

今回紹介した方法はシンプルで簡単ですが、システムを停止する必要があるため、切り替え時間を短くしたい場合は、AWSが推奨するブルー/グリーンデプロイの方がよいかもしれません。

それではまた！