Aurora Serverless v2 でのパフォーマンスとスケーリング - Amazon Aurora

Aurora Serverless v2 でのパフォーマンスとスケーリング

以下の手順と例は、Aurora Serverless v2 クラスターとそれに関連する DB インスタンスの容量範囲を設定する方法を示しています。以下の手順を使用して、DB インスタンスのビジー状態をモニタリングすることもできます。その結果によって容量範囲を増減させる必要があるかどうかを判断できます。

これらの手順を使用する前に、Aurora Serverless v2 のスケーリングの仕組みを把握しておいてください。スケーリングのメカニズムは、Aurora Serverless v1 とは異なります。詳細については、「」を参照してくださいAurora Serverless v2 でのスケーリング

Aurora クラスターの Aurora Serverless v2 での容量範囲の選択

Aurora Serverless v2 DB インスタンスでは、最初の Aurora Serverless v2 DB インスタンスを DB クラスターに追加するのと同時に、DB クラスター内のすべての DB インスタンスに適用する容量範囲を設定します。その手順については、「Aurora Serverless v2 クラスターの容量設定」を参照してください。

また、既存のクラスターの容量範囲を変更することもできます。以下のセクションでは、適切な最小値と最大値の選択方法と、容量範囲を変更した場合の動作について詳しく説明します。例えば、容量範囲を変更すると、一部の設定パラメータのデフォルト値が変更されることがあります。パラメータの変更をすべて適用するには、各 Aurora Serverless v2 DB インスタンスの再起動が必要になることがあります。

クラスターに Aurora Serverless v2 の最小容量設定を選択する

Aurora Serverless v2 の最小容量設定には、常に 0.5 を選択しようとします。この値にすることで、DB インスタンスが完全にアイドル状態になったときに最大限にスケールダウンできます。ただし、そのクラスターの使用方法やその他の設定によっては、最も効果的なのは別の値の場合もあります。最小容量設定を選択する場合は、以下の要素を考慮してください。

  • Aurora Serverless v2 DB インスタンスのスケーリングレートは、そのインスタンスの現在の容量によって異なります。現在の容量が大きいほど、スケールアップが速くなります。DB インスタンスを非常に大きな容量にすばやくスケールアップする必要があるときは、スケーリングレートの要件を満たす値に最小容量を設定することを検討してください。

  • 通常、ワークロードが高いか低いかを見越して DB インスタンスの DB インスタンスクラスを変更している場合は、その経験を活かして同等の Aurora Serverless v2 容量範囲を概算で見積もることができます。トラフィックが少ない場合に使用するメモリサイズを決定するには、「Aurora 用の DB インスタンスクラスのハードウェア仕様」を参照してください。

    例えば、クラスターのワークロードが低い場合に db.r6g.xlarge DB インスタンスクラスを使用するとします。その DB インスタンスクラスのメモリは 32 GiB です。したがって、Aurora 容量単位 (ACU) の最小設定を 16 に指定すると、ほぼ同じ容量にスケールダウンできる Aurora Serverless v2 DB インスタンスを設定できます。これは、各 ACU が約 2 GiB のメモリに対応するためです。db.r6g.xlarge DB インスタンスの使用率が低い場合に、DB インスタンスをさらにスケールダウンさせるため、やや小さい値を指定することがあります。

  • DB インスタンスのバッファキャッシュに一定量のデータがあるときにアプリケーションが最も効率的に動作する場合は、頻繁にアクセスされるデータを保持するのに十分なメモリ容量を持つ最小の ACU 設定を指定することを検討してください。それ以外の場合、Aurora Serverless v2 DB インスタンスがさらに小さいメモリサイズにスケールダウンした場合、一部のデータがバックキャッシュから削除されます。その後、DB インスタンスのスケールアップ時に、その情報が経時的に読み込まれてバッファキャッシュに戻ります。データをバッファキャッシュに戻すための I/O 量が大きい場合は、最小 ACU 値を大きくする方が効果的な場合があります。

  • ほとんどの時間、Aurora Serverless v2 DB インスタンスが特定の容量で実行されている場合、ベースラインよりも小さく、ただし小さすぎない最小容量の設定を検討してください。Aurora Serverless v2DB インスタンスが現在の容量が必要容量より極端に小さくない場合、スケールアップする規模と速度を最も効果的に見積もることができます。

  • プロビジョン済みワークロードのメモリ要件が T3 や T4g–などの小さな DB インスタンスクラスに対して大きすぎる場合は、R5 や R6g DB インスタンスに相当するメモリを提供する最小 ACU 設定を選択します。

    特に、指定された機能で使用するには、以下の最小容量をお勧めします (これらの推奨値は変更される場合があります)。

    • パフォーマンスインサイト – 2 ACU。

  • 場合によっては、クラスターに Aurora Serverless v2 ライターとは独立してスケーリングするリーダー DB インスタンスが含まれることがあります。その場合は、ライター DB インスタンスで書き込み集中型のワークロードでビジー状態のときに、リーダー DB インスタンスがライターからの変更を適用できるように十分な大きさの最小容量設定を選択します。昇格階層 2 ~ 15 のリーダーでレプリカのラグが発生した場合は、クラスターの最小容量設定を増やすことを検討してください。リーダー DB インスタンスのスケールをライターと一緒にスケーリングするか、個別にスケーリングするかを選択する方法の詳細については、「Aurora Serverless v2 リーダーの昇格階層の選択」を参照してください。

  • プロビジョン済みライターと Aurora Serverless v2 リーダーの混合設定クラスターの場合は、リーダーはライターと一緒にスケーリングできません。この場合、最小容量を小さく設定すると、レプリケーションの遅延が大きくなる場合があります。これは、データベースがビジー状態のときに、ライターからの変更を適用するのに十分な容量がリーダーにない可能性があるためです。クラスターがプロビジョン済みライターを使用する場合、最小容量をライターと同等のメモリと CPU の量を表す値に設定します。

  • Aurora PostgreSQL の場合、Aurora Serverless v2 容量の最小値を 0.5 に指定した場合、max_connections の設定は常時 2,000 が上限になります。Aurora PostgreSQL クラスターを重要な接続ワークロードに使用する場合は、最小 ACU 設定を 1 以上にすることを検討してください。Aurora Serverless v2 が max_connections 設定パラメータをどのように処理するかについての詳細は、「Aurora Serverless v2 の最大容量に基づいて Aurora が計算するパラメータ」を参照してください。

  • Aurora Serverless v2 DB インスタンスを最小容量から最大容量までスケーリングするのにかかる時間は、ACU の最小値と最大値の差によって異なります。現在の DB インスタンスの容量が大きい場合、Aurora Serverless v2 では、小さな容量から開始する場合よりも大きな増分で DB インスタンスをスケールアップします。したがって、比較的大きい最大容量を指定し、ほとんどの時間、DB インスタンスがその容量付近で使用されている場合は、最小 ACU の設定を引き上げることを検討してください。そうすれば、アイドル状態の DB インスタンスを、より迅速に最大容量にスケールアップできます。

