Aurora Serverless v2で開始 - Amazon Aurora

Aurora Serverless v2で開始

既存のデータベースを変換して Aurora Serverless v2 を使用する手順は、次のとおりです。

  • プロビジョニングされた Aurora クラスターからアップグレードします。

  • Aurora Serverless v1 クラスターからアップグレードします。

  • Aurora Serverless v2 (プレビュー) クラスターからダンプおよび復元を実行します。

アップグレードされたクラスターが Aurora Serverless v2 の要件 に記載されている適切なエンジンバージョンを実行している場合、Aurora Serverless v2 DBインスタンスの追加を始めることができます。アップグレードされたクラスターに追加する最初の DB インスタンスは、プロビジョニングされた DB インスタンスである必要があります。次に、書き込みワークロード、読み取りワークロード、またはその両方の処理を、Aurora Serverless v2 DBインスタンスに切り替えることができます。

既存のクラスターをアップグレードまたは切り替えて Aurora Serverless v2 を使用する

プロビジョニングされたクラスターに、Aurora Serverless v2 をサポートするエンジンバージョンがある場合、Aurora Serverless v2 に切り替えると、アップグレードは必要ありません。その場合は、元のクラスターに Aurora Serverless v2 DB インスタンスを追加できます。クラスターを切り替えて、すべての Aurora Serverless v2 DB インスタンスを使用することができます。また、同じ DB クラスターで Aurora Serverless v2 とプロビジョニングされた DB インスタンスを組み合わせて使用することもできます。Aurora Serverless v2 をサポートする Aurora エンジンのバージョンについては、「Aurora Serverless v2 には、最小のエンジンバージョンが必要です。」を参照してください。

Aurora Serverless v2 をサポートしていない下位のエンジンバージョンを使用している場合、以下の一般的な手順を実行します。

  1. クラスターをアップグレードします。

  2. アップグレードされたクラスターのプロビジョニングされた書き込み DB インスタンスを作成します。

  3. クラスターを変更して Aurora Serverless v2 DB インスタンスを使用する

このようなアップグレードには、1 つ以上のスナップショット復元オペレーションが含まれる場合があります。複数のメジャーエンジンバージョン間でアップグレードを行う場合は、元のクラスターと最終クラスター間のすべてのメジャーバージョンについて中間アップグレードを実行します。

重要

スナップショットの復元やクローンを使用して Aurora Serverless v2 互換バージョンへのメジャーバージョンアップグレードを実行する場合、新しいクラスターに追加する最初の DB インスタンスはプロビジョニングされた DB インスタンスである必要があります。この追加により、アップグレードプロセスの最終段階が開始されます。

最終段階が発生するまで、クラスターには Aurora Serverless v2 サポートに必要なインフラストラクチャがありません。したがって、これらのアップグレードされたクラスターは、常にプロビジョニングされた書き込み DB インスタンスで始まります。その後、プロビジョニングされた DB インスタンスを Aurora Serverless v2 インスタンスに変換したり、フェイルオーバーさせることができます。

Aurora Serverless v1 から Aurora Serverless v2 へのアップグレードでは、中間ステップとしてプロビジョニングされたクラスターを作成する必要があります。次に、プロビジョニングされたクラスターで開始したときと同じアップグレードステップを実行します。

Aurora Serverless v2 (プレビュー) から Aurora Serverless v2 への切り替えは、論理ダンプと復元が含まれます。

MySQL 互換クラスターが Aurora Serverless v2 を使用するためのアップグレードパス

元のクラスターで Aurora MySQL を実行している場合は、クラスターのエンジンのバージョンとエンジンモードに応じて適切な手順を選択します。

元の Aurora MySQL クラスターがこれである場合 Aurora Serverless v2 に切り替えるには、この操作を行います
Aurora MySQL バージョン 3 を実行するプロビジョニングされたクラスターは MYSQL 8.0 との互換性があります。

これは、既存の Aurora MySQL クラスターからのすべての変換の最終段階です。

必要に応じて、バージョン 3.02.0 以降へのマイナーバージョンアップグレードを実行します。書き込み DB インスタンスにプロビジョニングされた DB インスタンスを使用します。Aurora Serverless v2 書き込み DB インスタンスを 1 つ追加します。フェイルオーバーを実行して、それを書き込み DB インスタンスにします。オプション: クラスター内の他のプロビジョニングされた DB インスタンスを Aurora Serverless v2 に変換するか、新しい Aurora Serverless v2 DB インスタンスを追加し、プロビジョニングされた DB インスタンスを削除します。

