おはようございます。レアジョブのHUNTER×HUNTER芸人こと、DevOpsチームのshinoです。 (前回の記事: EC2 Auto Scalingを導入する際のポイント - RareJob Tech Blog)
HUNTER×HUNTERとAWSの知識をインプットするのが日課になっています。
今まさにAWS re:Inventが開催中です。来年は行きます。
この時期はAWSに関する大量の新サービス・アップデート情報が流れてくるのでキャッチアップが大変です。
今回はAWS re:Inventの中で発表があった情報の中で、個人的に熱いと思ったRDS Proxyについて触れたいと思います。
RDS Proxyとは
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しか使えないですが、東京リージョンでもお試し頂けます。
隙あらば利用していきたいと思います。
そういう訳で我々は一緒に働く仲間を大募集しております。
少しでも興味のある方は以下からどうぞ！
