Amazon Aurora Serverless v1 を作り、そして v2 に変換するまでの道のり

はじめに
背景
前提
Aurora Serverless v1 のクラスターを作成
Aurora Serverless v1 のクラスターを Aurora Serverless v2 にアップグレードする
さいごに

はじめに

こんにちは。アプリケーションサービス部の保田（ほだ）です。

今日は、Aurora Serverless v1 のクラスターを作成したあと、それを v2 にアップグレードしようと思います。

そもそも Amazon Aurora Serverless ってなに、という方は以下の弊社ブログ記事を読んでみて下さい。

blog.serverworks.co.jp

背景

最近（2023年9月）、次のような事態に出会ったからです。

Aurora Serverless v1 をマネジメントコンソールから作れない
既存の Aurora Serverless v1 を v2 にアップグレードしようとしても、マネジメントコンソールからは出来ない

前提

DB エンジンは MySQL 互換とします。
マネジメントコンソールから実行できない手順は、 AWS CLI から実行することにします。
AWS CLI バージョン2 の最新版を使っていることを前提とします。
- 本記事では Windows Subsystem for Linux 2 （WSL2）上でバージョン 2.13.13 を使っています。入手方法はこちらのドキュメントを参照してください。

$ aws --version
aws-cli/2.13.13 Python/3.11.4 Linux/5.15.90.1-microsoft-standard-WSL2 exe/x86_64.ubuntu.20 prompt/off

Aurora Serverless v1 のクラスターを作成

早速ですが、マネジメントコンソールからは執筆時点（2023年9月）では実施できません。

CloudFormation でも作成できますが、今回は AWS CLI で作りましょう。

awscli.amazonaws.com

パラメータが多いので、入力値は JSON ファイルから与えます。

create_db_cluster.json

{
  "AvailabilityZones": [
    "ap-northeast-1c"
  ],
  "DatabaseName": "<データベース名>",
  "DBClusterIdentifier": "<クラスター名>",
  "VpcSecurityGroupIds": [
    "sg-01234abcd"
  ],
  "DBSubnetGroupName": "default",
  "Engine": "aurora-mysql",
  "EngineVersion": "5.7.mysql_aurora.2.08.3",
  "MasterUsername": "<マスターユーザー名>",
  "MasterUserPassword": "<マスターパスワード>",
  "EngineMode": "serverless",
  "ScalingConfiguration": {
    "MinCapacity": 1,
    "MaxCapacity": 1,
    "AutoPause": true,
    "SecondsUntilAutoPause": 300,
    "TimeoutAction": "ForceApplyCapacityChange",
    "SecondsBeforeTimeout": 60
  }
}

特に注目したいポイントは以下の通りです。

  "Engine": "aurora-mysql",
  "EngineVersion": "5.7.mysql_aurora.2.08.3",
  ...(中略)...
  "EngineMode": "serverless",
  "ScalingConfiguration": {
    "MinCapacity": 1,
    "MaxCapacity": 1,
    "AutoPause": true,
    "SecondsUntilAutoPause": 300,
    "TimeoutAction": "ForceApplyCapacityChange",
    "SecondsBeforeTimeout": 60
  }

これが Aurora Serverless v1 を特徴づけます。ちなみに EngineVersion に選択できるバージョンは現状一択のため、省略できます。

では、このファイルと同階層で以下のコマンドを実行します。

$ aws rds create-db-cluster --cli-input-json file://create_db_cluster.json

少し時間かかりますが、作れました。

Aurora Serverless v1 のクラスターを Aurora Serverless v2 にアップグレードする

そもそもですが、Aurora Serverless v1 と Aurora Serverless v2 はアーキテクチャや適した用途が異なります。

なんとなく Aurora Serverless v1 のクラスターが現状マネジメントコンソールから作れなかったり、MySQL 5.7 までしか対応していなかったりするため、早いうちに v2 に移行しないとサービス終了してしまうのでは？という感覚はあります。

が、v2 に移行すべきかどうかは考える必要があります。

ザックリとしたイメージは以下のようになるかと思います。

ユースケース	DB
アクセス頻度は低く、必要な時だけ容量が欲しい	Aurora Serverless v1
アクセス頻度は定常的で、必要な容量も予測できる	Aurora (プロビジョニング済み)
アクセス頻度は予測しづらく、突発的に容量が求められることがある	Aurora Serverless v2

詳細は公式ドキュメントをご参照ください。

つまり、アクセス頻度が低いことが v1 を使う主なモチベーションだった場合、何も考えずに v2 にしてしまうとオーバースペックというか想定しない利用料がかかってしまいます。

これらを踏まえて、やっぱり v2 にしたいとなった場合は以下の手順を実行しましょう。

手順の概観

基本的な流れは公式ドキュメントの通りです。

docs.aws.amazon.com

つまり以下の流れです。

EnginMode を serverless から provisioned に
Aurora バージョン 2 から Aurora バージョン 3 にアップデート
provisioned のインスタンスを Aurora Serverless v2 に変換

ですが、一部マネジメントコンソールからは執筆時点（2023年9月）では実施できない手順があります。

EngineMode を serverless から provisioned に

Serverless v1 から v2 に直接移行することはできず、一度プロビジョニング済みのクラスターに変換する必要があります。

理由は、この次のステップで v2 互換のDBエンジンにアップグレードするのですが、 v1 と v2 が対応しているエンジンバージョンに互換性がなく、ワンクッション必要だからです。

それではやっていきましょう。

Aurora Serverless v1 DB クラスターをプロビジョニング済みに変換するにしたがって、現在の Serverless 最大容量に対応するインスタンスタイプを見積もります。

ただし、最低でも db.t3.medium 以上にします。db.t3.small は v2 に変更できません。

そしてここが最大の山場です。つまり AWS CLIが必須です。以下を実行しましょう。

aws rds modify-db-cluster \
    --db-cluster-identifier <クラスター名> \
    --engine-mode provisioned \
    --db-cluster-instance-class <インスタンスタイプ> \
    --allow-engine-mode-change

awscli.amazonaws.com

マネジメントコンソールをチラチラ見ながら、完了するのを待ちましょう。

できました。

Aurora バージョン 2 から Aurora バージョン 3 にアップデート

後は簡単です。マネジメントコンソール上から実行するのが一番簡単なので、それで済ませましょう。

少しややこしいですが、 Aurora Serverless v1 の DB エンジンは Aurora バージョン2 である一方、Aurora Serverless v2 は Aurora バージョン3 です。

v1 の方は DB エンジンを 5.7.mysql_aurora.2.08.3 として作成しましたが、5.7 が MySQL のバージョン、 2.08.3 が Aurora のバージョンを表します。既に見てきた通り v1 はこれしか選択肢がないので、どうやっても MySQL 5.7 しか選べませんし、 Aurora のバージョンは 2 しか選べません。

一方、 v2 の方は 8.0.mysql_aurora.3.0x.x の形式です。もちろん MySQLが 8.0 で Aurora のバージョンが 3 という訳です。

そのため、バージョンアップ作業が必要です。

この操作は、クラスター側の設定を変更することに注意です。

インプレースアップグレードの実行手順を参考に、Aurora バージョン 3 にアップグレードしてください。

プロビジョニング済みタイプに変更したので、エンジンのバージョンの選択肢が増えていますね！