MySQLアンカンファレンス#008_大規模Aurora MySQLクラスタの 無停止アップグレードを支えた Aurora Blue_Green Deployment機能

Amebaブログでサービス無停止のAurora MySQLアップグレードをおこなった際の方法と、遭遇したトラブルについて簡単に紹介しています。

Transcript

1. 大規模Aurora MySQLクラスタの 無停止アップグレードを支えた Aurora Blue/Green Deployment機能 MySQLアンカンファレンス#008
2. 自己紹介 @FAT47/ きかい 所属チームのブログ( https://ca-srg.dev )にて毎月記事を書いています 2025 AWS Community Builders認定 (Category: Data )
3. 本日の内容は年末に公開したブログから一部抜粋したもの https://developers.cyberagent.co.jp/blog/archives/51492/
4. Amebaについて
5. Amebaについて Amebaはアメーバブログを中心にしたさまざまなサービスで構成 CADC 2022「事業と歩むAmebaシステム刷新の道」資料より引用
6. 今日はアメーバブログでの事例の話 アメーバブログは2004年に運営開始し、今年で21年目になります
7. アメーバブログはAmazon Aurora MySQLを使用 ❏ マイクロサービス毎にAurora MySQL v2(MySQL5.7互換)クラスタが存在 ❏ 開発環境、ステージング環境、本番環境などが存在 ❏ マイクロサービス数　×　環境数　= 百数十クラスタが稼働 ❏ 1年以内にすべてのクラスタのアップグレードを完了する必要があった
8. 一般的なMySQLアップグレードの切り替え方法 • MySQL 5.7をソースにして、MySQL 8.0をレプリカとする
9. 一般的なMySQLアップグレードの切り替え方法 • サービスをメンテナンスモードにして書き込みクエリを止める • アプリケーションのクエリ向き先をMySQL 8.0に切り替えてデプロイ • 切り戻し環境用にMySQL 5.7にレプリケーションをはる
10. 同じようなことはAurora MySQLクラスタ間レプリでも可能
11. アメーバブログでは極力サービスメンテナンスを回避したかった • 運用開始20年超えのサービスで、途中にシステム刷新でマイクロサービス化 • 特定サービスのみをメンテナンスモードに切り替える機能がない部分があった ◦ メンテナンス＝アメーバブログ周辺すべてをメンテナンスモードにする必要がある • メンテナンス時間中にすべてのクラスタのアップグレードを完了する必要 ◦ 大量のクラスタがあるので長時間かかることが予想される
12. アメーバブログではオンラインでアップグレードを選択 • アメーバブログは参照ヘビーなサービス ◦ 書き込む頻度より、読み込む頻度のほうが圧倒的に多い ◦ CDNのキャッシュにより、著名人などのアクセス数が多いブログほどキャッシュアクセスされる • アップグレード時のダウンタイムを抑えればサービスへの影響は小さい あるマイクロサービスのクエリ量の差。 赤色が書き込みクエリ
13. Aurora Blue/Green Deployment機能
14. Aurora Blue/Green Deployment機能とは • 2022年12月に発表された機能 • Greenクラスタ環境の作成、Blue/Green間のレプリケーションが簡単に • B/Gの切り替えもボタンひとつで実施 ◦ B/Gの切り替えはダウンタイム最大1分
15. • 稼働中のクラスタ(Blue)を元にGreenクラスタを作成 • Blue/Green間は論理レプリケーション • Greenクラスタ側だけをAurora MySQL version3(MySQL8.0互換)にアップグレード可
16. • Greenクラスタには動作確認用のGreen用のエンドポイントが作成される ◦ アプリケーションの参照クエリの向き先をGreenに変えれば動作確認に利用できる
17. • Blue/Green切り替えを実行するとB/G両者書き込みの停止とDBコネクションの切断が実施 • GreenのレプリケーションがBlueに追いつくのを待つ
18. • 同期確認後、旧Blueインスタンスやクラスタ名は末尾に「-old1」という名前にリネーム ◦ 旧Blueのエンドポイントも「-old1」が付加されたものにリネーム • Greenインスタンスやクラスタ名が旧Blueと同名にリネーム ◦ 旧Greenのエンドポイントは旧Blueと同名のエンドポイントにリネーム
19. • ここまでの処理でなにか問題が起きれば、自動でロールバックされ切り戻される • 問題がなければ、DBコネクションと書き込みが許可されてアプリケーションがクエリ実行開始
20. この切り替え処理を自動で1分以内に実行完了してくれる 神機能
21. Aurora Blue/Green Deploymentの当初の問題点 • Blue/Greenの切り替えが完了すると切り戻せない
22. • B/G切り替え中のトラブルはロールバックされる機能があるが... • 完了すると旧Blueクラスタは独立した環境となり、新Blueクラスタとはデータ同期されない • B/G切り替えた瞬間のbinlogのポジションさえ分かればなんとかなるのに...
23. 2024年8月 AWS公式ブログにB/G切り戻しの記事が投稿 Implement a rollback strategy after an Amazon Aurora MySQL blue/green deployment switchover Blue/Green Deployment機能の機能追加で、B/G切替時の旧Greenクラスタの binlogファイルとpositionをイベント欄に表示してくれるようになった （この時Aurora MySQLアップグレードの期限日付まで残り3ヶ月...)
24. • これで最悪の事態になっても旧Blueに切り戻すことは可能になった
25. 無事この機能をつかってアメーバブログすべての Aurora MySQLアップグレードが完了
26. ですが、実際には色々トラブルがありました
27. トラブル事例の一部紹介
28. B/G間のレプリケーションステータスちゃんと確認しよう事件 • Green環境つくっていろいろ動作検証中。 ◦ Blue/Greenのステータスは「利用可能」
29. B/G間のレプリケーションステータスちゃんと確認しよう事件 • Green環境のレプリケーションラグも0秒だ。ヨシ！
30. B/G間のレプリケーションステータスちゃんと確認しよう事件 「Green環境にアプリケーションの参照クエリ向けたら、 レコードが見つからないエラー出てるんですけど」 開発チーム
31. B/G間のレプリケーションステータスちゃんと確認しよう事件 Greenクラスタのレプリケーション止まってる...
32. B/G間のレプリケーションステータスちゃんと確認しよう事件 GreenライターインスタンスのログとイベントタブにErrorがしっかり記録されてた
33. B/G間のレプリケーションステータスちゃんと確認しよう事件 • B/Gのステータス「利用完了」はあくまでも作成完了という意味だけ ◦ レプリケーションのステータスとかは見ていない • モニタリングの「AuroraBinlogReplicaLag」の0はレプリ停止状態でも0 ◦ Seconds_Behind_MasterはNULLだけど、0です • 切り替え前にGreenのライターインスタンスのイベント欄は確認しておく ◦ 当時何のエラーで止まっていたか思い出せないですが、多分文字コードとか照合順序の設定い じったりしていたので、そこで止まっていた...?
34. SELECT COUNT スローダウン問題 • MySQL 8.0で有名なあの問題 ◦ Aurora MySQL v3のLTSはVersion3.04(MySQL8.0.28互換） ◦ MySQL8.0.37以降でこのSELECT COUNT問題は一部解決している ▪ Changes in MySQL 8.0.37 (2024-04-30, General Availability)
35. バグ詳細 • Bug #100597 INDEX hint does not affect count(*) execution ◦ ヒント句をつけてもセカンダリインデックスが使用されずにクラスタ化インデックスが利用されてしまう ◦ EXPLAINの結果ではセカンダリインデックスが使われるように見えるが実際は使われておらず、 WHERE句を追加したときのみ使用されたという報告 • Bug #112767 SELECT COUNT(*) degraded performance on 8.0 compared to 5.7 ◦ 並列読み取りスレッドのページを事前に読み込む機能が、クラスタ化インデックスにおいて必要以上に ページを読み込んでしまい、過剰な読み取りI/Oを引き起こしてSELECT COUNTのパフォーマンスが 悪化しているという報告
36. 低速化を回避できそうな条件 1. クエリにヒント句をつけてセカンダリインデックスを指定する 2. WHERE句もつける この両方をつければMySQL8.0.28でも早くなるのでは
37. 低速化回避の検証 検証用テーブル( 100万レコード ) MySQL 5.7.41での結果 ( 0.37sec )
38. 低速化回避の検証 MySQL 8.0.28での結果 ( 7.65 sec ) EXPLAIN結果　( keyはidx )
39. 調査クエリで集計すると「idx」は利用されておらず「PRIMARY」だけがバッファプールに
40. 低速化回避の検証 MySQL 8.0.28でWHERE句だけ追加 ( 4.34 sec ) EXPLAIN結果　( keyはPRIMARY )
41. 低速化回避の検証 MySQL 8.0.28でFORCE INDEX追加とWHERE句 ( 0.44 sec ) EXPLAIN結果　( keyはidx )
42. 調査クエリで集計するとバッファプールにidxが乗ってきた MySQL 5.7.41 0.37 sec ↓ MySQL 8.0.28 7.65 sec ↓ MySQL 8.0.28 (クエリ変更後) 0.44 sec
43. MySQL 5.7相当まで早くなった
44. 詳しい検証結果はブログ記事をご参照ください • https://ca-srg.dev/8185854ff1dc44a28ffe1f8cfb15dd14
45. 現在Aurora MySQLの最新は3.08(MySQL 8.0.39互換) • ただし、3.08は標準サポート期限が2025/11/30 • LTS 3.04(MySQL 8.0.28互換)のサポート期限は2026/10/31 LTSじゃないものを選択するのはちょっときびしい...　早く次のLTSでたら嬉しいな！ Aurora MySQL v3のマイナーバージョンのアップグレードはインプレースでカジュアルにできるらしいが...
46. まとめ
47. まとめ ❏ アメーバブログはAurora B/G Deploymentをつかいノーメンテでアップグレード ❏ Aurora B/G Deploymentは素晴らしい機能だが注意点もある ❏ MySQL 5.7から8.0へのパフォーマンス問題は大変だった ❏ 早く次のLTS対応のAurora MySQLが出てくれたらうれしい
48. ありがとうございました