コネクションプールとは？仕組みをわかりやすく解説｜毎回接続を作り直さない理由| vol.21

この記事では、データベースへの接続にかかるコストと、
接続を使い回す仕組みであるコネクションプールについて解説します。

アプリケーション側とデータベース側の双方に存在する接続数の上限や、
セッションとの役割の違いを整理します。

お疲れ様です。花冷です🌸

前回（vol.20）は、
ログイン状態を保つセッションのお話をしました。

受付を抜けたパケットちゃんは、いよいよ奥のデータベースへ向かいます。 でもその手前に、もうひとつ関門があるんです。

📍 今回のパケット旅の現在地

【現在地】：5つ目のマス「AP & DB SERVERS」。 APサーバから奥のデータベースへ向かう、専用通路の前です📍

❓ 毎回あいさつからやり直すの、無駄じゃない？

vol.13で、TCPは通信を始める前に3ウェイハンドシェイクという挨拶をする、とお話ししましたよね。

DBに繋ぐときも当然これをやりますし、それだけでは終わりません。「あなた誰ですか」という認証も必要です。

つまりDBへの接続は、

という、けっこう重たい手続きなんです。

画面を1回開くたびに、
この手続きを最初からやり直していたらどうなるか。

……遅いですよね。
アクセスが増えるほど、
この「準備だけの時間」が積み上がります。

🏊 だから、開けっぱなしにしておく

そこで登場するのが、コネクションプールです。

考え方はシンプルで、あらかじめ接続を何本か開いておいて、使い終わったら閉じずに返してもらう。

必要になったらプールから1本借りて、使い終わったら戻す。 これで挨拶と認証のコストが、最初の1回だけで済みます。

しかもこの仕組み、2段構えになっています。

• アプリ側：「何本まで持っていいか」の設定（HikariCPなど）

• DB側：「何本まで受け入れられるか」の上限

両方に上限があるということ。ここ、次回の伏線です🚩

⚠️ コネクションは「誰か」を覚えていない

ここでひとつ、面白い対比があります。

前回のセッションは、
「この人は花冷さんです」という記憶を持っていました。

でも、コネクションは何も覚えていません。

さっきAさんのために使われた1本が、次の瞬間にはBさんのために使われる。データベースから見れば、
誰のための通信かは関係ないんです。

「この操作は誰のものか」を管理しているのは、
完全にアプリ側の責任なんですね。

同じ「繋がっている」でも、
覚えている層と、覚えていない層がある。

🌸 余談：数字を決めるのが、怖かった

私は、プールサイズを設定したり調整したりする場面に関わってきました。そして接続が枯渇してエラーになる経験もしています。

でも、いま学んでみると、「足りないなら増やせばいい」という単純な話ではありませんでした。

アプリ側の上限を増やしても、DB側の上限は変わらない。

きちんと現状の状態に則した数を決めてあげないとですね！

🌸 おわりに

🔴コネクションプール：
　接続を使い回して、挨拶と認証のコストを省く仕組み
🔴誰も覚えていない：
　コネクションは共有の通路。人の識別はアプリの仕事

ここからはちょーっと別の話。

「重いからサーバを増やそう」
➣その判断が、システムを止めることがあるんです。

次回は、APサーバー増設の罠を覗いていきます！

今日もお疲れ様でした✨
また次回の記事でお会いしましょう〜！

⭐次回の記事はこちら！

⭐マガジンはこちら！

📩質問はこちらまでどうぞ！