完全な手順と例については、「プロビジョニングされたクラスターから Aurora Serverless v2 への切り替え」を参照してください。

Aurora MySQL バージョン 2 を実行するプロビジョニングされたクラスターは MySQL 5.7 との互換性があります。 Aurora MySQL バージョン 3.02.0 以降へのメジャーバージョンのアップグレードを実行します。次に、Aurora MySQL バージョン 3 の手順に従って、Aurora Serverless v2 DB インスタンスを使用するようにクラスターを切り替えます。
Aurora MySQL バージョン 1 を実行するプロビジョニングされたクラスターは MySQL 5.6 との互換性があります。 Aurora MySQL バージョン 2 への中間メジャーバージョンのアップグレードを実行します。Aurora MySQL バージョン 3.02.0 以降への別のメジャーバージョンのアップグレードを実行します。次に、Aurora MySQL バージョン 3 の手順に従って、Aurora Serverless v2 DB インスタンスを使用するようにクラスターを切り替えます。
Aurora MySQL バージョン 2 を実行する Aurora Serverless v1 クラスターは MySQL 5.7 と互換性があります。

Aurora Serverless v1 からの変換を計画するには、まず Aurora Serverless v1 から Aurora Serverless v2 への移行 を参照してください。

スナップショット復元または高速クローン作成を使用して、Aurora Serverless v1 クラスターと同じデータを持つプロビジョニングされたクラスターを作成します。Aurora Serverless v1 クラスターと同じエンジンバージョンを選択します。次に、Aurora MySQL バージョン 2 のプロビジョニングされたクラスターからのアップグレードの手順に従います。

Aurora MySQL バージョン 1 を実行する Aurora Serverless v1 クラスターは MySQL g5.6 と互換性があります。

Aurora Serverless v1 からの変換を計画するには、まず Aurora Serverless v1 から Aurora Serverless v2 への移行 を参照してください。

スナップショット復元または高速クローン作成を使用して、Aurora Serverless v1 クラスターと同じデータを持つプロビジョニングされたクラスターを作成します。Aurora Serverless v1 クラスターと同じエンジンバージョンを選択します。次に、Aurora MySQL バージョン 1 のプロビジョニングされたクラスターからのアップグレードの手順に従います。

Aurora Serverless v2 (プレビュー) クラスター 論理ダンプを実行し、プレビュークラスターと同じエンジンバージョンを実行しているプロビジョニング済みクラスターに復元します。次に、手順に従ってそのバージョンからアップグレードします。

PostgreSQL 互換クラスターが Aurora Serverless v2 を使用するためのアップグレードパス。

元のクラスターで Aurora PostgreSQL を実行している場合は、クラスターのエンジンのバージョンとエンジンモードに応じて適切な手順を選択します。

元の Aurora PostgreSQL クラスターがこれである場合 Aurora Serverless v2 に切り替えるには、この操作を行います
Aurora PostgreSQL バージョン 13 を実行しているプロビジョニングされたクラスター

これは、既存の Aurora PostgreSQL クラスターからのすべての変換の最終段階です。

必要に応じて、バージョン 13.6 以降へのマイナーバージョンアップグレードを実行します。書き込み DB インスタンスにプロビジョニングされた DB インスタンスを追加します。Aurora Serverless v2 書き込み DB インスタンスを 1 つ追加します。その Aurora Serverless v2 インスタンスをライター DB インスタンスにするためにフェイルオーバーを実行します。オプション: クラスター内の他のプロビジョニングされた DB インスタンスを Aurora Serverless v2 に変換するか、新しい Aurora Serverless v2 DB インスタンスを追加し、プロビジョニングされた DB インスタンスを削除します。

完全な手順と例については、「プロビジョニングされたクラスターから Aurora Serverless v2 への切り替え」を参照してください。

