RDS Proxyを導入して、数ヶ月で撤去した話

こんにちは。 Dress Code株式会社でプロダクトエンジニアをしているぽこひで（@pokohide）です。 アプリ用のAurora PostgreSQLにRDS Proxyを導入し、数ヶ月運用した末に撤去しました。導入から撤去までの経緯と、判断の根拠にした実測値をまとめます。 先に結論です。 Prismaが生成する16KB超のSQLテキストは、RDS Proxyのセッションピン留めを引き起こす。AWS全エンジン共通のハード制限で、設定では回避できない 弊社では全クライアントセッションの約2割でピン留めが発生し、接続の多重化がほぼ機能していなかった 月数百ドルのコストとProxy層固有の障害面だけが残ったため撤去。Prisma 7で接続挙動の制御がアプリに戻っていたので、スパイク対策はpg.Poolの設定に置き換えた 導入の経緯 弊社のバックエンドはNestJS + Prismaで、AP

[kiririmode]

この環境では、RDS Proxyの中核機能である接続多重化がピン留めによりほぼ働いておらず、しかも、その多重化によって解くべき接続数自体も存在していなかった。コストと障害面を追加するだけの中間レイヤーのため削除

[mkusaka]

Aurora PostgreSQLでRDS Proxyを導入し数ヶ月で撤去。Prismaの16KB超SQLで約2割がピン留め、コスト残で直結へ