RDSProxyについて
何の記事か？
開発でRDSProxyを使うことがあったので学んだことをメモしておく。
意外とEC2->ECS載せ替え案件の際に苦労してドキュメントを読み解いたのに結構忘れていることに気づき、多分RDSProxyもまた同様に忘れそうだなと思ったから。
とはいえ・・・
この「RDSProxyのスタート方法」をちゃんと真面目に上から読めば大体OKな気がする。
aws cliからの操作方法、何を見るのか？がしっかり書かれているから。
RDSProxyとは？
By using Amazon RDS Proxy, you can allow your applications to pool and share database connections to improve their ability to scale.
コネクションプールを作って色々なアプリケーションからのアクセスを可能にするAWSリソース。
通常、コネクションプールはアプリケーションサーバー側で作っている（と自分は認識している）が、AWSがRDSの前段にプールを単体で作ってくれるというサービスになっている。
例えばECSで動かしているアプリA、Lambdaで動かしているアプリBがあるとしたら、そのアプリの間でコネクションを使いまわせるというイメージ。
ユースケースは下記にあるので、検討する際はこちらを読んでチームで相談するなりしていただきたい。
Aurora：https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy-planning.html
RDS：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy-planning.html
RDSProxyを作成する際の要素
公式というよりは私の頭の中にある認識にあたることを留意していただきたい。
コンソールから作る際の各種メモをしておく。
ポイント1
アイドルクライアントの接続タイムアウト
アイドル状態のコネクションを保持する時間をここで決定できる。
デフォルトは30分。
ポイント2
接続プールの最大接続数
「接続プールの最大接続数」は「接続先のRDSリソースのmax_connectionsの何%まで接続可能にするか？」を示す。
例えば、接続先RDSのmax_connectionsが2000で、10%に設定する場合、200となる。
100%で設定してしまって良いのかは判断した方が良い。
例えば「既存のプロダクトが直で対象のRDSに繋ぎに行ってて、conncectionsの推移を見たらざっくり80%で張りつき続ける時間が1時間ある」など。
仮に、RDSProxyを使うプロダクトの需要予測に基づいて負荷試験を実施した場合、コネクション数が結果的に対象RDSのmax_connectionsの30%必要だったら、他プロダクトに影響が出るはず。
ここをちゃんと見ることで今のシステムアーキテクチャやアーキテクチャ構成要素に問題がないか？を会話できるきっかけにもなる。
（自分がやった時は将来も含めて特に問題がなかったので、対象プロダクトのテックリードと会話した結果そこまで行かなかったが・・・。）
接続借用タイムアウト
そのままだが、プールからコネクションを取り出そうとしてどれくらいで諦めるかを設定できる。
「こういうconfig値もあるな・・・」と頭の隅に留めておくことで、負荷試験をした際に「あ、ここ変えれば改善するだろ」となれるかも。
（自分はそのあたりは微妙。）
認証
ここで作成されるリソースで注目すべきなのは
- IAMロール
- SecretsManager
の2つ。
（IAM認証については利用してないので注目しない。）
SecretsManagerはなければ、画面から飛んでそのまま作れてしまう。
IAMロールは作成したSecretsManagerのARNを内部に保持する。
だから、SecretsManagerを作り直すようなことがあれば、IAMロール内にあるARNを作り直したものに差し替える必要がある。
ポイント3
サブネット
対象のRDSが配置されているサブネットと疎通可能なサブネットを指定する。
（ネットワーク設定まじ弱いのでここは個人的に強化必須。）
セキュリティグループ
セキュリティグループの設定。
とは言ってもインバウンドルールに設定する値に気をつけるだけ。
このRDSProxyに接続するアプリケーションが存在しているサブネットを指定してあげる必要がある。
設定しない場合、当然該当のアプリケーションは接続を拒否される。
設定値いくつか
詳細はこのドキュメントを読めば良い。
が、実務上主に着目したのは下記2つの指標（ドキュメントでは4つある）
- MaxConnectionsPercent
- MaxIdleConnectionsPercent
MaxConnectionsPercentは最大接続数を対象RDSのmax_connectionsの何%にするか？という話。
再掲すると
例えば、接続先RDSのmax_connectionsが2000で、10%に設定する場合、200となる。
100%で設定してしまって良いのかは判断した方が良い。
例えば「既存のプロダクトが直で対象のRDSに繋ぎに行ってて、max_conncectionsの推移を見たらざっくり80%で張りつき続ける時間が1時間ある」など。
仮に、RDSProxyを使うプロダクトの需要予測に基づいて負荷試験を実施した場合、コネクション数が結果的に対象RDSのmax_connectionsの30%必要だったら、他プロダクトに影響が出るはず。
という感じ。
MaxIdleConnectionsPercentは「アイドル状態になれるコネクションのパーセンテージ」。
ドキュメントに
上限は MaxConnectionsPercent の値で指定します。
とあるので、そこに留意して設定する。
とはいえ、最大接続数 < 最大アイドル数 は普通におかしいのでまあそりゃそうかという感じではある。
（最大接続数より最大アイドル数を大きくしても、無駄にアイドル状態のコネクションがプールにあるだけでリソースの無駄になるから。）
追記
コネクションプールの数ってどう設定しますか？と言われ、ちゃんと答えられなかった。
理由は下記の理想を現実でできてないから。
ふと考えた理想は「SLO、つまり内向きの指標を作っておいて、予想リクエスト数に基づいた負荷試験をしながら数値を改善する際にコネクション数が関わるならそこをいじる。また、将来のリクエスト数が何倍までなら耐えられるかをみておく。そこ次第。」となった。
が、そもそも要件満たせないアーキテクチャ設計をしてる時点で後戻りできない感じになってる気がするのでminで作って試験ぶん回すとかはしておくべきだと思う。
要はアーキテクチャ設計を論理的にやってますか？という話な気がする。
終わりに
忘れたらここを読んで思い出せ自分。
Discussion