Amazon RDS Proxyによるデータベース接続管理

アプリケーションがリレーショナルデータベースへアクセスするには、データベースとの接続を確立して維持する必要があります。接続の作成と認証には処理時間やメモリなどの資源を使い、データベースが同時に受け入れられる接続数にも上限があります。アプリケーションの実行数が短時間に増えたり、多数の処理単位がそれぞれ別の接続を作ったりすると、クエリ自体は軽くても接続管理がデータベースの負荷やボトルネックになります。

Amazon RDS Proxy はアプリケーションと Amazon RDS または Amazon Aurora の間に配置する、フルマネージド型のデータベースプロキシです。アプリケーションからの接続を受け、バックエンドのデータベース接続をプールして再利用します。データベースエンジンやアプリケーションを大きく変更せずに、接続の集中を緩和し、障害時の接続管理を支援できます。

接続プールと多重化

RDS Proxyを使わない構成では、アプリケーションごとに確立した接続がそのままDB接続を占有しやすくなります。サーバーレス関数のように同時実行数が急増し得るアプリケーションでは、処理を実行する環境が増えたときDB接続も一気に増え、データベースの接続上限やメモリを圧迫することがあります。

Proxyを挟むと、アプリケーション側のクライアント接続をProxyが受け付け、データベースに対する接続を管理します。Proxyは接続をプールし、ある処理がバックエンド接続を使い終えた後、その接続を別の処理に再利用できます。データベースへ届く接続確立要求を抑え、短い処理が連続する状況で接続を効率よく使えるようにします。

この再利用を接続の多重化と呼びます。多くの場合、Proxyはトランザクションの境界でクライアントとバックエンドの対応を切り替えられます。ただし、アプリケーション側の接続数とデータベース側の接続数が常に一定比率になるわけではありません。並行して実行中のトランザクション数やクエリの時間、DB側の許容接続数がバックエンド接続数を左右します。

セッション固定と長い処理

データベースセッションには、ユーザー設定、セッション変数、一時テーブル、準備済みステートメントなど、接続にひも付く状態があります。Proxyがその状態を別のクライアントへ引き継げない場合、状態の整合性を保つためにクライアントと特定のDB接続を結び付けたままにします。これを**セッション固定（ピンニング）**と呼びます。

セッション固定が起きている間は、対象のバックエンド接続を他の処理へ回せません。また、トランザクション中の接続は処理が終わるまで占有されます。そのため、長いトランザクションやセッション状態を頻繁に変更するSQLが多いアプリケーションでは、Proxyを導入しても多重化率が期待ほど上がらない場合があります。アプリケーションが必要としないセッション状態を不用意に設定しないこと、トランザクションを必要な範囲で完了させることが重要です。

Lambdaなどで接続集中を抑える

AWS Lambdaでは、リクエスト増加に伴って関数の同時実行数が増えることがあります。各実行環境が独自にDB接続を作成すると、データベースの処理能力や通常の接続上限を超える接続要求が発生する可能性があります。RDS Proxyを間に置けば、関数からの接続要求をProxyで受けて、データベース側の接続プールを共有できます。

同じ考え方は、コンテナや常時稼働のアプリケーションにも適用できます。特に、アプリケーションの実行数が変動し、短いDB処理が多数発生する構成で有効です。Proxyを利用してもDBのCPU、メモリ、ストレージI/Oが増えるわけではありません。接続数が落ち着いても遅いSQLやDBの計算資源不足が残る場合は、実行計画やDB性能を別に調査します。

DB障害とフェイルオーバー時の接続

データベースがフェイルオーバーや再起動を行うと、アプリケーションから見た接続先のDBインスタンスが変わったり、既存の接続が利用できなくなったりすることがあります。アプリケーションがDBインスタンスへ直接つないでいる場合、接続を破棄して再作成する処理を個々のクライアントで適切に行う必要があります。

RDS Proxyは、データベースの状態を監視し、利用可能なターゲットへ接続し直すことでフェイルオーバー時の切り替えを支援します。また、ターゲットが一時的に利用できない場合、Proxyは接続プールですぐに処理できないアプリケーション接続をキューイングしたり、流量をスロットリングしたりできます。設定した接続数の上限を超える要求は拒否されることがあるため、Proxyは過負荷を無制限に吸収する装置ではありません。データベースへの接続を一元管理することで、多数のアプリケーション接続が一斉に新しいDB接続を作ろうとする負荷を抑え、DBが処理できる範囲を超えたときの動作を制御できます。

ただし、ProxyはDB障害をなくすものではありません。進行中のトランザクションや、障害の影響を受けた個々のクエリは失敗することがあります。待ち時間やタイムアウト設定を超えた処理、再送してはいけない更新処理も考慮が必要です。アプリケーションでは接続エラーを検出し、処理の冪等性を確認したうえで、必要な再試行を設計してください。

認証、暗号化、ネットワーク制御

