APサーバー増設の罠とは？仕組みをわかりやすく解説｜台数を増やしてもシステム全体が止まる理由| vol.22

この記事では、APサーバーを増設したことで、
かえってシステム全体が停止してしまう「増設の罠」について解説します。

プールサイズと台数の掛け算がデータベース側の上限を超える仕組みや、
アプリケーション側を見ているだけでは原因に気づけない理由を
整理します。

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

前回（vol.21）は、
DB接続を使い回すコネクションプールのお話をしました。

最後にこう書きました。
アプリ側とDB側、両方に上限があると。

今回は、その2つの上限がぶつかったときに起きる事故の話です。

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

【現在地】：5つ目のマス「AP & DB SERVERS」。
DBへの専用通路を、さらに増やそうとしている段階です📍

❓ 増やしたのに、なぜ全部止まる？

画面が重い。アクセスも増えている。 そこで出てくる判断が、これです。

ごく自然ですよね。処理する人を増やせば、さばける量も増えるはずです。

ところが、この判断でシステム全体が沈黙することがあります。
「少し遅くなる」ではなく、一切動かなくなるんです。

なぜでしょうか。

🧮 実は、算数で解けます

前回の話を思い出してください。

APサーバは、DBへの接続をあらかじめ何本か持っています（コネクションプール）。 そしてDB側にも、受け入れられる本数の上限があります。

数字を入れてみましょう。

ここまでは問題ありません。では増やします。

見えましたか。

AP1台あたりの設定は何も変えていません。 変えたのは台数だけ。 でも掛け算なので、台数を倍にすれば、要求する接続数も倍になるんです。

💣 「もう受け付けられません」

上限を超えたDBは、新しい接続を拒否します。

Oracleだと、こんなエラーになります。

怖いのは、特定の1台の問題ではないことです。どのAPサーバも同じように接続を取りに行くので、全台がエラーを引く可能性がある。

結果、増設する前より状況が悪くなるわけですね。

「サーバを増やせば性能が上がる」という直感が、
ここではきれいに裏切られます。

🔍 なぜ気づきにくいのか

この事故、アプリ側だけ見ていても絶対に分かりません。

• AP側の設定 → 変えていない

• コード → 変えていない

• 増やした台数 → 正しく動いている

どこにも間違いがないんです。間違っているのは、掛け算の答えだけ。

vol.14でも書きましたが、「遅い」「動かない」の原因は層をまたいで存在します。 これはその典型例ですね。

🌸 余談：私は、増やす側にいました

私は、増設の計画と試験に関わったことがあります。
台数を決めて、検証して、問題ないことを確かめる作業です。

AP側が限界でAP側を増設！して、
接続数が増えた状態でのコネクションプールをDB側が満たせているか？

これをきちんと予測しておかないと根本の解決にはならないので、
新しいサービスやどれくらいの需要があるか未知数な状態では、
気を付けておかないといけないポイントだと再認識できました。

🌸 おわりに

🔴AP増設の罠：
　台数を増やすと、必要な接続数も掛け算で増える
🔴ORA-00020：
　DB側の上限を超えると、新しい接続が拒否される
🔴気づきにくさ：
　アプリ側には間違いが1つもない

インフラとアプリの境目って、
どちらの担当者から見ても「相手側」に見えるところがあります。

だからこそ、両方の言葉が分かる人が強いんだと思います。
この連載を書いている理由も、そこにあります🚩

さて、ここまでずっと論理の話でした。
次回は、いちばん物理的な話を。

ケーブルそのものに、流せる量の限界があるという話です！

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

⭐次回の記事はこちら！

⭐マガジンはこちら！

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