Amazon Aurora Serverless v2 がGAしました

記事タイトルとURLをコピーする


コーヒーが好きな木谷映見です。

2022年4月21日に、Amazon Aurora Serverless v2 のGAが発表されました。今回は Amazon Aurora Serverless v2 とはどのようなものなのかまとめていきます。

今までの Amazon Aurora

Amazon Aurora の最大の特徴は、インスタンスとストレージが分離していることです。

DB クラスター という構成になっており、1 つ以上の DB インスタンスと、これらの DB インスタンスのデータを管理する 1 つのクラスターボリュームで構成されています。

Aurora DB クラスターを構成するDBインスタンス部分には以下2種類のインスタンスを含んでいます。

  • 読み書きオペレーションをサポートするプライマリ DB インスタンス(Writer)
  • 読み取りオペレーションのみをサポートするAurora レプリカインスタンス(Reader)

Aurora DB クラスターを構成するクラスターボリュームは永続データ用のストレージで、データベースのデータ量に応じて動的に拡張・縮小されます。 クラスターボリュームは、複数のアベイラビリティーゾーンにまたがる仮想データベースストレージボリュームで、各アベイラビリティーゾーンには DB クラスターデータのコピーが保存されます。

Aurora Serverless v2 とは

Amazon Aurora はインスタンスとボリュームを分離することで、ボリュームの拡張・縮小が高速、しかも自動で行われることが最大の特徴です。この特徴はそのままに、Aurora DB クラスターのインスタンス部分を自動で高速スケーリング(スケールアップ・ダウン)してくれるというものです。

DBインスタンスがなくなるわけではありません。今までは「プロビジョンドDBインスタンス」をデプロイしていましたが、 Aurora Serverless v2 では「サーバレスDBインスタンス」という新しいタイプのDBインスタンスがデプロイされる形になります。

裏側にはちゃんとインスタンスがいます。今までと同様の手順でインスタンスをデプロイします。

ちなみに「サーバーレス」という言葉は「サーバーがない」わけではなく、「サーバーの管理を意識しなくていい」という意味で使われます。

参考:Aurora Serverless v2 overview

Amazon Aurora Serverless v2 の特徴

Serverless v2 インスタンスにかかる負荷に応じて高速スケーリング(スケールアップ・ダウン)します。
実際に使われたACUに応じて課金されます。
実際の使用料に応じて細かくなめらかにスケーリングします。

今までの Amazon Aurora が持つすべての機能を提供

今までのプロビジョンド Aurora インスタンスでできたことはほぼすべて踏襲しています。
マルチAZ構成にも対応していますし、最大で16インスタンス(Writer 1 台、Reader 15 台)まで立ち上げられるところも同じです。 グローバルデータベースや RDS プロキシにも対応しています。

高速スケールアップ・ダウン

Aurora Serverless v2 インスタンスの負荷状況(CPU、メモリ、ネットワークなど)を監視し、自動で高速スケールアップ(垂直スケーリング)します。負荷が落ち着いてきたら自動でスケールダウンします。

スケーリングの際、コネクションが切れることはありません。スケーリング中にポーズしたり、スループットが落ちることもありません。

スケーリングに応じて、動的にパラメータも変わります。

Amazon Aurora Serverless では、スケーリング単位として Aurora Capacity Unit (ACU)を使用します。1 ACU は 約 2 GiB のメモリ、それに対応する CPU、ネットワーキングが組み合わせられています。

ACU の値は最小値(0.5 ACU)~最大値(128 ACU)まで、 0.5 ACU 刻みで DB クラスターに対して設定できます。
最小値が0.5 ACU なので、例えば全く使用していない期間でも常に 0.5 ACU 消費されるというコスト面の考慮事項はあります。しかし、メリットとして考えると、完全に停止することがありませんので、Aurora Serverless v1 の際に発生し得たコールドスタート問題が発生しません。

スケールアップは 0.5 ACU 刻みで行われ、利用状況に応じて細やかなスケーリングを実現します。

また、現在の容量が大きいほど、スケーリングの増分が大きくなります。突発的に利用増加した場合はちまちま 0.5 ACU ずつスケールアップしていくのではなく、その時の ACU の大きさに応じてグッと大きく増加してくれる、というわけです。この仕組みのおかげで、高速スケーリングを実現しています。

