クラウド事業部の原口です。
AuroraServerlessV2についてのお話です。
AuroraServerlessV2というサービスはデータベースのサービスなのですが、特徴としてACUと呼ばれる単位の性能を消費した分が費用となるサービスです。
消費したACUぶんだけの金額となるのでコストは最適化されますし、急激な負荷があった場合でもACUを消費して耐える事ができる、という感じです。
起きた問題
さて、こちらのAuroraServerlessV2ですが、運用中、writerとreaderの2台構成のクラスター環境においてwriterに負荷がかかると、(利用していないはずの)readerも併せてACUが増加してしまうという問題が発生しました。
これだと金額的にわりと問題ですのでこちらの原因を調べてみました。
先に結論
readerのフェイルオーバー優先順位の昇格階層(tier)が「0」か「1」に設定されているreaderインスタンスはwriterインスタンスに併せてACUがスケールしますので、この設定を除外したい場合は昇格階層(tier)を「2」以上にしてください。
検証環境を作成
取り急ぎwriterとreaderの2台構成のクラスターとしたAuroraServerlessV2を作成します。
最小ACUは1で最大を16としました。
負荷をかけてみる
簡易的な方法という事でEC2からmysqlslapで負荷をかけてみます。
接続先はWriterエンドポイントです。
1mysqlslap -u***** -p****** -P 3306 -h ********.******.rds.amazonaws.com --auto-generate-sql --iterations=10000 --concurrency=100さて、スケールしたACU消費量はCloudWatchメトリクスにおいては「ServerlessDatabaseCapacity」で確認可能です。こちらを確認してみると・・・
はい、、WRITERのACU消費に併せてREADERのACU消費もあがっている事がわかります。。
困った時のドキュメント
この仕様について調べてみるとAWSのドキュメントにはしっかり記載されていました。
ざっくり言うと「クラスター構成における writer昇格候補のreaderは常にwriterの役割を引き継げるようにwriterに併せてスケールしますよ」という事ですね。
readerの設定を変更し、昇格階層(Tier)をさげる
ドキュメントでは昇格階層が「0」か「1」の場合にwriter引き継ぎreaderとしてACUスケールするとあります。ですのでreaderの昇格階層を「2」へ変更します。
※というかここにもめっちゃ書いてあった。
再度負荷をかけてみる
readerの昇格階層を「2」へ変更しましたので、
再度EC2からwriterに向けてmysqlslapで負荷をかけてみます。
1mysqlslap -u***** -p****** -P 3306 -h ********.******.rds.amazonaws.com --auto-generate-sql --iterations=10000 --concurrency=100さて、cloudwatchはどうなったかというと、、、
ばっちり！writerのみACUがスケールされていました。
readerのACUが少しあがってるのはレプリケーション負荷でしょうね
まとめ
AuroraServerlessV2でできるだけコストを削減したい場合はreaderのTierは「2」にしましょうー