RDS ProxyはVPC内に配置され、アプリケーションとDBの間の接続点になります。ProxyとDBは同じVPCに配置する必要があり、Proxy自体をパブリックに公開することはできません。ProxyにはVPCセキュリティグループを設定し、アプリケーション側からProxyへの通信、およびProxyからデータベースへの通信をそれぞれ許可します。一般的には、DB側のセキュリティグループでアプリケーション全体からの直接接続を許可するのではなく、Proxyに割り当てたセキュリティグループを送信元として許可します。これにより接続経路を絞り、DBへの通信をProxy経由にできます。

データベースのユーザー名とパスワードをSecrets Managerに保管し、ProxyのIAMロールに必要なシークレットの読み取り権限を付与できます。クライアントからProxyへの接続にIAM認証を使い、ProxyからDBへはSecrets Managerに保存されたデータベース認証情報を使う構成が可能です。対応する構成では、クライアントからProxy、ProxyからDBまでの両区間にIAMデータベース認証を使うエンドツーエンドIAM認証も選べます。クライアントがProxyへ接続する際の認証、ProxyがDBへ認証する方法、ProxyのSecrets Managerアクセスを許可するIAMロールは、別の役割です。利用できる組み合わせはエンジンとバージョンで異なるため、設計時に公式の対応条件を確認します。

通信の機密性を保つため、クライアントとProxy、Proxyとデータベースの接続でTLSを構成できます。アプリケーション側でも、AWSが提供する証明書を正しく検証する設定を使用します。IAMポリシーやセキュリティグループを設定しただけで、DBユーザーやテーブルに対する権限が自動的に最小化されるわけではありません。データベース内部の権限も必要な操作だけに絞ります。

設定と運用で見る項目

ProxyはDB接続をまとめますが、利用可能なDB接続を無制限に作るわけではありません。DBの最大接続数を踏まえて、ProxyがDB接続プールに割り当てる上限や、接続が利用可能になるまでクライアントを待たせる時間を設定します。DB接続を使い切ると、追加の処理は待機またはエラーになるため、アプリケーションの同時実行数と実際のプール利用量を監視します。

運用では、Proxyの接続数、DB側の使用接続数、接続待ち時間、DB負荷、接続エラーやタイムアウトを合わせて確認します。DB接続の上限を大きく設定しすぎると、データベース側のメモリや処理能力を圧迫することがあります。プールの上限は「多ければよい」とは限らず、クエリの所要時間とDBの余力に合わせます。

RDS Proxyに対応するDBエンジンとバージョン、利用可能なリージョンには条件があります。また、接続上限や認証などの制約もエンジンによって異なります。導入前に対象DBの組み合わせを公式の対応表と制限事項で確認してください。Proxyには追加料金がかかります。費用の課金単位や単価は、DBエンジン、リージョン、構成などによって異なるため、導入前に最新の料金ページで確認します。接続管理による可用性や運用負荷の改善と、Proxyの利用費用・待ち時間のトレードオフをアプリケーションの負荷で評価してください。

RDS Proxyが解決する問題と解決しない問題

課題	RDS Proxyの役割	別に検討する機能・対策
多数の短い処理がそれぞれDB接続を作る	接続プールと多重化でDB接続を再利用する	アプリケーション側の接続ライフサイクル、同時実行数
フェイルオーバー時に多くの接続を張り直す	DBへの再接続を集中管理し、影響を緩和する	アプリケーションのタイムアウト、再試行、冪等性
読み取りクエリを複数DBへ分散する	接続管理を行うが、読み取りレプリカとしては動作しない	RDS/Auroraのリードレプリカ、読み取りエンドポイント
同じクエリ結果を再利用してDB負荷を下げる	クエリ結果をキャッシュしない	ElastiCacheなどのキャッシュをアプリケーションに導入する
遅いクエリを速くする	接続処理の負荷は抑えるが、SQL実行計画やDB容量は変更しない	SQL・インデックス・インスタンスクラス・ストレージの見直し

試験での見分け方

• Lambdaの同時実行増加でDB接続が急増する: RDS Proxyを使って接続をプールし、DB接続を再利用する。
• 短いトランザクションを多数処理する: Proxyによる多重化が有効になりやすい。DB接続上限とアプリケーション同時実行数も合わせて考える。
• セッション変数や一時テーブル、長時間トランザクションを多用する: セッション固定や接続占有により多重化の効果が弱まる可能性がある。
• DBのフェイルオーバーで接続の復旧負荷を軽減したい: RDS Proxyは接続先の切り替えを支援する。ただし、すべての処理が成功する保証やアプリケーションの再試行不要を意味しない。
• SQLの結果をキャッシュして読み取りを高速化したい: RDS Proxyではなく、ElastiCacheなどのキャッシュ設計を検討する。
• 読み取り要求を複製先へ分散したい: Proxyとリードレプリカは別の役割であり、レプリカや対応エンドポイントを検討する。
• RDS Proxyを導入すればDB自体の容量不足も解消する: 誤り。Proxyは接続管理を支援し、DBのCPU・メモリ・I/Oを増やさない。

AWS公式ドキュメント

• Amazon RDS Proxyとは
• RDS Proxyの概念と接続管理
• RDS Proxyでのセッション固定
• RDS Proxyへの接続
• RDS Proxyのベストプラクティス
• RDS Proxyの料金
• Amazon RDSの料金