皆さん、こんにちは。がーしらです。
PostgreSQLを使ってシステム運用してますが、中身はAWSのAmazon Auroraを使ってたりします。今回RDS Proxyの検証を行う機会がありましたので報告します。今後導入の参考にどうぞ。
RDS Proxyとは
RDS ProxyとはアプリケーションとDBの間に配置することができる、高可用性フルマネージド型データベースプロキシです。RDS Proxyには以下の利点があります。
- コネクションプーリングができる
- IAM認証を設定できる
- フェイルオーバーでもアプリ接続を切断せずにDBを切り替えれる
- TLS/SSL が使える
様々な用途でRDS Proxyの導入を検討されるかと思います。
今回は主に１の部分になります。その他の詳細はこちらより公式の説明をご覧ください。
コネクションがプーリングできるってことはコネクションが再利用できるのでは？という当たり前のことを思いついて試そうって話です。
RDS Proxyの料金
でも、お高いんでしょう？というのが業界の常です。では、RDS Proxyの価格はと言いますと、プロビジョニングインスタンスで東京リージョンの場合は以下の計算式となります。
0.018USD × vCPU × 時間
そうなんです。プロキシが動いている時間に対して課金なんです。商売上手ですよね、AWSって🤨
詳細はこちらに記載がありますが、Serverlessかどうかでも計算式違います。そこら辺はいい感じで読み替えてください。
仮にdb.r6g.2xlargeのAuroraにプロキシを設定して1ヶ月過ごす場合は以下の計算式になります。
0.018USD × 8 vCPU × 24時間 × 30日 = 103.68 USD
１ドル=150円なら15,552円となります。なかなか躊躇する金額ですよね、、、やっぱり高いやんけー。
とはいえ、DBのスペックを上げて倍々ゲームになるよりは格段に安いのでそこら辺は考慮する価値ありです。
試すことになったキッカケ
システムのテスト段階にて、分間12,600回を呼び出す場合にDB負荷が高くなり処理速度が劣化してしまうという壁がありました。今回のその壁を突破するために処理の改善やスペックの向上、リードレプリカへの分散など様々なことを行ったんですが、その中の１つにRDS Proxyの導入検討もありました。
今回はその内容を共有しようと思った次第です。
試した環境
今回RDS Proxyを試した環境は以下の環境となります。
- アプリケーションサーバー4台（EC2-c5.large×4台）
- データベースWriter1台（Aurora-db.r6g.2xlarge）
※Readレプリカはありません - ロードバランサーにてアプリサーバーは複数台で処理
※AutoScale環境ではありません - 呼び出す処理の内容は数回のDB参照と数回のDB更新を行う単純な処理
- 呼び出し回数は分間12,600回呼び出し（gatlingを利用）
- 処理はApache×PHP環境
- RDS Proxyの接続プールの最大接続数は4%←ここがポイント
※Auroraで上記インスタンスの場合、max_connectionは5000のため、5000 × 4% = 200プールされる想定
※最大接続数を適切に設定することによってプロキシは効果を発揮します。ここを変えなければDBとアプリケーションの間に意味のないトンネルをお金をかけて作るようなものです。
RDS Proxy無しの状態
RDS Proxyを設定せずにテストした場合の結果は以下です。
| DB-CPU | DB-メモリ | EC2-CPU | EC2-メモリ | 処理時間 |
|---|---|---|---|---|
| 73.53% | 75.29% | 53.59% | 22.13% | 0.6秒 |
RDS Proxy有りの状態
RDS Proxyを設定してテストした場合の結果は以下です。
| DB-CPU | DB-メモリ | EC2-CPU | EC2-メモリ | 処理時間 |
|---|---|---|---|---|
| 43.44% | 76.27% | 47.84% | 21.53% | 0.1秒 |
まとめ
結果を並べると以下になります。
| # | DB-CPU | DB-メモリ | EC2-CPU | EC2-メモリ | 処理時間 |
|---|---|---|---|---|---|
| Before | 73.53% | 75.29% | 53.59% | 22.13% | 0.6秒 |
| After | 43.44% | 76.27% | 47.84% | 21.53% | 0.1秒 |
あばばばばばばばばば
なんじゃこれぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇぇ
メモリの値変わってなぃぃぃぃぃぃぃぃぃぃぃぃぃぃぃぃ！！！！
うそやろぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉ！！！！
とまぁそっちかい的な冗談はさておいてですね、DBのCPUと処理時間が劇的に改善しました。推察するに、"今までDBで待っていた処理がプロキシで待つことになるのでその分DBのCPUが下がった"→"DBのCPUが下がったからもっと処理できるようになった"といったところでしょうか。
今回はPHPのため、コネクションをリクエストごとに接続＆リリースするというのも効果が出た要因に１つかと思われます。
この結果からRDS Proxyの良さが少しでも伝わったんじゃないでしょうか。とはいえ、実際に導入するとなるとピン留め問題やレイテンシーの検証など、確認検討事項は他にも有りますがそれでも導入する価値は有りそうかと！
簡単ですがRDS Proxyの能力についてご紹介しました。RDS Proxyには他にも利点があるので、それらも踏まえてコネクションプールのモジュールを導入するであったり、RDS Proxyを導入するであったりのキャッキャウフフ検討をする際の参考としていただければ幸いです。