この記事は Akatsuki Advent Calendar 2017 の 11 日目の記事です。
対象読者
AWSでRDSを運用している人
はじめに
2017/11/17からAuroraでAutoScaling が設定できるようになりました。
AuroraではReader Endpointを容易にスケールできるため、読み取り負荷を分散させたいようなワークフローでお世話になっている人も多いと思います。今回このスケールが自動化できるようになったため、負荷をかけてScalingを検証してみました。
スケールインの設定で注意すべき点がいくつかありますが、EC2やECSのAutoScalingのように作り込みを必要とせず設定1つで実現できるところはとても魅力ですので、検証結果をまとめていきたいと思います。
設定方法
GUIの場合
Auroraのクラスタを選択し、「Auto Scalingポリシーの追加」から設定できます。
AutoScaling設定後、自動でスケーリング発動用のCloudWatchAlarmも作成されます。
このCloudWatchAlarmのdescriptionには DO NOT EDIT OR DELETEと記載されているため要注意です。
CLIの場合
aws rdsではなくaws application-autoscalingで設定します。
aws application-autoscaling put-scaling-policy \
--policy-name test-autoscaling \
--policy-type TargetTrackingScaling \
--resource-id cluster:stress-test-masterdata-cluster \
--service-namespace rds \
--scalable-dimension rds:cluster:ReadReplicaCount \
--target-tracking-scaling-policy-configuration file://config.json
オプションで指定するjsonにはCloudWatchAlarmの情報などを、こと細かく埋め込まないといけないため、初見の場合はGUIの方が素早く作成できると思います。
以下、GUIから設定する前提で話を進めます。
設定項目
AuroraのAutoscalingで設定できる内容をまとめます。
Auroraから設定できる項目
以下の項目は、Autoscaling作成時に設定できます。
| 項目 | 説明 |
|---|---|
| ポリシー名 | ScalingGroupの名前 |
| IAM ロール | 自動で設定されます |
| ターゲットメトリクス | 平均CPU使用率 / 平均active接続数 |
| ターゲット値 | メトリクスの閾値 (CPU使用率30%など) |
| スケールイン | 有効 / 無効 |
| スケールインクールダウン期間 | スケールインしてから次のアクションまでの間隔 |
| スケールアウトクールダウン期間 | スケールアウトしてから次のアクションまでの間隔 |
| 最小キャパシティー | AuroraReplicaの最小数 |
| 最大キャパシティー | AuroraReplicaの最大数 (MAX15台) |
CloudWatchAlarmから設定できる項目
以下の項目は、自動作成されるCloudWatchAlarmを変更することで設定できます。
| 項目 | 説明 |
|---|---|
| スケールインの閾値 | defaultではスケールアウトのターゲット値 * 0.9 |
| 監視メトリクスのAlarm発動時間 | defaultではスケールアウトは3分間連続、スケールインは15分連続閾値を超えたらAlarmが発動します |
ただし、2017/12/11時点では、
- 自動作成されたCloudWatchAlarmのdescriptionには
DO NOT EDIT OR DELETEと変更が推奨されていないような記述がある（ 後述しますが、EDITしても問題なく動作します） - AutoScaling設定を変更すると、CloudWatchAlarmの設定も初期化される
といったことがあるので注意する必要があります。
設定できない項目
| 項目 | 説明 |
|---|---|
| スケジューラ | 時間をフックに起動はできません |
検証方法
- 今回、r4.xlargeのインスタンスのReader Endopointに対してCPU使用率15%程度がコンスタントにかかりつづけるように負荷をかけて検証をしました。
検証結果
1. ざっくり設定
1-1. 設定値
- スケールアウト閾値はCPU使用率14%
- スケールイン有効
- スケールイン/スケールアウトのクールダウン時間300秒
1-2. 結果
特にチューニングをしないと、 スケールアウトとスケールインを繰り返してしまいます。
理由は明確で、デフォルトのスケールイン閾値は スケールアウトの閾値 * 0.9 のため、今回の場合、スケールアウトしてCPU使用率が9%程度に下がった途端、スケールインの閾値CPU使用率12.6%を下回り、スケールインしてしまう、という状態になっていました。
上記のように、負荷のかかり具合によっては、スケールアウトとスケールインを繰り返すリスクがあります。
2. スケールインの設定を変更する
自動作成されるCloudWatchの設定を変更し、スケールインのチューニングができるか検証してみます。
（前述のとおりDO NOT EDIT OR DELETEという注意書きがあるのですが、無視して変更します）
2-1. 設定値
- スケールアウト閾値はCPU使用率14%
- スケールインの閾値はCPU使用率3%
- スケールイン有効
- スケールイン/スケールアウトのクールダウン時間300秒
2-2. 結果
変更した結果、スケールインすることなく動いています。
注意点としては、Aurora側でAutoScalingの設定を変更すると、過去のCloudWatchAlarmが削除され新規のCloudWatchAlarmが作成されるため、過去にCloudWatchAlarmでチューニングした内容が初期化されてしまいます。
その他補足
- AutoScaling設定を削除しても、スケールアウトによって作成されたインスタンスは削除されませんでした。
- 監視するメトリクスはインスタンスごとではなく、READER全体のクラスターメトリクスです。
- 作成されるrdsの名前はapplication-autoscalingになります。
まとめ
今回、AuroraのAutoScalingの検証によってわかったことをまとめます。
- Good
- AuroraのAutoScalingでは設定1つで簡単にReader EndpointのScalingが実現できる（作り込みの必要がない）
- オンラインで設定変更可能
- More
- 自動設定されるスケールインの閾値はデフォルトでは使いづらいためチューニング必須。
- スケールインのチューニングは自動生成されるCloudWatchをいじる必要があるが
DO NOT EDIT OR DELETEという、変更が推奨されていないような注意書きがある（変更しても問題なく動きます） - AuroraのAutoScaling設定を更新すると、CloudWatchで変更した内容が初期化されるため注意が必要
DO NOT EDIT OR DELETEの記述が恐ろしいという人は、万が一のときのためにスケールアウトの設定だけ自動化しておき、スケールアウトが発動したらイベントフックで通知してタイミングを見はからってスケールイン、ぐらいの運用にとどめておくのがよいかもしれません。
AuroraのAutoScalingはまだリリースしたばかりなので、今後のアップデートに期待です！
※ この記事は2017/12/11時点のAurora AutoScalingの設定で記事を書いてます。