Aurora PostgreSQL バージョン 12 を実行しているプロビジョニングされたクラスター Aurora PostgreSQL バージョン 13.6 以降へのメジャーバージョンアップグレードを実行します。次に、Aurora PostgreSQL バージョン 13 の手順に従って、Aurora Serverless v2 DB インスタンスを使用するようにクラスターを切り替えます。
Aurora PostgreSQL バージョン 11 を実行しているプロビジョニングされたクラスター Aurora PostgreSQL バージョン 13.6 以上に達するまで、連続する各 Aurora PostgreSQL メジャーバージョンへの中間メジャーバージョンアップグレードを実行します。開始バージョンによっては、Aurora PostgreSQL の最終バージョンに直接アップグレードできる場合があります。他の Aurora PostgreSQL メジャーバージョンに直接アップグレードできる Aurora PostgreSQL のバージョンについては、「メジャーバージョンのアップグレードを実施する方法」を参照してください。次に、Aurora MySQL バージョン 13 の手順に従って、Aurora Serverless v2 DB インスタンスを使用するようにクラスターを切り替えます。
Aurora PostgreSQL バージョン 10 を実行しているプロビジョニングされたクラスター Aurora PostgreSQL バージョン 13.6 以上に達するまで、連続する各 Aurora PostgreSQL メジャーバージョンへの中間メジャーバージョンアップグレードを実行します。開始バージョンによっては、Aurora PostgreSQL の最終バージョンに直接アップグレードできる場合があります。他の Aurora PostgreSQL メジャーバージョンに直接アップグレードできる Aurora PostgreSQL のバージョンについては、「メジャーバージョンのアップグレードを実施する方法」を参照してください。次に、Aurora MySQL バージョン 13 の手順に従って、Aurora Serverless v2 DB インスタンスを使用するようにクラスターを切り替えます。
Aurora PostgreSQL バージョン 10.18 を実行しているプロビジョニングされた Aurora Serverless v1 クラスター

Aurora Serverless v1 からの変換を計画するには、まず Aurora Serverless v1 から Aurora Serverless v2 への移行 を参照してください。

スナップショット復元または高速クローン作成を使用して、Aurora Serverless v1 クラスターと同じデータを持つプロビジョニングされたクラスターを作成します。Aurora Serverless v1 クラスターと同じエンジンバージョンを選択します。次に、Aurora PostgreSQL バージョン 10 のプロビジョニングされたクラスターからアップグレードする手順に従います。

プロビジョニングされたクラスターから Aurora Serverless v2 への切り替え

プロビジョニングされたクラスターを Aurora Serverless v2 を使用できるように切り替えるには、以下の手順に従います。

  1. Aurora Serverless v2 DBインスタンスで使用するためにプロビジョニングされたクラスターのアップグレードが必要かどうかを確認します。Aurora Serverless v2 と互換性がある Aurora バージョンについては、「Aurora Serverless v2 の要件」を参照してください。

    プロビジョニングされたクラスターが Aurora Serverless v2 で使用できないエンジンバージョンを実行している場合、クラスターのエンジンバージョンをアップグレードします。

    • MySQL 5.6 互換または MySQL 5.7 互換のプロビジョニングされたクラスターを使用している場合は、Aurora MySQL バージョン 3 へのアップグレード手順に従ってください。Aurora MySQL バージョン 3 へのアップグレード にある手順を実行します。

    • PostgreSQL バージョン 10 から 12 を実行している PostgreSQL 互換のプロビジョニングされたクラスターを使用している場合は、Aurora PostgreSQL バージョン 13 のアップグレード手順に従ってください。メジャーバージョンのアップグレードを実施する方法 にある手順を実行します。

  2. その他のクラスタープロパティは、Aurora Serverless v2 の要件 からの Aurora Serverless v2 要件と一致するように設定します。

  3. クラスターのスケーリング設定を設定します。「Aurora Serverless v2 クラスターの容量設定」の手順に従います。

  4. レイヤーに 1 つ以上の Aurora Serverless v2 DB インスタンスを追加します。DB クラスターに Aurora レプリカを追加する の一般的な手順に従います。新しい DB インスタンスごとに、AWS Management Console では サーバーレス、AWS CLI では db.serverless という特別な DB インスタンスクラス名、または Amazon RDS API を指定します。

    場合によっては、クラスター内に 1 つ以上のプロビジョニングされた読み取り DB インスタンスが既に存在することがあります。その場合、新しい DB インスタンスを作成する代わりに、リーダーの 1 つを Aurora Serverless v2 DB インスタンスに変換できます。これを行うには、「プロビジョン済みライターまたはリーダーを Aurora Serverless v2 に変換する」の手順に従います。

  5. Aurora Serverless v2 DB インスタンスの 1 つをクラスターの書き込み DB インスタンスとするフェイルオーバーオペレーションを行います。

  6. (オプション) プロビジョニングされた DB インスタンスを Aurora Serverless v2 に変換するか、クラスターから削除します。プロビジョン済みライターまたはリーダーを Aurora Serverless v2 に変換する または Aurora DB クラスターからの DB インスタンスの削除 の一般的な手順に従います。

    ヒント

    プロビジョニングされた DB インスタンスの削除は必須ではありません。Aurora Serverless v2 とプロビジョニングされた DB インスタンスの両方を含むクラスターを設定できます。ただし、Aurora Serverless v2 DB インスタンスのパフォーマンスとスケーリング特性に精通するまでは、すべて同じタイプの DB インスタンスでクラスターを設定することをお勧めします。

