https://devblog.thebase.in/entry/2022/05/26/180000
基盤チームでバックエンドエンジニアをやっている松田（ @tadamatu ）です。
以前にCTO川口が当ブログ内で公開した以下の記事があります。
新規接続の限界
BASE のアクセス量の伸びは凄まじくこの構成でも接続エラーが発生するようになってしまいました。 ピーク時に秒間 2 万もの新規接続が primary インスタンスへ行われているといった状態です。
この記事が公開されたのが約２年前で、当時100万程度 だったショップ数は170万を超え、我々はまだまだ伸ばしたいと考えています。 これは、ショップ数の伸びとともに、指数関数的に増えていくユーザのアクセスを捌く必要があることを意味します。
ブログ公開当時、我々はさまざまな検討の末、以下のような対策を取りました。
残された手段は primary のインスタンスに対しての接続数を如何にして減らすか、ということのみです。 ここで出来ることアプリケーション側の接続をいかに reader インスタンスに行うか、ということです。 これはクエリを reader に向けるというよくある負荷対策ではなく、新規接続自体を reader に最初から向ける
対応後もメディア露出などによりアクセスが集中すると、たびたびMySQLへの新規接続がボトルネックとなり、接続しづらい状態に陥っていました。 そこでBASEでは、RDS Proxy が2020/06にGAされたこともあり、検証を開始し、導入するまでに至りました。
本記事では、そこで得た知見、PHPとの相性はどうなのか、検証した方法、導入後どの程度効果があったのか、導入後発生した障害、など、RDS Proxy導入におけるメリット・デメリット を公開させていただこうと思います。
RDS Proxy導入方法など基本的なことは他の記事に譲ります。この記事では実際の導入を通して得たTips をできるだけ網羅しましたので、RDS Proxyが気になっている方や導入を検討している方のお役に立てれば嬉しいです。
まず、 RDS Proxy を導入することで公式に記載されているメリットを簡単に書いておきます。
(1) 接続プーリングによるパフォーマンスの向上
(2) フルマネージド
(3) フェイルオーバー発生時の時間短縮などによるアプリケーションの可用性向上
(4) IAM 認証を利用しセキュリティレベルの向上（オプション）
などいくつかありますが、もちろん我々が一番得たかったメリットは(1)になります。
さて、検証を始めていくわけですが、ポイントとなったものを記載していきます。
まず手始めに実際にDEV環境にRDS Proxyを構築してみて、アプリケーションからのDB接続をRDS Proxy経由に切り替えて検証をしてみます。 これに関してはQAチームに協力をしていただき、一通りリグレッションテストを通すことで検証、動作担保を行いました。