ストレージのスケーリングインスタンスのスケーリング読み取りのスケーリング接続の管理クエリ実行計画の管理

Aurora DB クラスターのパフォーマンスとスケーリングの管理

次のオプションを使用して、Aurora DB クラスターおよび DB インスタンスのパフォーマンスおよびスケーリングを管理できます。

トピック

ストレージのスケーリング
インスタンスのスケーリング
読み取りのスケーリング
接続の管理
クエリ実行計画の管理

ストレージのスケーリング

Aurora ストレージは、クラスターボリューム内のデータに合わせて自動的にスケーリングします。データが増大するに従って、クラスターボリュームストレージは最大 128 tebibytes (TiB) または 64 TiB まで拡張されます。最大サイズは、DB エンジンのバージョンによって異なります。クラスターボリュームに含まれるデータの種類については、「Amazon Aurora ストレージと信頼性」を参照してください。特定のバージョンの最大サイズは、「Amazon Aurora サイズ制限」でご確認ください。

クラスターボリュームのサイズは 1 時間ごとに評価され、ストレージコストが決定されます。料金情報については、Aurora の料金表ページを参照してください。

Aurora クラスターボリュームのサイズは多数のテビバイトまでスケールアップできますが、課金対象となるのはそのボリュームの使用した領域分のみです。請求対象のストレージ領域を決定する方法は、Aurora クラスターのバージョンによって異なります。

クラスターボリュームから Aurora データを削除すると、相応して請求対象の領域が全体的に減少します。この動的なサイズ変更動作は、基礎となるテーブルスペースの削除や再編成に伴って、必要な領域が減った場合に発生します。したがって、不要になったテーブルとデータベースを削除することで、ストレージ料金を削減できます。動的サイズ変更は、特定の Aurora バージョンに適用されます。データを削除するとクラスターボリュームが動的にサイズ変更される Aurora バージョンは次のとおりです。

Aurora MySQL	バージョン 3 (MySQL 8.0 互換): すべてのサポート対象バージョンバージョン 2 (MySQL 5.7 互換): 2.11 以上
Aurora PostgreSQL	サポートされている全バージョン
Aurora Serverless v2	サポートされている全バージョン
Aurora Serverless v1	サポートされている全バージョン

上記のバージョンよりも低い Aurora バージョンでは、データを削除したときに解放されたスペースをクラスターボリュームで再利用できますが、ボリューム自体のサイズが小さくなることはありません。
この機能は、Aurora が利用可能な AWS リージョンに段階的にデプロイされています。クラスターを使用するリージョンによっては、この機能はまだ利用できない場合があります。

動的サイズ変更は、クラスターボリューム内のテーブルスペースを物理的に削除またはサイズ変更するオペレーションに適用されます。つまり、DROP TABLE、DROP DATABASE、TRUNCATE TABLE、および ALTER TABLE ... DROP PARTITION などの SQL ステートメントに対し適用されます。DELETE ステートメントを使用した行の削除には適用されません。テーブルから多数の行を削除する場合は、Aurora MySQL OPTIMIZE TABLE ステートメントを実行するか、後で Aurora PostgreSQL pg_repack エクステンションを使用して、テーブルを再編成し、クラスターボリュームのサイズを動的に変更できます。

注記

Aurora MySQL の場合、innodb_file_per_table パラメータがテーブルストレージの編成方法に影響します。テーブルがシステムテーブルスペースの一部である場合、テーブルを削除してもシステムテーブルスペースのサイズは縮小されません。したがって、動的サイズ変更を最大限に活用するには、Aurora MySQL クラスターで必ず innodb_file_per_table を 1 に設定してください。

Aurora MySQL バージョン 2.11 以降では、InnoDB 一時テーブルスペースは再起動時に削除され、再作成されます。これにより、一時テーブルスペースが占めていたスペースがシステムに解放され、クラスターボリュームのサイズが変更されます。動的サイズ変更機能を最大限に活用するには、DB クラスターを Aurora MySQL バージョン 2.11 以降にアップグレードすることをお勧めします。