次の AWS CLI の例では、Aurora MySQL バージョン 3.02.0 を実行しているプロビジョニングされたクラスターを使用して、切り替え処理を示しています。クラスターには mysql-80 という名前が付けられています。このクラスターは、provisioned-instance-1provisioned-instance-2という 2 つのプロビジョニングされた DB インスタンス、ライターとリーダーから始まります。両者とも db.r6g.large DB インスタンスクラスを使用しています。

$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \ --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' --output text mysql-80 provisioned-instance-2 False provisioned-instance-1 True $ aws rds describe-db-instances --db-instance-identifier provisioned-instance-1 \ --output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]' provisioned-instance-1 db.r6g.large $ aws rds describe-db-instances --db-instance-identifier provisioned-instance-2 \ --output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]' provisioned-instance-2 db.r6g.large

いくつかのデータを含むテーブルを作成します。これにより、切り替えの前後のクラスターのデータとオペレーションが同じであることを確認できます。

mysql> create database serverless_v2_demo; mysql> create table serverless_v2_demo.demo (s varchar(128)); mysql> insert into serverless_v2_demo.demo values ('This cluster started with a provisioned writer.'); Query OK, 1 row affected (0.02 sec)

まず、クラスターに容量範囲を追加します。そうしないと、Aurora Serverless v2 DB インスタンスをクラスターに追加する際にエラーが発生します。この手順で AWS Management Console を使用すると、最初の Aurora Serverless v2 DB インスタンスを追加するときに、そのステップが自動的に行われます。

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 \ --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql An error occurred (InvalidDBClusterStateFault) when calling the CreateDBInstance operation: Set the Serverless v2 scaling configuration on the parent DB cluster before creating a Serverless v2 DB instance. $ # The blank ServerlessV2ScalingConfiguration attribute confirms that the cluster doesn't have a capacity range set yet. $ aws rds describe-db-clusters --db-cluster-identifier mysql-80 --query 'DBClusters[*].ServerlessV2ScalingConfiguration' [] $ aws rds modify-db-cluster --db-cluster-identifier mysql-80 \ --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16 { "DBClusterIdentifier": "mysql-80", "ServerlessV2ScalingConfiguration": { "MinCapacity": 0.5, "MaxCapacity": 16 } }

新しい DB インスタンスに db.serverless DB インスタンスクラスを指定し、元の DB インスタンスに代わる 2 つの Aurora Serverless v2 リーダーを作成します。

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql { "DBInstanceIdentifier": "serverless-v2-instance-1", "DBClusterIdentifier": "mysql-80", "DBInstanceClass": "db.serverless", "DBInstanceStatus": "creating" } $ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-2 \ --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql { "DBInstanceIdentifier": "serverless-v2-instance-2", "DBClusterIdentifier": "mysql-80", "DBInstanceClass": "db.serverless", "DBInstanceStatus": "creating" } $ # Wait for both DB instances to finish being created before proceeding. $ aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1 && \ aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-2

フェイルオーバーを実行して、Aurora Serverless v2 DB インスタンスの 1 つをクラスターの新しいライターにします。

$ aws rds failover-db-cluster --db-cluster-identifier mysql-80 \ --target-db-instance-identifier serverless-v2-instance-1 { "DBClusterIdentifier": "mysql-80", "DBClusterMembers": [ { "DBInstanceIdentifier": "serverless-v2-instance-1", "IsClusterWriter": false, "DBClusterParameterGroupStatus": "in-sync", "PromotionTier": 1 }, { "DBInstanceIdentifier": "serverless-v2-instance-2", "IsClusterWriter": false, "DBClusterParameterGroupStatus": "in-sync", "PromotionTier": 1 }, { "DBInstanceIdentifier": "provisioned-instance-2", "IsClusterWriter": false, "DBClusterParameterGroupStatus": "in-sync", "PromotionTier": 1 }, { "DBInstanceIdentifier": "provisioned-instance-1", "IsClusterWriter": true, "DBClusterParameterGroupStatus": "in-sync", "PromotionTier": 1 } ], "Status": "available" }

