サーバーレスインスタンスの凍結とPostgresプーラーのクライアントスロット枯渇：Next.js・Supabaseの運用事例とローカル再現

概要

サーバーレス関数は、応答後に実行環境が凍結される。このとき、アプリケーションがトランザクションプーラーに対して開いたコネクションがどのように残るかは明らかになっていない。本論文は、Next.js・Vercel・Supabaseで構築した社内ツールzenithにおいて2026年7–9月に繰り返し発生したコネクション障害を、障害記録11件とコミット16件から再構成し、原因を四つの機序に分類する。中核となる障害はプーラーのクライアントスロット200個の枯渇であり、プールの上限を10から4に下げた後も再発した。凍結されたインスタンスではアイドルタイマーが実行されないため、占有がリクエストを一度でも処理したインスタンス数Wに比例するというモデルW·min(q, m)を立てた。プロセス停止シグナルで凍結を、TCPプロキシでスロット上限40を模擬した再現実験において、タイマーのみに依存する二つの構成の最大占有はすべての条件でmin(W·min(q, m), 40)と一致し、失敗したインスタンスは上限4、W = 16のときに6個であった。プール全体が静穏になった後にソケットを閉じる返却構成は、インスタンスを8個から16個に増やしても最大占有が32–36個であり、上限40を下回り、失敗はなかった。その代償として、成功したリクエストの遅延の中央値が2.6–8.7 ms増加した。凍結がアイドルタイマーより短く、その間にソケットが切断された場合には、三つの防御構成のうちクエリ前のプール交換のみが最初のリクエストと再試行の両方を成功させた。

主な貢献

• 運用記録11件とコミット16件から障害の系譜を再構成する。原因を四つの機序（凍結されたソケットによるスロット占有、死んだソケットのhang、同時リクエスト間の返却干渉、パイプライン文の消失）に分類する。
• インスタンス凍結下におけるスロット占有のモデルを立てる。タイマーに基づく整理では、占有がアクティブなインスタンス数ではなくリクエストを一度でも処理したインスタンス数に比例するという予測を導く。
• プロセス停止シグナル（SIGSTOP）で凍結を模擬する再現環境を構築する。その環境において、予測と三つの返却構成の差を測定する。

結論

応答直後に凍結されるサーバーレスインスタンスにおいて、タイマーに基づく整理とプールの上限は、プーラーのクライアントスロットの占有を制限できなかった。再現実験において占有はmin(W·min(q, m), L)に従い、上限を下げても枯渇の時点が遅れるだけであった。プール全体が静穏になった後にソケットを閉じる返却は、インスタンスを8個から16個に増やしても最大占有を32–36個に維持した。その代償は、リクエストごとの接続確立（ループバックでp50が2.6–8.7 ms増加）と返却待ち時間である。死んだソケットのhangに対しては、クエリ前のプール交換が最初のリクエストと再試行の両方を救った。今後の課題は、実際のプラットフォームにおいて凍結中のタイマーの挙動を確認すること、および返却待ちのコストを測定することである。