# Aurora Serverless v2 の仕組み
以下の概要では、Aurora Serverless v2 の仕組みについて説明します。
**Topics**
+ [概要](#aurora-serverless-v2.architecture)
+ [クラスター設定](#aurora-serverless-v2.how-it-works.cluster_topology)
+ [Capacity](#aurora-serverless-v2.how-it-works.capacity)
+ [スケーリング](#aurora-serverless-v2.how-it-works.scaling)
+ [高可用性](#aurora-serverless.ha)
+ [Storage](#aurora-serverless.storage)
+ [設定パラメータ](#aurora-serverless-v2.parameters)
## 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 やメモリの容量がスケールダウンしても、クラスターには数テラバイトのデータを格納できます。
プロビジョニングやデータベースサーバーを管理する代わりに、データベース容量を指定します。Aurora Serverless v2 の容量についての詳細は、「[Aurora Serverless v2 の容量](#aurora-serverless-v2.how-it-works.capacity)」を参照してください。各 Aurora Serverless v2 ライターまたはリーダーの実際の容量は、ワークロードによって時間とともに変化します。このメカニズムの詳細については、「[Aurora Serverless v2 でのスケーリング](#aurora-serverless-v2.how-it-works.scaling)」を参照してください。
**重要**
Aurora Serverless v1 では、クラスターには、最小容量から最大容量の値の間でスケーリングできるコンピューティング性能の単一のメジャーがあります。Aurora Serverless v2 では、クラスターにはライターに加えてリーダーを含めることができます。各 Aurora Serverless v2 ライターとリーダーは、最小容量から最大容量までの値をスケーリングできます。したがって、Aurora Serverless v2 クラスターの全容量は、DB クラスターに定義された容量範囲と、クラスター内のライターとリーダーの数の両方で決まります。どの時点でも、Aurora DB クラスターで実際に使用している Aurora Serverless v2 の容量に対してのみ課金されます。
## Aurora DB クラスターの設定
Aurora DB クラスターごとに、Aurora Serverless v2 の容量およびプロビジョン済み容量、またはその両方を自由に組み合わせて選択できます。
*混在設定クラスター*と呼ばれる Aurora Serverless v2 とプロビジョン済み容量の両方を含むクラスターを設定できます。例えば、Aurora Serverless v2 ライターで利用可能な容量よりも、多くの読み取り/書き込み容量が必要だとします。この場合、非常に大きいプロビジョン済みライターを使用してクラスターをセットアップできます。その場合でも、引き続き Aurora Serverless v2 リーダーを使用できます。また、クラスターの書き込みワークロードは変化しているが、読み取りワークロードは安定しているとします。この場合、クラスターに 1 つの Aurora Serverless v2 ライターと 1 つまたは複数のプロビジョン済みリーダーをセットアップできます。
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.create.md#aurora-serverless-v2.create-cluster)」および「[プロビジョニングされたクラスターから Aurora Serverless v2 への切り替え](aurora-serverless-v2.upgrade.md#aurora-serverless-v2.switch-from-provisioned)」を参照してください。
DB クラスターで Aurora Serverless v2 をまったく使用しない場合、DB クラスター内のすべてのライターとリーダーは*プロビジョン済み*になります。これは、ほとんどのユーザーがよく知っている、最も古く、最も一般的な種類の DB クラスターです。実際に、Aurora Serverless の前には、このような種類の Aurora DB クラスターには特別な名前はありませんでした。プロビジョン済み容量は一定です。料金は比較的簡単に予測できます。ただし、必要な容量を事前に予測する必要があります。場合によっては、予測が不正確だったり、容量のニーズが変わったりすることもあります。このような場合、DB クラスターがプロビジョニングされない (希望よりも遅い)、またはオーバープロビジョニング (必要以上に高価) になる可能性があります。
## Aurora Serverless v2 の容量
Aurora Serverless v2 の単位は *Aurora 容量単位 (ACU)*.です。Aurora Serverless v2 の容量は、プロビジョン済みクラスターに使用する DB インスタンスクラスと関連性はありません。
各 ACU では、約 2 ギビバイト (GiB) のメモリと、対応する CPU、ネットワークが組み合わせられています。この単位を使用して、データベース容量の範囲を指定します。`ServerlessDatabaseCapacity` および `ACUUtilization` メトリクスは、データベースが実際に使用している容量と、その容量が指定された範囲内のどこにあるかを判断するのに役立ちます。
いつどんな場合でも、各 Aurora Serverless v2 DB ライターまたはリーダーは*容量*を持っています。容量は、ACU を示す浮動小数点数で表されます。容量は、ライターまたはリーダーがスケーリングするごとに増減します。この値は毎秒測定されます。Aurora Serverless v2 を使用する予定の各 DB クラスターに、各 Aurora Serverless v2 ライターまたはリーダーの間でスケーリングできる最小容量および最大容量の値である*容量範囲*を定義します。各 Aurora Serverless v2DB クラスターのライターまたはリーダーでは、容量範囲は同じです。Aurora Serverless v2 ライターまたはリーダーは、それぞれの範囲内の容量を持っています。
次の表は、Aurora MySQL および Aurora PostgreSQL でサポートされている Aurora Serverless v2 の容量範囲とエンジンバージョンを示しています。
| 容量範囲 (ACU) | Aurora MySQL 対応バージョン | Aurora PostgreSQL 対応バージョン |
| --- | --- | --- |
| 0.5～128 | 3.02.0 以上 | 13.6 以降、14.3 以降、15.2 以降、16.1 以降 |
| 0.5～256 | 3.06.0 以上 | 13.13 以降、14.10 以降、15.5 以降、16.1 以降 |
| 0～256 | 3.08.0 以降 | 13.15 以降、14.12 以降、15.7 以降、16.3 以降 |
次の表は、Aurora Serverless v2 プラットフォームバージョン別の ACU 範囲とパフォーマンス特性を示しています。
| Aurora Serverless v2 プラットフォームのバージョン | ACU 範囲 | パフォーマンス |
| --- | --- | --- |
| 1 | 0～128 | ベースラインパフォーマンス |
| 2 | 0～256 | ベースラインパフォーマンス |
| 3 | 0～256 | プラットフォームバージョン 2 と比較してパフォーマンスが最大 30% 向上 |
**注記**
特定のクラスターで使用可能なスケーリング範囲は、エンジンバージョンとプラットフォームバージョンの両方によって決まります。より性能の高いエンジンバージョンを、より性能の低いプラットフォームバージョンで実行することも、その逆で行うことも可能です。スケーリング範囲は、最も性能が低いエンジンまたはプラットフォームバージョンによって決まります。
どのプラットフォームバージョンでクラスターが実行されているかは、AWS マネジメントコンソールの [インスタンス設定] セクションで確認できます。または [DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DBCluster.html) の `ServerlessV2PlatformVersion` を表示することで API 経由で確認できます。
自動一時停止機能をサポートする Aurora Serverless v2 バージョンでは、定義可能な Aurora Serverless v2 の最小容量は 0 ACU です。最大容量値以下であれば、それ以上の数値を指定できます。最小容量を小さい量に設定することで、低ロードの DB クラスターでは最小限のコンピューティングリソースを消費できます。同時に、直ちに接続を受け入れ、ビジーになったらスケールアップする準備ができています。
各 DB ライターまたはリーダーがバッファプール内のアプリケーションのワーキングセットを保持できる最小値に設定することをお勧めします。これにより、アイドル中にバッファプールの内容が破棄されることはありません。最小容量値を選択する際のすべての考慮事項については、「[クラスターに Aurora Serverless v2 の最小容量設定を選択する](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.min_capacity_considerations)」を参照してください。最大容量値を選択する際のすべての考慮事項については、「[クラスターに Aurora Serverless v2 の最大容量設定を選択する](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max_capacity_considerations)」を参照してください。
マルチ AZ 配置でのリーダーの設定方法に応じて、その容量はライターの容量に関連付けることも、独立させることもできます。これを行う方法については、「[Aurora Serverless v2 でのスケーリング](#aurora-serverless-v2.how-it-works.scaling)」を参照してください。
Aurora Serverless v2 のモニタリングでは、DB クラスター内のライターとリーダーの容量値を経時的に測定します。データベースが最小容量にスケールダウンしない場合は、最小値の調整やデータベースアプリケーションの最適化などのアクションを実行できます。データベースが常に最大容量に達している場合は、最大容量を増やすなどのアクションを実行できます。また、データベースアプリケーションを最適化し、クエリのロードをより多くのリーダーに分散させることもできます。
Aurora Serverless v2 容量の料金は ACU の時間で測定されます。Aurora Serverless v2 料金の計算方法については、「[Aurora 料金のページ](https://aws.amazon.com/rds/aurora/pricing/)」をご覧ください。
クラスター内のライターとリーダーの合計数が *n* であるとします。この場合、クラスターは、データベースオペレーションを実行していないときにおよそ `n x minimum ACUs` を消費します。Aurora 自体がモニタリングやメンテナンスオペレーションを行うことで、わずかなロードがかかることがあります。そのクラスターでは、データベースを全容量で実行しても `n x maximum ACUs` を超える消費はしません。
適切な最小と最大の ACU 値の選択の詳細については、「[Aurora クラスターの Aurora Serverless v2 での容量範囲の選択](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2-examples-setting-capacity-range-for-cluster)」を参照してください。また、指定した ACU の最小値と最大値は、Aurora Serverless v2 の 一部の Aurora 設定パラメータ動作方法に影響します。容量範囲と設定パラメータ間のやり取りの詳細については、「[Aurora Serverless v2 のパラメータグループを使用する](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.parameter-groups)」を参照してください。
## Aurora Serverless v2 でのスケーリング
Aurora では、各 Aurora Serverless v2 ライターやリーダーの CPU、メモリ、ネットワークなどのリソースの使用率を継続的に追跡しています。これらの測定値を総称して*ロード*と呼びます。ロードには、アプリケーションによって実行されるデータベースオペレーションが含まれます。また、データベースサーバーと Aurora 管理タスクのバックグラウンド処理も含まれます。これらのいずれかによって容量が制約されると、Aurora Serverless v2 がスケールアップします。また、スケールアップすることで解決可能なパフォーマンスの問題を検出した場合、Aurora Serverless v2 もスケールアップします。「[Aurora Serverless v2 の重要な Amazon CloudWatch メトリクス](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring)」および「[パフォーマンスインサイトで Aurora Serverless v2 のパフォーマンスをモニタリングする](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.performance-insights)」の手順で、リソース使用率と Aurora Serverless v2 のスケーリングの影響をモニタリングできます。
ロードは、DB クラスターのライターとリーダーによって異なる場合があります。ライターは、`CREATE TABLE`、`ALTER TABLE`、`DROP TABLE` のようなすべてのデータ定義言語 (DDL) ステートメントを処理します。ライターは、`INSERT` および `UPDATE` のようなすべてのデータ操作言語 (DML) ステートメントも処理します。リーダーは、`SELECT` クエリのような読み取り専用ステートメントを処理できます。
*スケーリング*は、データベースの Aurora Serverless v2 容量を増減するオペレーションです。Aurora Serverless v2 には、各ライターとリーダーに ACU で測定された独自の現在の容量値を持っています。Aurora Serverless v2 は、現在の容量が小さすぎてロードを処理できない場合に、ライターまたはリーダーをより大きな容量にスケールアップします。ライターまたはリーダーの現在の容量が必要以上に大きい場合、小さい容量にスケールダウンします。
Aurora Serverless v1 では、DB クラスターがしきい値に達するたびに容量が 2 倍にスケーリングされますが、Aurora Serverless v2 では容量を段階的に増やすことができます。ワークロードの需要が、ライターやリーダーの現在のデータベース容量に達し始めると、Aurora Serverless v2 はそのライターまたはリーダーの ACU の数を増やします。Aurora Serverless v2 は、消費されるリソースに対し最適なパフォーマンスを実現するために必要な増分で、容量をスケールアップします。スケーリングは 0.5 ACU という小さい増分で行われます。現在の容量が大きいほど、スケーリングの増分が大きくなり、そのため、スケーリングがより高速になります。
Aurora Serverless v2 のスケーリングは高頻度、詳細、無停止であるため、Aurora Serverless v1 のように AWS マネジメントコンソール で離散的なイベントが発生することはありません。代わりに、`ServerlessDatabaseCapacity` や `ACUUtilization` のような Amazon CloudWatch メトリクスを測定し、その最小値、最大値、平均値を経時的に追跡できます。Aurora メトリクスの詳細については、「[Amazon Aurora クラスターでのメトリクスのモニタリング](MonitoringAurora.md)」を参照してください。Aurora Serverless v2 のモニタリングに関するヒントについては、「[Aurora Serverless v2 の重要な Amazon CloudWatch メトリクス](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring)」を参照してください。
リーダースケールは、関連するライターと同時に作成するか、ライターから独立して作成するかを選択できます。これを行うには、そのリーダーの昇格階層を指定します。
+ 昇格階層 0 および 1 のリーダーは、ライターと同じタイミングでスケーリングします。このスケーリング動作によって、優先階層 0 および 1 のリーダーは可用性に最適です。これは、フェイルオーバー時にライターからワークロードを引き継ぐために、常に適切な容量に合わせてサイズ調整されているためです。
+ 昇格階層 2 ～ 15 のリーダーは、ライターとは独立してスケーリングできます。各リーダーは、クラスターに指定した ACU の最小値と最大値の範囲内に収まります。リーダーが関連するライター DB とは独立してスケーリングすると、ライターが大量のトランザクションを処理し続けている間に、リーダーがアイドル状態になってスケールダウンする場合があります。下位の昇格階層で他のリーダーが利用できない場合でも、フェイルオーバーターゲットとして利用できます。ただし、ライターに昇格した場合は、ライターのワークロード全体を処理するためにスケールアップが必要になる場合があります。
昇格階層の詳細については、「[Aurora Serverless v2 リーダーの昇格階層の選択](aurora-serverless-v2-administration.md#aurora-serverless-v2-choosing-promotion-tier)」を参照してください。
Aurora Serverless v1 のスケーリングポイントおよび関連するタイムアウト時間の概念は、Aurora Serverless v2 には適用されません。Aurora Serverless v2 では、データベースの接続中、SQL トランザクション処理中、テーブルロック中、一時テーブルの使用中にスケーリングできます。Aurora Serverless v2 は、スケーリングを開始するためにクワイエットポイントを待ちません。スケーリングによって、進行中のデータベースオペレーションが中断されることはありません。
ワークロードで単一のライターと単一のリーダーで使用できるよりも多くの読み取り容量が必要な場合、クラスターに 複数の Aurora Serverless v2 リーダーを追加できます。各 Aurora Serverless v2 リーダーは、DB クラスターに指定した最小から最大の容量値でスケーリングできます。クラスターのリーダーエンドポイントを使用して、読み取り専用のセッションをリーダーに送信し、ライターのロードを軽減できます。
Aurora Serverless v2 がスケーリングを実行するどうか、また、スケーリング開始後の速度は、クラスターの最小および最大 ACU 設定によって異なります。さらに、リーダーとライターが一緒にスケーリングするように設定されているか、ライターとは独立してスケーリングするように設定されているかによって異なります。Aurora Serverless v2 のスケーリング影響を受ける要因の詳細については、「[Aurora Serverless v2 でのパフォーマンスとスケーリング](aurora-serverless-v2.setting-capacity.md)」を参照してください。
### ゼロへのスケーリング
Aurora MySQL および Aurora PostgreSQL の最近のバージョンでは、Aurora Serverless v2 ライターとリーダーは 0 ACU までスケールダウンできます。この機能は、自動一時停止と再開、または自動一時停止と呼ばれます。最小容量に 0 または 0 以外の値を指定することで、この動作を許可するかどうかを選択できます。Aurora Serverless v2 インスタンスが一時停止するまでの待機時間を選択することもできます。この機能を持つバージョンについての詳細は、「[Aurora Serverless v2 の容量](#aurora-serverless-v2.how-it-works.capacity)」を参照してください。この機能を効果的に使用する方法については、「[Aurora Serverless v2 の自動一時停止と再開によるゼロ ACU へのスケーリング](aurora-serverless-v2-auto-pause.md)」を参照してください。
Aurora MySQL および Aurora PostgreSQL の旧バージョンでは、アイドル状態の Aurora Serverless v2 ライターとリーダーはクラスターに指定した最小 ACU 値にスケールダウンできますが、0 ACU までスケールダウンすることはできません。その場合、容量範囲を設定する際に 0 ACU を選択肢として使用できません。この動作は、Aurora Serverless v1 が一定期間アイドル状態になると一時停止することがありますが、新しい接続を開いた場合、再開するのに時間がかかります。
Aurora Serverless v2 の容量を持つ DB クラスターがしばらく必要ない場合、プロビジョンド DB クラスターと同様にクラスター全体を停止および開始できます。この手法は、一度に何時間も必要とされず、クラスターの再開速度が重要ではない開発システムとテストシステムに最適です。クラスターの停止/開始機能は、すべての Aurora Serverless v2 バージョンで使用できます。その機能の詳細については、「[Amazon Aurora DB クラスターの停止と開始](aurora-cluster-stop-start.md)」を参照してください。
## Aurora Serverless v2 と高可用性
Aurora DB クラスターの高可用性を確立する方法として、マルチ AZ DB クラスターにすることがあります。*マルチ AZ Aurora DB クラスター*は、複数のアベイラビリティーゾーン (AZ) で常に利用可能なコンピューティング性能を持っています。この設定により、大規模な機能停止が発生した場合でも、データベースを稼働し続けます。Aurora は、ライターや AZ 全体に影響を及ぼす問題が発生した場合、自動的にフェイルオーバーを実行します。Aurora Serverless v2 では、ライターの容量と、待機しているコンピューティング性能のスケールアップとスケールダウンを選択できます。これにより、2 番目の AZ のコンピューティング性能は、いつでも現在のワークロードを引き継ぐことができます。同時に、データベースがアイドル状態になると、すべての AZ のコンピューティング性能をスケールダウンすることができます。AWS リージョン での Aurora の動作の仕組みとアベイラビリティーゾーンの詳細については、「[Aurora DB インスタンスの高可用性](Concepts.AuroraHighAvailability.md#Concepts.AuroraHighAvailability.Instances)」を参照してください。
Aurora Serverless v2 マルチ AZ 機能は、ライターに加えて*リーダー*も使用します。リーダーへのサポートは、Aurora Serverless v1 と比較して Aurora Serverless v2 は新しいです。Aurora DB クラスターには、3 つの AZ にわたる最大 15 の Aurora Serverless v2 リーダーを追加できます。
クラスター全体または AWS リージョン全体に影響を及ぼす問題が発生した場合でも、可用性を維持する必要があるビジネスクリティカルなアプリケーションには、Aurora グローバルデータベースを設定できます。災害対策の間、Aurora Serverless v2 容量を使用することで、セカンダリクラスターに引き継ぐことができます。また、データベースがビジー状態でないときは、スケールダウンできます。Aurora グローバルデータベースについての詳細は、「[Amazon Aurora Global Database の使用](aurora-global-database.md)」を参照してください。
Aurora Serverless v2 は、フェイルオーバーなどの高可用性を実現するためにプロビジョン済みのものと同じように動作します。詳細については、「[Amazon Aurora の高可用性](Concepts.AuroraHighAvailability.md)」を参照してください。
Aurora Serverless v2 クラスターで最大の可用性を確保するとします。ライターに加えてリーダーを作成することもできます。リーダーを昇格階層 0 または 1 に割り当てると、ライターに行われるスケーリングがリーダーにも行われます。そうすれば、フェイルオーバーが発生した場合にも、同じ容量のリーダーがライターを引き継ぐことができます。
クラスターがトランザクションの処理を継続するのと同時に、ビジネスの四半期レポートを実行するとします。Aurora Serverless v2 リーダーをクラスターに追加し、2 ～ 15 の昇格階層に割り当てると、そのリーダーに直接接続してレポートを実行できます。レポートクエリのメモリ負荷と CPU の負荷量に応じて、そのリーダーはワークロードに対応できるようにスケールアップできます。レポートが終了すると、再びスケールダウンできます。
## Aurora Serverless v2 とストレージ
各 Aurora DB クラスターのストレージは、3 つの AZ に分散したすべてのデータの 6 つのコピーで構成されます。この組み込みデータレプリケーションは、DB クラスターにライター以外にリーダーが含まれているかどうかにかかわらず適用されます。そうすれば、クラスターのコンピューティング性能に影響を与える問題からも、データを保護できます。
Aurora Serverless v2 ストレージには、「」で説明したものと同じように信頼性と耐久性を有しています。[Amazon Aurora ストレージ](Aurora.Overview.StorageReliability.md)これは、Aurora DB クラスターのストレージは、コンピューティング性能によって Aurora Serverless v2 を使用しても、プロビジョン済みのものを使用しても同じように動作するためです。
## Aurora クラスターの設定パラメータ
プロビジョン済み DB クラスターとして、Aurora Serverless v2 容量のクラスターと同じクラスターおよびデータベースの設定パラメータをすべて調整できます。ただし、容量に関連する一部のパラメータは、Aurora Serverless v2 については取り扱いが異なります。混合設定クラスターでは、それらの容量に関連するパラメータに指定したパラメータ値は、プロビジョン済みライターおよびリーダーに引き続き適用されます。
ほとんどすべてのパラメータは、Aurora Serverless v2 ライターとリーダーに対して、プロビジョン済みのものと同じように動作します。例外として、Aurora がスケーリング中に自動的に調整する一部のパラメータと、Aurora が最大容量設定に応じて固定値で保持するパラメータがあります。
例えば、バッファキャッシュ用に予約されているメモリ量は、ライターまたはリーダーがスケールアップすると増加し、スケールダウンすると減少します。そうすれば、データベースがビジー状態でないときにメモリを解放できます。逆に、Aurora では、最大容量設定に基づいて、自動的に適切な最大接続数を設定します。そうすれば、ロードが低下して Aurora Serverless v2 がスケールダウンしても、アクティブな接続が切断されません。Aurora Serverless v2 による特定のパラメータの取り扱いについての詳細は、「[Aurora Serverless v2 のパラメータグループを使用する](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.parameter-groups)」を参照してください。