クラスターに Aurora Serverless v2 の最大容量設定を選択する

Aurora Serverless v2 の最大容量設定には、常にある程度大きい値を選択しようとします。最大容量が大きいと、集中的なワークロードを実行している場合に、DB インスタンスは最もスケールアップできます。値を小さくすると、予期せぬ料金が発生する可能性を回避できます。そのクラスターの使用方法およびその他の設定によっては、最も効果的な値が当初検討していたより大きくなったり、小さくなったりすることがあります。最大容量設定を選択する場合は、以下の要素を考慮してください。

  • 最大容量は、最小容量より大きくなければなりません。最小容量と最大容量を同一に設定することができます。ただし、その場合は容量がスケールアップまたはスケールダウンすることはありません。したがって、テスト以外では、最小容量と最大容量に同じ値を使用することは適切ではありません。

  • 最大容量は 0.5 ACU より大きくなければなりません。ほとんどの場合、最小容量と最大容量は同じに設定できます。ただし、最小値と最大値の両方に 0.5 を指定することはできません。最大容量には 1 以上の値を使用します。

  • 通常、ワークロードが高いか低いかを見越して DB インスタンスの DB インスタンスクラスを変更している場合は、その経験を活用して同等の Aurora Serverless v2 容量範囲を見積もることができます。トラフィックが多い場合に使用するメモリサイズを決定するには、「Aurora 用の DB インスタンスクラスのハードウェア仕様」を参照してください。

    例えば、クラスターのワークロードが高い場合に db.r6g.4xlarge DB インスタンスクラスを使用するとします。その DB インスタンスクラスのメモリは 128 GiB です。したがって、ACU の最大設定を 64 に指定すると、ほぼ同じ容量にスケールアップできる Aurora Serverless v2 DB インスタンスを設定できます。これは、各 ACU が約 2 GiB のメモリに対応するためです。db.r6g.4xlarge DB インスタンスにワークロードを効果的に処理するのに十分な容量がないことがあり、DB インスタンスをよりスケールアップさせるために多少大きい値を指定することができます。

  • データベースの使用に予算の上限がある場合は、すべての Aurora Serverless v2 DB インスタンスを常に最大容量で実行しても、予算の上限に収まるような値を選択してください。クラスターに n の Aurora Serverless v2 DB インスタンスがある場合、クラスターが常に消費できる Aurora Serverless v2 の理論上の最大容量は、クラスターの最大 ACU 設定の n 倍であることに注意してください。(例えば、一部のリーダーがライターから独立してスケーリングする場合など、実際の消費量は少なくなる場合があります)。

  • Aurora Serverless v2 リーダー DB インスタンスを利用してライター DB インスタンスから一部の読み取り専用ワークロードをオフロードするには、最大容量設定を小さく選択できることがあります。これは、各リーダー DB インスタンスが、クラスターに単一の DB インスタンスしか含まれていない場合ほど大きくスケーリングする必要がないことを反映するためです。

  • データベースパラメータの設定間違いやアプリケーション内の非効率的なクエリによる過度の使用から保護したいとします。その場合、設定可能な理論的な最大値よりも最大容量設定を小さく選択することで、誤って過剰に使用することを回避できます。

  • 実際のユーザーアクティビティによるスパイクがまれしか発生しない場合は、最大容量設定を選択する際にその機会を考慮できます。アプリケーションが完全なパフォーマンスとスケーラビリティで動作し続けることを優先する場合は、通常の使用状況よりも大きい最大容量設定を指定できます。アクティビティの非常に極端なスパイク中、アプリケーションのスループットが低下しても問題ない場合は、最大容量を少し小さめに設定できます。アプリケーションの実行を維持するのに十分なメモリと CPU リソースがある設定を選択してください。

  • クラスターで 各 DB インスタンスのメモリ使用量を増やす設定をオンにする場合は、最大 ACU 値を決定する際にそのメモリを考慮に入れてください。このような設定には、パフォーマンスインサイト、Aurora MySQL 並列クエリ、Aurora MySQL パフォーマンススキーマ、Aurora MySQL バイナリログレプリケーションの設定が含まれます。それらの機能が使用されているときに、Aurora Serverless v2 DB インスタンスがワークロードを処理するのに十分なスケールアップができる 最大 ACU 値になっていることを確認します。最大 ACU の設定が小さいことと、メモリのオーバーヘッドが発生する Aurora 機能が組み合わされることによって発生する問題のトラブルシューティングについては、「メモリ不足エラーを回避する」を参照してください。

