結果だけ早く知りたい人は、「[まとめ]」と付いた目次部分を参照ください。
- Aurora Serverless v2 の最大接続数 (max_connections)
- Aurora 容量単位 (ACU) とメモリの相関関係
- Aurora Serverless v2 の最大接続数 PostgreSQL 編
- [まとめ]Aurora Serverless v2 の最大接続数 PostgreSQL 編
- Aurora Serverless v2 の最大接続数 MySQL 編
- [まとめ]Aurora Serverless v2 の最大接続数 MySQL 編
- 余談
Aurora Serverless v2 の最大接続数 (max_connections)
要約すると以下のようです。
- Aurora Serverless v2 は スケールアップ・スケールダウンを自動的に行う。自動でのスケールダウン時に接続が切れないように、スケールダウンしても最大接続数は変わらないようになっている。
- 最大接続数は、設定した最大 Aurora 容量単位 (ACU) = MaxCapacity に従って決まる。 MaxCapacity が持つメモリサイズから、最大接続数を計算し適用する。(MaxCapacity が持つメモリサイズについては下の見出しで解説。)
- MaxCapacity が持つメモリサイズから、最大接続数を計算する方法は、MySQL、PostgreSQLで異なる。サーバーレスでない通常の Aurora と同じ計算式になる。
- PostgreSQL の場合、最小 Aurora 容量単位 (ACU) = MinCapacity が 0.5 の時は、最大接続数の上限は 2,000 になる。MaxCapacity がどんなに大きくても、2,000以上にならない。MySQLは除く。
参考:Aurora Serverless v2 の最大容量に基づいて Aurora が計算するパラメータ
Aurora MySQL と Aurora PostgreSQL の両方に対して、Aurora Serverless v2 DB インスタンスでは、max_connections パラメータを一定に維持し、DB インスタンスのスケールダウン時に接続が切断されないようにします。このパラメータのデフォルト値は、DB インスタンスのメモリサイズを参照する数式から算出されます。プロビジョン済み DB インスタンスクラスの計算式とデフォルト値の詳細については、「Aurora MySQL DB インスタンスへの最大接続数」および「Aurora PostgreSQL DB インスタンスへの最大接続数」を参照してください。
Aurora Serverless v2 が計算式を評価する場合、現在の ACU 値ではなく、DB インスタンスの最大 Aurora 容量単位 (ACU) に基づいたメモリサイズを使用します。デフォルト値を変更する場合は、定数値を指定する代わりに、計算式のバリエーションを使用することをお勧めします。そうすれば、Aurora Serverless v2では、最大容量に基づいて適切なサイズに調整された設定を使用できます。
PostgreSQL 互換 Aurora Serverless v2 DB インスタンスでは、最小容量 0.5 ACU を指定すると、max_connections 設定の上限が 2,000 になります。
Aurora 容量単位 (ACU) とメモリの相関関係
1 ACU は メモリ 2 GiBです。
また、ACU の選択範囲は 0.5 〜 128です。
ACUの増分は 0.5です。
ACU | メモリ(GiB) |
---|---|
0.5 | 1 |
1 | 2 |
1.5 | 3 |
〜 | |
128 | 256 |
AWS マネジメントコンソールから Aurora Serverless v2 を作成した時の Aurora 容量ユニット (ACU) 選択画面です。
このとき、MinCapacityが持つメモリサイズは 1 GiB になります。
0.5 ACU = 1 GiB。
MaxCapacity が持つメモリサイズは 2 GiB になります。
1 ACU = 2 GiB。
Aurora Serverless v2 の最大接続数 PostgreSQL 編
PostgreSQL の Aurora Serverless v2 を作ってみました。
- 最小容量(MinCapacity) 0.5 ACU
- 最大容量(MaxCapacity) 1 ACU
「Aurora PostgreSQL DB インスタンスへの最大接続数」を参照すると、max_connections の計算式は以下になります。
- LEAST({DBInstanceClassMemory/9531392},5000)
この式がパラメータグループ の max_connections に入っています。
さて、最大接続数の計算には、最大容量(MaxCapacity) 1 ACU の方が関係します。
最大容量(MaxCapacity) 1 ACU のとき、メモリは 2 GiB です。
2 GiB は 2147483648バイト ですので、これを 9531392 で割ると 225 です。
225 と 5000 を比較すると、 225 の方が小さいため、LEAST 関数の結果は、225 です。
従って、最大接続数は 225 になります。
実際に作ってみると、max_connections は 189 でした。
DBインスタンスに 2GiB のメモリを割り当てても、全てをDB接続に割り当てられるわけではないので、実際の値は計算よりも少ないようです。
189 接続をメモリに直すと、約 1.7 GiBです。
MaxCapacity を大きくしてみる。
クラスターを変更し、MaxCapacity を 8 (メモリ 16 GiB)にしてみましょう。
この時、理論上の最大接続数は 1802 になります。
変更中。
利用可能になりました。
インスタンスの画面から、パラメーターグループをみると、「再起動の保留中」になっています。
変更には再起動が必要なので注意しましょう。
再起動します。
利用可能になりました。
max_connections は 1669 になっていました。
1669 接続をメモリに直すと、約 14.8 GiBです。
MaxCapacity を大きくしてみる。その2。
PostgreSQL の場合、最小容量 0.5 ACU を指定すると、max_connections 設定の上限が 2,000 になります。
と上に書いたことが、本当にそうなるのか、みてみましょう。
同クラスターを変更し、MinCapacityは 0.5 のまま、MaxCapacity を 16 (メモリ 32 GiB)にしてみましょう。
ちなみに最小容量 1 ACU以上の場合、理論上の最大接続数は 3605 になります。
手順は割愛します。
16 ACU (32 GiB)になりました。
max_connections は 2000 になっていました。想定通り。
理論値から考えると、最大接続数 MaxCapacity を 9〜10 (メモリ 18〜20 GiB) 以上にするときは、MinCapacity を 1 以上にすると良いでしょう。
MinCapacity を 1以上にしてみる。
MaxCapacity を 16 (メモリ 32 GiB)にしていて、MinCapacity を 1 にすると、理論上の最大接続数は 3605 になります。 これを確認してみましょう。
MaxCapacity を大きくしたときは、パラメーターグループが「再起動の保留中」になっていました。
しかし、今回はなっていませんでした。
ただし、再起動しないと 最大接続数は 2000 のままでした。
再起動後、最大接続数が 3360 に増えました。
3360 接続をメモリに直すと、約 30 GiBです。
想定通りですね。
MaxCapacity を大きくしてみる。その3。
- LEAST({DBInstanceClassMemory/9531392},5000)
この計算式だと、最大接続数は 5000 が頭打ち、ということになります。
MaxCapacity が 23 (メモリが 46 GiB)の時に、理論上の最大接続数が 5182 になります。
これまでの傾向だと、実際の値は理論値の8〜9割になっていたので、4600〜4800 くらいになるのかなと、思います。
MaxCapacity を 23 にしてみます。
max_connections は 4839 になっていました。想定通り。
MaxCapacity を大きくしてみる。その4(最後)。
最後に MaxCapacity を 24 (メモリが 48 GiB)にしてみます。
48 GiB の理論上の最大接続数が 5407 になります。
上の結果を踏まえると、実際の値も、5000 を超えるのかなと、思います。
その場合、LEAST関数の比較対象となる 5000 の方が小さい数字なので、最大接続数は 5000 になるはずです。
MaxCapacity を 24 (メモリが 48 GiB)にしたところ、結果、5000 になりました。
[まとめ]Aurora Serverless v2 の最大接続数 PostgreSQL 編
- 計算式
- LEAST({DBInstanceClassMemory/9531392},5000)
ただし、PostgreSQL の場合、MinCapacity 0.5 の場合は、LEAST 関数の結果が 2000 を超えても、 2000 に固定となる。
結果を表にしてみました。
実際の最大接続数 は一番右の列に記載しています。
MaxCapacity(メモリ GiB) | MinCapacity(メモリ GiB) | MaxCapacityのメモリ値のみから導く最大接続数 | 実際の最大接続数 |
---|---|---|---|
1(2) | 0.5(1) | 225 | 189 |
8(16) | 0.5(1) | 1802 | 1669 |
16(32) | 0.5(1) | 3605 | 2000 (MinCapacityが0.5のため。) |
16(32) | 1(2) | 3605 | 3360 |
23(46) | 1(2) | 5182 | 4839 |
24(48) | 1(2) | 5407 | 5000 (LEAST関数の結果 5000 が採用されるため。) |
Aurora Serverless v2 の最大接続数 MySQL 編
MySQL の場合、MinCapacity が 0.5 でも最大接続数には無影響です。
「Aurora MySQL DB インスタンスへの最大接続数」には書いていないものの、パラメータグループを見ると計算式は以下のようです。
GREATEST({log(DBInstanceClassMemory/805306368)*45},{log(DBInstanceClassMemory/8187281408)*1000})
対数の計算なので、Excel のLOG関数などをうまく使って計算する必要があります。
「DB パラメータログ式」を参照すると、底は2のようです。
log 関数はログベース 2 を表します。この例では、DBInstanceClassMemory 数式変数も使用しています。「DB パラメータ式の変数」を参照してください。
Excel 関数で表現
以下2つの関数の実行結果を Large 関数で比較し、大きい方の値になります。
DBInstanceClassMemory を別セルから参照するとよさそうです。
=LOG(DBInstanceClassMemory/805306368,2)*45 =LOG(DBInstanceClassMemory/8187281408,2)*1000
[まとめ]Aurora Serverless v2 の最大接続数 MySQL 編
結果を表にしてみました。
実際の最大接続数 は一番右の列に記載しています。
MaxCapacity(メモリ GiB) | MinCapacity(メモリ GiB) | MaxCapacityのメモリ値のみから導く最大接続数 | 実際の最大接続数 |
---|---|---|---|
1(2) | 0.5(1) | 63 | 90 |
8(16) | 0.5(1) | 1069 | 1000 |
32(64) | 0.5(1) | 3069 | 3000 |
MySQL の場合は、Postgres と少し異なる結果になりました。全体的には Postgres より小さめの値になっています。
参考
MaxCapacity :1 (メモリ: 2 GiB) のとき
MaxCapacity :8 (メモリ: 16 GiB) のとき
MaxCapacity :32 (メモリ: 64 GiB) のとき
余談
心の癒しに、富士山5合目から見た富士市と駿河湾の写真を貼っておきますね。