補足:スケールアップ・ダウン / スケールアウト・イン

スケールアップ・ダウン:1台のインスタンスのCPUやメモリが増減すること(垂直スケーリング)

スケールアウト・イン:同じ大きさのインスタンスが複数台に増減すること(水平スケーリング)

サーバレスインスタンスとプロビジョンドインスタンスの混在が可能

Aurora プロビジョンドインスタンスと、 Aurora Serverless v2 インスタンスを混在させることができます。下図はマネジメントコンソールで Aurora Serverless v2 を起動した画面ですが、「サイズ」の部分で Serverless v2 インスタンスが 2 台、db.t4g.medium のプロビジョンドインスタンスが 1 台起動しているのが分かります。

「いきなり全部サーバレスにするのはちょっと怖い」
「ちょっとサーバレスの使用感を試したい」

などの場合に、既存の Amazon Aurora DB クラスターに Serverless v2 インスタンス を追加いただき、使用感を確かめることができます。

プロビジョンドインスタンスと Serverless v2 インスタンスが混在していても、今まで通りのクラスターエンドポイントで接続可能です。
もちろん、クラスターエンドポイント、リーダーエンドポイント、カスタムエンドポイント、インスタンスエンドポイントも使用できます。

例えば、同じ Aurora DB クラスターの中にプロビジョンドインスタンスの Writer と Serverless v2 インスタンスの Reader が存在している場合、プロビジョンドインスタンスの Writer から Serverless v2 インスタンス にフェイルオーバーが可能です。

フェイルオーバー後は Serverless v2 インスタンスの Writerとして起動します。

フェイルオーバー後はサーバレスWriterとして起動する

参考:Configurations for Aurora clusters

高可用性

今までの Amazon Aurora が持つすべての機能を提供にも記載しました通り、今までのプロビジョンド Aurora DB クラスター同様マルチAZ構成にも対応していますし、最大で16インスタンス(Writer 1 台、Reader 15 台)まで立ち上げることができます。

フェイルオーバー優先順位

また、インスタンスに対して「フェイルオーバー優先順位」 という設定値があります。 これは tier-0 ~ 15 までの 16 段階設定が可能で、数字が小さいほどフェイルオーバーの優先度が高くなります。
Serverless v2 インスタンスで tier-0、1を設定すると、 Writer インスタンスのスケールアップに追従してスケールアップし、フェイルオーバー時にすぐ Writer に昇格できるよう備えます。
Serverless v2 インスタンスで tier-2 ~ 15 を設定すると、Writer インスタンスのスケールアップに追従せず、その時の利用状況に応じてスケーリングします。 tier-2 ~ 15 に設定された Serverless v2 インスタンスがフェイルオーバーする場合、Writer インスタンスの大きさまでスケールアップする時間が追加で必要になります。

参考:Choosing the promotion tier for an Aurora Serverless v2 reader

グローバルデータベース

最大5リージョンにreaderインスタンスを置くことができます。リージョン障害時は別リージョンにフェイルオーバーすることが可能です。

また、セカンダリリージョンで Serverless v2 インスタンスを最小 0.5 ACU で起動しておけば、コストを抑えながら DR 対策でき、フェイルオーバー時には高速でスケールアップしてデータベースを使うことができるようになります。

参考:Aurora Serverless v2 and high availability

Amazon Aurora Serverless v2 ユースケース

  • 可変またはスパイキーなワークロード
    • アクティビティが突然増加して予測できないワークロードに適しています。
    • Serverless v2を使用すると、データベースはアプリケーションのピーク負荷のニーズに合わせて容量を自動的にスケーリングできます。
  • 新しいアプリケーション

    • 必要な DB インスタンスのサイズがわからない場合に適しています。
    • Serverless v2 を使用することで、アプリケーションの容量要件に合わせてデータベースを自動スケーリングします。
  • マルチテナントアプリケーション

    • SaaSやASPサービスなどのように、同一のシステムやサービスを複数のユーザー(企業や個人)で共有するマルチテナントアプリケーションで、それぞれのテナントの使用状況に応じてServerless v2 インスタンスを自動スケーリングさせることで、個別に管理する必要がなくなり効率的になります。
    • アクティビティの少ないクラスターで発生するDBインスタンスの料金は最小限に抑えられ、アクティビティの多い期間にはすばやくスケールアップし処理できるようになります。

