APIの「接続疲れ」を癒やす：コネクションプーリングの深淵と正しい設計論
ネットワークエンジニアとして現場を歩いていると、多くのエンジニアが「APIのレスポンスが遅い」という悩みを抱えて相談にやってくる。調査してみると、その原因の8割はアプリケーションコードの非効率さではなく、「TCPコネクションの管理」にあることが多いんだ。
特にマイクロサービス全盛の今、バックエンド間通信におけるコネクションプーリングは、単なる最適化ではなく、システム全体の生存に関わる「生命線」だ。今日は、RFC 7230（HTTP/1.1）が規定する通信の裏側を覗きながら、現場で本当に役立つコネクションプールの設計指針を共有しよう。
—
1. なぜ「毎回接続」が地獄への入り口なのか
HTTPは本来ステートレスなプロトコルだが、TCPの上で動いている以上、接続の確立（3-way handshake）と切断（FIN/ACK）というオーバーヘッドからは逃れられない。さらに、HTTPSならTLSハンドシェイクが追加される。
毎回リクエストのたびに SYN を投げ、証明書を検証し、暗号化パラメータをネゴシエーションしていたらどうなるか？ サーバーのポートは TIME_WAIT で溢れかえり、カーネルのファイルディスクリプタは枯渇する。これが、大規模トラフィックでシステムが「瞬き」する理由だ。
コネクションプーリングとは、この「コネクションの使い回し」を指す。一度確立したTCPセッションを「プール」という名の箱にストックし、次のリクエストが来たらそれを再利用する。これだけで、レイテンシは劇的に改善する。
—
2. プール設計の「3つの魔法のパラメータ」
コネクションプールを設計する際、意識すべき変数は主に3つだ。これらはシステムの負荷とメモリ、そしてネットワーク機器（L7ロードバランサーやファイアウォール）の制約を考慮して決める必要がある。
① プールサイズ（Pool Size）
- 考え方: 「あればあるほど良い」は嘘だ。サイズを大きくしすぎると、バックエンド側に膨大な接続を張りに行き、サーバー側のメモリを圧迫する。
- 指針: 「同時実行数 × 冗長性」で考える。基本的にはスレッド数やイベントループの同時実行数に合わせるのが定石だ。
② アイドルタイムアウト（Idle Timeout）
- 考え方: プール内で待機しているコネクションをいつ捨てるか。
- 指針: 重要だ。 多くのL7ロードバランサー（AWS ALBなど）は、アイドル状態が続くと静かにコネクションを切断する。ロードバランサーのタイムアウトよりも「短い時間」をアプリ側に設定しておくのが鉄則だ。そうしないと、アプリが「生きている」と信じているコネクションにリクエストを投げ、L7側から
RSTを食らうことになる。
③ 最大生存期間（Max Lifetime）
- 考え方: 1つのコネクションをどれだけ長く使い続けるか。
- 指針:
Keep-Aliveの過信は禁物だ。DNSの変更を反映させるため、あるいはメモリリーク対策として、数分〜1時間程度で定期的にコネクションを「リフレッシュ」させる仕組みを入れておくべきだ。
—
3. 実践：コネクションプールを正しく設定する
Pythonの urllib3 や requests (HTTPAdapter) を使う場合、以下のように設定するのが「現場の作法」だ。
import requests
from requests.adapters import HTTPAdapter
# セッションオブジェクトの生成
session = requests.Session()
# HTTPアダプターの作成（プール設定）
# pool_connections: プールするホスト数
# pool_maxsize: ホストごとの最大コネクション数
adapter = HTTPAdapter(
pool_connections=10,
pool_maxsize=50,
pool_block=True # プールが満杯の時に待機させるか
)
session.mount("https://", adapter)
session.mount("http://", adapter)
# これでリクエストを送ると、TCP接続が再利用される
response = session.get("https://api.example.com/v1/resource")また、Go言語のような並行処理に強い言語では、標準ライブラリの http.Transport で細かくチューニングを行う。
var transport = &http.Transport{
// 最大アイドル接続数
MaxIdleConns: 100,
// ホストごとの最大アイドル接続数（ここを適切に設定しないとボトルネックになる）
MaxIdleConnsPerHost: 20,
// アイドルコネクションの生存時間
IdleConnTimeout: 90 * time.Second,
}—
4. トラブルシューティング：現場で見る「悪しき兆候」
現場で障害対応をしていると、netstat や ss コマンドを叩く機会が多い。もし以下の状況が見えたら、即座にコネクションプールの設定を見直すべきだ。
TIME_WAITが数千件：Keep-Aliveが機能していないか、クライアント側が短時間でコネクションを乱発している。FIN_WAIT2が多い：サーバー側が切断を待ち続けている。アプリ側のタイムアウト設定がロードバランサーと合っていない証拠だ。
以下のコマンドで、現在のコネクション状態をリアルタイムに監視する癖をつけてほしい。
# 現在のコネクションの状態を集計する（Linux環境）
ss -ant | awk '{print $1}' | sort | uniq -c最後に：ネットワークを「育てる」意識を
API設計において、エンドポイントのURLが美しいかどうかも重要だが、その裏側を支えるコネクションが「適切に管理されているか」こそが、シニアエンジニアとしての腕の見せ所だ。
コネクションプールは、一度設定したら終わりではない。トラフィックの増減、インフラ構成の変更に合わせて、チューニングを繰り返す必要がある。この「泥臭い調整」の積み重ねこそが、ダウンタイムゼロの安定したシステムを作る唯一の道だ。
今日から、自社のAPIが裏でどんなTCPハンドシェイクを繰り返しているか、一度パケットを覗いてみてはどうだろうか？ きっと、新しい発見があるはずだ。
コメント