Amazon Aurora PostgreSQL の管理
次のセクションでは、Amazon Aurora PostgreSQL DB クラスターのパフォーマンスとスケーリングの管理について説明します。また、他のメンテナンスタスクについても説明します。
トピック
Aurora PostgreSQL DB インスタンスのスケーリング
Aurora PostgreSQL DB インスタンスは、インスタンススケーリングと読み取りスケーリングの 2 つの方法でスケールできます。読み取りスケーリングの詳細については、「読み取りのスケーリング」を参照してください。
DB クラスター内の各 DB インスタンスで DB インスタンスクラスを変更することで、Aurora PostgreSQL DB クラスターのスケーリングが行えます。Aurora PostgreSQL は、Aurora 用に最適化された DB インスタンスクラスを複数サポートしています。サイズが 40 テラバイト (TB) より大きい Aurora クラスターには、db.t2 または db.t3 インスタンスクラスを使用しないでください。
注記
T DB インスタンスクラスは、開発サーバーおよびテストサーバー、またはその他の本稼働以外のサーバーにのみ使用することをお勧めします。T インスタンスクラスの詳細については、「DB インスタンスクラスタイプ」を参照してください。
スケーリングは、瞬時には行われません。別の DB インスタンスクラスへの変更を完了するには、15 分以上かかることがあります。このアプローチを使用して DB インスタンスクラスを変更する場合は、ユーザーに影響を与えないように、次回のスケジュールされたメンテナンス期間中に (すぐにではなく) 変更を適用します。
DB インスタンスクラスを直接変更する代わりに、Amazon Aurora の高可用性機能を使用してダウンタイムを最小限に抑えることができます。まず、Aurora レプリカをクラスターに追加します。レプリカを作成するときに、クラスターに使用する DB インスタンスクラスのサイズを選択します。Aurora レプリカがクラスターと同期されてから、新しく追加されたレプリカにフェイルオーバーします。詳細については、「Aurora レプリカ」および「Amazon Aurora PostgreSQL による高速フェイルオーバー」を参照してください。
Aurora PostgreSQL でサポートされている DB インスタンスクラスの詳細な仕様については、「DB インスタンスクラスでサポートされている DB エンジン」を参照してください。
Aurora PostgreSQL DB インスタンスへの最大接続数
Aurora PostgreSQL DB クラスターは、DB インスタンスクラスとその使用可能なメモリに基づいてリソースを割り当てます。DB クラスターへの各接続は、メモリや CPU など、これらのリソースの増分量を消費します。接続ごとに消費されるメモリは、クエリの種類、カウント、一時テーブルが使用されているかどうかによって異なります。アイドル接続でもメモリと CPU を消費します。これは、クエリが接続で実行されると、各クエリに対してより多くのメモリが割り当てられ、処理が停止しても完全に解放されないためです。したがって、アプリケーションがアイドル状態の接続を保持していないことを確認することをお勧めします。これらの各接続はリソースを浪費し、パフォーマンスに悪影響を及ぼします。詳細については、「アイドル状態の PostgreSQL 接続によって消費されるリソース
Aurora PostgreSQL DB インスタンスによって許可されている接続の最大数は、その DB インスタンスのパラメータグループで指定された max_connections パラメータ値によって決まります。max_connections パラメータの理想的な設定は、アプリケーションが必要とするすべてのクライアント接続をサポートするもので、未使用の接続が余剰になっておらず、さらに AWS オートメーションをサポートするために少なくとも 3 つの接続があるものです。max_connections パラメータ設定を変更する前に、以下を考慮することをお勧めします。
-
max_connections値が小さすぎる場合、クライアントが接続を試みるときに Aurora PostgreSQL DB インスタンスには十分な接続が使用可能でない可能性があります。このような場合は、psqlを使用して接続を試みると、次のようなエラーメッセージが表示されます。psql: FATAL: remaining connection slots are reserved for non-replication superuser connections -
max_connections値が実際に必要な接続数を超えている場合、未使用の接続によってパフォーマンスが低下する可能性があります。
デフォルト値である max_connections は、次の Aurora PostgreSQL LEAST 関数から派生されます。
LEAST({DBInstanceClassMemory/9531392},5000).
max_connections の値を変更する場合は、カスタム DB クラスターパラメータグループを作成して、その値を変更する必要があります。カスタム DB パラメータグループをクラスターに適用した後、新しい値が有効になるように、プライマリインスタンスを再起動してください。詳細については、Amazon Aurora PostgreSQL のパラメータおよびDB クラスターのパラメータグループの作成を参照してください。
ヒント
アプリケーションが頻繁に接続を開いたり閉じたりする場合や、長時間の接続を多数開いたままにする場合は、Amazon RDS Proxy の使用を推奨します。RDS Proxy は、接続プーリングを使用してデータベース接続を安全かつ効率的に共有する、フルマネージドの高可用性データベースプロキシです。RDS Proxy の詳細については、Amazon RDS Proxy for Aurora の使用 を参照してください。
Aurora Serverless v2 インスタンスによるこのパラメータの処理方法については、「Aurora Serverless v2 の最大接続数」を参照してください。
Aurora PostgreSQL 用の一時ストレージの制限
Aurora PostgreSQL は、Aurora ストレージサブシステムにテーブルとインデックスを格納します。非永続的な一時ファイル用として、Aurora PostgreSQL は別の一時ストレージを使用します。これには、クエリ処理中の大きなデータセットのソートや、インデックスの作成オペレーションなどの目的に使用するファイルが含まれます。詳細については、記事「Aurora PostgreSQL 互換のインスタンスでローカルストレージの問題のトラブルシューティングを行う方法を教えてください
これらのローカルストレージボリュームは、Amazon Elastic Block Store によってバックアップされ、より大きな DB インスタンスクラスを使用することで拡張できます。ストレージの詳細については、「Amazon Aurora ストレージと信頼性」を参照してください。NVMe 対応のインスタンスタイプと Aurora Optimized Reads 対応の一時オブジェクトを使用して、一時オブジェクトのローカルストレージを増やすこともできます。詳細については、「Amazon Optimized Reads による Aurora PostgreSQL のクエリパフォーマンスの向上」を参照してください。
注記
db.r5.2xlarge から db.r5.4xlarge へなど、DB インスタンスをスケーリングすると、storage-optimization イベントが表示される可能性があります。
次の表は、Aurora PostgreSQL DB インスタンスクラス別に使用可能な一時ストレージの最大量を示しています。Aurora の DB インスタンスクラスサポートの詳細については、「Aurora DB インスタンスクラス」を参照してください。
| DB インスタンスクラス | 使用可能な一時ストレージの最大量 (GiB) |
|---|---|
| db.x2g.16xlarge | 1829 |
| db.x2g.12xlarge | 1606 |
| db.x2g.8xlarge | 1071 |
| db.x2g.4xlarge | 535 |
| db.x2g.2xlarge | 268 |
| db.x2g.xlarge | 134 |
| db.x2g.large | 67 |
| db.r7g.16xlarge | 1008 |
| db.r7g.12xlarge | 756 |
| db.r7g.8xlarge | 504 |
| db.r7g.4xlarge | 252 |
| db.r7g.2xlarge | 126 |
| db.r7g.xlarge | 63 |
| db.r7g.large | 32 |
| db.r6g.16xlarge | 1008 |
| db.r6g.12xlarge | 756 |
| db.r6g.8xlarge | 504 |
| db.r6g.4xlarge | 252 |
| db.r6g.2xlarge | 126 |
| db.r6g.xlarge | 63 |
| db.r6g.large | 32 |
| db.r6i.32xlarge | 1829 |
| db.r6i.24xlarge | 1500 |
| db.r6i.16xlarge | 1008 |
| db.r6i.12xlarge | 748 |
| db.r6i.8xlarge | 504 |
| db.r6i.4xlarge | 249 |
| db.r6i.2xlarge | 124 |
| db.r6i.xlarge | 62 |
| db.r6i.large | 31 |
| db.r5.24xlarge | 1500 |
| db.r5.16xlarge | 1008 |
| db.r5.12xlarge | 748 |
| db.r5.8xlarge | 504 |
| db.r5.4xlarge | 249 |
| db.r5.2xlarge | 124 |
| db.r5.xlarge | 62 |
| db.r5.large | 31 |
| db.r4.16xlarge | 960 |
| db.r4.8xlarge | 480 |
| db.r4.4xlarge | 240 |
| db.r4.2xlarge | 120 |
| db.r4.xlarge | 60 |
| db.r4.large | 30 |
| db.t4g.large | 16.5 |
| db.t4g.medium | 8.13 |
| db.t3.large | 16 |
| db.t3.medium | 7.5 |
注記
NVMe 対応のインスタンスタイプでは、利用可能な一時スペースを NVMe の合計サイズまで増やすことができます。詳細については、「Amazon Optimized Reads による Aurora PostgreSQL のクエリパフォーマンスの向上」を参照してください。
DB インスタンスで使用できる一時ストレージをモニタリングするには、FreeLocalStorage CloudWatch メトリクスを使用できます。詳細については、「Amazon Aurora の Amazon CloudWatch メトリクス」を参照してください。(これは Aurora Serverless v2 には適用されません。)
一部のワークロードでは、オペレーションを実行しているプロセスに割り当てるメモリ量を増やすことで、一時ストレージの量を減らすことができます。オペレーションに使用できるメモリを増やすには、PostgreSQL パラメータの work_mem
Huge pages for Aurora PostgreSQL
Huge pages はメモリ管理機能です。DB インスタンスが、共有バッファで使用されるような、大きく連続したメモリチャンクで動作しているときのオーバーヘッドを軽減します。この PostgreSQL 機能は、現在利用可能なすべての Aurora PostgreSQL バージョンでサポートされています。
Huge_pages パラメータは、t3.medium,db.t3.large,db.t4g.medium,db.t4g.large インスタンスクラス以外のすべての DB インスタンスクラスについて、デフォルトでオンになっています。サポートされている Aurora PostgreSQL のインスタンスクラスでは、huge_pages パラメータ値を変更したり、この機能をオフにしたりすることはできません。
