- 課題
- Application Auto Scalingの「スケジュールされたスケーリング」が有効
- 設定手順
- 補足1.Application Auto Scalingが作成したリードレプリカのフェイルオーバー優先順位について
- 補足2.スケールイン時の削除仕様について
- 感想
技術4課の前田です。 実務で下記の課題に直面した時に考えたことを記事にさせていただきました。
課題
- とあるシステムでDBにAurora PostgreSQLを使用している。
- 日中帯はリードレプリカ1台のみを稼働させ、夜間帯はバッチ処理を行うためにリードレプリカ台数を増加させたい。
- 急激なリクエスト増加に対応するために、バッチ処理開始時刻の前に増加させておきたい。
Application Auto Scalingの「スケジュールされたスケーリング」が有効
Application Auto ScalingとはAWSリソースを自動スケーリングするためのサービスで、Aurora以外にもECS、EMR、DynamoDBなどでも使われています。
（AuroraのAuto Scalingは「Aurora Auto Scaling」と呼ばれることもありますが、実態はApplication Auto Scalingです。）
Auroraで使用できるApplication Auto Scalingには下記の3つの種類があり、上記の要件に対応するには「スケジュールされたスケーリング」が有効になりそうです。
ターゲット追跡スケーリングポリシー…Auroraリードレプリカの平均CPU使用率や平均接続数を指定し、指定した値になるようスケールイン・スケールアウトするポリシーです。
ステップスケーリングポリシー…CPU使用率等が閾値を超えた場合などに、あらかじめ指定した単位でスケールイン・スケールアウトするポリシーです。ターゲット追跡スケーリングポリシーと似ていますが、閾値1、閾値2と複数の閾値を設けることが可能であったり、スケーリング台数を閾値1超過時、閾値2超過時ごとにそれぞれ指定する…と細やかに制御することが可能です。
スケジュールされたスケーリング…予め指定したスケジュールに基づいてスケールイン・スケールアウトするポリシーです。
設定手順
前提
「スケジュールされたスケーリング」は2024年1月時点ではマネジメントコンソールから設定することは出来ず、AWS CLIを使用する必要があります。
今回はAdministrator権限を持つIAMユーザで、CloudShellからCLIコマンドを実行していきます。
最小権限についての解説は別の記事で行います。
環境
「database-1」という名前のAurora PostgreSQLがあります。
デフォルトでライターインスタンス1台、リーダーインスタンス(リードレプリカ)1台がある状態です。
左記DBに対してリードレプリカが最大5台になるよう増加させ、最小1台まで減少させるようにスケジュール設定していきたいと思います。
1.スケーラブルターゲットの登録
「どのAWSリソースがApplication Auto Scalingの対象になるのか？」を定義するための操作です。 「register-scalable-target」コマンドを実行します。
- 「resource-id」には、Auroraクラスターの識別子を指定します。今回は「database-1」となります。
- 「min-capacity」「max-capacity」の値は手順2と手順3で設定するスケジュールドアクションによって上書きされるため、適当な値で問題ないのですが、一応1、5をそれぞれ設定しています。
aws application-autoscaling register-scalable-target \
--service-namespace rds \
--resource-id cluster:database-1 \
--scalable-dimension rds:cluster:ReadReplicaCount \
--min-capacity 1 --max-capacity 5
実際に登録されたかを確認するには「describe-scalable-targets」コマンドを実行します。
aws application-autoscaling describe-scalable-targets \
--service-namespace rds
実行画面は下記になります。
2.スケジュールドアクションの登録_スケールアウト
「リードレプリカをいつ、何台まで増加させるのか？」を定義するための操作です。「put-scheduled-action」コマンドを実行します。
- 「scheduled-action-name」は一意になるような名前を付けてください。今回は「scaleout」としています。
- 「schedule」にはcron式を用いています。下記の設定ですと、「毎日18:54」となります。UTC日付となるためご注意ください。
- 「scalable-target-action」にはスケーリング時の台数を指定します。5台までスケールアウトさせたいため「MinCapacity」「MaxCapacity」ともに5と設定しています。（実を言うとスケールアウトするだけであれば「MinCapacity」の値を設定するだけで良いのですが、スケールインも織り交ぜて毎日実行することを考慮し「MaxCapacity」の値も明示的に設定しています。）
aws application-autoscaling put-scheduled-action \
--service-namespace rds \
--scalable-dimension rds:cluster:ReadReplicaCount \
--resource-id cluster:database-1 \
--scheduled-action-name scaleout \
--schedule "cron(54 9 * * ? *)" \
--scalable-target-action MinCapacity=5,MaxCapacity=5
「describe-scheduled-actions」コマンドを実行し、登録したスケジュールの確認が行えます。
aws application-autoscaling describe-scheduled-actions \
--service-namespace rds \
--resource-id cluster:database-1
実行画面は下記になります。
指定した時間以降にコンソール画面を見てみると、デフォルトのリードレプリカ1台に加えて、Auto Scalingで4台追加され、合計5台になっていることが分かります。
3.スケジュールドアクションの登録_スケールイン
「リードレプリカをいつ、何台まで減少させるのか？」を定義するための操作です。「put-scheduled-action」コマンドを実行します。
- 「scheduled-action-name」は「scalein」としています。
- 「scalable-target-action」には1台までスケールインさせたいため「MinCapacity」「MaxCapacity」ともに1と設定しています。
aws application-autoscaling put-scheduled-action \
--service-namespace rds \
--scalable-dimension rds:cluster:ReadReplicaCount \
--resource-id cluster:database-1 \
--scheduled-action-name scalein \
--schedule "cron(12 10 * * ? *)" \
--scalable-target-action MinCapacity=1,MaxCapacity=1
指定した時間以降にコンソール画面を見てみると、デフォルトのリードレプリカ1台にまで減少していることが分かります。
4.スケーリング結果の確認
今まで行われたスケーリングの詳細を確認できる操作です。
「describe-scaling-activities」コマンドを実行します。
aws application-autoscaling describe-scaling-activities \
--service-namespace rds \
--scalable-dimension rds:cluster:ReadReplicaCount \
--resource-id cluster:database-1
実行画面は下記になります。
5.その他のコマンドについて
上記で挙げた以外にも下記のコマンドの使用機会があるかと思います。詳細についてはApplication Auto ScalingのAPIリファレンスをご覧ください。
スケジュールドアクションの削除…delete-scheduled-action
スケーラブルターゲットの解除…deregister-scalable-target
補足1.Application Auto Scalingが作成したリードレプリカのフェイルオーバー優先順位について
Application Auto Scalingによって作成されるインスタンスのフェイルオーバー優先順位は一番低い15に設定されていました。
そのためフェイルオーバーが発生しても、手動で作成されたものなど、優先順位の高いレプリカが最初にライターインスタンスに昇格されます。
公式ドキュメントにも上記仕様は明記されています。
また、新しい Aurora レプリカの昇格階層は、最も低い優先順位 (デフォルトでは 15) に設定されています。つまり、フェイルオーバー時には、手動で作成されたものなど、優先順位の高いレプリカが最初に昇格されます。
補足2.スケールイン時の削除仕様について
Application Auto Scalingの仕様として、削除対象にはApplication Auto Scalingが作成したリードレプリカ以外のリードレプリカは含まれません。今回の例で言えば、デフォルトで存在するリードレプリカはApplication Auto Scalingの削除対象にはなりません。
Aurora Auto Scaling では、自身が作成した Aurora レプリカのみ削除されます。
感想
AWS CLIからしか設定できないところが初見だとややとっつきにくいですが、使いこなせれば便利だなと感じました！
同じような課題を持っている方の一助になれば幸いです。