例: Aurora MySQL クラスターの Aurora Serverless v2 容量範囲の変更

以下の AWS CLI の例では、既存の Aurora MySQL クラスター内の Aurora Serverless v2 DB インスタンスの ACU 範囲を更新する方法を示しています。最初は、クラスターの ACU 範囲は 8 ~ 32 です。

$ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \ --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]' { "MinCapacity": 8.0, "MaxCapacity": 32.0 }

この時点で DB インスタンスには、以下の容量に関連した設定が適用されます。DB インスタンスはアイドル状態で、8 ACU にスケールダウンされます。バッファプールのサイズを読みやすい単位で表すため、2 の 30 乗 で割り算して、ギビバイト (GiB) 単位の測定値で表示します。これは、Aurora のメモリ関連の測定値では 10 の累乗ではなく 2 の累乗に基づく単位を使用しているためです。

mysql> select @@max_connections; +-------------------+ | @@max_connections | +-------------------+ | 3000 | +-------------------+ 1 row in set (0.00 sec) mysql> select @@innodb_buffer_pool_size; +---------------------------+ | @@innodb_buffer_pool_size | +---------------------------+ | 9294577664 | +---------------------------+ 1 row in set (0.00 sec) mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes; +-----------+ | gibibytes | +-----------+ | 8.65625 | +-----------+ 1 row in set (0.00 sec)

次に、クラスターの容量範囲を変更します。変更後、modify-db-cluster コマンドの実行が完了すると、クラスターの ACU 範囲は 12.5 ~ 80 になります。

$ aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \ --serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80 $ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \ --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]' { "MinCapacity": 12.5, "MaxCapacity": 80.0 }

容量範囲を変更したことで、一部の設定パラメータのデフォルト値が変更されました。Aurora では、これらの新しいデフォルトの一部をすぐに適用できます。ただし、一部のパラメータの変更は、再起動後に有効になります。この pending-reboot status は、一部のパラメータの変更を適用するために再起動が必要であることを示しています。

ヒント

お客様が DB インスタンスを再起動することで、これらのパラメータの変更を適用できます。または、Aurora が再起動するのを待って、次回の定期メンテナンス期間中にパラメータ変更を適用することもできます。

$ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \ --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]' { "DBClusterMembers": [ { "DBInstanceIdentifier": "serverless-v2-instance-1", "DBClusterParameterGroupStatus": "pending-reboot" } ] }

以下の例では、DB インスタンスの現在の容量に基づいて、innodb_buffer_pool_size パラメータが既に調整されていることを示しています。この時点では、クラスターはアイドル状態で、DB インスタンス serverless-v2-instance-1 では 12.5 ACU を消費しています。max_connections パラメータは、以前の容量範囲の値をそのまま反映しています。この値をリセットするには、DB インスタンスを再起動する必要があります。

mysql> select @@max_connections; +-------------------+ | @@max_connections | +-------------------+ | 3000 | +-------------------+ 1 row in set (0.00 sec) mysql> select @@innodb_buffer_pool_size; +---------------------------+ | @@innodb_buffer_pool_size | +---------------------------+ | 15572402176 | +---------------------------+ 1 row in set (0.00 sec) mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes; +---------------+ | gibibytes | +---------------+ | 14.5029296875 | +---------------+ 1 row in set (0.00 sec)

ここで、DB インスタンスを再起動して、再び利用可能になるまで待機します。

$ aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1 { "DBInstanceIdentifier": "serverless-v2-instance-1", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1

DB インスタンスを再起動したことで、これで pending-reboot ステータスがクリアされました。in-sync の値によって、Aurora が保留中のパラメータの変更をすべて適用したことを確認します。

$ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \ --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]' { "DBClusterMembers": [ { "DBInstanceIdentifier": "serverless-v2-instance-1", "DBClusterParameterGroupStatus": "in-sync" } ] }

以下の例では、再起動前と同じパラメータをチェックしています。innodb_buffer_pool_size パラメータは、アイドル状態の DB インスタンスの最終サイズに増加しました。ACU の最大値から計算した値を反映するようにmax_connections パラメータが増加しました。Aurora が max_connections に使用する計算式によると、メモリサイズが 2 倍になると 1,000 増加します。

mysql> select @@innodb_buffer_pool_size; +---------------------------+ | @@innodb_buffer_pool_size | +---------------------------+ | 16139681792 | +---------------------------+ 1 row in set (0.00 sec) mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes; +-----------+ | gibibytes | +-----------+ | 15.03125 | +-----------+ 1 row in set (0.00 sec) mysql> select @@max_connections; +-------------------+ | @@max_connections | +-------------------+ | 4000 | +-------------------+ 1 row in set (0.00 sec)

以下の例では、前と同じ手順で容量範囲を 0.5 ~ 128 ACU に設定しました。DB インスタンスを再起動して、すべての変更を静的パラメータに適用しました。ここで、アイドル状態の DB インスタンスのバッファキャッシュサイズは 1 GiB 未満なので、メビバイト (MiB) 単位で測定します。5,000 という max_connections 値は、最大容量設定のメモリサイズから算出しています。

mysql> select @@innodb_buffer_pool_size / pow(2,20) as mebibytes, @@max_connections; +-----------+-------------------+ | mebibytes | @@max_connections | +-----------+-------------------+ | 672 | 5000 | +-----------+-------------------+ 1 row in set (0.00 sec)

