Help us understand the problem. What is going on with this article?

RDSProxyを使ってもDB接続は速くならないという話

結論

特別、速くはならない。
速さを求めるのであれば自分でプールするしかないっぽい。
※とはいえ、接続数管理してくれるのは魅力。。

以下、AWSサポートとのやり取り。

AWSサポートへの質問

本文の最後に記載している "実行しているLambda" を実行しています。

(1) RDSProxyのエンドポイントを指定した場合、DB接続にかかる時間は下記になります。
connect:0.754[sec] ※Lambdaのコールドスタート
connect:0.420[sec] ※以降、同じコンテナで再実行
connect:0.322[sec]
connect:0.551[sec]

(2) RDSのエンドポイント&コネクションプール無しで設定した場合、DB接続にかかる時間は下記になります。
connect:0.640[sec] ※Lambdaのコールドスタート
connect:0.442[sec] ※以降、同じコンテナで再実行
connect:0.419[sec]
connect:0.410[sec]

(3) RDSのエンドポイント&コネクションプール有りで設定した場合、DB接続にかかる時間は下記になります。
※ pool_size=1 のコメントアウトを外す
connect:0.729[sec] ※Lambdaのコールドスタート
connect:0.002[sec] ※プールが効いているので接続にほぼ時間がかからない
connect:0.003[sec]
connect:0.002[sec]

(1)のRDSProxyをエンドポイントに指定した場合の結果に関して、RDS⇔RDSProxy間でコネクションプールが張られるので、
(3)結果と等しくなることを期待していました。

こちらの結果に関して、そういうものなのか、実装or設定方法に何かしら誤りがあるのか判断したいための問い合わせとなります。
ご確認いただけますでしょうか。


RDSのmax_connectionsを超えるようにLambda同時実行した場合、(1)の場合、正常に終了しますが、(2)の場合、too many connectionsが出るので
RDSProxyへのアクセス自体は正常に行えていると思います。


実行しているLambda(DB接続はmysql-connector-pythonを使用)

from mysql import connector
import os
import time

def lambda_handler(event, context):

    # 接続にかかった時間
    start = time.time()
    con = connector.connect(
        host=os.environ['DB_HOST'],
        user=os.environ['DB_USER'],
        password=os.environ['DB_PASSWORD'],
        database=os.environ['DB_DATABASE'],
        # pool_name="mypool",
        # pool_size=1,
    )

    elapsed_time = time.time() - start
    print ("connect:{0}".format(elapsed_time) + "[sec]")

    SQL( "select sleep(3), 2" )を実行して結果を取得する処理

    # 切断
    con.close()

AWSサポートの回答

(1)のRDSProxyをエンドポイントに指定した場合の結果に関して、RDS⇔RDSProxy間でコネクションプールが張られるので、(3)結果と等しくなることを期待していました。
こちらの結果に関して、そういうものなのか、実装or設定方法に何かしら誤りがあるのか判断したいための問い合わせとなります。ご確認いただけますでしょうか。

いいえ、恐れ入りますが、クライアント側でConnection Poolingを使用した場合と等しくはなりえません。
クライアント側で各Driverにて実施できるConnection Poolingと、RDS ProxyなどDatabase ProxyのConnection Poolingでは立ち位置が異なり、例えば、前者ではクライアント/DBサーバー間のコネクションを再利用できますが、後者では再利用されうるコネクションはあくまでProxy/DBサーバー間ですのでクライアント/Proxyの接続は必要であり、クライアントから見た接続時の所要時間としてはややオーバーヘッドになります。
また、ProxyのConnection Poolingのコネクションは常に必ず再利用されるというものではなく、必要に応じて、ピン留めが発生したり、ProxyやDB側で接続が切断されることもございます。

基本的には、例えば、「コネクションが再利用できる場合、DBでの新規コネクション作成の負荷軽減につなげることができる」、「接続の多重化としてDBへの実際のConnection数をおさえることができる」、「IAM認証をDB側で実施するのではなくProxy側で実施できる」などの特徴の観点で、ご想定されている運用方法などを踏まえ、ご検討・ご検証いただけますと幸いでございます。

[+] Amazon RDS Proxy による接続の管理 - RDS Proxy の概念
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/rds-proxy.html#rds-proxy-overview

k_hoso
記事のまとめは↓のサイトリンクから。 とりあえずevernoteにまとめていた備忘録メモを徐々にQiitaに転載していく感じ。ネタとしてひとまとめにしているものはちゃんと個別の記事にしていきたい、いつか。。ざくっとした記事もちゃんとした記事にできればいいけど、それもいつか。。 ※↓のリンクはQiita記事の目次
https://qiita.com/k_hoso/private/3c883802aa6baf9a6269
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away