Zenn
🔍

PrismaのDB接続数はFargateでどう決まる？ vCPUとメモリ別に検証してみた

に公開
AWS
Node.js
PostgreSQL
Prisma
ECS
tech

PrismaをAWS ECS Fargate環境で使用する際、自動的に決定されるデータベースコネクション数（connection pool size）がどのように算出されているか気になったことはありませんか？

Prismaの公式ドキュメントには「num_physical_cpus * 2 + 1 ÷ インスタンス数」という計算式が記載されていますが、Fargateのような仮想化コンテナ環境では「物理CPU数」がどう扱われるのかは明確にされていません。

今回はこの疑問を解消するために、実際に複数の vCPU × メモリ構成で検証を行い、Prismaがどのような接続数を採用するのかを調べました。

前提

そもそもPrisma公式によるとPrismaでデフォルトで使用されるDBコネクション数は以下の通りです。

Recommended connection pool size
The recommended connection pool size (connection_limit) to start with for long-running processes is the default pool size (num_physical_cpus * 2 + 1) ÷ number of application instances.

info
num_physical_cpus refers to the the number of CPUs of the machine your application is running on.

https://www.prisma.io/docs/orm/prisma-client/setup-and-configuration/databases-connections

num_physical_cpus * 2 + 1がデフォルトconnection pool sizeとして使用されるのですが、num_physical_cpus=稼働しているマシンの物理CPUの数（コア数）とのことなので、物理CPUが割り当てられないはずのAWS ECSのようなコンテナ環境では果たしていくつになるのか？という疑問がありました。

結論

vCPUとメモリによって変わりました。以下テーブルの縦軸はvCPU、横軸がメモリ、テーブルの値がログに出たPrismaのconnection数です。

1GB 2GB 4GB 8GB 16GB 24GB 28GB 30GB 32GB 60GB 120GB
1vCPU - 3 3 3 - - - - - - -
2vCPU - - 3 3 5 - - - - - -
4vCPU - - - 5 5 5 5 5 - - -
8vCPU - - - - 9 17 17 - 9 9 -
16vCPU - - - - - - - - 17 - 17
  • -はvCPUとメモリの組み合わせとして未サポート
  • 0.25と0.5vCPUは未調査
  • コンテナイメージはnode:22-slimをベースにビルドしたNodeサーバ

Prismaのデフォルト設定で5 connectionを用意したい場合、上記の通り2vCPU,16GBと4vCPU,8GBの選択肢がありますが、時間あたりのメモリ従量課金料金の方がvCPUより安いため2vCPU,16GBのほうが安い計算結果になりました。

確認方法

実際に使用されるコネクションがいくつかはPrismClientをnewするときにinfoログ出力を指定すれば確認できます。

const prisma = new PrismaClient({
    log: ['info']
})

試しにローカル環境のM3 Macbook Pro上で確認したところ以下のようなログが出力されました。

prisma:info Starting a postgresql pool with 17 connections.

Macのシステム情報をみると

  チップ:	Apple M3
  コアの総数:	8（パフォーマンス: 4、効率性: 4）

とあるので8*2+1=17となり計算通りのコネクション数になっています。

物理的にコア数が分かれば計算式の通りになりますが、ECS Fargateのようなコンテナプラットフォームでは一体いくつになるのか？はPrismaの公式には言及ありませんでした。

結果

コネクション数

1GB 2GB 4GB 8GB 16GB 24GB 28GB 30GB 32GB 60GB 120GB
1vCPU - 3 3 3 - - - - - - -
2vCPU - - 3 3 5 - - - - - -
4vCPU - - - 5 5 5 5 5 - - -
8vCPU - - - - 9 17 17 - 9 9 -
16vCPU - - - - - - - - 17 - 17

時間あたり単価

2025年5月時点AWS東京リージョン単価
https://aws.amazon.com/jp/fargate/pricing/

単位 料金
1 時間あたりの vCPU 単位 USD 0.05056
1 時間あたりの GB 単位 USD 0.00553

USD単位

1GB 2GB 4GB 8GB 16GB 24GB 28GB 30GB 32GB 60GB 120GB
1vCPU - 0.06162 0.07268 0.0948 - - - - - - -
2vCPU - - 0.12324 0.14536 0.1896 - - - - - -
4vCPU - - - 0.24648 0.29072 0.33496 0.35708 0.36814 - - -
8vCPU - - - - 0.49296 0.5372 0.55932 - 0.58144 0.73628 -

３０日換算

USD単位

1GB 2GB 4GB 8GB 16GB 24GB 28GB 30GB 32GB 60GB 120GB
1vCPU - 44.3664 52.3296 68.256 - - - - - - -
2vCPU - - 88.7328 104.6592 136.512 - - - - - -
4vCPU - - - 177.4656 209.3184 241.1712 257.0976 265.0608 - - -
8vCPU - - - - 354.9312 386.784 402.7104 - 418.6368 530.1216 -
16vCPU - - - - - - - - 709.8624 - 1060.2432

アプリケーションロジック側の要件次第ではありますが、3コネクションで済むなら2vCPU以下で選択肢は色々あるということになりました。

おまけ

今回は自動設定されるコネクション数について確認しましたが、Prismaにはprisma.schemaに設定するurlにconnection_limitを設定することで明示的なコネクション数を指示できます。ただし、推奨の計算式を超えた値を設定したら意味があるのかどうかは未調査です。
GPTのDeep Searchに調査を依頼したところ、「（要約）技術的には設定可能だが、アプリ側のCPU・メモリ負荷につながるので注意が必要。少ないコネクション数からチューニングすべし。」とのことでした。明示的な「そのような設定は避けるべき」という情報はなかった様子です。

ただ当たり前ですが、CPUやメモリはアプリケーションロジック側の影響も受けるのでサーバ側の機能が変わっていけばその特徴も変わります。ここから先は各システムでちゃんと負荷試験や本番監視をしてチューニングしましょうね、ということだと考えています。

今回の検証により、ECS Fargate上で動作するPrismaアプリケーションにおいて、接続数は単純にvCPU数に比例するのではなく、vCPUとメモリの組み合わせによって決定されることが確認できました。また、コスト面では同じ接続数を確保する構成でも選択肢が複数存在し、調整の余地があります。

あくまでこれはデフォルトの自動設定値の挙動ですが、アプリケーションの特性や負荷に応じて明示的に接続数を設定する選択肢もあります。負荷試験や実運用での挙動を踏まえ、最適な構成を検討する際の参考になれば幸いです。

Discussion