この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
PostgreSQL版のRDS Proxyがプレビューリリースされました！
昨年2019年12月のre:Invent中にプレビューリリースされたRDS Proxyですが、その際にリリースされたのはMySQL版で、RDS MySQLとMySQL Auroraのみに対応していました。これが新たにAurora PostgreSQL と RDS PostgreSQLにも対応しました！
RDS Proxyって何？
名前の通りRDS用のプロキシで、DBのクライアントとRDSの間に配置します。
例えば以下はクライアントがLambda関数の場合ですが、RDS Proxy無しだとこんな構成です。
これがRDS Proxyありだとこうなります。
何が嬉しいの？
メリット1: 接続処理に関する問題の緩和
クライアントとRDBが通信するにはまず接続処理を実施する必要があります。接続生成処理にはDBのリソースを大きく消費するので、この接続生成処理をできるだけ実施しなくて済むようにしたいです。そこで、一度生成した接続をリクエスト間で再利用するコネクションプールという機構を導入することでDBリソース消費を抑える場合があります。
ですが、クライアントがLambda関数の場合、このコネクションプールの機構を導入するのが難しいです。かつ、Lambdaがよく使われるケースとして、リクエストが急激に増える場合があるワークロードがあります。リクエスト急増時、つまりDB同時接続数が増えた場合に、DBリソースの消費が激しくなったり、同時接続最大数を超えてエラーになったりすることが考えられます。もしくはそのようなことを起こさないために過剰にスペックの高いRDSを用意する必要がありました。
このRDS Proxyを導入することで、クライアントがLambda関数である場合でもコネクションプールの機構を簡単に導入することができ、前述のような問題の緩和が期待できます。
メリット2: フェイルオーバー時間短縮
RDS Proxyを使うと、使わない場合に比べてフェイルオーバーにかかる時間を最大66%削減することができます。（これはMySQL版がリリースされた昨年12月時点のドキュメントに書かれていた記述ですので、PostgreSQL版は少し異なる可能性はあります。）
RDS Proxyを使わない場合のフェイルオーバーは、DNSレコード値の切り替えによって実現されています。つまり、RDSのエンドポイントのDNSレコードがマスターインスタンスのIPを返す状態であったところから、スタンバイインスタンス（Auroraの場合はマスターインスタンスに昇格したインスタンス）のIPを返すように変更します。この方法ですと、例えばクライアントがローカルにDNSレコード値をキャッシュしていた場合、フェイルオーバー先インスタンスにリクエストしに行くようになるまでに時間がかかる場合があります。
RDS Proxyを使う場合、クライアントのアクセス先はDBのエンドポイントからRDS Proxyのエンドポイントに変わります。RDS Proxyのエンドポイントは、フェイルオーバーが発生しても引き続き同じIPで接続を受け入れます。RDS ProxyからRDS（Aurora）間の接続をRDS Proxyが内部的に（=DNSレコード切り替えではない方法で）実現するため、フェイルオーバー時間を短縮できます。
メリット3: セキュリティの向上
- RDS Proxy - RDS（Aurora）との通信が暗号化(TLS通信)されていなくても、クライアント - RDS Proxy間の通信を暗号化(TLS化)することができます。
- クライアント - RDS Proxy間の認証をIAM認証にすることができます。永続的な認証情報を使わなくなるので、よりセキュアになります。
- RDS ProxyからRDS(Aurora)に接続する際、認証情報はSecrets Manager経由で読み取る必要があります。クライアント - RDS Proxy間もこのSecrets Managerを使う構成にすればよりセキュアな環境にすることができます。（クライアント - RDS Proxy間でSecrets Managerを使用することは必須ではありません）
メリット4: 簡単に使える
- クライアントは接続エンドポイントをRDS（Aurora）のものからRDS Proxyのものに変更するだけでRDS Proxyを利用できます。
- RDS Proxyはマネージドサービスですので、プロビジョニングは不要です。需要に応じてスケールします。
デメリット
料金
追加料金がかかります。Proxyを設置するRDS（Aurora）のvCPU×時間で課金されます。東京リージョンの場合、1時間×1vCPUあたり$0.018です。
例えば、2 vCPUsを持つm5.largeDBインスタンスに対して30日間RDS Proxyを有効化した場合、料金は以下の通りになります。
- $0.018 × 2(vCPUs) × 24(時間) × 30(日) = $25.92
また、以下の補足があります。
- ※ 最低でも 2vCPU分の課金が発生します。つまりt2.small DBインスタンス(1vCPU)に対してRDS Proxyを有効化した場合でも1時間あたり 2vCPU分の課金 = $0.018×2 = $0.036ずつの課金が発生します。
- ※ 秒単位で課金されます。また、最低でも(=10分以内の利用でも)10分ぶんの課金が発生します。
料金についての詳細は以下からどうぞ。
レイテンシ
RDS Proxyを使うと、使わない場合に比べてクエリまたはトランザクションの応答時間に平均 5 ミリ秒のレイテンシが発生します。
（これもMySQL版がリリースされた昨年12月時点のドキュメントに書かれていた記述ですので、PostgreSQL版は少し異なる可能性はあります。）
注意点: まだプレビューです
- 予告なく提供の停止・終了がされる場合があります。
- 予告なく仕様が変更になる場合があります。
- そのため本番環境での利用は時期早々です。控えましょう。
- 使ってみて得られた情報をブログやSNSへの投稿するのはNGです。
プレビューについての詳細は以下エントリに書かれています。
3