その変更が有効になるまで、数秒かかります。その時点で、Aurora Serverless v2 ライターと Aurora Serverless v2 リーダーがあることになります。したがって、元のプロビジョニングされた DB インスタンスも必要ありません。

$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \ --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \ --output text mysql-80 serverless-v2-instance-1 True serverless-v2-instance-2 False provisioned-instance-2 False provisioned-instance-1 False

切り替え手順の最後のステップは、プロビジョニングされた両方の DB インスタンスを削除することです。

$ aws rds delete-db-instance --db-instance-identifier provisioned-instance-2 --skip-final-snapshot { "DBInstanceIdentifier": "provisioned-instance-2", "DBInstanceStatus": "deleting", "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.02.0", "DBInstanceClass": "db.r6g.large" } $ aws rds delete-db-instance --db-instance-identifier provisioned-instance-1 --skip-final-snapshot { "DBInstanceIdentifier": "provisioned-instance-1", "DBInstanceStatus": "deleting", "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.02.0", "DBInstanceClass": "db.r6g.large" }

最終チェックとして、Aurora Serverless v2 ライター DB インスタンスから元のテーブルにアクセスでき、書き込みが可能であることを確認します。

mysql> select * from serverless_v2_demo.demo; +---------------------------------------------------+ | s | +---------------------------------------------------+ | This cluster started with a provisioned writer. | +---------------------------------------------------+ 1 row in set (0.00 sec) mysql> insert into serverless_v2_demo.demo values ('And it finished with a Serverless v2 writer.'); Query OK, 1 row affected (0.01 sec) mysql> select * from serverless_v2_demo.demo; +---------------------------------------------------+ | s | +---------------------------------------------------+ | This cluster started with a provisioned writer. | | And it finished with a Serverless v2 writer. | +---------------------------------------------------+ 2 rows in set (0.01 sec)

また、Aurora Serverless v2 読み取り DB インスタンスに接続し、新たに書き込まれたデータがそこでも利用できることを確認します。

mysql> select * from serverless_v2_demo.demo; +---------------------------------------------------+ | s | +---------------------------------------------------+ | This cluster started with a provisioned writer. | | And it finished with a Serverless v2 writer. | +---------------------------------------------------+ 2 rows in set (0.01 sec)

Aurora Serverless v1 から Aurora Serverless v2 への移行

既に Aurora Serverless v1 を使用していて、Aurora Serverless v2 を使用したい場合は、まず違いをよく理解してください。以下では、以下では、Aurora Serverless v1 と Aurora Serverless v2 の違いについて説明します。また、DB クラスターとアプリケーションを別の DB クラスターに移動する方法も学習できます。

Aurora Serverless v2 と Aurora Serverless v1 の比較

既に Aurora Serverless v1 を使用している場合、Aurora Serverless v1 と Aurora Serverless v2 の大きな違いを知ることができます。読み取り DB インスタンスのサポートなどのアーキテクチャの違いにより、新しいタイプのユースケースが生まれます。

次の表を使用して、Aurora Serverless v2 と Aurora Serverless v1 の最も重要な違いを理解できます。

Aurora Serverless v2 と Aurora Serverless v1 要件の比較

Aurora Serverless v2 または Aurora Serverless v1 を使用して、データベースを実行するためのさまざまな要件の概要を次の表に示します。Aurora Serverless v2 では、Aurora Serverless v1 よりも上位バージョンの Aurora MySQL および Aurora PostgreSQL DB エンジンが提供されています。

