💬

AuroraにAutoScalingを実装しようとしたら失敗した話

2023/09/21に公開

AWS

RDS

aurora

tech

概要

経緯

DBにAuroraMySQLを使用している。
１台構成なのでCPU負荷が高くなった場合、アプリが重くなるなどの問題が発生する。
AutoScalingの設定を追加して、CPU負荷が高くなった場合、アプリが重くならないように対応したい。

検証した解決方法

DBのCPU負荷が高くなった時に自動で1台追加してくれるようAutoScaling設定を追加する。
・現在の構成
プライマリインスタンス1台
リードレプリカ0台

結果

Aurora１台構成ではAutoScalingできるが、リードレプリカが一気に２台増える。

結論

AutoScalingで２台増えるのはコスト的に無駄が多いため、最初からAurora2台構成にするか、Amazon Aurora Serverlessの導入を検討する。

加えて、AutoScaling起動時間を測定してみたが、起動に15分以上かかるため5分ぐらいのスパイクには対応できなさそうです。
以下はDB CPU使用率

検証

Amazon Auroraアーキテクチャについて

AuroraはAmazon Aurora DB クラスターという単位で構成されています。
クラスタの構成要素は1つ以上のDBインスタンスから成るインスタンス層とデータを管理するクラスタボリュームから成るストレージ層になります。

インスタンスの種類は、書き込み/読み取りのオペレーションで使用出来るプライマリDBインスタンスと、読み取り専用のオペレーションでのみ使用出来るリードレプリカになります。

Amazon Auroraについて

AutoScaling

CPU使用率が、一定以上の数値が一定期間が続いた場合、インスタンスを一台追加する機能
CPU使用率が、一定以下の数値が一定期間が続いた場合、インスタンスを一台削除する機能

AutoScalingポリシーの追加

設定：Aurora レプリカの平均 CPU 使用率が15％を超えたら一台追加する

設定項目

Policy name:ポリシーを識別するための名前
ターゲットメトリクス：インスタンスの増減の基準とするCPU使用率とかを選択する
ターゲット値：インスタンスを一台増やす基準
今回はテストのためターゲット値は15％に設定しました。

スケールイン/スケールアウト設定

スケールイン/スケールアウトのリクエストを一定時間ブロックするクールダウン期間を設定。
スケールアウト：インスタンスを一台増やす
スケールイン：インスタンスを一台減らす

普段は一台で使いたいため最小容量は0にしました。

インスタンスの削除設定は勝手に作られます。
Aurora レプリカの平均 CPU 使用率が13.5％を下回ったら一台削除します。
（50%でスケールアウトする設定の場合、45％を下回ったらスケールインします）

LocustでDBに負荷をかけてみる。

CPU負荷が25％以上でもAuroraの台数が増えない。

参照しているメトリクスがAuroraレプリカの平均 CPU 使用率なため、Aurora レプリカが最低一台起動していないとメトリクスが取れない状態でした。

参照メトリクスの変更

参照しているメトリクスをAuroraプライマリインスタンスの平均 CPU 使用率に変更。
AutoScalingポリシーアラームの説明にDO NOT EDIT OR DELETEと書いてありますが変更しました。
CPU負荷が15％以上の状態にして、Cloudwatchalramがアラーム状態になることを確認。

これでリードレプリカが1台増えると思いましたが、リードレプリカが２台増えました。。。

2台増える原因

AWS内の仕様のため非公開
AWSに問い合わせたところ、メトリクスのターゲット値と負荷の状況によって同時に複数台の追加が行われる場合があるらしいです。

他の対応案

Amazon Aurora Serverless

コスト削減と現状のAuroraで耐えられない負荷が来た時に対応するためAmazon Aurora Serverless v1かv2の導入を検討しました。

Amazon Aurora Serverlessとは
アプリケーションのニーズに応じて自動的に起動、シャットダウン、および容量をスケールアップまたはスケールダウンします。

ACU

Aurora 容量単位の事を指します。
スケールアップ/スケールダウンの単位としてACU(Aurora Capacity Unit)を使用しています。
1ACU あたり約2ギビバイト(GiB)のメモリ、対応するCPU、ネットワークが組み合わされます。
参考

Amazon Aurora Serverlessメリット

スパイク対策、CPU負荷対策になります。
CPU負荷が高くなると自動で高負荷にオートスケールしてくれる。
v２は1 秒あたり数十万のトランザクションへの即時スケーリングが可能。

参考

コスト

Aurora Serverless v2
東京リージョン料金: $0.20 per ACU Hour
ACUを0.5とした最小構成(東京)で1年で最低$876＝129648円

Aurora Serverless v1
東京リージョン料金: $0.10 per ACU Hour
ACUを1とした最小構成(東京)で1年で最低$876＝129648円

db.t4g.medium
リザーブドインスタンス1年で$710=105080円

Aurora Serverless v2、Aurora Serverless v1の方が高くつく結果に・・・

移行における課題

リーザブドインスタンスの期間が終わっていないため、移行すると前払い金額が無駄に。
今使っているdb.t4g.mediumよりコストが高くなりそうです。

まとめ

・AuroraのAutoScalingを動かすには常時ライターインスタンス一台とリードレプリカを起動しておく必要があります。

・現状の環境はAurora1台構成なので、CPU使用率が高くなっても自動でスケールアウトすることができない問題が残ったままです。
加えてAZ障害が起きると再度立ち上がるのに15分以上はかかりそうです。

・現状はDBのCPU使用率は平均11%とそこまで高くないので、問題はなさそうだが今後アクセスが増えるとAuroraかAurora Serverless v2をリーダーインスタンスとして追加した方がいいかもしれません。

・コスト削減のため、アクセスがないと停止して課金がされないAurora Serverless v1を開発環境に入れてもいいかもしれません。

概要

経緯