
LambdaからRDSへの接続が遅い原因を徹底調査!RDS ProxyやAZ跨ぎの影響は?
みなさんこんにちは、@ultaroです!
今回は、RDS ProxyのAZ跨ぎ影響による接続時間遅延の検証を紹介します。エンジニアなら気になるこのトピック、詳しく見ていきましょう!
1. LambdaでRDSが遅い!?原因を徹底解明!
ある日、とあるプロジェクトで、Lambdaで実装したAPIからRDSに接続する際に、時間がかかるという話を聞きました。詳しく話を聞くと・・・RDSへの接続処理だけで100ms程度かかっているとのことでした。SQL実行は含まれていませんし、RDS Proxyも使用しているのに、これはおかしいですね。
話を聞いた時に幾つかの怪しいことろは心当たりありましたし、やみくもにやっても成果が出るとは思えませんでした!そこで、原因と考えられる仮説を立て、実際に計測を行って、ホントのところはどうなのか、を検証してみました。

主要な構成要素
・AWS Lambda → WebAPIとして使用
・Amazon RDS → アプリが使用するデータを格納
・Amazon RDS Proxy → イベント駆動でWebAPIが呼び出されるケースがあるので使用
図1では、Lambda関数からRDSにアクセスする際に遅延が発生する構成を示しています。この構成を基に2つの仮説を立て検証しました。
仮説①: アベイラビリティゾーン(AZ)跨ぎが発生する場合に遅くなっているのではないか?
仮説②: RDS Proxyを挟むことで逆に遅くなっているのではないか?
これらの仮説を検証していきます!
2. RDS Proxyとは何か?
そもそもRDS Proxyとは何でしょうか?遅い原因に絡んでおり今回の主役候補となるRDS Proxyについて改めて確認してみましょう!
Amazon RDS向けの高可用性フルマネージド型データベースプロキシで、アプリケーションのスケーラビリティやデータベース障害に対する回復力と安全性を高めます。
と、AWSでは説明されていました。
RDS Proxyの主な機能・特徴
接続の再利用: 一度確立した接続を再利用し、接続確立にかかる時間とリソースを節約します。
スケーラビリティの向上: 多数の接続リクエストを効率的に処理し、接続プールのサイズを自動的に調整します。結果として、高いスケーラビリティを実現します。
自動フェイルオーバー: フェイルオーバー時に自動的に新しいプライマリインスタンスへの接続を切り替えます。エンドポイントの再接続と既存のセッションが継続され、アプリケーション側の影響を最小限に抑えます。
3. 検証①: AZ跨ぎが発生する場合に遅くなる?
3-1. 目的と期待する結果
この検証の目的は、Lambda関数からRDSへ直接接続した場合の標準的な接続時間を測定し、AZを跨ぐ接続による影響を見極めることです。具体的な期待結果は以下の通りです。
直接接続した場合の基準となる接続時間の把握
RDS Proxyを利用しない場合の、LambdaからRDSへの標準的なパフォーマンスを評価します。AZを跨ぐ接続による接続時間の増加の確認
LambdaとRDSが異なるAZに配置された場合、どれぐらいの接続時間へ影響があるのかを検証します。期待する結果として、AZを跨がない接続よりAZを跨ぐ接続の方が遅くなり、もともと聞いた話のようなRDSへの接続が遅くなることを予想しています。
3-2. 検証の構成

環境設定:
RDS: AZ 1aにRDSインスタンスを配置する。
Lambda関数: 3つのAZ(1a, 1c, 1d)にLambda関数を配置する。
検証実行:
各AZのLambda関数からRDSインスタンスへの接続を50回繰り返し試行する。
各試行でのDB接続部分の時間を計測し、平均、最小、最大、標準偏差を算出する。
3-3. 結果と分析

同一AZ内の接続時間のレイテンシーは低い:
1a内での接続時間の平均は5.9msであり、他のAZからの接続に比べて接続時間が短いため、同一AZ内の接続のレイテンシーは低いと考えられます。WebAPIとしても許容範囲ですね!異なるAZ間での接続時間のレイテンシーは高い:
1cと1dからの接続では、それぞれ平均で14.9msと15.2msとなり、同一AZ内の接続よりも遅延があることが確認されたため、AZを跨ぐ接続のレイテンシーは高くなると考えられます。特に1dからの接続は100msを超えており、とあるプロジェクトで発生した内容と近い値です!稀とはいえ100msをDB接続だけに使われると気になってくるところ!
4. 仮説②: RDS Proxyを挟むことで逆に遅くなる?
4-1. 目的と期待する結果
この検証の目的は、RDS Proxyを介することによる接続遅延およびアベイラビリティゾーン(AZ)間の接続時間の影響を評価することです。期待される結果としては、RDS Proxyの導入により、DBとの間に別の要素が加わることで、若干遅くなることを予想しています。また、同一AZ内の接続がより高速であり、AZを跨ぐ接続が相対的に遅くなることを確認したいです。
4-2. 検証の構成

