RDS Proxy とは

アプリケーションと RDS の間に入って、DB 接続を効率的に管理するサービス

RDS Proxy なしの場合の問題

1. 接続数の上限に達する

RDS には同時接続数の上限がある(インスタンスサイズ依存)

Lambda が 1000 同時実行されると、各インスタンスが DB 接続を開くので 1000 接続必要になる。上限を超えると「Too many connections」エラーで新規接続が拒否される

対策としてアプリ側で接続プールを実装しても、Lambda のようにインスタンスが独立している環境では意味がない

各インスタンスが自分用のプールを持つだけで、全体の接続数は減らない

2. フェイルオーバーで接続が全部切れる

Multi-AZ 構成でプライマリが落ちると、スタンバイに切り替わる

このとき既存の接続は全部切れる。アプリは再接続処理が必要で、DNS キャッシュの問題もあって数十秒〜数分エラーが続くことがある

出典: RDS Proxy concepts and terminology

“Without RDS Proxy, a failover involves a brief outage. During the outage, you can’t perform write operations on the database in failover. Any existing database connections are disrupted, and your application must reopen them.”

3. 接続/切断のオーバーヘッドが重い

DB 接続を開くには TCP 接続、TLS ハンドシェイク、認証、セッション初期化が必要

Lambda のような短命なコンピューティングが毎回これをやると、処理時間の大部分が接続確立に費やされることもある。特に TLS 接続は重い

RDS Proxy ありの場合

接続プーリング

1000 個の Lambda からの接続を受けつつ、DB への実際の接続は 50 本程度に抑えられる

出典: RDS Proxy concepts and terminology

“You can open many simultaneous connections to the proxy, and the proxy keeps a smaller number of connections open to the DB instance or cluster.”

フェイルオーバー時の接続維持

Proxy がフェイルオーバーを検知して新しいプライマリに接続し直す

アプリから見ると接続は維持されたまま

出典: RDS Proxy concepts and terminology

“When the original DB instance becomes unavailable, RDS Proxy connects to the standby database without dropping idle application connections.”

接続の再利用

Proxy が接続を保持しているので、アプリは毎回接続を開く必要がない

接続確立のオーバーヘッドを削減できる

具体例

EC サイトの注文処理を Lambda で実装した場合

セール時にアクセスが急増して Lambda が 500 同時実行になった状況を考える

RDS Proxy なしの場合

  1. 500 個の Lambda インスタンスがそれぞれ DB 接続を開こうとする
  2. RDS の接続上限が 100 だとすると、101 個目以降の Lambda は接続できない
  3. 「Too many connections」エラーが発生
  4. 注文処理が失敗してユーザーにエラーが返る

RDS Proxy ありの場合

  1. 500 個の Lambda インスタンスが RDS Proxy に接続する(Proxy への接続数に上限はほぼない)
  2. RDS Proxy は DB への接続を 30 本程度にプールして使い回す
  3. Lambda A のトランザクションが終わったら、その接続を Lambda B が再利用する
  4. DB の接続上限に達しないので、全ての注文処理が正常に完了する

出典: Using AWS Lambda with Amazon RDS

“Proxies are recommended for production environments as they manage a pool of shared database connections, enabling high concurrency without exhausting connections.”