例: Aurora PostgreSQL クラスターの Aurora Serverless v2 容量範囲の変更

以下の CLI の例では、既存の Aurora PostgreSQL クラスター内の Aurora Serverless v2 DB インスタンスの ACU 範囲を更新する方法を示しています。最初は、クラスターの ACU 範囲は 8 ~ 32 です。

$ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \ --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]' { "MinCapacity": 8.0, "MaxCapacity": 32.0 }

この時点で DB インスタンスには、以下の容量に関連した設定が適用されます。DB インスタンスはアイドル状態で、8 ACU にスケールダウンされます。

postgres=> show shared_buffers; shared_buffers ---------------- 1327104 (1 row) postgres=> show max_connections; max_connections ----------------- 2000 (1 row)

次に、クラスターの容量範囲を変更します。変更後、modify-db-cluster コマンドの実行が完了すると、クラスターの ACU 範囲は 12.5 ~ 80 になります。

$ aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \ --serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80 $ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \ --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]' { "MinCapacity": 12.5, "MaxCapacity": 80.0 }

容量範囲を変更することで、一部の設定パラメータのデフォルト値が変更されます。Aurora では、これらの新しいデフォルトの一部をすぐに適用できます。ただし、一部のパラメータの変更は、再起動後に有効になります。この pending-reboot status は、一部のパラメータの変更を適用するために再起動が必要であることを示しています。

ヒント

お客様が DB インスタンスを再起動することで、これらのパラメータの変更を適用できます。または、Aurora が再起動するのを待って、次回の定期メンテナンス期間中にパラメータ変更を適用することもできます。

$ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \ --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]' { "DBClusterMembers": [ { "DBInstanceIdentifier": "serverless-v2-instance-1", "DBClusterParameterGroupStatus": "pending-reboot" } ] }

以下の例では、DB インスタンスの現在の容量に基づいて、shared_buffers パラメータが既に調整されていることを示しています。この時点では、クラスターはアイドル状態で、DB インスタンス serverless-v2-instance-1 では 12.5 ACU を消費しています。max_connections パラメータは、以前の容量範囲の値をそのまま反映しています。この値をリセットするには、DB インスタンスを再起動する必要があります。

postgres=> show shared_buffers; shared_buffers ---------------- 344064 (1 row) postgres=> show max_connections; max_connections ----------------- 1034 (1 row) postgres=> select name as parameter_name, setting, unit, (((setting::BIGINT)*8)/1024)::BIGINT as "size_MiB", postgres-> (((setting::BIGINT)*8)/1024/1024)::BIGINT as "size_GiB", pg_size_pretty((((setting::BIGINT)*8)*1024)::BIGINT) postgres-> from pg_settings where name in ('shared_buffers'); parameter_name | setting | unit | size_MiB | size_GiB | pg_size_pretty ----------------+---------+------+----------+----------+---------------- shared_buffers | 32768 | 8kB | 256 | 0 | 256 MB (1 row)

ここで、DB インスタンスを再起動して、再び利用可能になるまで待機します。

$ aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1 { "DBInstanceIdentifier": "serverless-v2-instance-1", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1

DB インスタンスを再起動したことで、これで pending-reboot ステータスがクリアされました。in-sync の値によって、Aurora が保留中のパラメータの変更をすべて適用したことを確認します。

$ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \ --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]' { "DBClusterMembers": [ { "DBInstanceIdentifier": "serverless-v2-instance-1", "DBClusterParameterGroupStatus": "in-sync" } ] }

以下の例では、再起動前と同じパラメータをチェックしています。shared_buffers パラメータは、アイドル状態の DB インスタンスの最終サイズに増加しました。ACU の最大値から計算した値を反映するようにmax_connections パラメータが増加しました。

postgres=> show shared_buffers; shared_buffers ---------------- 1425408 (1 row) postgres=> show max_connections; max_connections ----------------- 1034 (1 row) postgres=> select name as parameter_name, setting, unit, pg_size_pretty((((setting::BIGINT)*8)*1024)::BIGINT) postgres-> from pg_settings where name in ('shared_buffers'); parameter_name | setting | unit | pg_size_pretty ----------------+---------+------+---------------- shared_buffers | 1425408 | 8kB | 11 GB (1 row)

以下の例では、前と同じ手順で容量範囲を 0.5 ~ 128 ACU に設定しました。DB インスタンスを再起動して、すべての変更を静的パラメータに適用しました。2,000 という max_connections 値は、最大 ACU 設定からは算出されません。ACU の最小設定が 0.5 の場合、PostgreSQL 互換の Aurora Serverless v2 DB インスタンスでは、ACU の最大値に関係なくデフォルトの 2,000 のmax_connections 値を使用します。

postgres=> show shared_buffers; shared_buffers ---------------- 2228224 (1 row) postgres=> show max_connections; max_connections ----------------- 1034 (1 row) postgres=> select name as parameter_name, setting, unit, pg_size_pretty((((setting::BIGINT)*8)*1024)::BIGINT) from pg_settings where name in ('shared_buffers'); parameter_name | setting | unit | pg_size_pretty ----------------+---------+------+---------------- shared_buffers | 2228224 | 8kB | 17 GB (1 row)

Aurora Serverless v2 のパラメータグループを使用する

Aurora Serverless v2 DB クラスターの作成時に、特定の Aurora DB エンジンと、それに関連する DB クラスターパラメータグループを選択します。Aurora で、パラメータグループを使用してクラスター間で一貫した設定を適用する方法に精通していない場合は、「パラメータグループを使用する」を参照してください。パラメータグループの作成、修正、適用などのアクションに関する手順は、すべて Aurora Serverless v2 に適用されます。

