【要約】Connection Poolの理解。Supabaseで接続数の検証 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がデータベースの接続管理を行う際、クライアント側の接続数とDB側の接続数を混同する問題がある。この誤解は、システム拡張時に予期せぬリソース不足を招く。具体的には以下の課題が挙げられる。
- ・クライアント接続数とDB接続数の乖離による混乱。
- ・Connection Pool sizeに対する認識の不足。
- ・接続数増加に伴うメモリやCPU負荷の増大リスク。
// Approach
筆者はSupabaseのConnection Poolが、設定された上限を超えた際にどう動くかを検証した。具体的には、DB接続上限を超える接続試行を行い、その成否を確認した。手順は以下の通りである。
- ・SupabaseのDatabase SettingsでPool sizeを確認。
- ・DB接続上限（15本）に対し、16本目の接続を並行して実行。
- ・接続の成否および処理時間を計測。
// Result
検証の結果、設定されたPool sizeを超えても接続が成功することが判明した。これにより、Pool sizeが単純な接続拒否の閾値ではないことが示された。得られた知見は以下の通りである。
- ・16本目の接続も成功し、BEGIN/SELECT処理が完了した。
- ・Pool sizeの設定は、単純な接続上限とは異なる挙動を示す。
- ・接続数を増やす際は、メモリやCPU負荷とのトレードオフを考慮すべきである。
Senior Engineer Insight
> Serverless環境では接続数が急増するため、Poolerの活用は不可欠だ。本検証で16本目の接続が成功した点は注目に値する。これはPoolerがリクエストをキューイングしている可能性を示唆している。単にPool sizeを増やすのは危険だ。DB側のメモリやCPUリソースの限界を正確に把握せよ。スケーラビリティとリソース消費のバランスを設計段階で定義することが、高負荷環境での安定稼働の鍵となる。