Aurora Provisioned vs Serverless v2：最適な選択と移行ガイド

はじめに

Amazon Aurora には、Provisioned と Serverless という2つの主要なキャパシティタイプがあります。
今回は、両者の特徴を比較し違いや選択の基準、Provisioned から Serverless v2 への移行手順について解説をします。
また、Serverless v2を利用する際の注意点についても何点か紹介します。

目次

• Aurora Provisioned と Serverless v2 の比較
• Aurora Provisioned → Serverless v2 への移行方法
  • Aurora Provisioned → Serverless v2 への移行
• 注意点
  • Auroraクラスター内にProvisionedとServerless v2を同時に稼働させる
  • AuroraServerless v2でサポートされるリージョンとAuroraDBエンジン
  • Aurora Serverless v2 の0 ACUによる自動一時停止と再開
  • Serverless v2でRDS Proxyを利用する場合、料金が高額になりがち
• まとめ

Aurora Provisioned と Serverless v2 の比較

※1 Aurora Serverless v2 の容量
※2 Aurora Serverless v2 でサポートされているリージョンと Aurora DB エンジン
※3 Amazon Relational Database Service Proxy の料金

詳細比較

スケーリング

• Provisioned:
  Amazon Aurora Auto Scalingによるリーダーインスタンス数のスケールが可能です。
  ライターインスタンスは事前に決定したインスタンスサイズを手動でプロビジョニングし、負荷の変化に応じて手動でスケールアップ/ダウンが必要となります。

• Serverless v2:
  ワークロードに応じて自動的に、設定した最小・最大ACUの範囲内で、必要に応じた容量（メモリ・CPU等）が自動調整されます。
  0 ACUに設定することでインスタンスの一時停止が可能。

パフォーマンス特性

• Provisioned:
  一貫したパフォーマンス特性が提供されます。選択したインスタンスクラスに基づく固定リソースでの稼働となります。

• Serverless v2:
  負荷に応じたリソース割り当てが行われます。高負荷時には最大ACUまでスケールアップし、低負荷時には最小ACUまでスケールダウンします。
  Serverless v2は負荷に応じて自動的にスケールしますが、急激な負荷増加時には一時的にパフォーマンスが低下する可能性があります。特に最小ACUを低く設定している場合、スケールアップに若干の時間がかかることがあります。

コスト構造

• Provisioned:
  インスタンスサイズに基づく固定料金となり、使用率が低くても稼働時間分の支払いをする必要があります。
  リソース状況が安定していて将来的なリソース不足の可能性もない場合、リザーブド購入によりコスト削減が可能となります。

• Serverless v2:
  実際に使用したACUに対して秒単位で課金が発生します。変動するワークロードに対してコスト効率を高くすることが可能です。

適用シナリオ

• Provisioned:
  予測可能で一定の負荷を持つ本番環境での利用がおすすめです。常に高パフォーマンスが必要な場合はProvisionedを利用するのが良いです。

• Serverless v2:
  ピーク時とオフピーク時の負荷の差が激しいシステムや開発/テスト環境の利用がおすすめです。
  運用の手間をかけずに柔軟なスケールが求められる環境ではServerlessを利用のするのが良いです。

Aurora Serverless v2の容量を決める際の基準

Aurora Serverless v2のACUを決める際に下記情報が参考となりそうでした。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.max_capacity_considerations

例えば、クラスターのワークロードが高い場合に db.r6g.4xlarge DB インスタンスクラスを使用するとします。その DB インスタンスクラスのメモリは 128 GiB です。したがって、ACU の最大設定を 64 に指定すると、ほぼ同じ容量にスケールアップできる Aurora Serverless v2 DB インスタンスを設定できます。これは、各 ACU が約 2 GiB のメモリに対応するためです。db.r6g.4xlarge DB インスタンスにワークロードを効果的に処理するのに十分な容量がないことがあり、DB インスタンスをよりスケールアップさせるために多少大きい値を指定することができます。

とあるため、Aurora Serverless v2での性能は「Provisionedのメモリ/2 = ACU」の値となるスペックで考えることができそうです。