パラメータグループ機能は、プロビジョン済みクラスターと、Aurora Serverless v2 DB インスタンスを含むクラスターの間でほぼ同じように動作します。

  • クラスター内のすべての DB インスタンスのデフォルトパラメータ値は、クラスターパラメータグループで定義されます。

  • これらの DB インスタンスのカスタム DB パラメータグループを指定することで、特定の DB インスタンスの一部のパラメータを上書きできます。これは、特定の DB インスタンスのデバッグまたはパフォーマンスのチューニング中に行うことができます。例えば、ある Aurora Serverless v2 DB インスタンスとプロビジョン済み DB インスタンスを含むクラスターがあるとします。この場合、カスタム DB パラメータグループを使用して、プロビジョン済み DB インスタンスに複数の異なるパラメータを指定できます。

  • Aurora Serverless v2 の場合、provisioned の値を持つすべてのパラメータをパラメータグループ内の SupportedEngineModes 属性に使用できます。Aurora Serverless v1 では、SupportedEngineModes 属性には serverless を持つパラメータのサブセットに限り使用できます。

デフォルトパラメータ値

プロビジョン済み Aurora Serverless v2 DB インスタンスと DB インスタンスの決定的な相違点は、DB インスタンスの容量に関連する特定のパラメータのカスタムパラメータ値を Aurora が上書きするということです。カスタムパラメータ値は、クラスター内のプロビジョン済み DB インスタンスにも適用されます。Aurora Serverless v2 DB インスタンスが Aurora パラメータグループのパラメータを解釈する方法についての詳細は、「Aurora クラスターの設定パラメータ」を参照してください。Aurora Serverless v2 が上書きする具体的なパラメータは、「Aurora Serverless v2 のスケールアップとスケールダウンの際に Aurora が調整するパラメータ」および「Aurora Serverless v2 の最大容量に基づいて Aurora が計算するパラメータ」を参照してください。

CLI コマンドの describe-db-cluster-parameters を使用し AWS リージョン に対しクエリすることで、さまざまな Aurora DB エンジンのデフォルトパラメータグループのデフォルト値リストを取得できます。Aurora Serverless v2 と互換性のあるエンジンバージョンの --db-parameter-group-family-db-parameter-group-name オプションに使用できる値は以下のとおりです。

データベースエンジンとバージョン パラメータグループファミリー デフォルトパラメータグループ名

Aurora MySQL バージョン 3

aurora-mysql8.0

default.aurora-mysql8.0

Aurora PostgreSQL バージョン 13.x

aurora-postgresql13

default.aurora-postgresql13

以下の例では、Aurora MySQL 3 と Aurora PostgreSQL 13 のデフォルトの DB クラスターグループからパラメータのリストを取得します。これらは、Aurora Serverless v2 で使用する Aurora MySQL と Aurora PostgreSQL のバージョンです

Linux、macOS、Unix の場合:

aws rds describe-db-cluster-parameters \ --db-cluster-parameter-group-name default.aurora-mysql8.0 \ --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \ --output text aws rds describe-db-cluster-parameters \ --db-cluster-parameter-group-name default.aurora-postgresql13 \ --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \ --output text

Windows の場合:

aws rds describe-db-cluster-parameters ^ --db-cluster-parameter-group-name default.aurora-mysql8.0 ^ --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^ --output text aws rds describe-db-cluster-parameters ^ --db-cluster-parameter-group-name default.aurora-postgresql13 ^ --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^ --output text

Aurora Serverless v2 のスケールアップとスケールダウンの際に Aurora が調整するパラメータ

オートスケーリング中、Aurora Serverless v2 は、容量の増減に対して各 DB インスタンスが最適に機能するように、パラメータを変更できる必要があります。したがって、容量に関連する一部のパラメータを上書きすることはできません。上書きできる一部のパラメータでは、固定値のハードコートはしないでください。容量に関連するこれらの設定には、以下の考慮事項が適用されます。

Aurora MySQL の場合、Aurora Serverless v2 では、スケーリング中に一部のパラメータのサイズを動的に変更します。Aurora Serverless v2 では、以下のパラメータには指定したカスタムパラメータ値を使用しません。

  • innodb_buffer_pool_size

  • innodb_purge_threads

  • table_definition_cache

  • table_open_cache

Aurora PostgreSQL の場合、Aurora Serverless v2 では、スケーリング中に以下のパラメータのパラメータサイズを動的に変更します。Aurora Serverless v2 では、以下のパラメータには指定したカスタムパラメータ値を使用しません。

  • shared_buffers

このセクションと Aurora Serverless v2 のスケールアップとスケールダウンの際に Aurora が調整するパラメータ に記載されている以外のパラメータについては、Aurora Serverless v2 DB インスタンスでは、プロビジョン済み DB インスタンスと同じように動作します。デフォルトのパラメータ値は、クラスターパラメータグループから継承されます。カスタムクラスターのパラメータグループを使用して、カスタムクラスター全体のデフォルトを変更できます。または、カスタム DB パラメータグループを使用して、特定の DB インスタンスのデフォルトを変更できます。動的パラメータはすぐに更新されます。静的パラメータの変更は、DB インスタンスの再起動後に有効になります。

Aurora Serverless v2 の最大容量に基づいて Aurora が計算するパラメータ

Aurora MySQL と Aurora PostgreSQL の両方に対して、Aurora Serverless v2 DB インスタンスでは、max_connections パラメータを一定に維持し、DB インスタンスのスケールダウン時に接続が切断されないようにします。このパラメータのデフォルト値は、DB インスタンスのメモリサイズを参照する数式から算出されます。プロビジョン済み DB インスタンスクラスの計算式とデフォルト値の詳細については、「Aurora MySQL DB インスタンスへの最大接続数」および「Aurora PostgreSQL DB インスタンスへの最大接続数」を参照してください。

