Aurora Serverlessの自動スケールが失敗するときは ForceApplyCapacityChange を有効にしよう!

quiver

2020.03.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Amazon Aurora Serverless はワークロードに応じてキャパシティが自動的にスケールします。

いざ評価してみると、スケールアップが繰り返し失敗し、いつまでもキャパシティが増えないことがあります。

そのようなときは ForceApplyCapacityChange オプションを有効にしましょう。

説明

Aurora Serverless の FAQ でスケールしない理由が説明されています。

Q: Aurora Serverless DB クラスターが自動的にスケールしないのはなぜですか?

Aurora Serverless では、スケーリングオペレーションが開始されると、データベースのスケーリングを安全に行える時点となるスケーリングポイントを見つけようとします。Aurora Serverless では、進行中の長期のクエリやトランザクションがある場合や、一時的なテーブルやテーブルロックを使用している場合、スケーリングポイントを特定できないことがあります。

スケーリングポイントを検出できないままタイムアウトすると、デフォルトではスケーリングオペレーションはキャンセルされます。

キャパシティーの強制変更オプションを有効にすることで、必要に応じてスケーリングポイントの検出を妨げる接続を切断し、キャパシティーが変更されるようになります。

やってみた

この動作を実際に確認してみます。

評価方法

Aurora Serverless クラスターを作成し、キャパシティを1〜4の範囲で変化するようにします。

適当にテーブルを作成し、ダミーデータを投入します。

キャパシティが低い状態で、処理に時間のかかるクエリーを投げ、ForceApplyCapacityChange オプションの有効・無効による挙動の違いを確認します。

強制オプション無効状態

強制オプションがデフォルトの無効状態のまま、キャパシティが2の状態で数十分かかる重いクエリーを投げます。

$ mysql -h db.XXX.rds.amazonaws.com -u admin -p test \
  -e "select count(1) from data a join data b join data c join data d join data e"
Enter password:s
...

Log & Events タブを確認すると、スケーリングオペレーション開始イベントを確認できます。

Time	System Notes
Sat, 21 Mar 2020 13:53:50 GMT	Scaling DB cluster from 2 capacity units to 4 capacity units for this reason: Autoscaling.

クエリーが完了しないため、5分程度でタイムアウトが発生し、スケーリングオペレーションがキャンセルされます。

Time	System Notes
Sat, 21 Mar 2020 13:58:53 GMT	The DB cluster failed to scale from 2 capacity units to 4 capacity units for this reason: A scaling point wasn’t found.
Sat, 21 Mar 2020 13:53:50 GMT	Scaling DB cluster from 2 capacity units to 4 capacity units for this reason: Autoscaling.

約1.5分後、重いクエリーは継続中で、スケールアップが必要なため、再びスケーリングオペレーションが開始されます。

Time	System Notes
Sat, 21 Mar 2020 14:00:30 GMT	Scaling DB cluster from 2 capacity units to 4 capacity units for this reason: Autoscaling.
Sat, 21 Mar 2020 13:58:53 GMT	The DB cluster failed to scale from 2 capacity units to 4 capacity units for this reason: A scaling point wasn’t found.
Sat, 21 Mar 2020 13:53:50 GMT	Scaling DB cluster from 2 capacity units to 4 capacity units for this reason: Autoscaling.

クエリーが完了しない限り、以降はスケーリング→タイムアウト→キャンセルが繰り返されます。

Time	System Notes
Sat, 21 Mar 2020 14:12:34 GMT	The DB cluster failed to scale from 2 capacity units to 4 capacity units for this reason: A scaling point wasn’t found.
Sat, 21 Mar 2020 14:07:17 GMT	Scaling DB cluster from 2 capacity units to 4 capacity units for this reason: Autoscaling.
Sat, 21 Mar 2020 14:05:34 GMT	The DB cluster failed to scale from 2 capacity units to 4 capacity units for this reason: A scaling point wasn’t found.
Sat, 21 Mar 2020 14:00:30 GMT	Scaling DB cluster from 2 capacity units to 4 capacity units for this reason: Autoscaling.
Sat, 21 Mar 2020 13:58:53 GMT	The DB cluster failed to scale from 2 capacity units to 4 capacity units for this reason: A scaling point wasn’t found.
Sat, 21 Mar 2020 13:53:50 GMT	Scaling DB cluster from 2 capacity units to 4 capacity units for this reason: Autoscaling.

強制オプション有効状態

この状態で、DB クラスターの強制オプションを有効にします。

スケーリングポイントの検出にタイムアウトすると、クエリーが切断されます。

$ mysql -h db.XXX.rds.amazonaws.com -u admin -p test \
  -e "select count(1) from data a join data b join data c join data d join data e"
Enter password:
...
ERROR 1080 (08S01) at line 1: /rdsdbbin/oscar/bin/mysqld: Forcing close of thread 9  user: 'admin'

RDS のイベントログを確認すると、スケーリングオペレーション開始から約5.5分後(=タイムアウト後)にキャパシティが変更(has scaled)されていました。

Time	System Notes
Sat, 21 Mar 2020 14:19:47 GMT	The DB cluster has scaled from 2 capacity units to 4 capacity units.
Sat, 21 Mar 2020 14:14:18 GMT	Scaling DB cluster from 2 capacity units to 4 capacity units for this reason: Autoscaling.
Sat, 21 Mar 2020 14:XX:XX GMT	`ForceApplyCapacityChange` オプション有効化
Sat, 21 Mar 2020 14:12:34 GMT	The DB cluster failed to scale from 2 capacity units to 4 capacity units for this reason: A scaling point wasn’t found.