ACUはCPUとメモリの両方をスケールします。1ACUあたり約2GiBのメモリと対応するCPU処理能力を提供します。
インスタンスタイプとACUを表にすると下記のようになります。※表に記載されているのはメモリ容量の対応関係であり、CPUパフォーマンスも同様にスケールします。

最大8ACUとした場合、「db.r6g.large」のスペックと一致するということになります。
これを利用することでAurora Provisioned → Serverless v2 変更時の最大ACUの判断基準とすることができます。

Aurora Provisioned → Serverless v2への移行方法

すべてProvisioned作成されているAurora クラスターをServerless v2へ移行する方法です。
この手順のProvisionedとServerless v2を逆に読み替えて実施すれば、逆に Serverless v2 → Provisionedへの変更も可能です。

ProvisionedのライターインスタンスをServerless v2に変更する際のざっくり流れとしては下記の通りとなります。

1. リーダーインスタンスとしてサーバレスを追加
2. フェイルオーバー優先順位の変更
3. 作成したサーバレスのリーダーインスタンスを手動フェイルオーバー ※数秒のダウンタイムが発生
4. 3.の変更が完了するとライターインスタンスがServerless v2となる
5. 旧ライターインスタンス（コンソール上はリーダー）をServerless v2へ変更する

詳細な手順はこの後説明していきます。

Aurora Provisioned → Serverless v2への移行

Provisionedで稼働するAuroraを、Serverless v2へ切り替えを実際にやってみます。

切り替え作業を実施して、再度クラスターのステータスが「利用可能」になるまで全体で30~40分ほど時間を要しました。※データ量に依存する可能性はありますのであくまで参考程度
なお、接続の断は数十秒程度です。

①クラスターへAurora Serverless v2のリーダーインスタンスを追加

Auroraクラスターにて「リーダーの追加」を選択

以下の箇所を設定してリーダーを追加
・Auroraレプリカのソース：Provisionedで使用していた任意の移行元インスタンス
・DB インスタンスの識別子：任意のインスタンス名
・DB インスタンスクラス：「Serverless v2」を選択
・最小キャパシティ：任意の値を選択。※「0」を選択すると一定時間通信がない場合にインスタンスを一時停止可能
・最大キャパシティ：任意の値を選択。※「256」まで選択可能
・アベイラビリティーゾーン：Serverless v2を起動したいAZを選択

10分くらいすると下記のようにServerless v2のインスタンスが作成完了します。

②フェイルオーバー優先順位の変更

作成したServerless v2インスタンスをライターインスタンスへ昇格させます。
今回はリーダーが複数台いるためフェイルオーバーの優先順位をまず変更します。

昇格させるServerless v2インスタンスを選択し、「変更」を押下します。

フェイルオーバーの優先順位を
「tier-1」→「tier-0」
へ変更し、「すぐに適用」を押下します。

③フェイルオーバーの実施

優先順位の変更が完了したら、ライターインスタンスを選択し、
「アクション」- 「フェイルオーバー」を押下します。
この時、ライター → リーダーの切り替え時に数秒間の接続断が発生します。

④ライターインスタンスのタイプを確認

10分ほど待つと下記の通りライターインスタンスが、Provisioned → Serverless v2へ切り替わったことが確認できます。

⑤必要に応じてクラスター内部のリーダーインスタンスを変更

あとは残りのServerless v2のリーダインスタンスを追加、もしくは既存のProvisionedインスタンスをServerless v2に変更し、必要な分のインスタンスをクラスター内に配置すれば切り替えが完了となります。

注意点

Auroraクラスター内にProvisionedとServerless v2を同時に稼働させる

プロビジョニングされた DB インスタンスの削除は必須ではありません。Aurora Serverless v2 とプロビジョニングされた DB インスタンスの両方を含むクラスターを設定できます。ただし、Aurora Serverless v2 DB インスタンスのパフォーマンスとスケーリング特性に精通するまでは、すべて同じタイプの DB インスタンスでクラスターを設定することをお勧めします。