Aurora Serverless v2 が計算式を評価する場合、現在の ACU 値ではなく、DB インスタンスの最大 Aurora 容量単位 (ACU) に基づいたメモリサイズを使用します。デフォルト値を変更する場合は、定数値を指定する代わりに、計算式のバリエーションを使用することをお勧めします。そうすれば、Aurora Serverless v2では、最大容量に基づいて適切なサイズに調整された設定を使用できます。

PostgreSQL 互換 Aurora Serverless v2 DB インスタンスでは、最小容量 0.5 ACU を指定すると、max_connections 設定の上限が 2,000 になります。

以下のパラメータについても、Aurora PostgreSQL では、max_connections と同様に 最大 ACU 設定に基づくメモリサイズから算出したデフォルト値を使用します。

  • autovacuum_max_workers

  • autovacuum_vacuum_cost_limit

  • autovacuum_work_mem

  • effective_cache_size

  • maintenance_work_mem

メモリ不足エラーを回避する

Aurora Serverless v2 DB インスタンスの 1 つが常に最大容量の制限に達している場合、Aurora ではこの状態を DB インスタンスのステータスを incompatible-parameters に設定することで表示します。DB インスタンスが incompatible-parameters のステータスの間、一部のオペレーションはブロックされます。例えば、エンジンバージョンをアップグレードすることはできません。

通常、DB インスタンスでは、メモリ不足エラーが原因で頻繁に再起動した場合、このステータスになります。Aurora では、このタイプの再起動が発生したときにイベントを記録します。イベントを表示するには、「Amazon RDS イベントの表示」の手順に従います。パフォーマンスインサイトや IAM 認証などの設定をオンにすることによるオーバーヘッドが原因で、メモリ使用量が異常に大きくなる場合があります。また、DB インスタンスのワークロードが高い場合や、多数のスキーマオブジェクトに関連するメタデータの管理から発生する場合があります。

DB インスタンスが頻繁に最大容量に達しないように、メモリの負荷が低くなると、Aurora では DB インスタンスのステータスを自動的に available に戻します。

この状態から回復させるには、以下アクションの一部またはすべてを実行できます。

  • クラスターの Aurora 容量単位 (ACU) の最小値を変更して、Aurora Serverless v2 DB インスタンスの容量の下限を引き上げます。これを行うことで、アイドル状態のデータベースが、クラスターでオンになっている機能に必要なメモリよりも少ない容量にスケールダウンする問題を回避できます。クラスターの ACU 設定を変更した後、Aurora Serverless v2 DB インスタンスを再起動します。そうすることで、Aurora がステータスを available に戻してリセットできるかが評価されます

  • クラスターの ACU の最大値を変更して、Aurora Serverless v2 DB インスタンスの容量の上限を引き上げます。そうすることで、クラスターでオンになっている機能やデータベースワークロードに、ビジー状態のデータベースが十分なメモリがある容量にスケールアップできない問題を回避できます。クラスターの ACU 設定を変更した後、Aurora Serverless v2 DB インスタンスを再起動します。そうすることで、Aurora がステータスを available に戻してリセットできるかが評価されます

  • メモリオーバーヘッドが必要な設定をオフにします。例えば、AWS Identity and Access Management (IAM)、パフォーマンスインサイト、Aurora MySQL バイナリログレプリケーションをオンにしているが、使用していないとします。その場合は、これらをオフにできます。または、クラスターの最小容量と最大容量値を調整することで、これらの機能で使用されるメモリを考慮することもできます。最小および最大容量設定の選択に関するガイドラインについては、「Aurora クラスターの Aurora Serverless v2 での容量範囲の選択」を参照してください。

  • DB インスタンスのワークロードを削減します。例えば、クラスターにリーダー DB インスタンスを追加して、読み取り専用クエリからのロードを他の DB インスタンスに分散させることができます。

  • アプリケーションで使用される SQL コードを調整して、使用されるリソースを削減します。例えば、クエリプランの確認、遅いクエリログのチェック、テーブルのインデックスの調整ができます。その他、従来の SQL チューニングを実行することもできます。

Aurora Serverless v2 の重要な Amazon CloudWatch メトリクス

Aurora Serverless v2 DB インスタンスで Amazon CloudWatch の使用を開始するには、「Amazon CloudWatch の Aurora Serverless v2 ログの表示」を参照してください。CloudWatch を使用して Aurora DB クラスターをモニタリングする方法の詳細については、「Amazon CloudWatch でログイベントをモニタリングする」を参照してください。

CloudWatch で Aurora Serverless v2 DB インスタンスを表示すると、ServerlessDatabaseCapacity メトリクスで各 DB インスタンスが消費する容量をモニタリングできます。また、DatabaseConnectionsQueries などの Aurora CloudWatch のスタンダードのメトリクスをすべてモニタリングできます。Aurora でモニタリング可能な CloudWatch メトリクスのすべてのリストは、「Amazon Aurora の Amazon CloudWatch メトリクス」を参照してください。メトリクスは、Amazon Aurora のクラスターレベルのメトリクス および Amazon Aurora のインスタンスレベルのメトリクス で、クラスターレベルとインスタンスレベルのメトリクスに分けることができます。

