# Aurora DB クラスターのパフォーマンスとスケーリングの管理
次のオプションを使用して、Aurora DB クラスターおよび DB インスタンスのパフォーマンスおよびスケーリングを管理できます。
**Topics**
+ [ストレージのスケーリング](#Aurora.Managing.Performance.StorageScaling)
+ [インスタンスのスケーリング](#Aurora.Managing.Performance.InstanceScaling)
+ [読み取りのスケーリング](#Aurora.Managing.Performance.ReadScaling)
+ [接続の管理](#Aurora.Managing.MaxConnections)
+ [クエリ実行計画の管理](#Aurora.Managing.Optimizing)
## ストレージのスケーリング
Aurora ストレージは、クラスターボリューム内のデータに合わせて自動的にスケーリングします。データが増加するにつれて、クラスターボリュームストレージは DB エンジンのバージョンに応じて拡張されます。Aurora クラスターボリュームの各エンジンバージョンの最大サイズについては、「[Amazon Aurora サイズ制限](CHAP_Limits.md#RDS_Limits.FileSize.Aurora)」を参照してください。クラスターボリュームに含まれるデータの種類については、「[Amazon Aurora ストレージ](Aurora.Overview.StorageReliability.md)」を参照してください。特定のバージョンの最大サイズは、「[Amazon Aurora サイズ制限](CHAP_Limits.md#RDS_Limits.FileSize.Aurora)」でご確認ください。
クラスターボリュームのサイズは 1 時間ごとに評価され、ストレージコストが決定されます。料金情報については、[Aurora の料金表ページ](https://aws.amazon.com/rds/aurora/pricing)を参照してください。
Aurora クラスターボリュームのサイズは多数のテビバイトまでスケールアップできますが、課金対象となるのはそのボリュームの使用した領域分のみです。請求対象のストレージ領域を決定する方法は、Aurora クラスターのバージョンによって異なります。
+ クラスターボリュームから Aurora データを削除すると、相応して請求対象の領域が全体的に減少します。この動的なサイズ変更動作は、基礎となるテーブルスペースの削除や再編成に伴って、必要な領域が減った場合に発生します。したがって、不要になったテーブルとデータベースを削除することで、ストレージ料金を削減できます。動的サイズ変更は、特定の Aurora バージョンに適用されます。データを削除するとクラスターボリュームが動的にサイズ変更される Aurora バージョンは次のとおりです。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html)
+ 上記のバージョンよりも低い Aurora バージョンでは、データを削除したときに解放されたスペースをクラスターボリュームで再利用できますが、ボリューム自体のサイズが小さくなることはありません。
動的サイズ変更は、クラスターボリューム内のテーブルスペースを物理的に削除またはサイズ変更するオペレーションに適用されます。つまり、`DROP TABLE`、`DROP DATABASE`、`TRUNCATE TABLE`、および `ALTER TABLE ... DROP PARTITION` などの SQL ステートメントに対し適用されます。`DELETE` ステートメントを使用した行の削除には適用されません。テーブルから多数の行を削除する場合は、Aurora MySQL `OPTIMIZE TABLE` ステートメントを実行するか、後で Aurora PostgreSQL `pg_repack` エクステンションを使用して、テーブルを再編成し、クラスターボリュームのサイズを動的に変更できます。
Aurora MySQL の場合、次の考慮事項が適用されます。
+ DB クラスターを動的サイズ変更をサポートする DB エンジンバージョンにアップグレードした後、その特定の AWS リージョン でこの機能が有効になっている場合、`DROP TABLE` などの特定の SQL ステートメントによって後で解放される領域は再利用可能です。
特定の AWS リージョン でこの機能が明示的に無効になっている場合、動的サイズ変更をサポートするバージョンであっても、スペースは再使用可能にすぎず、再利用可能ではない可能性があります。
この機能は、2020 年 11 月から 2022 年 3 月の間、特定の DB エンジンバージョン (1.23.0～1.23.4、2.09.0～2.09.3、2.10.0) で有効になり、それ以降のバージョンではデフォルトで有効になっています。
+ テーブルは、さまざまなサイズの 1 つ以上の連続したフラグメントに内部的に保存されます。`TRUNCATE TABLE` 操作の実行中に、最初のフラグメントに対応するスペースは再使用可能であり、再利用可能ではありません。他のフラグメントは再利用可能です。`DROP TABLE` 操作中、テーブルスペース全体に対応するスペースは再利用可能です。
+ `innodb_file_per_table` パラメータは、テーブルストレージの編成方法に影響します。テーブルがシステムテーブルスペースの一部である場合、テーブルを削除してもシステムテーブルスペースのサイズは縮小されません。したがって、動的サイズ変更を最大限に活用するには、Aurora MySQL クラスターで必ず `innodb_file_per_table` を 1 に設定してください。
+ バージョン 2.11 以降では、InnoDB 一時テーブルスペースは再起動時に削除され、再作成されます。これにより、一時テーブルスペースが占めていたスペースがシステムに解放され、クラスターボリュームのサイズが変更されます。動的サイズ変更機能を最大限に活用するには、DB クラスターをバージョン 2.11 以降にアップグレードすることをお勧めします。
**注記**
動的サイズ変更機能は、テーブルスペース内のテーブルが削除されてもすぐにスペースを再利用しませんが、1 日あたり約 10 TB のレートで徐々に増加します。システムテーブルスペースは削除されないため、システムテーブルスペース内のスペースは再利用されません。テーブルスペース内の再利用されていないスペースは、操作によってそのテーブルスペースにスペースが必要になったときに再利用されます。動的サイズ変更機能では、クラスターが使用可能な状態にある場合にのみ、ストレージスペースを再利用できます。
クラスターで使用されているストレージ容量を確認するには、CloudWatch の `VolumeBytesUsed` メトリクスをモニタリングします。ストレージ料金の詳細については、「[Aurora データストレージに対する請求方法](Aurora.Overview.StorageReliability.md#aurora-storage-data-billing)」を参照してください。
+ AWS マネジメントコンソール の場合、クラスターの詳細ページで `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 または Aurora PostgreSQL の互換バージョンを実行しているクラスターにおいて、`AuroraVolumeBytesLeftTotal` が報告する空きサイズに 256 TiB のサイズ制限がどのように反映されているかを示しています。互換バージョンの詳細については、「[Amazon Aurora サイズ制限](CHAP_Limits.md#RDS_Limits.FileSize.Aurora)」を参照してください。
```
$ 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"
256 TiB remaining for this cluster
```
## インスタンスのスケーリング
DB クラスター内の各 DB インスタンスの DB インスタンスクラスを変更することで、必要に応じて Aurora DB クラスターをスケーリングできます。Aurora は、データベースエンジンの互換性に応じて Aurora 用に最適化された、複数の DB インスタンスクラスをサポートしています。
| データベースエンジン | インスタンスのスケーリング |
| --- | --- |
| Amazon Aurora MySQL | 「[Aurora MySQL DB インスタンスのスケーリング](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.Performance.InstanceScaling)」を参照してください。 |
| Amazon Aurora PostgreSQL | 「[Aurora PostgreSQL DB インスタンスのスケーリング](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.Performance.InstanceScaling)」を参照してください。 |
## 読み取りのスケーリング
Aurora DB クラスターの読み取りのスケーリングは、DB クラスターに最大 15 個の Aurora レプリカを作成することで実現できます。各 Aurora レプリカは、最小限のレプリカラグでクラスターボリュームから同じデータを返します。通常、このラグはプライマリインスタンスが更新を書き込んだ後、100 ミリ秒を大幅に下回ります。読み取りトラフィックが増えたら、追加の Aurora レプリカを作成し、それらに直接接続することで DB クラスターの読み取りワークロードを分散できます。Aurora レプリカの DB インスタンスクラスは、プライマリイスタンスと同じものである必要はありません。
DB クラスターに Aurora レプリカを追加する方法については、「[DB クラスターに Aurora レプリカを追加する](aurora-replicas-adding.md)」を参照してください。
## 接続の管理
Aurora DB インスタンスへの許可されている接続の最大数は、DB インスタンスのインスタンスレベルパラメータグループの `max_connections` パラメータによって決まります。そのパラメータのデフォルト値は、DB インスタンスおよびデータベースエンジンの互換性に使用される DB インスタンスクラスによって異なります。
| データベースエンジン | max\$1connections のデフォルト値 |
| --- | --- |
| Amazon Aurora MySQL | 「[Aurora MySQL DB インスタンスへの最大接続数](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections)」を参照してください。 |
| Amazon Aurora PostgreSQL | 「[Aurora PostgreSQL DB インスタンスへの最大接続数](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.MaxConnections)」を参照してください。 |
**ヒント**
アプリケーションが頻繁に接続を開いたり閉じたりする場合や、長時間の接続を多数開いたままにする場合は、Amazon RDS Proxy の使用を推奨します。RDS Proxy は、接続プーリングを使用してデータベース接続を安全かつ効率的に共有する、フルマネージドの高可用性データベースプロキシです。RDS Proxy の詳細については、[Amazon RDS Proxy for Aurora](rds-proxy.md) を参照してください。
## クエリ実行計画の管理
Aurora PostgreSQL のクエリプラン管理を使用すると、オプティマイザーが実行する計画を制御できます。詳細については、「[Aurora PostgreSQL のクエリ実行計画の管理](AuroraPostgreSQL.Optimize.md)」を参照してください。