はじめに
Amazon Aurora ServerlessでAutoScallingに失敗する症状が発生し、原因や対策を調査しました。
環境
- Amazon Aurora Serverless v1 MySQL 5.7.2.08.3
- Capacity settings
- Minimum Aurora capacity units: 1 capacity unit
- Maximum Aurora capacity units: 16 capacity unit
- Autoscaling timeout: 5 minutes
- If the timeout expires before a scaling point is found, do this: Roll back the capacity change
症状
RDSの Logs & eventsで以下のログが頻発しAutoScallingに失敗する
The DB cluster failed to scale from 1 capacity unit to 2 capacity units for this reason: A scaling point wasn’t found.
原因
Aurora Serverless では、進行中の長期のクエリやトランザクションがある場合や、一時的なテーブルやテーブルロックを使用している場合、スケーリングポイントを特定できないことがあるようです。
Q. Aurora Serverless DB クラスターが自動的にスケールしないのはなぜですか?
A. Aurora Serverless では、スケーリングオペレーションが開始されると、データベースのスケーリングを安全に行える時点となるスケーリングポイントを見つけようとします。Aurora Serverless では、進行中の長期のクエリやトランザクションがある場合や、一時的なテーブルやテーブルロックを使用している場合、スケーリングポイントを特定できないことがあります。
プロセス調査
進行中の長期のクエリやトランザクションがある場合や、一時的なテーブルやテーブルロックを使用している場合
プロセス一覧取得コマンドより確認できます。RDSのQuery Editor画面で実行しました。
SHOW FULL PROCESSLIST
ログ出力設定＆調査
Amazon Aurora ServerlessのMySQL互換では、スロークエリログ、一般ログ、監査ログをCloudWathchへ出力することができます。
ログ出力を設定しておき確認することで、あらかじめ適切なcapacityを指定したり、時間がかかっている処理を調査することができます。
スロークエリ・・・DBMSへの問い合わせ（クエリ）のうち、基準よりも遅いor時間がかかっているクエリのこと
| ログの種類 | CloudWathch ロググループ名 | 補足 |
|---|---|---|
| エラーログ | /aws/rds/cluster/{DBクラスタ名}/error | デフォルトで出力される |
| スロークエリログ | /aws/rds/cluster/{DBクラスタ名}/slowquery | 設定が必要 |
| 一般ログ | /aws/rds/cluster/{DBクラスタ名}/general | 設定が必要 |
| 監査ログ | /aws/rds/cluster/{DBクラスタ名}/audit | 設定が必要 |
エラー以外のログをClowdWatchへ出力する手順
クラスターパラメータグループでログの出力設定を行います。
設定したパラメータグループの環境
| 項目 | 値 |
|---|---|
| Parameter group family | aurora-mysql5.7 |
| Type | DB Cluster Parameter Group |
編集するパラメータグループの項目
- スロークエリログ
| 項目 | 値 | 備考 |
|---|---|---|
| slow_query_log | 1 | 有効/無効 |
- 一般ログ
| 項目 | 値 | 備考 |
|---|---|---|
| general_log | 1 | 有効/無効 |
- 監査ログ
| 項目 | 値 | 備考 |
|---|---|---|
| server_audit_logging | 1 | 有効/無効 |
| server_audit_logs_upload | 1 | ClowdWatchへの送信許可 有効/無効 |
| server_audit_events | CONNECT,QUERY,QUERY_DCL, QUERY_DDL,QUERY_DML,TABLE |
|
| server_audit_incl_users | (空白) | 空白にすることで全てのユーザーが対象になる |
| server_audit_excl_users | (空白) | 空白にすることで全てのユーザーが対象になる |
対策
① 手動でプロセスKill
手動で問題のプロセスをkillする方法が考えられます。
killするとスケーリングポイントができます。
- MySQLサーバーへの接続を終了
CALL mysql.rds_kill({process_id})
- MySQLサーバーへ実行中のクエリを終了
CALL mysql.rds_kill_query({process_id})
② Force the capacity changeオプションをオンにする
データベースの設定にある、Force the capacity changeオプションをオンにすることでタイムアウト前にスケーリングポイントが見つからない場合でも、Aurora Serverless v1 DB クラスターに容量を強制的に変更させられます。
このオプションを使用すると、スケーリングポイントの検出を阻害している接続が、Aurora Serverless v1 により削除されることがあります。
オートスケーリングのタイムアウトとアクション - このセクションでは、Aurora Serverless がタイムアウトする前にスケーリングポイントを見つけるまでの待機時間を指定します。また、スケーリングポイントが見つからないために容量の変更がタイムアウトしたときに実行するアクションも指定します。Aurora は、容量を可能な限り早く指定した値に設定するために、容量の変更を強制できます。または、容量の変更をロールバックして、キャンセルすることができます。
まとめ
今回は、AutoScallingに失敗する症状の原因とその対策について調査しました。
コストとの兼ね合いもありますが、あらかじめログを出力しておき、設定の最適化やエラー発生時の調査をしやすい状態にしておくことが大切だと思いました。