特徴 Aurora Serverless v2 の要件 Aurora Serverless v1 の要件
DB エンジン Aurora MySQL、Aurora PostgreSQL Aurora MySQL、Aurora PostgreSQL
サポートされている Aurora MySQL バージョン バージョン 3.02.0 は MySQL 8.0 と互換性があります。 バージョン 1 と 2 は、MySQL 5.6 および 5.7 と互換性があります。
サポートされている Aurora PostgreSQL バージョン バージョン 13.6 バージョン 10.18
プロビジョニングされた Aurora Serverless v1 クラスターからの変換 次の方法を使用します。
  • 1 つまたは複数の Aurora Serverless v2 読み取り DB インスタンスを既存のプロビジョニングされたクラスターに追加します。ライターに Aurora Serverless v2 を使用する場合は、Aurora Serverless v2 DB インスタンスのいずれかにフェイルオーバーを実行します。クラスター全体で Aurora Serverless v2 DB インスタンスを使用する場合、Aurora Serverless v2 DB インスタンスをライターに昇格させた後、プロビジョニングされた書き込み DB インスタンスを削除してください。

  • 適切な DB エンジンとエンジンバージョンの新しいクラスターを作成します。標準的な方法のいずれかを使用します。例えば、クラスタースナップショットを復元したり、既存のクラスターのクローンを作成できます。新しいクラスターの一部またはすべての DB インスタンスで Aurora Serverless v2 を選択します。

    クローン作成を使用して新しいクラスターを作成する場合、エンジンのバージョンを同時にアップグレードすることはできません。元のクラスターが、Aurora Serverless v2 と互換性があるエンジンバージョンを既に実行していることを確認します。

プロビジョニングされたクラスターのスナップショットをリストアして、新しい Aurora Serverless v1 クラスターを作成します。
利用可能な DB インスタンスクラス 特別な DB インスタンスクラス db.serverless。AWS Management Console では、サーバーレスと表記されています。 該当しません。
ポート MySQL または PostgreSQL と互換性のあるポート デフォルトの MySQL または PostgreSQL ポートのみ
パブリック IP アドレスは許可されていますか。 はい いいえ
Virtual private Cloud (VPC) が必要ですか。 いいえ はい。各 Aurora Serverless v1 クラスターは、VPC に割り当てられた 2 つのインターフェイスとゲートウェイロードバランサーのエンドポイントを消費します。

Aurora Serverless v2 と Aurora Serverless v1 のスケーリングと可用性の比較

Aurora Serverless v2 と Aurora Serverless v1 のスケーラビリティおよび可用性の違いを以下の表にまとめました。

Aurora Serverless v2 スケーリングは、Aurora Serverless v1 のスケーリングよりも応答性が高く、きめ細かく、破壊性が低くなります。Aurora Serverless v2 は、DB インスタンスのサイズを変更することでも、DB クラスターに DB インスタンスを追加することでも拡張できます。また、Aurora グローバルデータベースに他の AWS リージョン のクラスターを追加することでスケールすることもできます。対照的に、Aurora Serverless v1 はライターの容量を増減させるだけでスケールできます。Aurora Serverless v1 クラスターのすべてのコンピューティングは、1 つのアベイラビリティーゾーンと 1 つの AWS リージョン で実行されます。

特徴 Aurora Serverless v2 スケーリングと高可用性の動作 Aurora Serverless v1 スケーリングと高可用性の動作
最小 Aurora 容量ユニット (ACU) (Aurora MySQL) 0.5 クラスターが実行中の場合は 1、クラスターが一時停止しているときは 0。
最小 ACU (Aurora PostgreSQL) 0.5 クラスターが実行中の場合は 2、クラスターが一時停止しているときは 0。
最大 ACU (Aurora MySQL) 128 256
最 大ACU (Aurora PostgreSQL) 128 384
クラスターの停止 プロビジョニングされたクラスターと同じクラスター停止および開始機能を使用して、手動でクラスターを停止および開始できます。 クラスターは、タイムアウト後に自動的に一時停止します。アクティビティが再開すると、利用可能になるまでに少し時間がかかります。
DB インスタンスのスケーリング 0.5 ACU の最小増分でスケールアップおよびスケールダウン ACU を倍増または半分にすることでスケールアップとスケールダウン
DB インスタンス数 プロビジョニングされたクラスターと同じ: 1 つの書き込み DB インスタンス、最大 15 の読み取り DB インスタンス。 1 つの DB インスタンスは、読み取りと書き込みの両方を処理します。
SQL ステートメントの実行中にスケーリングが発生する可能性がありますか。 はい。Aurora Serverless v2 はクワイエットポイントを待つ必要はありません。 いいえ。例えば、スケーリングは、長時間実行されるトランザクション、一時テーブル、およびテーブルロックの完了を待ちます。
読み取り DB インスタンスはライターとともにスケーリングされます オプション。 該当しません。
最大ストレージ 128 TiB データベースエンジンとバージョンに応じて、128 TiB または 64 TiB。
スケーリング時にバッファキャッシュが保持されます はい。バッファキャッシュは動的にサイズ変更されます。 いいえ。バッファキャッシュは、スケーリング後にリウォームされます。
フェイルオーバー はい、プロビジョニングされたクラスターの場合と同じです。 ベストエフォートのみ。キャパシティの可用性によります。Aurora Serverless v2 中より遅い。
マルチ AZ 機能 はい、プロビジョニングされた場合と同じです。マルチ AZ クラスターには、第 2 アベイラビリティーゾーン (AZ) 内の読み取り DB インスタンスが必要です。マルチ AZ クラスターの場合、Aurora は AZ に障害が発生した場合にマルチ AZ フェイルオーバーを実行します。 Aurora Serverless v1 クラスターは、すべてのコンピューティングを 1 つの AZ で実行します。AZ に障害が発生した場合の復旧はベストエフォートのみであり、キャパシティの可用性によります。
Aurora Global Database はい いいえ
メモリプレッシャーに基づくスケーリング はい いいえ
CPU 負荷に基づくスケーリング はい はい
ネットワークトラフィックに基づくスケーリング はい。ネットワークトラフィックのメモリと CPU オーバーヘッドに基づきます。max_connections パラメータは一定のままであり、スケールダウン時に接続がドロップされないようにします。 はい、接続の数に基づいています。
スケーリングイベントのタイムアウトアクション いいえ はい
AWS Auto Scaling で新しい DB インスタンスをクラスターに追加する 該当しません。Aurora Serverless v2 読み取り DB インスタンスを昇格階層 2~15 で作成し、低容量にスケールダウンしておくことができます。 いいえ。読み取り DB インスタンスは利用できません。

