[NEW]「Lambda-RDS」パターンももう怖くない!?フェイルオーバーももっと早くなるよ! RDS Proxyがプレビュー公開されました!#reinvent

2019.12.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、大阪オフィスのかずえです。現在ラスベガスで開催中のre:InventでAmazon RDS Proxyのリリースがアナウンスされました。(ただしプレビューです!

なにそれ?

  • 名前の通りRDS用のプロキシです。
  • スケーラビリティ、DB障害への耐久性、セキュリティの向上が期待できます。
  • 現在のところRDS MySQLとAurora MySQLで利用可能です。RDS PostgreSQL と Aurora PostgreSQLは間も無くとのこと。
  • 東京リージョンで早速使えます!

これまで

  • アプリとDB(RDS)間はコネクションを張ることで通信します。
  • ですがこのコネクション、DBサーバーのメモリやCPUを食います。
  • 例えばサーバーレスアーキテクチャーのアプリの場合、このコネクション数がものすごい数になることがあります。DBに負荷がかかってしまいます。遅くなったりスケーラビリティが制限されてしまいます。

これから

アプリとRDSの間にRDS Proxyを置くことができるようになります。

スケーラビリティの向上

このRDS Proxyが、一度張ったコネクションをプールし他のアプリからのアクセスでも使えるようにします(コネクションプーリング)。「これまで」で書いたような遅くなったり、スケーラビリティの制限が発生するのを改善することができます。

耐久性の向上

マスターインスタンスに障害が発生した場合、RDS Proxyは自動的にスタンバイインスタンスに接続しにきます。RDS Proxyを使わない場合に比べて最大66%フェイルオーバー時間が短縮されます。

セキュリティの向上

RDSプロキシを使用することで、Secrets Managerに認証情報を保存するか、IAM認証を使うとことでデータベースアクセスを管理できます。アプリのコード内に認証情報を埋め込む必要がなくなります。

使い方

  • RDS Proxyのプロビジョニングは不要です(マネージド)。パッチ当ての必要もありません。
  • 配置するサブネットを指定します。最低2つです。
  • アプリから繋ぎにいくエンドポイントをRDSのものからProxyのものに変えるだけで利用可能です。

料金

Pricing is simple and predictable: you pay per vCPU of the database instance for which the proxy is enabled.
(価格形態はシンプルかつ予測可能なものです。プロキシを有効化するDBインスタンスのvCPUごとの課金です。)

と、 RDS製品ページのAmazon RDS Proxy紹介に記載されていたので、DBインスタンスのスペックによって決まるようです。が、具体的な料金表を見つけることはできませんでした。。

感想

「Lambda - RDSってアンチパターンなんでしょ?」と言われる主要要因の一つの同時接続数の問題が解決できるはずで、非常にアツいアップデートかと思います。RDBの汎用性を享受しながら、サーバーレスの各種メリットも得られる、普通にアリな構成と言えるようになったのではないでしょうか。
Provisioned Concurrencyの件と併せて、これまでLambdaで辛かった大きな問題がふたつ一気に改善された良き日となりました。

また、最大66%フェイルオーバー時間を短縮できるというのもすごいですよね。「できる限りダウンタイムは減らしたい」という要件の場合は、サーバーレスな構成ではないアプリであってもRDS Proxy挟んだ構成をテストしてみる価値があると思います。

参考情報