プロビジョニングされたクラスターから Aurora Serverless v2 への切り替え に記載がある通りですが、Auroraクラスター内にProvisionedとServerless v2を同時に稼働させることは可能です。
ただし、プライマリが Provisioned インスタンスから、Serverless v2 レプリカに意図せずフェイルオーバーした場合などACUの設定によってはパフォーマンスに大きな影響を与えるなど様々な問題が発生する可能性もあるため注意してご利用ください。

AuroraServerless v2でサポートされるリージョンとAuroraDBエンジン

Aurora Serverless v2で使用可能なリージョンとAurora MySQL/PostgreSQLエンジンバージョンは下記を参照してください。
バージョンが対応していない場合直接の移行はできないため、まずはアップグレードを実施する必要があります。

• Serverless v2 で利用できる Aurora MySQL
• Serverless v2 で利用できる Aurora PostgreSQL

Aurora Serverless v2 の0 ACUによる自動一時停止と再開

ACU=0にすることで、インスタンスへの接続がなく指定した間隔が経過した際のAurora Serverlessを一時停止（料金を発生させなくすること ※ストレージ料金等は発生）が可能となります。

下記の通り、作成画面で「最小キャパシティ=0 (ACU)」を設定すると、「非アクティブ後に一時停止」の入力欄が登場します。※5min~24hourの間で選択可能
こちらを設定することで、指定した時間（例：この画像の場合5分間）アクティビティがない場合に、自動的にクラスターを一時停止させることが可能です。

DBへのヘルスチェックなど、クライアントがコネクションを貼り続けていると、アイドルにはならないためACU=0にならない場合はDBのコネクション周りも確認してみると良いでしょう。

他にも、Aurora Serverless v2 の 0ACUによる自動一時停止と再開に関する挙動・注意点はこちらAurora Serverless v2 の自動一時停止と再開によるゼロ ACU へのスケーリング を参照してください。

とくに、インスタンスが一時停止すると、再接続には15秒程度かかります。
また、一時停止期間が24時間を超えると "ディープスリープ" 状態となり、接続に30秒以上かかる場合があります。１日以上一時停止をすると接続できるようになるまで時間がかかりますので注意してください。

Aurora Serverless v2 インスタンスが 24 時間以上一時停止したままの場合、Aurora はインスタンスをディープスリープ状態にすることがあるため、再開に時間がかかります。その場合、再開時間は 30 秒以上になることがあり、インスタンスの再起動とほぼ同じになります。データベースの非アクティブ期間が 1 日以上続く場合は、接続タイムアウトを 30 秒以上に設定することをお勧めします。

Serverless v2でRDS Proxyを利用する場合、料金が高額になりがち

https://aws.amazon.com/jp/rds/proxy/pricing/?nc=sn&loc=3

時間当たりの料金がServerlessだと若干高いです。
さらに、「最低料金」が設定されており、それぞれ8ACUと2vCPUとなっています。
これはリソースがこれ以下の小さいものを利用していても、最低この料金は発生しますということになります。
つまり、それぞれにかかる月額最低料金は

• Provisioned:

  0.018 x 2 （vCPU） x 24 （時間） x 30（日） x 1 （Proxy）= USD 25.92 /月

• Serverless v2:

  0.025 x 8 （ACU） x 24 （時間） x 30（日） x 1 （Proxy）= USD 144 /月

となり、Serverless v2の方が非常に高くなることがわかります。
例えば、Aurora Serverless v2で0.5ACUで動作していたとしても、Proxyの料金計算上は8ACU分の「USD 144 /月」の費用が発生します。

まとめ

Aurora Serverless v2 は、Provisioned インスタンスの柔軟性とコスト効率を大幅に向上させたオプションです。特に負荷が大きく変動するワークロードでのコスト最適化・ミリ秒単位でのスケール管理を簡単に行いたいなどが重要な環境に適しています。一方、完全に予測可能な負荷を持つ環境では、Provisioned インスタンスも引き続き有効な選択肢となります。
また、コスト観点ではProvisionedでのリザーブドインスタンスなどを検討するとServerlessよりProvisionedの方が優れている可能性もあります。

Serverless v2への移行を検討する際は、ワークロードパターン、コスト構造、必要な機能セットを考慮して最適な選択をしましょう。