※ LambdaとRDS Proxyの間は、基本的に同一アベイラビリティゾーン (AZ) 内に配置されたRDS Proxyに接続されます。ただし、同一AZ内にRDS Proxyが存在しない場合は、AWSが自動的に接続の振り分けを行います。
環境設定:
RDS: AZ 1aにRDSインスタンスを配置する。
Lambda関数: 3つのAZ(1a, 1c, 1d)にLambda関数を配置する。
RDS Proxy: 2つのAZ(1a, 1c)にRDS Proxyを配置する。マルチAZ前提のため、シングルAZの構成を取れないため。
検証実行:
やることは検証①と同じ
各AZのLambda関数からRDSインスタンスへの接続を50回繰り返し試行し、各試行でのDB接続部分の時間を計測し、平均、最小、最大、標準偏差を算出する。
4-3. 結果と分析

直接接続に比べて、平均接続時間が約2倍~5倍ほど高い
各AZからの平均値を見ると、平均接続時間が直接接続に比べて高く、RDS Proxyを挟まない方が接続時間が短いことが考えられます。同一AZ内の接続時間のレイテンシーは低い:
1a, 1c内での接続時間の平均は28.7msと28.4msであり、1dからの接続に比べて接続時間が短いため、同一AZ内の接続のレイテンシーは低いと考えられます。異なるAZ間の接続時間のレイテンシーは高く、大きなばらつきがある:
1dからの接続では、平均で43.0msとなり、同一AZ内の接続よりも遅延がある。さらに最大値や標準偏差が高いことから、AZを跨ぐ接続のレイテンシーは高く、接続時間に大きなばらつきがあると考えられます。
5. まとめ
5-1. プロジェクトで発生していた課題と解決のヒント
AZを跨ぐ接続で接続時間が増加・ばらつきが発生
LambdaからRDSに接続する際、AZを跨ぐ場合に接続時間が増加し、さらにばらつきも見られることを確認しました。この課題はリードレプリカを同一AZ内に配置することで解決可能ですが、コストが発生する点に注意が必要です。また、書き込み処理についてはマスターへのアクセスが不可避であるため、全体のシステム設計を踏まえた検討が必要です。
RDS Proxyの利用で接続遅延が発生
RDS Proxyを経由した場合、RDSに直接接続する場合よりも接続時間が約2~5倍に増加することが分かりました。接続数が少ない小規模アプリケーションでは、この遅延がデメリットとなるため、直接接続も選択肢に入るでしょう。一方、今回のプロジェクトのようにイベント駆動で突発的なアクセス集中が予想されるケースでは、RDS Proxyが有効と判断し、この構成を採用しました。
5-2. 検証結果:LambdaからRDS接続のポイント
AZを跨ぐ接続では接続時間に注意が必要
→ 必要に応じてリードレプリカの利用を検討RDS Proxyの採用はアプリケーションの特性に依存
→ メリットとデメリットを理解し、ユースケースに応じた選択を
RDS Proxyが適したユースケース:
高トラフィック環境
大量のクライアントから同時に接続されるシナリオでは、RDS Proxyが効果を発揮します。Proxyはデータベースへの接続プールを提供し、接続の再利用によってDBインスタンスの負荷を軽減します。たとえば、大規模ECサイトやSNSのように一瞬でトラフィックが集中するケースでは、直接接続に比べスループットが向上します。大量の同時接続が発生する場合
一般的にRDSは接続の上限数があり、同時接続が増えると性能が低下します。RDS Proxyは接続を効率的に管理し、アプリケーションからの接続要求を集約することでデータベースに余計な負荷をかけません。例えば、複数のLambda関数から並列にアクセスが発生するシステムに適しています。高可用性が求められるシステム
ミッションクリティカルなアプリケーションでは、フェイルオーバーの時間を短縮できる点が大きなメリットです。RDS Proxyは障害発生時にセッションの再接続を自動で管理するため、アプリケーションが即座に接続先を切り替えられます。たとえば、金融システムやヘルスケアアプリケーションなど、停止が許されないシステムに最適です。
それでは、次回も楽しみにしていてください!@ultaroでした!👋💻✨