背景・目的

Aurora Serverlessについて、触ったことがあるものの特徴など理解していなかったので整理します。
また、簡単に動作確認します

まとめ

下記に特徴を整理します

特徴	説明
概要	・Auroraのオンデマンドのオートスケーリング設定を指す・キャパシティは、自動で調整される DBクラスタが消費するリソースに対してのみ課金される
ユースケース	様々なワークロードに役立つ。特に下記のユースケースに有効である・変動するワークロード・マルチテナントアプリケーション・新規アプリケーション・複合用途アプリケーション・キャパシティプランニング・開発とテスト
メリット	・プロビジョニングよりも簡単な容量管理・高アクティビティ時のスケーリングを高速かつ簡単に実行・アクティビティの少ない期間の費用対効果が高い・プロビジョニングと同等以上の機能・Aurora Serverless v1 より高速、詳細で、中断が少ないスケーリング

概要

Using Aurora Serverless v2

Aurora Serverless v2 を使用するを元に整理します。

Aurora Serverless v2 は、Amazon Aurora 用のオンデマンドのオートスケーリング設定です。Aurora Serverless v2 によって、ワークロードをモニタリングし、データベースの容量を調整するプロセスを自動化しやすくなります。容量は、アプリケーションの需要に応じて自動的に調整されます。DB クラスターが消費するリソースに対してのみ課金されます。このように、Aurora Serverless v2 によって予算内に収め、使用しないコンピュータリソースに対して料金を支払うことを避けるのに役立ちます。
この種の自動化は、マルチテナントデータベース、分散型データベース、開発、テストシステムなど、さらにワークロードが大きく変動し、予測不可能な環境において特に有効です。

Auroraのオンデマンドのオートスケーリング設定を指す
キャパシティは、自動で調整される
DBクラスタが消費するリソースに対してのみ課金される

Aurora Serverless v2 ユースケース

多くのワークロードをサポートしています。特に下記のユースケースに役立つとのこと。

変動するワークロード
マルチテナントアプリケーション
新規アプリケーション
複合用途アプリケーション
キャパシティプランニング
開発とテスト

Aurora Serverless v2 の利点

下記のようなメリットがあるとのこと

プロビジョニングよりも簡単な容量管理
高アクティビティ時のスケーリングを高速かつ簡単に実行
- Aurora Serverless v2 でリーダー DB インスタンスを使用できることで、垂直方向のスケーリングに加え、水平方向のスケーリングも利用できる
アクティビティの少ない期間の費用対効果が高い
- オーバープロビジョニングを回避するのに役立つ
プロビジョニングと同等以上の機能
- 以下の機能が利用できる
  - リーダー DB インスタンス
    - リーダー DB インスタンスを活用して水平方向にスケーリング
    - クラスターに 1 つまたは複数のリーダー DB インスタンスが含まれている場合、ライター DB インスタンスに問題が発生した場合に、クラスターはすぐにフェイルオーバーできる
  - マルチ AZ クラスター
    - 複数のアベイラビリティーゾーン (AZ) に分散できる
    - マルチ AZ クラスターを設定することで、AZ 全体に影響する問題が発生するようなまれなケースでも、ビジネスの継続性を確保できる
  - グローバルデータベース
    - Aurora グローバルデータベースと組み合わせて使用することで、災害対策用として他の AWS リージョンにクラスターの読み取り専用のコピーを追加で作成できる
  - RDS Proxy
    - アプリケーションでデータベース接続をプールおよび共有して、アプリケーションのスケーリング能力を向上させる
Aurora Serverless v1 より高速、詳細で、中断が少ないスケーリング
- より速くスケールアップ、スケールダウンできる
- スケーリングでは、ACU の数を 2 倍または半分にする代わりに、0.5 ACU という少ない単位で容量を変更できる
- 通常、処理を一度も中断することなく行われる
- Aurora Serverless v1 のように注意しなければならないイベントは発生しない
- SQL ステートメントの実行中やトランザクションが開いている間にスケーリングを行うことができる

How Aurora Serverless v2 works

Aurora Serverless v2 の概要

