RareJob Tech Blog

レアジョブのエンジニア・デザイナーによる技術ブログです

RDS Proxyでサーバレス捗りそうだと思いました

f:id:shino8383:20191205183647j:plain

おはようございます。レアジョブのHUNTER×HUNTER芸人こと、DevOpsチームのshinoです。 (前回の記事: EC2 Auto Scalingを導入する際のポイント - RareJob Tech Blog)

HUNTER×HUNTERAWSの知識をインプットするのが日課になっています。

今まさにAWS re:Inventが開催中です。来年は行きます。

この時期はAWSに関する大量の新サービス・アップデート情報が流れてくるのでキャッチアップが大変です。

今回はAWS re:Inventの中で発表があった情報の中で、個人的に熱いと思ったRDS Proxyについて触れたいと思います。

RDS Proxyとは

f:id:shino8383:20191205184022p:plain

RDS Proxyとは名前の通りRDSへの接続をプロキシするお方です。

RDS Proxyの主なメリットは以下のようになります。

  • RDSへの接続にコネクションプールを利用できる
  • RDS Proxyの利用にはSecrets ManagerかIAM認証を用いて接続するので、よりセキュアな認証を強制できる(推奨はIAM認証)

また、RDS Proxy自体は可用性を持ったマネージドなプロキシサービスなのでプロキシサーバの管理コストはこちらが持つ必要がありません。 移行コストについては、従来利用していたRDSエンドポイントをRDS Proxyが提供するエンドポイントに差し替えるだけで利用可能です。

クライアント側でコネクションプールを実装しなくていいってだけでも嬉しいです。

このようなサービスのRDS Proxyですが、私が初見で感じた感想は

「サーバレス捗りそう(小並感)」

でした。

LambdaとRDS(RDB)の話

話は変わりますが、LambdaとRDS(RDB)は相性が悪く、アンチパターンと言えます。

なぜ相性が悪いのでしょうか?

一般的にRDBは大量の接続要求をさばくのが苦手だからです

RDBがクエリを処理する際にかかるコストに比べ、TCP接続を確立するコストやDB側でコネクションを生成するコストが比較的高いため、 高負荷なワークロードでは"接続"にかかるコストでCPUやメモリを食いつぶしてしまうことが多いです。

そのため、アプリケーション規模が大きくなってきてRDBが悲鳴を上げ始めたらコネクションプーリングなどを用いて、DBへの接続にかかるコストを低くするなどの対処が取られるケースが多いかと思います。 ただし、コネクションをプールして利用するのにもメモリやCPUを使いますし、レスポンスタイムも遅くなることが多いのでRDBへの負荷が小さいうちは割に合わないと思います。

(RDBじゃないですがRedisでもコネクションプールを使わずにCPUリソースを食いつぶしてしまったことがあります。)

これがどうLambdaと関係あるかと言うと、

簡単にスケールしてしまうLambdaはコネクションプールを使うことができず、 Lambda->RDSを利用しようと思うと大量の接続要求を行ってしまいRDSが悲鳴をあげる、

という図です。 夜間のバッチ処理とかなら使えるとは思いますが、用法用量を守る覚悟が必要です。

また、RDS側がリソース的に耐えられたとしてもDBへの最大接続数の制限に引っかかってエラーとかも全然あります。

なので、サーバレスやろうぜってなってもRDS(RDB)をデータソースの候補にあげることができず、DynamoさんやElastiCache For Redisさんなどが使われる事例が多いと思います。

今回、RDS Proxyさんが降臨なさったのでLambdaからRDS使えるぞ!というのが

「サーバレス捗りそう(小並感)」

に繋がります。

終わりに

RDS Proxyの登場で、RDBMSの種類問わずにRDSをデータソースとしたアーキテクチャをサーバレスで構築することが可能になります。 控えめに言って熱いです。

現在はまだPreview版なのでMySQLとAuroraしか使えないですが、東京リージョンでもお試し頂けます。

隙あらば利用していきたいと思います。

そういう訳で我々は一緒に働く仲間を大募集しております。

少しでも興味のある方は以下からどうぞ!

👏採用/求人情報 | アピール | 未来の教育を作る人のマガジン インフラエンジニア(AWS)