Aurora Serverless v2 と Aurora Serverless v1 機能サポートの比較

次の表に以下の内容がまとめてあります。

  • Aurora Serverless v2 では使用できるが、Aurora Serverless v1 では使用できない機能

  • Aurora Serverless v1 と Aurora Serverless v2 で異なる働きをする機能

  • Aurora Serverless v2 では現在使用できない機能

Aurora Serverless v2 には、Aurora Serverless v1 では提供されていないプロビジョニングされたクラスターの機能が多く含まれています。

特徴 Aurora Serverless v2 の機能 Aurora Serverless v1 の機能
クラスタートポロジ Aurora Serverless v2 は個々の DB インスタンスのプロパティです。クラスターには複数の Aurora Serverless v2 DB インスタンス、または Aurora Serverless v2 とプロビジョニングされた DB インスタンスの組み合わせを含めることができます。 Aurora Serverless v1 クラスターは、DB インスタンスの概念を使用しません。クラスターの作成後は、Aurora Serverless v1 プロパティを変更できません。
設定パラメータ プロビジョニングされたクラスターの場合とほぼ同じパラメータを変更できます。詳細については、「Aurora Serverless v2 のパラメータグループを使用する」を参照してください。 パラメータのサブセットのみを変更できます。
パラメータグループ クラスターパラメータグループと DB パラメータグループ SupportedEngineModes 属性に provisioned 値を持つパラメータが使用できます。それは Aurora Serverless v1 よりもはるかに多くのパラメータです。 クラスターパラメータグループのみ。SupportedEngineModes 属性に serverless 値を持つパラメータが使用できます。
クラスターボリュームの暗号化 オプション。 必須。Amazon Aurora の暗号化された DB クラスターの制限事項 での制限事項は、すべての Aurora Serverless v1 クラスターに適用されます。
クロスリージョンスナップショット はい スナップショットは、独自の AWS Key Management Service (AWS KMS) キーで暗号化する必要があります。
TLS/SSL はい。サポートは、プロビジョニングされたクラスターの場合と同じです。使用に関する情報については、「Aurora Serverless v2 での TLS/SSL の使用」を参照してください。 はい。プロビジョニングされたクラスターの TLS サポートとはいくつかの違いがあります。使用に関する情報については、「Aurora Serverless v1 での TLS/SSL の使用」を参照してください。
クローン作成 Aurora Serverless v2 と互換性がある DB エンジンバージョン間のみ。クローン作成を使用して、Aurora Serverless v1 またはプロビジョニングされたクラスターの以前のバージョンからアップグレードすることはできません。 Aurora Serverless v1 と互換性がある DB エンジンバージョン間のみ。
Amazon S3 バックアップからの復元 現在ではありません。 はい
Amazon CloudWatch への ログのアップロード オプション。どのログをオンにするかと、CloudWatch にアップロードするログを選択します。 オンになっているすべてのログは CloudWatch に自動的にアップロードされます。
Data API が利用可能 いいえ はい
クエリエディタが使用可能 いいえ はい
Performance Insights はい いいえ
Amazon RDS Proxy が使用可能 はい いいえ

