いかがでしたかブログ風のタイトルですが、調べてみたがわかりませんでしたというオチでは無いのでご安心下さい。
はじめに
re:Invent2019でAmazon RDSプロキシが発表されました。発表された時はLambdaからRDSへの接続パターンが主に取りざたされていて、直近でLambdaからRDSを使う予定が特に無かった私はシュッと興味リストから外してしまっていました。がしかし、ある日、同僚のre:Invent参加レポートを読んでいたら興味深い文言を発見しました。
RDS Proxy を使うとフェイルオーバーが 66% くらい速くなる
まじか！これならLambda云々関係なく導入した方が幸せになりますね。実際にRDSプロキシのページを見てみると
With RDS Proxy, failover times for Aurora and RDS databases are reduced by up to 66%
と書いてありました。急にRDS Proxyに興味が湧いたので動かして実際にフェイルオーバ時の不通時間を計測して比較してみることにしました。
検証環境
以下のような環境で検証しました。検証用のために作ったDBで特にデータなどは入れていません。
DB
- DB: AuroraMySQL
- バージョン: 5.6.mysql_aurora.1.22.1
- マルチAZ: 2ゾーン(ap-northeast-1a / ap-northeast-1c)
- DBインスタンス: db.t3.small
RDS Proxy
- Previewリリース
- TLSやIAM認証はOFF
検証方法
こんな感じの素朴なshell scriptで1秒に1回mysqladminのpingコマンドを実行しました。
while true;
do
date ;
mysqladmin ping -h $HOST -u $USER -p$PASS ;
sleep 1;
done
このスクリプトを以下の3つのエンドポイントに向かって同時に実行しました。
- Auroraの読み取りエンドポイント
- Auroraのクラスタエンドポイント
- RDS Proxyのプロキシエンドポイント
その状態でコンソールからフェイルオーバーを実行し、pingが最後に成功した時間から次に成功するまでの時間を不通時間として計測しました。
結果
フェイルオーバー実績
- 07:29:06 ~ 07:30:06
- 1分
不通時間
- 読み取りエンドポイント
- 07:29:06 ~ 07:29:11
- 5秒
- クラスタエンドポイント
- 07:29:10 ~ 07:29:20
- 10秒
- プロキシエンドポイント
- 07:29:10 ~ 07:29:12
- 2秒
プロキシエンドポイントの不通時間はわずか2秒でした。pingの間隔が1秒なので、もしかしたらもっと短い時間で接続可能になっていた可能性もあります。読み取りエンドポイントと比較して60%、クラスタエンドポイントでは80%フェイルオーバー時の不通時間が短くなりました。
これはAuroraのエンドポイントがDNSの名前解決先を変えることによって接続先を変更するのに対し、プロキシエンドポイントはプロキシ側で接続先を直接ルーティングしているのが大きな差を要因みたいです。(そう書いてあった)
おわりに
いかがでしたか？
あんまり厳密には検証してはおらずちょっと動かして計測してみたという感じですが、それでもフェイルオーバ時の不通時間は圧倒的に少なくなりました。
現状プレビューなのでGAまでどうなるかはわかりませんが、個人的にはAuroraのカスタムエンドポイントが使いづらいと感じているのでRDS ProxyがAuroraクラスタの接続先インスタンスをより細かく制御できるように拡張されるとより便利だよなぁと期待しています。