AWS RDS Aurora Serverless v1からv2へ移行したので手順メモ

こんにちは。バックエンドエンジニアの わいけいです。
今回、業務の中でAWS RDS Serverless v1からv2へのアップグレードを行ったのでその備忘録です。
DBに大きな更新が生じるときは、サービスへの影響度が大きくうっかりミスが致命的な損失を生むこともあります。
かなりドキドキしながらの作業でした。

Serverless v2へのアップグレードが必要になった背景

Serverless v1のサポートが2024年で終了

きっかけはAWSから以下のようなメールが送られてきたことでした。

差出人: "Amazon Web Services, Inc." [e-mail]
件名: [アクションが必要です] 2024 年 12 月 31 日までに Amazon Aurora Serverless v1 をアップグレードしてください | [Action Required] Upgrade Amazon Aurora Serverless v1 by December 31, 2024 [AWS Account: 191466460916] [AP-NORTHEAST-1]
日付: 2023年12月28日 15:11:22 JST
宛先: ************

English follows Japanese | 英語のメッセージは日本語の後にございます

いつもお世話になっております。

2024 年 12 月 31 日をもって、Amazon Aurora はサーバーレスバージョン 1 (v1) をサポートしなくなることをお知らせします。Aurora バージョンポリシー [1] に従い、データベースクラスターをアップグレードする時間を確保するために 12 か月前に通知を行っています。Aurora は 2 つのサーバーレスバージョンをサポートしていますが、Serverless v1 のみサポート終了をお知らせします。Aurora Serverless v2 は引き続きサポートされています。Amazon Aurora Serverless v1 を実行しているデータベースを、2024 年 12 月 31 日までのご都合の良いタイミングで Amazon Aurora Serverless v2 に積極的にアップグレードすることをお勧めします。（以下略）

我々のサービスでは元々Aurora Serverless v1 を使用していましたが、それが2024年でサポート切れになるとのこと。
この場合、移行しないという選択肢がそもそもありません。このメールが届いた時点から情報収集にとりかかりました。

Aurora Serverless v1とv2の共通点と違い

Aurora Serverless v1とv2は、名前からすると単なるバージョン違いのようにも思えますが、実は大きく異なる部分もあります。
まずは、v1とv2の共通点と相違点をおさらいしておきましょう。

v1とv2の共通点

• 負荷対策やネットワーク関係の全般的な設定はAWSにすべて任せることができて非常にラク
• いずれもリクエスト量に応じての自動スケーリングが可能
• 使用量に応じて課金される

v1とv2の相違点

• v1は最低ACUを0にすることで全く使用しなかった場合の課金額を0にできたが、v2はできない（2024/2時点）
• 一方でスケーリングはv2の方が柔軟に行える。v1は急激に負荷が高まったときにスケーリングが追いつきにくい仕組みだった。

ここで挙げた他にもパブリックIPの使用有無やサポートされているAurora MySQLやPostgresqlのバージョンなど色々な違いがあります。気になる方は以下の公式ドキュメントを参照してください。

AWS公式ドキュメント

超乱暴にいうとコストのv1, 性能ならv2といったところでしょうか。
このような特性からserverless v1を開発環境に使い、v2を本番環境に使用する、という使い方をしていた方も多いのではないでしょうか。

移行手順概略

具体的な移行手順の前に、概念的にどういう作業を行えばいいか整理しておきます。
v1からv2への以降では以下のような作業が必要になります。

• v2側で使用可能なMySQLやPostgresQLのバージョンにアップグレードする（これは完全にv1単体の作業で、v2でサポートされていないバージョンを使っていた場合のみ必要になります）
• v1のDBスナップショットを作成し、保存する
• 保存したスナップショットをserverless v2として復元する
• 新しいプライベートIPが払い出されるので、アプリケーションサーバーからそのIPに接続するように設定変更する

今回の我々のケースでは十分なメンテナンスタイムを設けることが可能だったので行いませんでしたが、必要な場合はブルー・グリーンデプロイなども検討してみてください。

また、最後の手順についてはDBというよりそれを使う側の話なので、ここでは触れません。
（我々の場合はDBのホスト情報はAWSのSSMのパラメーターストアにて保存しているので、そこの情報を書き換えました）

具体的な移行作業

以下は我々独自の設定内容も含まれています。参考にする場合はそれぞれの要件にあわせてカスタマイズしてください。また、2024年1月時点での作業メモであることに注意してください。

1.スナップショット作成

AWSのマネコンにて、左メニューから

RDS > データベース

にてDBクラスターを選択。
アクションで「スナップショットの取得」を選択。
分かりやすい名前をつけておき、取得。

2.スナップショット復元

左メニューの

RDS > スナップショット

にて先程取得したスナップショットを選択。
「アクション」から「スナップショットを復元」を選択する。

• キャパシティータイプを「サーバーレス」ではなく、「プロビジョニング済み」にする
• DB インスタンス識別子は分かりやすい名前にしておく
• インスタンスの設定で、serverless v2を選択
• アベイラビリティゾーン：なし
• Enable the RDS Data API情報　を有効化する（我々の場合はクエリエディタの使用のために有効化した）
• 追加設定で「削除保護の有効化」をオンにする（開発環境などは別にオフでも良いかもしれない）

最小ACUと最大ACUは予算や予想される負荷に応じて調整してください。
また、v2では最小ACUが最低でも0.5必要なため、全く使って無い間も課金されます（涙）

クエリエディタの注意点

2024年2月現在、sereverless v2に対してクエリエディタを実行すると、v1の時とはやや挙動が異なる部分があるようです。

例えばv2移行後に
SELECT created_at FROM hoge_table;
としたときにtimezone付きのdatetime型を取得しようとしたことでエラーが出るようになっていました。

The result contains the unsupported data type TIMESTAMPTZ.

このエラーの場合、下記のように取得時に値を文字列にキャストしておけば一応回避できました。

SELECT cast(created_at AS text) FROM hoge_table;

とはいえ不便なので、AWSチームに対応してもらえると嬉しいんだけどなあ（チラッ）。
（いつも素晴らしいインフラ基盤サービスを提供してもらっているのに厚かましくてすみません）