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

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 と互換)、すべてのマイナーバージョン

    • Aurora MySQL 2.09 (MySQL 5.7 と互換) 以降

    • Aurora MySQL 1.23 (MySQL 5.6 と互換) 以降

    • すべての Aurora PostgreSQL 13 バージョン

    • Aurora PostgreSQL 12.4 以降

    • Aurora PostgreSQL 11.8 以降

    • Aurora PostgreSQL 10.13 以降

  • 上記のバージョンよりも低い Aurora バージョンでは、データを削除したときに解放された領域をクラスターボリュームで再利用できますが、ボリューム自体のサイズが小さくなることはありません。

  • この機能は、Aurora が利用可能な AWS リージョンに段階的にデプロイされています。クラスターを使用するリージョンによっては、この機能はまだ利用できない場合があります。

動的サイズ変更は、クラスターボリューム内のデータファイルを物理的に削除またはサイズ変更するオペレーションに適用されます。つまり、DROP TABLEDROP DATABASETRUNCATE 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 バージョンでは、クラスターボリュームのストレージ制限が下位バージョンよりも高くなっています。したがって、元の 64 TiB ボリュームサイズを超えそうな場合は、これらのバージョンのいずれかにアップグレードすることを検討できます。

クラスターで使用されているストレージ容量を確認するには、CloudWatch の VolumeBytesUsed メトリクスをモニタリングします。

  • 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 が対象です。このクラスターは Aurora MySQL バージョン 1.22 を実行しているため、クラスターの空きサイズには元の 64 TiB の制限が反映されているのを確認できます。

$ 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 69797193744384.0 2020-08-05T17:52:00+00:00 Count DATAPOINTS 69797193744384.0 2020-08-05T18:52: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 バージョン 1.23 または 2.09 以降を実行しているクラスターや、Aurora PostgreSQL 3.3.0 または 2.6.0 以降を実行しているクラスターの場合、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 バージョン 1.23 または 2.09 以降を実行しているクラスターや、Aurora PostgreSQL 3.3.0 または 2.6.0 以降を実行しているクラスターで、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 クラスターの読み取りのスケーリングは、最大 15 個の Aurora レプリカをシングルマスターレプリケーションを使用する DB クラスター内に作成することで実現できます。各 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 プロキシの詳細については、Amazon RDS Proxy の使用 を参照してください。

クエリ実行計画の管理

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