構成図のレビューで、由来を誰も説明できない箱が出てくることがあります。「前任者が入れました」「たぶん接続数の対策だと思います」。動いているので放置され、月々の請求には毎月載り続ける。
この状態がやっかいなのは、外すことに誰も踏み切れない点です。 効いているかどうかが分からないため、外して障害が起きたときの説明が立たない。結果として、効いていない可能性がある構成要素が、効いている前提のまま残ります。
2026年8月に公開された実例が、この構図をきれいに示していました。
効かなかった理由が設定ではなく仕様だったケース
Dress Code の開発チームが公開したのは、アプリ用の Aurora PostgreSQL に RDS Proxy を導入し、数か月運用したうえで撤去したという記録です。撤去の判断根拠として挙げられているのは、次の点です。
Prisma が生成する 16KB を超える SQL テキストは、RDS Proxy のセッションピン留めを引き起こす。これは AWS が対応する全エンジン共通のハード制限で、設定では回避できない。同社では全クライアントセッションの約2割でピン留めが発生し、接続の多重化がほぼ機能していなかった。残ったのは月数百ドルのコストと、Proxy 層に固有の障害面だけだった。
AWS のドキュメントでも、テキストサイズが 16KB を超えるステートメントはプロキシがセッションをピン留めすると明記されています。ピン留めされた接続は他のセッションと共有されないため、その分だけ多重化の効果が消えます。
ここで重要なのは、これがチューニング不足ではないという点です。設定で緩和できる性能問題なら、調整して使い続ける選択肢があります。仕様上の制限で、かつ SQL を生成しているのが自前のコードではなく ORM である場合、アプリ側から短くする余地も限られます。 ORM が生成する SQL は、リレーションを含むクエリで容易に長くなります。
効いているかは、ひとつの指標で見える
この事例が実務的に有用なのは、判定に使える指標が具体的だからです。
RDS Proxy には DatabaseConnectionsCurrentlySessionPinned というメトリクスがあり、60秒ごとにピン留めされている接続数を示します。このメトリクスと、プロキシ経由の総接続数を比べれば、多重化が効いているかどうかは数字で出ます。
つまり、この構成要素については「効いているか分からない」という状態は本来ありえません。見ていないだけです。
同じことは他の構成要素にも言えます。キャッシュ層ならヒット率、CDN なら配信比率、キューなら滞留時間。「念のため」で入るものの多くは、効果を測る指標が定義できるにもかかわらず、導入時に決められていません。
決められない理由も分かります。導入時の関心は「入れたら動くか」であって、「入れた甲斐があったか」ではないためです。稼働したら次のタスクへ移り、測定は誰の仕事でもなくなります。
なぜ外せなくなるのか
もうひとつの論点は、撤去の意思決定です。
効いていないと分かっても、撤去はすぐには進みません。理由は技術ではなく予算の側にあります。追加には「対策」という名目が付きますが、撤去には名目が付きにくい。 月数百ドルの削減は、撤去作業の工数と比べると小さく見えることが多く、優先度が上がりません。
さらに、撤去には固有のリスク認識が伴います。入れたときは「入れないと危ないかもしれない」で通りますが、外すときは「外して大丈夫と誰が言うのか」になります。非対称なのです。
この非対称性を崩す方法はひとつしかないと考えています。入れる時点で、外す条件を書いておくことです。 稼働後に「外していいか」を議論すると必ず紛糾しますが、導入時に「この指標がこの値を下回ったら外す」と決めてあれば、実行は事務作業になります。
なお、この事例では撤去後の代替も用意されています。Prisma 7 で接続挙動の制御がアプリ側に戻ったため、スパイク対策は pg.Pool の設定に置き換えられたとのことです。撤去が成立したのは、代替が存在したからでもあります。 外す条件を書くときは、外した後に何で代替するかもセットにしないと、条件だけが空回りします。
導入時に書いておくこと
発注する側・請ける側のどちらの立場でも、構成要素を1つ足すときに合意しておく内容は共通です。
何のために入れるのか、を数値で書く。 「接続枯渇の防止」ではなく「同時接続数がDBの上限に対して何割を超えないこと」。目的が数値になっていないと、達成の判定ができません。
効果を測る指標と、その確認方法を書く。 メトリクス名まで書きます。ダッシュボードに載せるところまでを導入作業に含めると、後で探す手間が消えます。
判定する時期を書く。 導入から1か月後、3か月後といった具体的な日付です。期限が無い測定は実行されません。
効果が出なかった場合の扱いを書く。 撤去する、設定を変えて再評価する、そのまま残すが費用を再承認する。どれでも構いませんが、決めておくこと自体に意味があります。
これらは仕様書に書くというより、構成変更のチケットや議事録に3〜4行残しておくだけで足ります。分量ではなく、書いてあるかどうかが分かれ目です。
DBまわりの構成判断そのものについてはAurora Serverless の使いどころで扱っています。また、性能問題の受け入れ条件を数値でどう書くかはクエリ本数を検収条件にする話と地続きです。
次にやること
自社のインフラ構成図を開き、過去1年に追加された構成要素を洗い出してください。 そのうち、効果を示す数字を今すぐ出せるものが何割あるかを数えます。
出せないものについては、まず指標を1つ決めてダッシュボードに載せるところから始めるのが現実的です。撤去の判断はその後で構いません。測っていない状態で撤去を議論すると、必ず「念のため残す」に着地します。
インフラ構成の棚卸し、コスト削減の余地の洗い出し、既存システムの構成見直しについては、グリームハブの開発・AI・自動化のご相談で承っています。構成の規模と稼働状況によって進め方が変わるため、個別にお見積りします。お問い合わせからご相談ください。