動的サイズ変更機能は、テーブルスペース内のテーブルが削除されてもすぐにスペースを再利用しませんが、1 日あたり約 10 TB のレートで徐々に増加します。システムテーブルスペースは削除されないため、システムテーブルスペース内のスペースは再利用されません。テーブルスペース内の再利用されていないスペースは、操作によってそのテーブルスペースにスペースが必要になったときに再利用されます。動的サイズ変更機能では、クラスターが使用可能な状態にある場合にのみ、ストレージスペースを再利用できます。

クラスターで使用されているストレージ容量を確認するには、CloudWatch の VolumeBytesUsed メトリクスをモニタリングします。ストレージ料金の詳細については、「Aurora データストレージに対する請求方法」を参照してください。

AWS Management Console の場合、クラスターの詳細ページで Monitoring タブを表示することで、この容量をグラフで確認できます。

AWS CLI の場合、次の Linux の例のようなコマンドを実行できます。スタート時刻、終了時刻、クラスター名は、独自の値に置き換えます。


aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '6 hours ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" \
  --statistics Average Maximum Minimum \
  --dimensions Name=DBClusterIdentifier,Value=my_cluster_identifier

このコマンドでは、次のような出力が生成されます。


{
    "Label": "VolumeBytesUsed",
    "Datapoints": [
        {
            "Timestamp": "2020-08-04T21:25:00+00:00",
            "Average": 182871982080.0,
            "Minimum": 182871982080.0,
            "Maximum": 182871982080.0,
            "Unit": "Bytes"
        }
    ]
}

次の例では、Linux システムで AWS CLI コマンドを使用することにより、Aurora クラスターのストレージ使用状況を経時的に追跡する方法を示しています。--start-time パラメータと --end-time パラメータは、全体の時間間隔を 1 日として定義します。--period パラメータは、1 時間間隔で測定値をリクエストします。メトリクスは継続的にではなく、間隔を置いて収集されるため、--period として小さい値を選択しても意味がありません。また、Aurora ストレージオペレーションは、関連する SQL ステートメントが終了した後で、バックグラウンドでしばらく続行することがあります。

初期の例では、デフォルトの JSON 形式で出力が返されます。データポイントは、タイムスタンプでソートされず、任意の順で返されます。この JSON データをチャートツールにインポートして、並べ替えや視覚化を行うことができます。


