こんにちは。ソフトウェアエンジニアの古屋です。データベースのメトリクス、見てますか？私のチームが開発運用を担当する『カミナシ レポート』では Amazon Aurora MySQL をメインのRDBMSとして利用しています。この Aurora MySQL について少し課題がありました。
課題1. 増え続けるコスト
昨年の12月以降くらいでコスト、とくに Aurora:StorageIOUsage が右肩上がりで増えています（図の青色）。
課題2. 悪化するパフォーマンス
（実際に運用されているのを初めて見たのですが）『カミナシ レポート』で利用している Aurora クラスターはCPU利用率（しきい値：60%）に基づいたオートスケールの設定がされており、アクセスのピーク帯になると負荷に応じて自動的にスケールアウトするようになっています。ただ、スケールアウトしてもパフォーマンスがよくなっていない、むしろ悪くなっているのでは？という状況でした。下の図は、とある日のピーク帯かつ Aurora がスケールアウトしている時間帯のとあるエンドポイントの Latency（上からp95, 90, 75, 50） です。特にp95, 90あたりで顕著にパフォーマンスが悪くなっていることがわかります。スケールアウトしているのに…
原因
「スケールアウトして作成されるReaderインスタンスが、他のReaderよりサイズが小さいこと」が原因でした。以下がスケール前の構成です。
- Writerインスタンス: db.r6g.2xlarge が1台
- Readerインスタンス: db.r6g.4xlarge が数台
なぜWriterとReaderのサイズが異なるのかというと、Aurora MySQL v3 にバージョンアップしたあとクエリキャッシュが使えなくなったことにより、Readerインスタンスのみスペックをあげないとアクセスに耐えきれなくなったからです（本来はクエリチューニング等で最適化しつつサイズを揃えるべきですが、まだ改善できていないのが現状です）。
Aurora のスケールアウトはWriterを基準にインスタンスを追加するため、2xlarge （他のReaderの半分のスペック）のReaderが増える、つまり
- Writerインスタンス: db.r6g.2xlarge が1台
- スケールアウトで作られたReaderインスタンス: db.r6g.2xlarge が数台
- Readerインスタンス: db.r6g.4xlarge が数台
という形になっていました。実際の動きを見ているとそのスケールアウトで作られたインスタンスのみが CPU 100% になっており、 Performance Insights で見ても AAS（Average Active Sessions）、特に wait/io/table/sql/handler が基準値を大幅に超えていました。おそらくバッファプールが溢れ、ディスクIOが大量に発生した、ということかと思います。IOの大量発生はコストの増加とも一致しています。
そして爆発
スケールアウトしたインスタンスの負荷増加に伴い、ついにインスタンスの強制再起動が発動するまでになってしまいました。
レプリカラグが大きくなりすぎると Zero-downtime restart が発動すると書いてあり、実際メトリクスを見てもそんな感じでした。
対処
このままではパフォーマンス・コスト面でよろしくないのと、再起動まで発生するようになってしまったので早急に対応しなければなりません。
まず思いつく方法としてWriterを 4xlarge にスケールアップすることでオートスケールするインスタンスも 4xlarge にする、というものがあります。ただ多少なりとダウンタイムが必要なのと、Writer自身のスペックは現状で十分であるためコストを考えて今回は見送りました。
このため一時的な対応としてまずオートスケールを止めました。負荷に応じたオートスケールのメリットはなくなりますが、スペック的に処理しきれないインスタンスサイズで問題が起こるよりは遥かにマシです。合わせて、ピーク時間と連動する形で 4xlarge のReaderインスタンスを追加・削除するように Amazon EventBridge Scheduler を設定しました。AWSのAPIを叩くだけであれば EventBridge Scheduler のみで完結できるのですごくいいですね！ダウンタイム等の懸念もなくスピーディに対応できいい感じで動いてはいますが、オートスケールの恩恵を再び受けるためにもインスタンスサイズを揃えるなどどこかのタイミングで恒久対応は必要そうだと感じています。
ちょっぴり注意点
EventBridge Scheduler で AWS のAPIを叩くときはパラメータ名に気をつける必要があります。
- APIドキュメント記載のパラメータ名
- DBInstanceClass
- DBInstanceIdentifier
- Schedulerで設定可能なパラメータ名
- DbInstanceClass
- DbClusterIdentifier
PascalCase（複合語の場合単語の先頭だけ大文字）にしないといけないんですね。ついついAPIドキュメントのパラメータで組んでしまって、起動しない！ってなっていました。
コンソールにはちゃんと書いてあったのですが、ここを読み飛ばしておりちょっぴり時間を溶かしました… EventBridge Scheduler でAWSのAPIパラメータを設定する際はお気をつけください。
結果
わかりやすく効果が出て、ピーク時の遅いリクエストが大幅に減りました。お客様が体感できるレベルで改善できており「かなり動きが良くなった」とコメントいただきました。
コストについても右肩上がりを阻止できました。ただ今回の対応で以前よりサイズの大きいインスタンスが立ち上がるようになったので、IO料金が減りつつもインスタンス料金がちょっと増えるという感じになっています。このあたりはもう少し様子見です。
まとめ
Aurora MySQL の負荷上昇をきっかけに調査と対処をしました。EC2やRDSにおいて、インスタンスの負荷が高まっていること自体には問題がないケースもあります。CPUやメモリを十分に使いきってこそ、という考え方もありますしユーザー体験に影響がなければCPUが張り付いていても問題はないといえます。
逆に今回のようにユーザー体験の悪化やコスト増大に結びついているようであれば、適切なキャパシティを確保することでそれらを解決できます。もし気になった方はすぐデータベースのメトリクスやアプリケーションのパフォーマンスを見てみましょう！