他にもさまざまなユースケースが考えられます。詳細は Aurora Serverless v2 use cases(AuroraServerlessv2のユースケース) をご参照ください。

プロビジョンドインスタンスの Aurora を利用した方がいい場面

定常的に起動しており、利用が安定しているプリケーションは、プロビジョンドインスタンスの Aurora の方が適しています。Reserved Instance を購入することによってコストを抑える方法も考えられます。

対応バージョン

GA 時点では以下のバージョンがサポートされています。

  • MySQL 8.0.23 以上
  • PostgreSQL 13.6 以上

補足

GA版はプレビュー版から大きく変更された

Aurora Serverless v2 GA版は、プレビュー版より高速でスケールアップ・ダウンし、機能セットも大幅に増えています。

レプリカの Auto Scaling には対応していない

レプリカの Auto Scaling で、Serverless v2 インスタンスを選択することはできません。つまり、Serverless v2 インスタンスは、スケールアップ・ダウン(垂直スケーリング)には対応していますが、スケールアウト・イン(水平スケーリング)には対応していません。
Serverless v2 Reader インスタンスを追加するには、手動で追加する必要があります。

プロビジョンド Reader インスタンスであれば、 Auto Scaling できます。
DB クラスターに Serverless v2 インスタンスが既に存在している場合は、レプリカの Auto Scaling によってプロビジョンドインスタンスのレプリカと Serverless v2 インスタンス が混在する構成になります。

メモリを消費する機能を有効にする場合の ACU 最低値に注意

例えば、Performance Insights を有効にすると 2 ACU程度のメモリが消費されます。 その他、MySQL バイナリログを出す、MySQL パラレルクエリを実行するなど、メモリを消費するような機能を有効にする場合、ACU 最低値を 0.5 ACU にしてしまうと、メモリが足りなくなってしまいます。これらの機能を有効にする場合は最低値を 2 ACU 以上にすることが推奨されます。

参考:Avoiding out-of-memory errors

静的パラメータの変更

DB クラスターパラメータグループの項目には以下2種類のパラメータ項目が存在します。

  • 動的(dynamic)パラメータ:DB インスタンスの再起動なしで値が変更・反映されるパラメータ
  • 静的(static)パラメータ:値を変更・反映させるには DB インスタンスの再起動が必要なパラメータ

Amazon Aurora Serverless v2 はスケーリングに合わせてパラメータも変わりますが、静的パラメータが変わった場合はステータスが「pending-reboot」という状態になります。
「pending-reboot」というステータスになっている場合、適用されていないパラメータが存在し再起動待ちになっている可能性があるということを頭の片隅に入れておくといいでしょう。

参考:Working with parameter groups for Aurora Serverless v2

Serverless v1 と Serverless v2 の違い 

大まかな違いを表にしてみます。

------------- Serverless v2 Serverless v1
ACUのスケーリング 最小0.5ACUから0.5ACU刻みでスケーリング クラスターが実行中の場合は最低1ACUから2倍ずつスケーリング。 クラスターが一時停止している場合は0ACU
クラスターの停止・開始 クラスターを停止および開始できる クラスター停止および開始できない
マルチAZ機能 使用可能 単一のAZのみ
スケーリングの際の一時停止 ない トランザクション、一時テーブル、テーブルロックの完了を待機してからスケーリングする
利用料金(東京リージョン) $0.20 per ACU Hour $0.10 per ACU Hour

AuroraServerlessv2とAuroraServerlessv1の詳細な比較についてはComparison of Aurora Serverless v2 and Aurora Serverless v1 feature support(AuroraServerlessv2とAuroraServerlessv1の機能サポートの比較) をご参照ください。

Aurora Serverless v2 未サポート

GA 時点でまだサポートされていない機能は以下になります。

  • Database Activity Streams
  • バックトラック(MySQL)
  • クラスターキャッシュマネージメント(PostgreSQL)
  • Billing コンソールのタグフィルタ

参考

docs.aws.amazon.com

emi kitani(執筆記事の一覧)

AS部LX課。2022/2入社、コーヒーとサウナが好きです。執筆活動に興味があります。AWS認定12冠。