[祝GA!] Aurora Serverless v2 の特徴まとめ

Posted on April 24, 2022  -  8 min read

2022.4.22 に Aurora Serverless v2 が GA された。 以前から気になっていた機能なので特徴について気になった点をまとめてみた。

Disclaimer

  • 2022.4.22 時点での情報です。最新の情報は公式ドキュメントを参照してください。

  • 本記事では網羅性はあまり意識していません。繰り返しになりますが、詳細は公式ドキュメントを参照してください。

Aurora Serverless v2 の主な機能概要

  1. 負荷に応じてインスタンスタイプが自動的にスケールアップ
  2. Provisioned インスタンスと Serverless インスタンスを混在して一つのクラスタに配置できる
  3. v1 と比較してよりきめ細やかな Option が指定可能(インスタンスタイプ、Global Database の指定等)

※ Disclaimer でも触れた通り網羅性は意識していません

1. 負荷に応じてインスタンスタイプが自動的にスケールアップ

  • 0.5 ACU 刻みで MIN ,MAX キャパシティの指定が可能
  • スケールアップ/ダウン時のユーザ影響なし
  • インスタンスの入れ替わりが起こるのではなく、実際に稼働しているインスタンスがトランザクションを受け付けながらスケールアップが行われる(in place scaling)
    • 新しくインスタンスが追加されるわけではないため、キャッシュがウォーミングされていないといった状態を回避しやすい
  • スケールアップのスピード(scaling rate)はそのタイミングの ACU に依存する。大きい ACU であればあるほどジャンプできる ACU 数が増える
  • Buffer Pool などのパラメータも動的に変更してくれる
    • mysql の max_connection は MAX で設定される ACU の max_connection が設定される

Aurora のアーキテクチャの特徴として、コンピュート層とストレージ層が分離されているためこういったスケール戦略が可能らしい ↓

architecture.png
architecture.png

2. Provisioned インスタンスと Serverless インスタンスを混在して一つのクラスタに配置できる

  • v2 への移行には新たにクラスタを起動する必要はなく、既存のクラスタに Serverless v2 インスタンスを混在することができる
    • ※ ただし Aurora の version は serverless v2 が対応しているものを使用する必要がある
  • 段階的な移行の手段として、v2 インスタンを徐々に増やしていくといった方式が可能
  • Custom endpoint の機能を用いて特定の Reader endpoint にだけ Serverless v2 を割り当てるといった運用も可能

3. v1 と比較してよりきめ細やかな Option が指定可能(インスタンスタイプ、Global Database の指定等)

  • v1 と異なり Read Replica や Global Database にも対応
  • v1 では ACU のスケールは 2 倍ずつしか設定できなかったが、v2 ではきめ細かい ACU サイズが指定可能
  • Global Database 内の設定でも Provisioned と Serverless を混在させることが可能
    • フェールオーバー先のリージョンに Serverless インスタンスを配置することで、トータルのコストを抑えることができる

Aurora Serverless v2 の使い所

  • トラフィックが予想できないようなユースケース

  • 特定の時間帯のみ起動するアプリケーション

  • Writer だけ、もしくは Reader だけ動的にスケールアップ/ダウンさせたい場合

    • 分析用クエリだけは Aurora Serverless v2 を使用する等

  • 逆に安定してトラフィックが予想できる場合は Provisioned インスタンスを用いる

refer to: Aurora Serverless v2 use cases

Aurora Serverless v2 使用時の注意点

対応 version が限られている

  • MySQL
    • Aurora MySQL 3.03.0 or higher
    • MySQL 8.0
  • PostgreSQL
    • Aurora PostgreSQL 13.6.0 以上
    • PostgreSQL 13

refer to: Upgrade paths for MySQL-compatible clusters to use Aurora Serverless v2

ユーザ利用領域以外の ACU も考慮が必要

  • 0.5ACU から設定可能だが Engine や Tools が使用する ACU についても考慮する必要あり
  • 例えば Performance Insights を使用した場合最低でも 2ACU 使用されるため、ACU の minimum はそれよりいくつか大きいサイズを指定する必要がある

refer to: Choosing the minimum Aurora Serverless v2 capacity setting for a cluster

Aurora serverless v1 と v2 との比較(一部抜粋)

詳しくは以下リンクを参照

refer to: Comparison of Aurora Serverless v2 and Aurora Serverless v1

Feature Aurora serverless v2 Aurora serverless v1
最小 ACU(MySQL) 0.5 停止状態: 0
起動状態: 1
最小 ACU(PostgreSQL) 0.5 停止状態: 0
起動状態: 1
最大 ACU(MySQL) 128 256
最大 ACU(PostgreSQL) 128 384
フェールオーバー Yes Best effort
グローバルデータベース Yes No
クラスタの停止 手動停止が必要 自動で停止するオプションも可能
バッファキャッシュ 動的にバッファサイズが変化 サイズ変更後にキャッシュの rewarm が発生してしまう
価格(ACU Hour ・Tokyo resion) $0.2 $0.1
Data API 非対応 😢 対応
Query editor 非対応 😢 対応
Performance Insights 対応 非対応
RDS Proxy 対応 非対応
  • v1 は開発用、v2 は Production ready
  • v1 が廃止されるわけでは無いらしい
  • 単価は v2 の方が高く見えるが、v1 と比較して ACU サイズのオプションが多いため、結果的にコスト安になるケースが多いと思われる

所感

  • 既存の Aurora の機能がほぼ使えるので Production でも十分に使用できそう。
  • Data API や Query editor など個人的に便利だった機能がなくなっているのは残念。(Amplify の RDS との Integration が v1 の DataAPI を前提としていたので今後の動向が気になる)
  • v1 ではスケール時にクエリリクエストが待たされてしまう(connection が切れるわけではない)点が最大の Blocker だったと思うので、ユーザ影響なしにスケールができるのはすごい(語彙力)
  • 個人的には今年最大のアップデート

社内でも段階的に使用できないか検証していきたい。