Amazon Aurora Serverless v2 は、最も変化が激しく、要求の厳しいワークロードに適しています。用途の例としては、データベースの使用負荷が短時間の間だけ増大し、その後に軽いアクティビティが長時間続くか、またはアクティビティがまったく発生しなくなるケースが挙げられます。例えば、定期的に販売促進イベントを行う小売り、ゲーム、スポーツなどのウェブサイト、必要なときにレポートを作成するレポートデータベースなどがあります。また、開発やテスト環境、また、新しいアプリケーションでは急激に利用が増加することがあります。他にも多くが考えられますが、このようなケースに対してプロビジョニングされたモデルを使用しても、事前に容量を正しく指定できるとは限りません。また、過剰なプロビジョニングを行い、使用しない容量が生じた場合には、コストが高くなる可能性もあります。

変化が激しく、要求の厳しいワークロードに適している

一方で、プロビジョン済み Aurora クラスターは、安定したワークロードに適しています。プロビジョン済みクラスターでは、メモリサイズ、CPU パワー、I/O 帯域幅などが事前定義された DB インスタンスクラスを選択します。ワークロードが変更された場合、ライターとリーダーのインスタンスクラスを手動で変更します。プロビジョン済みモデルは、消費パターンが予想され、事前に容量を調整できる場合に有効です。クラスター内のライターとリーダーのインスタンスクラスを変更しながら、短時間の停止の発生が許容される場合は有効に機能します。

プロビジョン済みは、安定したワークロードに適している

Aurora Serverless v2 は、すぐにスケーリング可能なサーバーレス DB クラスターをサポートするためにゼロから設計されています。また、Aurora Serverless v2 は、プロビジョン済みライターやリーダーと同レベルのセキュリティと分離を提供するように設計されています。このような側面は、マルチテナントのサーバーレスクラウド環境では非常に重要です。データベースのワークロードの変更に迅速に対応できるように、動的スケーリングメカニズムにはオーバーヘッドがほとんどありません。また、処理需要の劇的な増加に対応するための、十分な能力も備わっています。

すぐにスケーリング可能
動的スケーリングメカニズムには、オーバーヘッドがほとんどない

Aurora Serverless v2 を使用することにより、各ライターとリーダーにある特定のデータベース容量の制約を受けずに Aurora DB クラスターを作成できます。お客様は、最小容量と最大容量の範囲を指定します。Aurora では、その容量範囲内のクラスター内の各 Aurora Serverless v2 ライターまたはリーダーをスケーリングします。各ライターまたはリーダーによって動的にスケーリングできるマルチ AZ クラスターを使用することで、動的スケーリングと高可用性を活用できます。

キャパシティの範囲を指定する

Aurora Serverless v2 では、最小容量と最大容量の仕様に基づいて、データベースリソースを自動的にスケーリングします。ほとんどのスケーリングイベントのオペレーションは、ライターまたはリーダーが同じホスト上で保持されるため、高速にスケーリングします。Aurora Serverless v2 ライターまたはリーダーが、あるホストから別のホストに移動するまれなケースでも、Aurora Serverless v2 では自動的に接続を管理します。データベースクライアントアプリケーションのコードやデータベースの接続文字列を変更する必要はありません。

最小と最大の仕様に基づきオートスケーリングする
スケーリングイベントは、ライター、リーダーが同じホスト上で保持されるため、高速にスケーリングする
ライター、リーダーが、あるホストから別のホストに移動するケースでも、自動的に接続を管理する

Aurora Serverless v2 では、プロビジョン済みクラスターと同様に、ストレージ容量とコンピューティング性能は別々になっています。Aurora Serverless v2 容量やスケーリングに言及した場合、増減するのは常にコンピューティング性能です。したがって、CPU やメモリの容量がスケールダウンしても、クラスターには数テラバイトのデータを格納できます。

ストレージとコンピューティングは別管理
CPUやメモリのキャパシティがスケールダウンしても、クラスタには数TBのデータを格納できる

プロビジョニングやデータベースサーバーを管理する代わりに、データベース容量を指定します。Aurora Serverless v2 の容量についての詳細は、「Aurora Serverless v2 の容量」を参照してください。各 Aurora Serverless v2 ライターまたはリーダーの実際の容量は、ワークロードによって時間とともに変化します。このメカニズムの詳細については、「Aurora Serverless v2 でのスケーリング」を参照してください。

Aurora DB クラスターの設定

Aurora DB クラスターごとに、Aurora Serverless v2 の容量およびプロビジョン済み容量、またはその両方を自由に組み合わせて選択できます。

