概要
SREチームが管理する一部のAWSアカウントで、10月25日以降、Aurora MySQLクラスターのCPU使用率が平均して8%ほど上昇する事象が確認されました。
事象が確認されたクラスターのインスタンスタイプは t4g.medium のため、CPUベースラインは20% 1 となります。
監視上はCPU使用率が平均20%を超えた場合にアラートを出す設定としており、一次調査を行うことにしました。
発生日時
2023/10/25 23時以降継続的に発生。
調査
- CPU使用率の上昇は10月25日23時頃から発生。平常時のCPU使用率が平均15%未満に対し、複数のRDSクラスターで突発的にCPU使用率が23%台に上昇。その後 (2023年12月現在) も使用率が下がらない状況となっている。
- 23時台にフェイルオーバーと推測される挙動をメトリクスから確認。
- ワークロードに関連するAPMやメトリクスを確認する限り、急激なスパイクアクセスや高負荷の形跡は見当たらなかった。
- 該当時間帯にリリースは行われていない。
- MySQLで
SHOW PROCESSLISTを確認しても、負荷の高いクエリは実行されていない。 - 同様にスロークエリのログも記録されていなかった。
- 該当時間帯はメンテナンスウィンドウの時間帯に一致していた。このことから、メンテナンスウィンドウ内で行われた何らかのアップデートによりCPU使用率が上昇した可能性が考えられる。
- 10月25日以降、T系インスタンスで構成される全てのクラスターでCPUクレジットの消費が発生していることを確認。
- CPUクレジット枯渇後、
aws.rds.cpusurplus_credit_balance(CPUSurplusCreditBalance 2) の上昇を検知。
- インスタンスの再起動を試みたところ、再起動直後は15%台 (平常時と同じ) をキープするものの、約24時間経過することで23%台まで上昇することを確認。
- ワークロードの問題か基盤の問題かを切り分けるため、クラスターの接続許可ポートを一時的に使用していない番号に変更。
- 検証した結果、再起動と同様、一時的にCPU使用率は下がるものの、約24時間経過で23%台まで上昇することを確認できた。
- 事象が発生しているクラスターを元に、最新のスナップショットから新しいクラスターを構築したところ、1週間経過を見てもCPU使用率は11%台をキープし、CPU使用率の上昇は発生しないことを確認できた。
- 以上の状況から、CPU使用率上昇の原因はワークロードではなく、メンテナンスウィンドウ以降、対象クラスターの基盤に何らかの問題が発生している可能性が考えられる。
原因
上記内容を踏まえてAWSサポートに問い合わせたところ、Aurora MySQLバージョン3.04以降で監査ログの処理に失敗し、CPU使用率が上昇する不具合が確認された。
アクションアイテム
| アクションアイテム | 種類 | 優先度 | 担当 | 対応状況 |
|---|---|---|---|---|
| インスタンス不具合の修正依頼 | 修復 | High | AWS | AWSサポートの回答によると、インスタンスで発生している不具合に対して (AWS側で) 修正措置が可能とのこと。ただし基盤自体の仮想サーバーホストが入れ替わった場合は効果が失効するため、恒久対応としては修正バージョンのリリースを待つ必要がある。3 |
という訳で、Aurora MySQLで監査ログを有効化している場合、バージョン3.04以降でCPU使用率が上がる可能性があるようです。
問題が発生したタイミングや影響範囲、今後の対策については引き続きAWSと対応を進め、共有できることがあればこちらに追記していきます。
続報
2024/04/13 追記
2024年3月7日にリリースされた 3.06.0 でこの不具合は解消されたようです。
-
Aurora MySQL データベースエンジンアップデート 2024-03-07 (バージョン 3.06.0、MySQL 8.0.34 に対応)
監査ログファイル管理に関連する問題を修正しました。これにより、ログファイルにアクセスしてダウンロードやローテーションができなくなり、場合によっては CPU 使用率が高くなる可能性があります。
尚、CPU使用率は平均して1〜2%上がるようです。