Aurora Serverless v1 ユースケースの Aurora Serverless v2 への適応

Aurora Serverless v1 のユースケースに応じて、次のように Aurora Serverless v2 機能を利用するようにそのアプローチを適応させることができます。

負荷の軽い Aurora Serverless v1 クラスターがあり、コストを最小限に抑えながら継続的な可用性を維持することを優先するとします。Aurora Serverless v2 では、Aurora Serverless v1 の最小 ACU が 1 であるのに対し、0.5 と小さく設定することが可能です。マルチ AZ 設定を作成することで、可用性を高めることができます。読み取り DB インスタンスの最小値は 0.5 ACU です。

開発およびテストシナリオで使用する Aurora Serverless v1 クラスターがあるとします。この場合、コストも高い優先度になりますが、クラスターを常時利用可能にする必要はありません。現在、Aurora Serverless v2 はクラスターが完全にアイドル状態になったときに自動的に一時停止することはありません。代わりに、不要になったときにクラスターを手動で停止し、次のテストまたは開発サイクルの時間になったときにクラスターを開始できます。

重いワークロードを持つ Aurora Serverless v1 クラスターがあるとします。Aurora Serverless v2 を使用する同等のクラスターは、より詳細にスケールすることができます。例えば、Aurora Serverless v1 は、容量を 2 倍にすることでスケールします (例えば 64 ACU から 128 ACU)。反対に、Aurora Serverless v2 DB インスタンスは、これらの数字の中間の値にスケールできます。

ワークロードが、Aurora Serverless v1 で使用可能な容量より大きな総容量を必要とするとします。複数の Aurora Serverless v2 読み取り DB インスタンスを使用して、書き込み DB インスタンスからワークロードの読み取り負荷の高い部分をオフロードすることができます。読み取り負荷の高いワークロードを複数の読み取り DB インスタンスに分割することもできます。

書き込みが多いワークロードの場合、大規模なプロビジョニング された DB インスタンスをライターとして、1 つまたは複数の Aurora Serverless v2 読み取り DB インスタンスと一緒にクラスターを設定することができます。

Aurora Serverless v1 クラスターから Aurora Serverless v2 クラスターへのアップグレード

Aurora Serverless v1 クラスターをアップグレードして Aurora Serverless v2 を使用するには、以下の手順に従います。

  1. Aurora Serverless v1 クラスターのクラスタースナップショットを作成します。「DB クラスタースナップショットの作成」の手順に従います。

  2. スナップショットを復元して、新しいプロビジョニングされたクラスターを作成します。「DB クラスターのスナップショットからの復元」の手順に従います。新しいクラスターのエンジンバージョンは、Aurora Serverless v1 クラスターより 1 つ上のメジャーバージョンを選択します。それは、Aurora Serverless v1 は Aurora Serverless v2 と同じメジャーな Aurora MySQL と Aurora PostgreSQL のバージョンで利用できないからです。したがって、Aurora Serverless v1 から Aurora Serverless v2 への移行には、少なくとも 1 回のメジャーバージョンアップが必要です。

  3. これ以降は、プロビジョニングされたクラスターを Aurora Serverless v2 を使用するようにアップグレードするのと同じ手順に従います。詳細については、「プロビジョニングされたクラスターから Aurora Serverless v2 への切り替え」を参照してください。

    Aurora Serverless v1 クラスターが起動したエンジンのバージョンによっては、連続するメジャーバージョンへの中間アップグレードを追加で行う必要があります。

Aurora Serverless v2 (プレビュー) からの Aurora Serverless v2 へのアップグレード

Aurora Serverless v2 プレビューを使用して作成した Aurora MySQL クラスターは、スナップショット復元メカニズムを使用してアップグレードすることはできません。プレビューは、テストのみを目的としています。プレビュークラスターには、本番稼働用データやビジネスクリティカルなデータを含めないでください。Aurora Serverless v2 プレビュークラスターから Aurora Serverless v2 にデータを取り込む必要がある場合、論理ダンプと復元を実行します。mysqldump を使用した MySQL から Amazon Aurora への移行 で説明した mysqldump コマンドを使用します。