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 インスタンスクラスを使用しないでください。
スケーリングは、瞬時には行われません。別の 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 クラスターのパラメータグループの作成」を参照してください。
Aurora PostgreSQL で使用できる各 DB インスタンスクラスについて、max_connections
に使用できる最大限の値をリストした表を次に示します。DB インスタンスクラスについて示されている数よりも多くの接続をアプリケーションが必要とした場合は、次の代替方法を検討してください。
-
メモリが多くある DB インスタンスクラスを選択します。Aurora PostgreSQL DB クラスターをサポートする DB インスタンスクラスの接続要件が高すぎると、データベースが過負荷になり、パフォーマンスが低下する可能性があります。Aurora PostgreSQL の DB インスタンスクラスのリストについては、「DB インスタンスクラスでサポートされている DB エンジン」を参照してください。各 DB インスタンスクラスのメモリ量については、「Aurora 用の DB インスタンスクラスのハードウェア仕様」を参照してください。
Aurora PostgreSQL DB クラスターで RDS プロキシを使用して接続をプールします。詳細については、「Amazon RDS Proxy の使用」を参照してください。
Aurora Serverless v2 インスタンスによるこのパラメータの処理方法については、「Aurora Serverless v2 の最大容量に基づいて Aurora が計算するパラメータ」を参照してください。
インスタンスクラス | max_connections で可能な最大値 |
---|---|
db.x2g.16xlarge | 5000 |
db.x2g.12xlarge | 5000 |
db.x2g.8xlarge | 5000 |
db.x2g.4xlarge | 5000 |
db.x2g.2xlarge | 5000 |
db.x2g.xlarge | 5000 |
db.x2g.large | 3479 |
db.r6g.16xlarge | 5000 |
db.r6g.12xlarge | 5000 |
db.r6g.8xlarge | 5000 |
db.r6g.4xlarge | 5000 |
db.r6g.2xlarge | 5000 |
db.r6g.xlarge | 3479 |
db.r6g.large | 1722 |
db.r5.24xlarge | 5000 |
db.r5.16xlarge | 5000 |
db.r5.12xlarge | 5000 |
db.r5.8xlarge | 5000 |
db.r5.4xlarge | 5000 |
db.r5.2xlarge | 5000 |
db.r5.xlarge | 3300 |
db.r5.large | 1600 |
db.r4.16xlarge | 5000 |
db.r4.8xlarge | 5000 |
db.r4.4xlarge | 5000 |
db.r4.2xlarge | 5000 |
db.r4.xlarge | 3200 |
db.r4.large | 1600 |
db.t4g.large | 844 |
db.t4g.medium | 405 |
db.t3.large | 844 |
db.t3.medium | 420 |
Aurora PostgreSQL 用のテンポラリストレージの制限
Aurora PostgreSQL は、Aurora ストレージサブシステムにテーブルとインデックスを格納します。非永続的なテンポラリファイル用として、Aurora PostgreSQL は別のテンポラリストレージを使用します。これには、クエリ処理中の大きなデータセットのソートや、インデックスの作成オペレーションなどの目的に使用するファイルが含まれます。ストレージの詳細については、「Amazon Aurora ストレージと信頼性」を参照してください。
次の表は、Aurora PostgreSQL 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.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.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 |
DB インスタンスで使用できるテンポラリストレージをモニタリングするには、FreeLocalStorage
CloudWatch メトリクスを使用できます。詳細については、「Amazon Aurora の Amazon CloudWatch メトリクス」を参照してください。
一部のワークロードでは、オペレーションを実行しているプロセスに割り当てるメモリ量を増やすことで、テンポラリストレージの量を減らすことができます。オペレーションに使用できるメモリを増やすには、PostgreSQL パラメータの work_mem