はじめに

Aurora Serverless v2 を使っているシステムがありましたが、パフォーマンスよりコストを優先して Provisioned へ移行しました。
その際に「なぜ移行したのか」と「どう移行したのか」について記述します。

最後に、簡単ではありますが、Serverless v2 を使ってみたいいところも記述します。

Provisioned と Serverless

はじめに軽く、今回の比較対象の「Provisioned」と「Serverless」について記述します。

• Aurora Provisioned → 通常 Aurora で利用される DB インスタンスクラス
  • 予想されるワークロードに基づいてインスタンスクラスを選択
  • 起動しているインスタンスごとの時間単位の料金が発生
• Aurora Serverless → Aurora Provisioned をより便利(マネージド)にした DB インスタンスクラス
  • ACU という単位に基づいてスケールを行う
  • 事前に定義した範囲で⾃動的にスケールアップ・ダウン
  • 細かい粒度のスケーリングが可能
  • 秒単位のシンプルな従量課⾦

Creating an Amazon Aurora DB cluster – Amazon Aurora

移行した理由

結論を伝えると「コストが高い」という理由になります。

[Serverless を使用したシステムの簡単な説明]
以下 2 つのシステムで Serverless を使用していました。

• 社内用システム A
  • 特徴
  • 平日の営業時間中(9:00 ~ 19:00 ぐらい)がピークタイム
  • かなり負荷の高い SQL が一日に数回実行される

• 社外用システム B
  • 特徴
  • サーバーレスアーキテクチャで構築
  • Lambda を使って RDS Proxy 経由で Aurora へ接続

具体的には上記の 2 つのシステムでそれぞれのコストが高かった内容を記述します。

1. Provisioned と比較してインスタンスコストが高い
   1. 社内用システム A の話
2. RDS Proxy の最低料金の ACU が高い
   1. 社外用システム B の話

Provisioned と比較してインスタンスコストが高い

システム A では、Serverless v2 の ACU を 4 ACU ~ 16 ACU で設定していました。
これを Provisioned のインスタンスサイズに変更すると「db.r6.xlarge」相当になります。

各 ACU では、約 2 ギビバイト (GiB) のメモリと、対応する CPU、ネットワークが組み合わせられています。
Aurora Serverless v2 の仕組み – Amazon Aurora

以下は、とある日の ServerlessDatabaseCapacity(ACU の値)を表示したメトリクスです。
これを見ると、営業中はスケールしていることがわかり、タイミングによっては最大値の 16ACU までスケールしています。

ServerlessDatabaseCapacity
Aurora Serverless DB クラスターの現在の容量。
Amazon Aurora の Amazon CloudWatch メトリクス – Amazon Aurora

上記、メトリクスから一日の使用量の平均を計算すると 5 ACU を使っている計算となりました。
冗長構成で 2 台インスタンス起動しているのでその倍コストが発生します。

これらを計算するとこんな感じになります。

プラスして、Provisioned の場合は RI が購入できるので、コスト最適化を考慮するとこんな感じです。

ちなみに、最低 ACU をもっと下げればコストは削減できますが、Serverless の仕様上スケーリング速度は、現在の ACU 容量に依存します。
本システムの特性上、突如重たいクエリが投げられるので最低の 0.5 ACU にしていた場合はまったくスケールが間に合いません。
そのため、ある程度容量をあげた 4 ACU と設定していました。

スケーリングの詳細については以下をご覧ください。
Aurora Serverless v2 のパフォーマンスとスケーリング – Amazon Aurora

上記の結果を総合して、Serverless のメリットを感じられなく、Provisioned のほうがコスト最適化が見込めると判断しました。
システム A は、社内用なのでパフォーマンスよりコストのほうが優先度が高かったためこのような結果になりました。

RDS Proxy の最低料金の ACU が高い

先程の話とはまた別のシステム B の話ですが、こちらでも Serverless v2 を採用してテスト構築をしていました。
このシステム B では、サーバーレス構成なのでコネクションに RDS Proxy を採用しました。

ところが、この RDS Proxy で思わぬところでコストが発生しました。

RDS Proxy には、最低料金が存在しており、8 ACU 以下に設定しても 8 ACU のコストが発生することがあとから判明しました。

Amazon RDS プロキシの料金 | 高可用性データベースプロキシ | Amazon Web Services

計算するとこんな感じになります。

このシステムも、全体的にコストを抑えたかったので、Aurora ではなく DynamoDB にできないかと方針を変更しました。

どうやって移行したのか

ここからは、実際にどうやって移行したのかを簡単ではありますが記述します。
なお、対象は「社内用システム A の話」としております。

社内用のシステムだったのでダウンタイムは 2 時間程度の余裕がありました。
なので、一番シンプルなスナップショットからの復元を行いました。

スナップショットを復元をすると、特に Serverless と Provisioned で変わりない画面なので、既存の環境と設定は同じにしていきます。

Provisioned に変える方法は、「インスタンスの設定」で DB インスタンスクラスを Serverless v2 からお好きなクラスに変えるだけです。
いまなら、R6g がコストパフォーマンスがいいのでオススメです。

あとは、時間が経てば利用可能になるのでそうなったらエンドポイントを切り替えるだけです。

1 時間程度で作業は無事完了しました。

使ってみて思った Serverless のいいところ

最後に、Serverless を使ってみて、「Serverless のここがいいな」と思ったところを簡単ですが記述します。

• スケール速度が早い
• スケールアップ・ダウンが簡単

スケール速度が早い

Serverless v2 の強みでもあるスケール速度は申し分ないと思いました。

とある日のグラフです。
青線:ServerlessDatabaseCapacity の使用率(MAX ACU / ServerlessDatabaseCapacity)
緑線:CPU 使用率

統計:平均
期間:5 分

これを見ると、CPU 使用率(緑線)が上がり始めるタイミングで ACU (青線)がスケールしていることがわかります。
また、段階的にスケールしてくれるので負荷に合わせたスケールをしてくれていました。

スケールアップ・ダウンが簡単

Serverless は、スケールアップ・ダウンを簡単に行えます。
ここで言う、簡単に行えると指している内容は、最小・最大 ACU の増減を指してます。

Serverless は、最小と最大 ACU の範囲でスケールしますが、この最小・最大 ACU の変更も簡単にダウンタイムもほとんどなしで実施ができます。
Provisioned でインスタンスの変更を行う場合、場合によっては 10 ~ 30 分ぐらいは発生します。

そのため、今回紹介した システム A のような社内利用のシステムの場合、定時後や休日・祝日にはアクセスがほとんどないため最小 ACU を下げることでコスト最適化が行えます。

詳細については以下をご覧ください。

詳細は記載しないですが、検証を行った際には、ACU の変更中に一秒間隔で接続を行いましたが、接続ができなかったということはなかったです。

まとめ

Serverless は「アクセスがある」ときの負荷や要求スペックと「アクセスがない」ときの負荷や要求スペックの落差が大きいときにかなり有用なのかなと思いました。
常時一定数のアクセスをさばく場合は、Provisioned のほうが適していそうな印象でした。
また、Provisioned でも十分なぐらいマネージドですし、使いこなせるようになるのであれば Provisioned のほうがコストは抑えられると思います。

なお、「インフラのスケール等の管理をまったくしたくない」って方だと、Serverless はめちゃくちゃ刺さると思います。