結論

• Prisma 側がデフォルトで提供するコネクションプールは無効化する(≒同時接続上限を1にする)
  • 接続URLに connection_limit=1 を付与
• PostgreSQL 用のコネクションプールである PgBouncer を supabase の管理画面で有効化する
  • プールモードはトランザクションモードにする
• Prisma 側で PgBouncer を使用するように設定する
  • 接続URLに PgBouncer のポートを指定し、 pgbouncer=true を付与
• prisma migration の場合のみ、 PgBouncer を使わずに直接 PostgresQL に繋ぐようにする

接続用URLはこんなん

postgres://postgres:[YOUR-PASSWORD]@db.xxxxxxxx.supabase.co:6543/postgres?pgbouncer=true&connection_limit=1

以下を読みながら整理してく。

https://www.prisma.io/docs/guides/performance-and-optimization/connection-management

スクラップのモチベーション

個人開発しているアプリで Vercel の serverless function 上から、supabase の postgresql に Prisma を用いてリクエストを投げているが、SSR/ISR を含んだビルド中(クエリが大量発生している間)にアクセスするとタイムアウトが発生してしまう事象について、正しく理解して解決したい。

普段はいわゆるフロントエンジニアなのでこの辺の知識がガバガバな状態からスタート。

概要

データベースが同時に処理できるコネクション数には制限がある。各コネクションにはRAMが割り当てられるため、単にコネクション数の上限を増やすだけでは限界がある。

コネクションを増やすことでさばけるリクエストは増えるものの、メモリが不足してパフォーマンスが低下し、最悪の場合はダウンしてしまうこともある。

アプリケーション側でコネクションをどのように管理するかによってもパフォーマンス影響はあるため、本ガイドではサーバーレス環境と常駐プロセスそれぞれでのアプローチを紹介する。

常駐プロセス

常駐プロセスの一例として、Node アプリケーションを Heroku や VM にホストして長時間起動し続けるプロセスで考える。

常駐プロセスにおいて重要は以下である。

• コネクションプールサイズを適切にすること
• PrismaClient をアプリケーション全体で1個だけ生成すること

推奨プールサイズ (常駐プロセス)

(デフォルトプールサイズ(CPU数 * 2 + 1)) / アプリケーションインスタンス数 がオススメ。

インスタンスが一つの場合はデフォルトサイズをそのまま使えばOKで、インスタンスが複数ある場合は connection_limit parameter で明示的に指定する

PrismaClient をシングルトン化する (常駐プロセス)

アプリケーション全体で PrismaClient が1個しか存在しないようにする。
モジュールのトップレベルでインスタンスを生成してそれを戻すようにすればOK

let prisma = new PrismaClient()
export default prisma

ただし開発環境の場合は、HMRによって何度も同じモジュールが実行されることがあるので、グローバル変数を使ってそれを回避する。

import { PrismaClient } from '@prisma/client'

// add prisma to the NodeJS global type
interface CustomNodeJsGlobal extends NodeJS.Global {
  prisma: PrismaClient
}

// Prevent multiple instances of Prisma Client in development
declare const global: CustomNodeJsGlobal

const prisma = global.prisma || new PrismaClient()

if (process.env.NODE_ENV === 'development') global.prisma = prisma

export default prisma

明示的に $disconnect() しない (常駐プロセス)

prisma.$disconnect()

でコネクションを明示的に切ることができるが、いちいち切断して次のクエリで再接続してだと効率が悪いため。

サーバーレス環境

常駐プロセスの話は終わりで、ここからはサーバーレス環境でのコネクション管理の話。

ここでいうサーバレス環境は、 AWS Lambda, Vercel, Netlify などにホストされた Node.js 関数を指す。

サーバレース環境においては以下の観点が重要。

• サーバーレスチャレンジ(The serverless challenge) の仕組みを理解する
• 外部のコネクションプールを利用するかに基づいたプールサイズ設定
• PrismaClient をハンドラの外側で生成し、明示的な $disconnect をしないこと
• 並列実行の設定を適切に行うこと

サーバーレスチャレンジ

(ここでは AWS Lambda を例に考える)

サーバーレス環境においては、各Lambdaが自身の PrismaClient インスタンスを生成し、それぞれが独自のコネクションプールを作成してしまう。

プールサイズが3の場合、Lambda が1個しか動いていないならコネクション数も3に収まり問題ないが、トラフィックがスパイクして3個のLambdaが同時に動いた場合、総コネクション数は 3 * 3 の 9 に膨れてしまう。

引用元

Lambda が 200 になればコネクションは600個。こうなると DBMS 側が限界を迎えてダウンしてしまう。

これを避けるため、以下の対応を考える

• Prisma 側のプールサイズを1にする (connection_limit=1)
• PgBouncer のような外部のコネクションプールの利用を検討する

推奨プールサイズ (サーバーレス環境)

サーバーレス環境における推奨プールサイズは以下に依存して決定する

• 外部のコネクションプールを使用するのか
• 関数が並列にクエリを投げるように設計されているか

外部コネクションプールを使用しない場合

connection_limit=1 から始めてから最適化しよう。

各リクエストは寿命の短い Node.js プロセスによって裁かれるため、プールサイズが大きいとあっという間にDBコネクション制限に到達してしまうため。

外部コネクションプールを使用する場合

デフォルト設定 (CPU数 * 2 + 1) で OK
外部コネクションプール側がスパイクに対応してくれる。