以下の CloudWatch インスタンスレベルのメトリクスは、Aurora Serverless v2 DB インスタンスはスケールアップとスケールダウンを理解するうえで重要なモニタリングです。これらすべてのメトリクスは 1 秒ごとに計算されます。そうすれば、Aurora Serverless v2 DB インスタンスの現在のステータスをモニタリングできます。Aurora Serverless v2 DB インスタンスが容量に関連するメトリクスのしきい値に近づいた場合に通知するアラームを設定できます。最小容量と最大容量設定は適切か、調整が必要かを判断できます。データベースの効率を最適化するため、どこに注力すべきかを判断できます。

  • ServerlessDatabaseCapacity。インスタンスレベルのメトリクスとして、現在の DB インスタンスの容量で表される ACU 値を報告します。クラスターレベルのメトリクスとして、クラスター内のすべての Aurora Serverless v2 DB インスタンスの ServerlessDatabaseCapacity 値の平均を表しています。このメトリクスは、Aurora Serverless v1 ではクラスターレベルのメトリクスに限られます。Aurora Serverless v2 では、DB インスタンスレベルとクラスターレベルで利用できます。

  • ACUUtilization。これは Aurora Serverless v2 での新しいメトリクスです。この値は割合 (%) で表されます。これは、ServerlessDatabaseCapacity メトリクスの値を DB クラスターの最大 ACU 値で割った値です。このメトリクスを解釈してアクションを実行するには、以下のガイドラインを考慮してください。

    • このメトリクスが 100.0 値に近づいた場合、DB インスタンスは限りなく大きくスケールアップしたことになります。クラスターの最大 ACU 設定を引き上げることを検討してください。これにより、ライターとリーダーの両方の DB インスタンスを、より大きな容量にスケーリングできます。

    • 読み取り専用のワークロードによって、リーダー DB インスタンスが 100.0ACUUtilization に近づき、一方でライター DB インスタンスは最大容量に近づいていないとします。その場合は、クラスターにリーダー DB インスタンスを追加することを検討してください。これにより、ワークロードの読み取り専用部分のワークロードをより多くの DB インスタンスに分散することで、各リーダー DB インスタンスのロードを軽減できます。

    • パフォーマンスとスケーラビリティが主な考慮事項である本番アプリケーションを実行しているとします。その場合、クラスターの最大 ACU 値を大きい数値に設定できます。目標は、ACUUtilization のメトリクスが常に 100.0 未満であることです。ACU の最大値を大きくすると、データベースのアクティビティに予期しないスパイクが発生した場合でも十分な余裕があり、安心につながります。実際に消費されたデータベース容量に対してのみ課金されます。

  • CPUUtilization。このメトリクスは Aurora Serverless v2 において、プロビジョン済みの DB インスタンスとは異なる解釈がされます。Aurora Serverless v2 の場合、この値は、現在の CPU の使用量を DB クラスターの最大 ACU 値で使用可能な CPU 容量で割った割合です。Aurora はこの値を自動的にモニタリングし、DB インスタンスが CPU 容量 を使用している割合が常に大きい場合、Aurora Serverless v2 DB インスタンスをスケールアップします。

    このメトリクスが 100.0 値に近づいた場合、DB インスタンスは最大 CPU 容量に達しています。クラスターの最大 ACU 設定を引き上げることを検討してください。このメトリクスがリーダー DB インスタンスで 100.0 値に近づいた場合、クラスターにリーダー DB インスタンスを追加することを検討してください。これにより、ワークロードの読み取り専用部分のワークロードをより多くの DB インスタンスに分散することで、各リーダー DB インスタンスのロードを軽減できます。

  • FreeableMemory。この値は、Aurora Serverless v2 DB インスタンスを最大容量にスケーリングしたときに利用できる未使用のメモリ量を表します。現在の容量が最大容量を下回る 各 ACU では、この値は約 2 GiB 増加します。したがって、DB インスタンスが限りなく大きくスケールアップされるまで、このメトリクスはゼロに近づきません。

    このメトリクスが 0 値に近づいた場合、DB インスタンスは可能な限りスケールアップし、使用可能なメモリの上限に近づいています。クラスターの最大 ACU 設定を引き上げることを検討してください。このメトリクスがリーダー DB インスタンスで 0 値に近づいた場合、クラスターにリーダー DB インスタンスを追加することを検討してください。これにより、ワークロードの読み取り専用部分のワークロードをより多くの DB インスタンスに分散することで、各リーダー DB インスタンスのメモリ使用量を軽減できます。

  • TempStorageIops。DB インスタンスにアタッチされたローカルストレージで実行された IOPS の数です。これには、読み取りと書き込みの両方の IOPS が含まれます。このメトリクスはカウントを表し、1 秒に 1 回測定されます。これは、Aurora Serverless v2 の新しいメトリクスです。詳細については、「」を参照してくださいAmazon Aurora のインスタンスレベルのメトリクス

  • TempStorageThroughput。DB インスタンスに関連するローカルストレージとの間で転送されるデータの量です。このメトリクスはバイトを表し、1 秒に 1 回測定されます。これは、Aurora Serverless v2 の新しいメトリクスです。詳細については、「」を参照してくださいAmazon Aurora のインスタンスレベルのメトリクス

通常、Aurora Serverless v2 DB インスタンスのスケールアップの大部分は、メモリ使用率と CPU アクティビティに起因しています。TempStorageIops および TempStorageThroughput のメトリクスは、DB インスタンスとローカルストレージデバイス間の転送のためのネットワークアクティビティが、予期しない容量増加の原因となるまれなケースを診断するのに役立ちます。他のネットワークアクティビティを監視するには、以下の既存のメトリクスを使用できます。

  • NetworkReceiveThroughput

  • NetworkThroughput

  • NetworkTransmitThroughput

  • StorageNetworkReceiveThroughput

  • StorageNetworkThroughput

  • StorageNetworkTransmitThroughput

