Aurora Serverless v2 でのパフォーマンスとスケーリング - Amazon Aurora
容量範囲を選択するAurora Serverless v2 のパラメータグループを使用するメモリ不足エラーを回避する重要な CloudWatch メトリクスパフォーマンスインサイトで Aurora Serverless v2 のパフォーマンスをモニタリングするAurora Serverless v2 の容量の問題のトラブルシューティング

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 グローバルデータベース — 8 ACU (プライマリ AWS リージョン のみに適用)

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

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

  • Aurora Serverless v2 DB インスタンスの max_connections パラメータの値は、最大 ACU から得られるメモリサイズに基づきます。ただし、PostgreSQL 互換 DB インスタンスで 0.5 ACU の最小容量を指定すると、max_connections の最大値は 2,000 に制限されます。

    Aurora PostgreSQL クラスターを重要な接続ワークロードに使用する場合は、最小 ACU 設定を 1 以上にすることを検討してください。Aurora Serverless v2 が max_connections 設定パラメータをどのように処理するかについての詳細は、「Aurora Serverless v2 の最大接続数」を参照してください。

  • 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 範囲を更新する方法を示しています。最初は、クラスターの容量範囲は 8～32 ACU です。

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

DB インスタンスはアイドル状態で、8 ACU にスケールダウンされます。この時点で DB インスタンスには、以下の容量に関連した設定が適用されます。バッファプールのサイズを読みやすい単位で表すため、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 は、一部のパラメータの変更を適用するために再起動が必要であることを示しています。

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 インスタンス serverless-v2-instance-1 では 12.5 ACU を消費しています。innodb_buffer_pool_size パラメータは、DB インスタンスの現在の容量に基づいて、既に調整されています。max_connections パラメータは、以前の最大容量の値をそのまま反映しています。この値をリセットするには、DB インスタンスを再起動する必要があります。

注記

カスタム DB パラメータグループで max_connections パラメータを直接設定する場合、再起動は必要ありません。

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

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 範囲を更新する方法を示しています。

  1. クラスターの容量範囲は 0.5～1 ACU から始まります。

  2. 容量範囲を 8～32 ACU に変更します。

  3. 容量範囲を 12.5～80 ACU に変更します。

  4. 容量範囲を 0.5～128 ACU に変更します。

  5. 容量を初期値の 0.5～1 ACU の範囲に戻します。

次の図は、Amazon CloudWatch の容量の変化を示しています。

CloudWatch の Aurora Serverless v2 の容量の変化を示すグラフ

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

postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)

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

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

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

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 インスタンス serverless-v2-instance-1 では 8.0 ACU を消費しています。shared_buffers パラメータは、DB インスタンスの現在の容量に基づいて、既に調整されています。max_connections パラメータは、以前の最大容量の値をそのまま反映しています。この値をリセットするには、DB インスタンスを再起動する必要があります。

注記

カスタム DB パラメータグループで max_connections パラメータを直接設定する場合、再起動は必要ありません。

postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 1425408
(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"
        }
    ]
}

再起動後、max_connections は新しい最大容量が反映された値を示します。

postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 1425408
(1 row)

次に、クラスターの容量範囲を 12.5～80 ACU に変更します。

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
}

この時点では、クラスターはアイドル状態で、DB インスタンス serverless-v2-instance-1 では 12.5 ACU を消費しています。shared_buffers パラメータは、DB インスタンスの現在の容量に基づいて、既に調整されています。max_connections の値は 5000 のままです。

postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 2211840
(1 row)

再起動しますが、パラメータ値は変わりません。これは、Aurora PostgreSQL を実行している Aurora Serverless v2 DB クラスターの max_connections の最大値が 5000 であるためです。

postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 2211840
(1 row)

ここで、容量範囲を 0.5～128 ACU に設定します。DB クラスターは 10 ACU、2 ACU の順にスケールダウンします。DB インスタンスを再起動します。

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

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)

Aurora Serverless v2 DB インスタンスの max_connections の値は、最大 ACU から得られるメモリサイズに基づきます。ただし、PostgreSQL 互換 DB インスタンスで 0.5 ACU の最小容量を指定すると、max_connections の最大値は 2,000 に制限されます。

ここで、容量を初期範囲の 0.5～1 ACU に戻し、DB インスタンスを再起動します。max_connections パラメータは元の値に戻されました。

postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(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 PostgreSQL バージョン 14.x

aurora-postgresql14

default.aurora-postgresql14

Aurora PostgreSQL バージョン 15.x

aurora-postgresql15

default.aurora-postgresql15

Aurora PostgreSQL バージョン 16.x

aurora-postgresql16

default.aurora-postgresql16

以下の例では、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 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 では、最大容量に基づいて適切な設定を使用できます。

Aurora Serverless v2 DB クラスターの最大容量を変更する場合、Aurora Serverless v2 DB インスタンスを再起動して max_connections 値を更新する必要があります。これは、Aurora Serverless v2 の場合、max_connections が静的パラメータであるためです。

次の表は、最大 ACU 値に基づいた Aurora Serverless v2 の max_connections のデフォルト値を示しています。

最大 ACU Aurora MySQL のデフォルトの最大接続値 Aurora PostgreSQL のデフォルトの最大接続値
1 90 189
4 135 823
8 1,000 1,669
16 2,000 3,360
32 3,000 5,000
64 4,000 5,000
128 5,000 5,000
注記

Aurora Serverless v2 DB インスタンスの max_connections の値は、最大 ACU から得られるメモリサイズに基づきます。ただし、PostgreSQL 互換 DB インスタンスで 0.5 ACU の最小容量を指定すると、max_connections の最大値は 2,000 に制限されます。

ACU の最大値によって max_connections がどのように変化するかを示す具体例については、「例: Aurora MySQL クラスターの Aurora Serverless v2 容量範囲の変更 」と「例: Aurora PostgreSQL クラスターの Aurora Serverless v2 容量範囲の変更」を参照してください。

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 DB インスタンスでは、プロビジョン済み DB インスタンスと同じように動作します。デフォルトのパラメータ値は、クラスターパラメータグループから継承されます。カスタムクラスターのパラメータグループを使用して、カスタムクラスター全体のデフォルトを変更できます。または、カスタム DB パラメータグループを使用して、特定の DB インスタンスのデフォルトを変更できます。動的パラメータはすぐに更新されます。静的パラメータの変更は、DB インスタンスの再起動後に有効になります。

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

以下のパラメータについては、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 インスタンスが消費する容量をモニタリングできます。また、DatabaseConnections や Queries などの 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.0 のACUUtilization に近づき、一方でライター 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 値の整数の平均になります。

Aurora Serverless v2 の容量の問題のトラブルシューティング

場合によっては、データベースに負荷がかからない状態でも、Aurora Serverless v2 が最小容量にスケールダウンしない場合があります。これは、次のような理由で発生します。

  • 特定の機能により、リソースの使用量が増加し、データベースが最小容量までスケールダウンできない可能性があります。主な機能は以下のとおりです。

    • Aurora Global Database

    • CloudWatch Logs のエクスポート

    • Aurora PostgreSQL 互換 DB クラスターでの pg_audit の有効化

    • 拡張モニタリング

    • Performance Insights

    詳細については、「クラスターに Aurora Serverless v2 の最小容量設定を選択する」を参照してください。

  • リーダーインスタンスが最小容量までスケールダウンせず、ライターインスタンスと同じかそれ以上の容量にとどまっている場合は、リーダーインスタンスの優先度の階層を確認します。階層 0 または 1 の Aurora Serverless v2 リーダー DB インスタンスは、ライター DB インスタンスと少なくとも同程度の最小容量に保たれます。リーダーの優先度の階層を 2 以上に変更して、ライターとは無関係にスケールアップおよびスケールダウンされるようにします。詳細については、「Aurora Serverless v2 リーダーの昇格階層の選択」を参照してください。

  • 共有メモリのサイズに影響するデータベースパラメータをデフォルト値に設定します。デフォルト値より大きく設定すると、共有メモリ要件が増加し、データベースが最小容量までスケールダウンできなくなります。例は、max_connections および max_locks_per_transaction です。

    注記

    共有メモリパラメータを更新するには、データベースを再起動して変更を有効にする必要があります。

  • データベースワークロードが重いと、リソースの使用量が増える可能性があります。

  • データベースのボリュームが大きいと、リソースの使用量が増える可能性があります。

    Amazon Aurora は DB クラスターの管理にメモリと CPU リソースを使用します。Aurora は、データベースボリュームが大きい DB クラスターを管理するために、より多くの CPU とメモリを必要とします。クラスターの最小容量がクラスター管理に必要な最小容量よりも少ない場合、クラスターは最小容量までスケールダウンされません。

  • 消去などのバックグラウンド処理によっても、リソースの使用量が増加する場合があります。

それでもデータベースが設定された最小容量までスケールダウンしない場合は、データベースを停止して再起動し、時間の経過とともに蓄積した可能性があるメモリフラグメントを再利用します。データベースを停止して起動するとダウンタイムが発生するため、これを実行するかどうかは慎重に判断することをお勧めします。