並列リクエストの最適化

Promise.all() {
  query1,
  query2,
  query3
  query4,
  ...
}

のような並列クエリを含んでいる場合、プールサイズが1の場合は実質直列化してしまうし、場合によってはタイムアウトが発生してしまうので、並列化をやめるか、プールサイズを増やす対応が必要になる。

サーバーレス環境における PrismaClient

PrismaClient のインスタンス生成はハンドラの外側で行うこと

サーバーレス環境がウォームスタンバイで動いている場合、ハンドラの外側のスコープは保持されるため、連続したリクエストに対してコネクションを再利用することができる。

import { PrismaClient, Prisma } from '@prisma/client'

const client = new PrismaClient()

export async function handler() {
  /* ... */
}

明示的な $disconnect() をしない

これはサーバーレスでも常駐プロセスでも一緒。
特にサーバーレスだと、せっかくウォームスタンバイで再利用できるコネクションをいちいち破棄することになっちゃうので。

サーバレス環境でのその他の考慮点

コンテナ再利用

サーバーレス環境では連続したリクエストが必ず同じコンテナに割り当てられる保証はないため、コネクションがなければ確立する、あれば再利用するといったステートレスな実装にすること。

ゾンビコネクション

削除予定とマークされたコンテナが、削除されないまま存在し続けることがある。この状態が続くとき、使用できないコネクションが維持され続けてしまう可能性がある。

アイドル状態の接続をクリーンアップするアプローチがあるが、Prisma では使用することができない。

並列実行制限

サーバーレス並行実行の上限によっては、並行実行するだけでDBコネクションを消費しきってしまうことがある。

これを防ぐためにはサーバーレスの同時実行数上限を、DBの最大コネクション数をプールサイズで割った値にすればよい。

コネクションプールの最適化

コネクションタイムアウトは以下のような場合に発生する

• 多数のユーザーが同時にアクセスした場合
• 1回のリクエストで並行クエリが多数発行された場合

この場合タイムアウトログが出力されるため、断続的に発生することがわかったら connection_limit や pool_timeout を見直そう。

プールサイズの増加

Prisma のプールサイズを増加することでより多くの並列クエリを実行できるが、DB側のコネクション制限に引っかからないように気をつけよう。

タイムアウトの増加

プールサイズを既に充分に増加しており、クエリがメモリを使い果たさずに完了できると確認しできるのであれば pool_timeout を見直そう。

あるいは pool_timeout=0 とすることで、タイムアウトを無効化することもできる。これは単発で巨大なクエリを投げ、メモリが枯渇しないことに確信が持てる場合に有用である。

外部コネクションプール

本ガイドでは Prisma が作成するコネクションプールの話がメインだったが、データベース側にもコネクションをプールする仕組みがある場合がある。

Data Proxy

Prisma Data Platform が提供するマネージドのコネクションプール

PgBouncer

PostgreSQL 用のコネクションプール。

PostgreSQL は一定の同時接続数しか対応できなく、特にサーバーレス環境ではすぐに枯渇してしまうため、PgBouncer を用いたコネクションプールで Prisma Client とデータベースの間のコネクションを取り持つことで、データベースが常時処理しなければならないプロセスを減らすことが出来る。

AWS RDS Proxy

AWS RDS が提供するやつだが、Prisma とあわせて使う場合は特に意味がない(らしい)

Prisma Client と PgBouncer

https://www.prisma.io/docs/guides/performance-and-optimization/connection-management/configure-pg-bouncer

URL 設定

Prisma Client で PgBouncer を使用する場合は、URL に ?pgbouncer=true を付与する。

postgresql://USER:PASSWORD@HOST:PORT/DATABASE?pgbouncer=true

ちなみに postgresql のポート番号は通常 5432 だが、PgBouncer は他のポートで動いている場合があるので注意。

PgBouncer モード

Prisma Client の場合、PgBouncer はトランザクションモードで動かす必要がある。

Prisma Migrate

Prisma Migrate はシングルコネクションを使用することを前提としているため、pgBouncer を使わずに postgreSQL に直接つなぎに行こうね

supabase と Prisma

最後に、supabase 側にも PgBouncer と Prisma のインテグレーションに関するドキュメントがあるのでそこに目を通す。
こっちは日本語訳があるのでメモ程度で済ませる。

https://www.supabase.jp/docs/guides/integrations/prisma#supabaseでのコネクションプーリング

サーバーレス環境（AWS Lambda、Vercel、Netlify FunctionsにホストされているNode.js関数など）で作業している場合は、コネクションプーリングを設定する必要があります

断言なんだ。まぁすべてデフォルト設定で考えると Prisma 側はプールを生成するから、1リクエストで多数のコネクションを張りに行ってすぐに枯渇するからそれはそう…？

Supabaseは、PgBouncerを使用して接続管理をサポートしており、デフォルトで有効になっています。

あぁ、別に PostgreSQL が PgBouncer の仕組みを持ってるわけじゃなくて、PgBouncer っていう別のツールがあって、 supabase はそれと PostgreSQL を繋いでくれる機能があるよってことか。

マイグレーションを実行する際には、プールされていない接続URL（ステップ4で使用したようなもの）を使用する必要があります。

こっちにも書いてあった。

同時接続数を最小限にするため、connection_limitを1に設定することも推奨されます。

Prisma 側ではコネクションプールを作らずに、PgBouncer に寄せるのね。