Aurora で、一部またはすべてのデータベースログを CloudWatch に発行することができます。公開するログを選択するには、Aurora Serverless v2 DB インスタンスを含むクラスターに関連する DB クラスターパラメータグループの general_log や slow_query_log などの設定パラメータをオンにします。ログ設定パラメータをオフにすると、CloudWatch へのログの公開が停止します。不要になったログは CloudWatch で削除することもできます。

Aurora Serverless v2 メトリクスを AWS の請求に適用する方法

AWS の請求書に記載されている Aurora Serverless v2 の料金は、お客様がモニタリング可能な ServerlessDatabaseCapacity メトリクスと同じものに基づいて計算されています。請求メカニズムでは、Aurora Serverless v2 の容量を 1 時間の一部しか使用していない場合、このメトリクスで計算された CloudWatch の平均とは異なる場合があります。また、システムの問題で、短時間 CloudWatch メトリクスが利用できない場合にも異なる場合があります。したがって、お客様が ServerlessDatabaseCapacity の平均値から計算したものと、請求書に記載される ACU 時間の値が若干異なる場合があります。

Aurora Serverless v2 メトリクス用の CloudWatch コマンドの例

以下の AWS CLI の例では、Aurora Serverless v2 に関連する最も重要な CloudWatch メトリクスをモニタリングする方法を示しています。いずれの場合も、--dimensions パラメータの Value= 文字列は、お客様の Aurora Serverless v2 インスタンスの ID に置き換えてください。

以下の Linux の例では、DB インスタンスの最小、最大、平均の容量値を 1 時間で 10 分ごとに測定して表示しています。Linux の date コマンドでは、現在の日付と時刻を基準にして開始時刻と終了時刻を指定します。--query パラメータの sort_by 関数は、Timestamp のフィールドに基づいて結果を時系列でソートします。

aws cloudwatch get-metric-statistics --metric-name "ServerlessDatabaseCapacity" \ --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \ --namespace "AWS/RDS" --statistics Minimum Maximum Average \ --dimensions Name=DBInstanceIdentifier,Value=my_instance \ --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

以下の Linux の例では、クラスター内の各 DB インスタンスの容量のモニタリングをデモンストレーションしています。各 DB インスタンスの最小、最大、平均の容量使用率を測定しています。測定は、1 時間に 1 回、3 時間にわたって行います。これらの例では、ACU の固定数を表すの ServerlessDatabaseCapacity の代わりに、ACU の上限に対する割合を表す ACUUtilization メトリクスを使用しています。そうすれば、容量範囲の最小と最大の ACU 値の実際の数値を知る必要はありません。割合は 0 から 100 までの範囲で表示できます。

aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \ --start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \ --namespace "AWS/RDS" --statistics Minimum Maximum Average \ --dimensions Name=DBInstanceIdentifier,Value=my_writer_instance \ --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \ --start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \ --namespace "AWS/RDS" --statistics Minimum Maximum Average \ --dimensions Name=DBInstanceIdentifier,Value=my_reader_instance \ --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

以下の Linux の例では、前のものと同様の測定を実行します。この場合は、CPUUtilization のメトリクスのための測定になります。測定は、1 時間で 10 分ごとに行われます。この数値は、DB インスタンスの最大容量設定に利用可能な CPU リソースに基づき、利用可能な CPU リソースを表します。

aws cloudwatch get-metric-statistics --metric-name "CPUUtilization" \ --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \ --namespace "AWS/RDS" --statistics Minimum Maximum Average \ --dimensions Name=DBInstanceIdentifier,Value=my_instance \ --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

以下の Linux の例では、前のものと同様の測定を実行します。この場合は、FreeableMemory のメトリクスのための測定になります。測定は、1 時間で 10 分ごとに行われます。

aws cloudwatch get-metric-statistics --metric-name "FreeableMemory" \ --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \ --namespace "AWS/RDS" --statistics Minimum Maximum Average \ --dimensions Name=DBInstanceIdentifier,Value=my_instance \ --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

パフォーマンスインサイトで Aurora Serverless v2 のパフォーマンスをモニタリングする

パフォーマンスインサイトを使用して、Aurora Serverless v2 DB インスタンスのパフォーマンスをモニタリングできます。パフォーマンスインサイトの手順については、「Amazon Aurora での Performance Insights を使用したDB 負荷のモニタリング」を参照してください。

以下の新しいパフォーマンスインサイトカウンタが Aurora Serverless v2 DB インスタンスに適用されます。

  • os.general.serverlessDatabaseCapacity - ACU 内の DB インスタンスの現在の容量。この値は、ServerlessDatabaseCapacity DB インスタンスの CloudWatch メトリクスに対応します。

  • os.general.acuUtilization — 設定された最大容量のうち、現在の容量の割合。この値は、ACUUtilization DB インスタンスの CloudWatch メトリクスに対応します。

  • os.general.maxConfiguredAcu — この Aurora Serverless v2 DB インスタンスのために設定した最大容量。これは、ACU で測定されます。

  • os.general.minConfiguredAcu — この Aurora Serverless v2 DB インスタンスのために設定した最小容量。これは、ACU で測定されます

パフォーマンスインサイトカウンタのすべてのリストは、「Performance Insights カウンターメトリクス」を参照してください。

パフォーマンスインサイトで Aurora Serverless v2 DB インスタンスの vCPU 値が表示される場合、その値は、DB インスタンスの ACU 値に基づいた推定値を表します。デフォルトの 1 分間隔では、vCPU 値の小数分は整数に切り上げられます。それ以上の間隔の場合、表示される vCPU 値は、1 分ごとの vCPU 値の整数の平均になります。