混在設定クラスターと呼ばれる Aurora Serverless v2 とプロビジョン済み容量の両方を含むクラスターを設定できます。例えば、Aurora Serverless v2 ライターで利用可能な容量よりも、多くの読み取り/書き込み容量が必要だとします。この場合、非常に大きいプロビジョン済みライターを使用してクラスターをセットアップできます。その場合でも、引き続き Aurora Serverless v2 リーダーを使用できます。また、クラスターの書き込みワークロードは変化しているが、読み取りワークロードは安定しているとします。この場合、クラスターに 1 つの Aurora Serverless v2 ライターと 1 つまたは複数のプロビジョン済みリーダーをセットアップできます。

Serverless v2とプロビジョン済みの両方を含むことが可能

Aurora Serverless v2 によってすべての容量が管理される DB クラスターをセットアップすることもできます。これを行うには、新しいクラスターを作成し、最初から Aurora Serverless v2 を使用します。または、Aurora Serverless v2 で既存のクラスター内でプロビジョン済みのすべての容量を置き換えることができます。例えば、古いバージョンのエンジンからのアップグレードパスには、プロビジョン済みライターで開始して、Aurora Serverless v2 ライターで置き換えが必要なものもあります。Aurora Serverless v2 で新しい DB クラスターを作成するか、または既存の DB クラスターを Aurora Serverless v2 に切り替える手順の詳細については、「Aurora Serverless v2 DB クラスターの作成」および「プロビジョニングされたクラスターから Aurora Serverless v2 への切り替え」を参照してください。

リプレイスも可能

DB クラスターで Aurora Serverless v2 をまったく使用しない場合、DB クラスター内のすべてのライターとリーダーはプロビジョン済みになります。これは、ほとんどのユーザーがよく知っている、最も古く、最も一般的な種類の DB クラスターです。実際に、Aurora Serverless の前には、このような種類の Aurora DB クラスターには特別な名前はありませんでした。プロビジョン済み容量は一定です。料金は比較的簡単に予測できます。ただし、必要な容量を事前に予測する必要があります。場合によっては、予測が不正確だったり、容量のニーズが変わったりすることもあります。このような場合、DB クラスターがプロビジョニングされない (希望よりも遅い)、またはオーバープロビジョニング (必要以上に高価) になる可能性があります。

実践

Aurora Serverless v2の構築

今回、クエリエディタを使用したいため、バージニアで構築します
最新のサポート状況は、こちらを御覧ください。

AWSにサインインし、RDSのトップページに遷移します
データベースの作成をクリックします
データベースの作成方法を選択します。ここでは標準作成を選びます
エンジンではPostgreSQLを選択します
バージョンは、15.4としました
下記を指定します
- DBクラスター識別子
- マスターユーザ名
本番か、開発/テストか選びます。今回は、開発/テストを選びました
クラスターストレージ設定では、Auroraスタンダートとしました
ここで、Serverless v2を選択しました。また、キャパシティではAUCを0.5〜1にしています
テスト環境なので、Auroraレプリカを作成しないとします。
コンピューティングリソースでは、「ECに接続しない」、VPCを選択しています
DBサブネット、パブリックアクセスなしにしています。また、SGやAZを指定します
RDS Data APIを有効化します。これによりクエリエディタが利用できます
モニタリングはデフォルトとしておきます
データベースを指定し、最後に作成をクリックします
しばらく待ちます
できました

クエリを実行する

Secret ManagerのARNをコピーする

認証情報の設定で、Credentials managementで、SecretManagerを選択している場合、SecretManagerのシークレットが自動で作成されます。このARNをコピーします。

Secret Managerに移動します
できていたので、シークレットをクリックします
ARNをコピーします

クエリエディタでSQLを実行する

ナビゲーションペインで「クエリエディタ」をクリックします
下記を入力し、接続をクリックします
- データベース
- データベースユーザ名には、Secret Managerを選択
- Secret ManagerのARN
- データベース名
接続されるのでデフォルトのクエリを実行します。成功しました

考察

今回、Aurora Serverless v2を試してみました。
AUCという単位でキャパシティを設定しておけば、あとは自動でスケーリングしてくれるのは良いですね。
また、プロビジョニング済みのインスタンスも組み込めるのは、特徴的だと感じました。次回以降試してみたいと思います。

参考