DB接続プール・サイジング計算
商用環境向けのデータベース接続プール計算およびキャパシティプランニングツールです。リトルの法則（Little's Law）、HikariCPのコア飽和計算式、PgBouncerのトランザクション多重化比率に基づき、Kubernetes Podごとの最適プールサイズ算出、スレッドスラッシング防止、キュー待機時間の予測、OOM（メモリ枯渇）クラッシュからのDB保護を正確に実行できます。
技術リファレンス・アーキテクチャガイド
DB接続プール計算＆サイジング — 技術リファレンス
本番環境対応のデータベース接続プール計算およびキャパシティプランニング設計ツールです。リトルの法則（Little's Law）、HikariCPのCPUコア飽和算出式、PgBouncerのトランザクション多重化比率に基づき、Kubernetes Pod単位での最適なプールサイズ算出、スレッドスラッシングの防止、キュー待機時間の予測、そしてメモリ枯渇（OOM）クラッシュからのDB保護を正確に実現します。
主要パラメータと設定項目
DBホストCPUコア数（vCPU）string
データベースインスタンスで利用可能な物理CPUコア数またはハイパースレッド数です。
初期値: auto
平均クエリ実行時間（ms）string
ネットワーク転送時間およびプール取得待機時間を除いた、データベース単体での平均クエリ処理時間です。
初期値: auto
プロキシ多重化比率string
PgBouncerやAWS RDS Proxyのトランザクションモードにおいて、1つのバックエンド永続DB接続で処理されるクライアントアプリケーション接続の比率です。
初期値: auto
ピーク時バーストヘッドルーム倍率string
突発的なトラフィックスパイクを吸収するため、定常状態のリトルの法則に基づく並行接続数に乗算する安全マージンです。
初期値: auto
現場のベストプラクティス・実践Tips
minimumIdleをmaximumPoolSizeと同値に設定する
HikariCPをはじめとする高スループット接続プールでは、minimumIdleをmaximumPoolSizeと同じ値に設定し、固定サイズのプールを維持してください。トラフィックスパイク発生時にプールを動的リサイズすると、システムが高負荷に晒されている最中にTCPハンドシェイク、TLSネゴシエーション、認証のオーバーヘッドが発生し、レイテンシが悪化します。
Pod起点ではなくデータベース起点（内向き）でサイジングする
データベースのCPUおよびメモリの上限値に対する合計接続数を検証せずに、Pod単位だけでプールサイズを決定してはなりません。常に「Podあたりのプールサイズ = (DBの安全な許容接続数 / HPA最大レプリカ数)」という計算式で定義してください。
PostgreSQLのwork_memはクエリノード単位で消費される点に留意する
PostgreSQLのwork_memは接続単位ではなく、ソート（Sort）やハッシュ（Hash）操作のノードごとに割り当てられます。複数の結合や並べ替えを含む複雑なクエリでは、1回の実行でwork_memが同時に3〜5倍確保されることがあります。過大な接続数と多めのwork_mem設定が重なると、LinuxのOOM Killerが発動し、DBプロセスが強制終了する大事故につながります。
PgBouncerのトランザクションモードとプリペアドステートメントを活用する
最新のPgBouncer（v1.21以降）は、トランザクションプーリングモードにおいてプロトコルレベルのプリペアドステートメントをサポートしています。PgBouncerとの互換性を最大限に高めるため、アプリケーション側のDBドライバでクライアント側の名前付きステートメントのクリーンアップ処理を無効化するか、無名ステートメント（Unnamed Statements）を使用するよう設定してください。
よくある落とし穴とトラブルシューティング
⚠️HikariCP ConnectionTimeoutException / 接続取得タイムアウト
pg_stat_activityやMySQLスロークエリログで遅延クエリを特定し、複合インデックスの追加などで最適化します。DBのCPU使用率が低い（50%未満）場合は、プールサイズを段階的に引き上げるか、PgBouncerの導入を検討してください。
⚠️PostgreSQL「FATAL: sorry, too many clients already」エラー
Kubernetes PodとPostgreSQLの間にトランザクションモードのPgBouncerを配置するか、「(最大Pod数 × プールサイズ) < max_connections」を満たすように各PodのmaximumPoolSizeを縮小してください。
⚠️LinuxのOOM Killerによるデータベースプロセスの強制停止
max_connectionsを減らすか、work_memの設定値を下げてください。shared_buffers（通常RAMの25%程度）と「max_connections × 20MB」の合計を差し引いた上で、OSのページキャッシュ用に物理RAMの20〜30%以上の空き領域を常に確保してください。
よくある質問 (FAQ)
最適なデータベース接続プールサイズはどのように計算すればよいですか？▼
最適なプールサイズ設計は、アプリケーション側の並行要求を測る「リトルの法則（Little's Law）」と、データベース側の「ハードウェア飽和限界」という2つの基本原則に基づいて算出します。まず、リトルの法則を用いて並行接続数を算出します：並行数 = 目標QPS × 平均クエリレイテンシ（秒）。例えば、目標が2,000 QPSで平均レイテンシが5ms（0.005秒）の場合、必要なアクティブ接続数は「2,000 × 0.005 = 10本」となります。これに30%のバーストヘッドルームを加えると13本です。次に、DBハードウェアの最適飽和点を「(CPUコア数 × 2) + ディスクスピンドル数」で確認します。16コアのSSD環境であれば、ハードウェアの飽和限界は約33接続です。Kubernetesで5つのPodを実行する場合、各PodのHikariCPプールサイズを3に設定すれば（合計15接続）、キューの枯渇を防ぎつつハードウェア上限（33接続）の内側に安全に収めることができます。
なぜHikariCPは「プールサイズ = (コア数 × 2) + 有効スピンドル数」の計算式を推奨しているのですか？▼
この経験則に基づく計算式は、HikariCPの作者Brett Wooldridge氏がPostgreSQLやOracleの性能エンジニアによるハードウェアベンチマーク結果をもとに提唱したものです。1つのCPUコアは同時に1つの命令ストリームしか実行できません。クエリがメモリキャッシュにヒットしている場合、1接続だけで1コアを100%飽和させます。しかし、高速なNVMeストレージであっても時折ディスクI/O待機が発生し、その間スレッドはI/O wait状態となってCPUを別スレッドに明け渡せます。そのため、コアあたり2倍の接続数（コア数 × 2）に有効スピンドル係数を加えることで、過度なコンテキストスイッチを引き起こすことなくCPUパイプラインを限界まで活用できます。実際のベンチマークでは、接続数を2,048から96に削減したことで、スループットを向上させながらクエリレイテンシを100msから2msへと劇的に短縮できることが実証されています。
データベース接続プールサイズを過大に設定するとどのような問題が発生しますか？▼
接続プールサイズを過大に設定すると、以下の3大障害モードが発生します。1) CPUコンテキストスイッチによるスラッシング：数百ものDBスレッドが限られたCPUコアを取り合うと、OSカーネルは実際のSQL実行よりもCPUレジスタ状態の退避・復元に処理時間を費やすようになります。2) メモリ枯渇とOOMクラッシュ：各接続プロセスは個別のセッションメモリ（PostgreSQLのバックエンド個別メモリやMySQLのスレッドバッファなど）を消費します。ソートやハッシュを伴う高負荷クエリが重なると物理RAMを食い潰し、LinuxカーネルのOOM KillerがメインDBプロセスを強制終了させます。3) ディスクI/Oキューの滞留と直列化：過剰な同時書き込みによりディスクコントローラやキャッシュキューが飽和し、I/O待機時間が急増して全マイクロサービスに接続タイムアウトの連鎖障害（カスケード障害）を引き起こします。
複数のKubernetes Podやマイクロサービス間で接続プールをサイジングするにはどうすればよいですか？▼
複数のマイクロサービスやオートスケーリングするKubernetes Pod全体で接続プールを設計する際は、「Pod起点（外向き）」ではなく「データベース起点（内向き）」で逆算します。まず、データベースの安全な接続許容量を決定します（例: max_connectionsが200の場合、運用監視用に20を確保し、アプリ用は180とする）。次に、HPA（Horizontal Pod Autoscaler）のピーク時における最大想定Pod数を算出します（例: 30 Pod）。接続予算を最大Pod数で除算します（180 ÷ 30 = Podあたり6接続）。もしPodあたり6接続では目標QPSに対するリトルの法則を満たせない場合は、Pod側のプールサイズを増やすのではなく、PodとDBの間にPgBouncerやAWS RDS Proxyなどのトランザクション接続プーラーを導入して多重化してください。
PgBouncerにおけるセッションプーリングとトランザクションプーリングの違いは何ですか？▼
セッションプーリング（Session Pooling）モードでは、クライアントが接続した時点で専用のサーバー接続が割り当てられ、切断するまで占有され続けます。すべてのSQL機能を安全に使用できる反面、常時接続を維持するアプリケーションプールに対しては多重化（集約）の効果がほとんど得られません。一方、トランザクションプーリング（Transaction Pooling）モードでは、単一のトランザクション（BEGIN ... COMMIT）の実行中のみDB接続がクライアントに貸し出されます。トランザクションが完了した瞬間に接続はプールへ返却され、即座に別のPodへ再割り当てされるため、5:1〜10:1という高い多重化比率を実現できます。ただし、LISTEN/NOTIFY、明示的な名前付けのないPREPARE、一時テーブル（TEMPORARY TABLE）、セッション単位のアドバイザリーロックなど、一部のセッション依存機能に制限が生じます。
PostgreSQLやMySQLのデータベース接続1本あたり、どの程度のメモリを消費しますか？▼
PostgreSQLでは、接続ごとに独立したOSプロセスが生成され、ベースとなる常駐メモリとして約5MB〜10MBを消費します。さらに、実行中のバックエンドプロセスは、クエリ内のソート・ハッシュ・結合ノードごとにwork_mem（デフォルト4MB）を動的に確保します。3つのソート／ハッシュ操作を含む複雑なクエリの場合、work_memだけで12MBを消費し、1接続あたりのメモリ消費量は計22MBに達します。MySQL（InnoDB）の場合、接続はOSスレッドとして動作し、約256KB〜1MBのスタックメモリとセッションバッファ（read_buffer_size、sort_buffer_size、join_buffer_sizeなど）を消費し、1接続あたり平均2MB〜6MBとなります。仮にPostgreSQLで1,000接続を維持する場合、接続プロセスだけで最低10GB〜20GBのRAMを見積もる必要があり、shared_buffersやOSのディスクページキャッシュに割り当てられるメモリ領域を大幅に圧迫します。
関連開発者ツール
全ツール一覧 →APIレートリミット計算機開発者ツール
トークンバケットやRPS（秒間リクエスト数）に基づくAPIレートリミットを、ブラウザ上でリアルタイムに試算・可視化できるシミュレーションツールです。
ツールを開く→
抵抗カラーコード計算・判読開発者ツール
IEC 60062規格に準拠し、3・4・5・6本帯の抵抗カラーコードを双方向で瞬時に計算・判読。許容差範囲、温度係数（TCR）ドリフト、E系列の逆算合成、SMD相当コードまで高精度に算出します。
ツールを開く→
RabbitMQキュー容量計算開発者ツール
RabbitMQのキューメモリ消費量とスループットをリアルタイムに試算・可視化できる、完全ブラウザ完結型の高精度サイジングツールです。
ツールを開く→
PostgreSQLメモリ計算機開発者ツール
PostgreSQLのメモリ設定計算およびPGTuneに基づくpostgresql.confパラメータを自動生成。shared_buffers、work_mem、effective_cache_size、max_connectionsを最適化します。
ツールを開く→
RAID容量計算（ZFS対応）開発者ツール
RAID 0/1/5/6/10/50/60およびZFS（RAIDZ1/Z2/Z3）構成の実効容量を十進法TB・二進法TiBで正確に計算。パリティ損失、URE（回復不能読み取りエラー）によるリビルド失敗リスク、再構築所要時間、ドライブベイ配置の可視化に対応した高精度ストレージ設計ツールです。
ツールを開く→
ABテスト サンプルサイズ計算開発者ツール
A/Bテストに必要なサンプルサイズ、統計的検定力、所要期間を高精度に計算。最小検出効果（MDE）の逆算、売上等の連続値指標、多群ボンフェローニ補正、サンプル比率の不整合（SRM）検証に対応。
ツールを開く→