$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600
  --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id
{
    "Label": "VolumeBytesUsed",
    "Datapoints": [
        {
            "Timestamp": "2020-08-04T19:40:00+00:00",
            "Maximum": 182872522752.0,
            "Unit": "Bytes"
        },
        {
            "Timestamp": "2020-08-05T00:40:00+00:00",
            "Maximum": 198573719552.0,
            "Unit": "Bytes"
        },
        {
            "Timestamp": "2020-08-05T05:40:00+00:00",
            "Maximum": 206827454464.0,
            "Unit": "Bytes"
        },
        {
            "Timestamp": "2020-08-04T17:40:00+00:00",
            "Maximum": 182872522752.0,
            "Unit": "Bytes"
        },
... output omitted ...

次の例は、前と同じデータを返します。--output パラメータは、コンパクトなプレーンテキスト形式でデータを表します。aws cloudwatch コマンドは、その出力を sort コマンドにパイプします。-k コマンドの sort パラメータは、3 番目のフィールドで出力をソートします。これは、UTC (世界協定時刻) 形式のタイムスタンプです。


$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id \
  --output text | sort -k 3
VolumeBytesUsed
DATAPOINTS  182872522752.0  2020-08-04T17:41:00+00:00 Bytes
DATAPOINTS  182872522752.0  2020-08-04T18:41:00+00:00 Bytes
DATAPOINTS  182872522752.0  2020-08-04T19:41:00+00:00 Bytes
DATAPOINTS  182872522752.0  2020-08-04T20:41:00+00:00 Bytes
DATAPOINTS  187667791872.0  2020-08-04T21:41:00+00:00 Bytes
DATAPOINTS  190981029888.0  2020-08-04T22:41:00+00:00 Bytes
DATAPOINTS  195587244032.0  2020-08-04T23:41:00+00:00 Bytes
DATAPOINTS  201048915968.0  2020-08-05T00:41:00+00:00 Bytes
DATAPOINTS  205368492032.0  2020-08-05T01:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T02:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T03:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T04:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T05:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T06:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T07:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T08:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T09:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T10:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T11:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T12:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T13:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T14:41:00+00:00 Bytes
DATAPOINTS  206833664000.0  2020-08-05T15:41:00+00:00 Bytes
DATAPOINTS  206833664000.0  2020-08-05T16:41:00+00:00 Bytes

ソートされた出力は、モニタリング期間のスタート時と終了時のストレージの使用量を示します。また、該当期間中に Aurora でより多くのストレージがクラスターに割り当てられたポイントも確認できます。次の例では、Linux コマンドを使用して、スタート時と終了時の VolumeBytesUsed 値をギガバイト (GB) およびギビバイト (GiB) として再フォーマットします。ギガバイトは 10 の累乗で測定された単位を表し、回転式ハードドライブのストレージに関する説明でよく使用されます。ギビバイトは、2 の累乗で測定された単位を表します。Aurora ストレージでは通常、測定値と制限を、ギビバイトやテビバイトなどの 2 の累乗単位を使用して表記します。


$ GiB=$((1024*1024*1024))
$ GB=$((1000*1000*1000))
$ echo "Start: $((182872522752/$GiB)) GiB, End: $((206833664000/$GiB)) GiB"
Start: 170 GiB, End: 192 GiB
$ echo "Start: $((182872522752/$GB)) GB, End: $((206833664000/$GB)) GB"
Start: 182 GB, End: 206 GB

VolumeBytesUsed メトリクスは、料金を発生させているクラスター内のストレージの量を示します。したがって、この数値はできるだけ最小限に抑えるようにします。ただし、このメトリクスには、Aurora がクラスターで内部的に使用している、課金対象外のストレージは含まれません。クラスターがストレージ制限に近づき、容量が不足する可能性がある場合は、AuroraVolumeBytesLeftTotal メトリクスをモニタリングし、その数値を最大限に増やすようにします。次の例では、前と同様の計算を実行しますが、AuroraVolumeBytesLeftTotal ではなく、VolumeBytesUsed が対象です。


$ aws cloudwatch get-metric-statistics --metric-name "AuroraVolumeBytesLeftTotal" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_old_cluster_id \
  --output text | sort -k 3
AuroraVolumeBytesLeftTotal
DATAPOINTS      140530528288768.0       2023-02-23T19:25:00+00:00       Count
$ TiB=$((1024*1024*1024*1024))
$ TB=$((1000*1000*1000*1000))
$ echo "$((69797067915264 / $TB)) TB remaining for this cluster"
69 TB remaining for this cluster
$ echo "$((69797067915264 / $TiB)) TiB remaining for this cluster"
63 TiB remaining for this cluster

Aurora MySQL バージョン 2.09 以降または Aurora PostgreSQL を実行しているクラスターの場合、VolumeBytesUsed によって報告される空きサイズは、データが追加されると増加し、データが削除されると減少します。以下の例のように指定します。このレポートには、テンポラリデータを含むテーブルの作成や削除に伴う、クラスターの最大と最小のストレージサイズが 15 分間隔で表示されます。レポートには、最小値の前に最大値が表示されます。したがって、15 分間隔内のストレージ使用量の変動を確認するには、数値を右から左へと解釈します。


$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \
  --namespace "AWS/RDS" --statistics Maximum Minimum --dimensions Name=DBClusterIdentifier,Value=my_new_cluster_id
  --output text | sort -k 4
VolumeBytesUsed
DATAPOINTS	14545305600.0	14545305600.0	2020-08-05T20:49:00+00:00	Bytes
DATAPOINTS	14545305600.0	14545305600.0	2020-08-05T21:19:00+00:00	Bytes
DATAPOINTS	22022176768.0 14545305600.0	2020-08-05T21:49:00+00:00	Bytes
DATAPOINTS	22022176768.0	22022176768.0	2020-08-05T22:19:00+00:00	Bytes
DATAPOINTS	22022176768.0	22022176768.0	2020-08-05T22:49:00+00:00	Bytes
DATAPOINTS	22022176768.0 15614263296.0	2020-08-05T23:19:00+00:00	Bytes
DATAPOINTS	15614263296.0	15614263296.0	2020-08-05T23:49:00+00:00	Bytes
DATAPOINTS	15614263296.0	15614263296.0	2020-08-06T00:19:00+00:00	Bytes

次の例は、Aurora MySQL バージョン 2.09 以降または Aurora PostgreSQL を実行しているクラスターで、AuroraVolumeBytesLeftTotal によって報告される空きサイズに 128 TiB のサイズ制限がどのように反映されているかを示しています。


$ aws cloudwatch get-metric-statistics --region us-east-1 --metric-name "AuroraVolumeBytesLeftTotal" \
  --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBClusterIdentifier,Value=pq-57 \
  --output text | sort -k 3
AuroraVolumeBytesLeftTotal
DATAPOINTS	140515818864640.0	2020-08-05T20:56:00+00:00	Count
DATAPOINTS	140515818864640.0	2020-08-05T21:26:00+00:00	Count
DATAPOINTS	140515818864640.0	2020-08-05T21:56:00+00:00	Count
DATAPOINTS	140514866757632.0	2020-08-05T22:26:00+00:00	Count
DATAPOINTS	140511020580864.0	2020-08-05T22:56:00+00:00	Count
DATAPOINTS	140503168843776.0	2020-08-05T23:26:00+00:00	Count
DATAPOINTS	140503168843776.0	2020-08-05T23:56:00+00:00	Count
DATAPOINTS	140515818864640.0	2020-08-06T00:26:00+00:00	Count
$ TiB=$((1024*1024*1024*1024))
$ TB=$((1000*1000*1000*1000))
$ echo "$((140515818864640 / $TB)) TB remaining for this cluster"
140 TB remaining for this cluster
$ echo "$((140515818864640 / $TiB)) TiB remaining for this cluster"
127 TiB remaining for this cluster

インスタンスのスケーリング

DB クラスター内の各 DB インスタンスの DB インスタンスクラスを変更することで、必要に応じて Aurora DB クラスターをスケーリングできます。Aurora は、データベースエンジンの互換性に応じて Aurora 用に最適化された、複数の DB インスタンスクラスをサポートしています。

データベースエンジン	インスタンスのスケーリング
Amazon Aurora MySQL	「Aurora MySQL DB インスタンスのスケーリング」を参照してください。
Amazon Aurora PostgreSQL	「Aurora PostgreSQL DB インスタンスのスケーリング」を参照してください。

読み取りのスケーリング

Aurora DB クラスターの読み取りのスケーリングは、DB クラスターに最大 15 個の Aurora レプリカを作成することで実現できます。各 Aurora レプリカは、最小限のレプリカラグでクラスターボリュームから同じデータを返します。通常、このラグはプライマリインスタンスが更新を書き込んだ後、100 ミリ秒を大幅に下回ります。読み取りトラフィックが増えたら、追加の Aurora レプリカを作成し、それらに直接接続することで DB クラスターの読み取りワークロードを分散できます。Aurora レプリカの DB インスタンスクラスは、プライマリイスタンスと同じものである必要はありません。

DB クラスターに Aurora レプリカを追加する方法については、「DB クラスターに Aurora レプリカを追加する」を参照してください。

接続の管理

Aurora DB インスタンスへの許可されている接続の最大数は、DB インスタンスのインスタンスレベルパラメータグループの max_connections パラメータによって決まります。そのパラメータのデフォルト値は、DB インスタンスおよびデータベースエンジンの互換性に使用される DB インスタンスクラスによって異なります。

データベースエンジン	max_connections のデフォルト値
Amazon Aurora MySQL	「Aurora MySQL DB インスタンスへの最大接続数」を参照してください。
Amazon Aurora PostgreSQL	「Aurora PostgreSQL DB インスタンスへの最大接続数」を参照してください。

ヒント

アプリケーションが頻繁に接続を開いたり閉じたりする場合や、長時間の接続を多数開いたままにする場合は、Amazon RDS Proxy の使用を推奨します。RDS Proxy は、接続プーリングを使用してデータベース接続を安全かつ効率的に共有する、フルマネージドの高可用性データベースプロキシです。RDS Proxy の詳細については、Amazon RDS Proxy for Aurora の使用を参照してください。

クエリ実行計画の管理

Aurora PostgreSQL のクエリプラン管理を使用すると、オプティマイザーが実行する計画を制御できます。詳細については、「Aurora PostgreSQL のクエリ実行計画の管理」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

Aurora レプリカの追加

Aurora DB クラスターのボリュームのクローン作成