Amazon Aurora のバージョンアップ手法について

2025/02/27（木）に開催された「KAGのLT会 #3」における私のLT「Amazon Aurora のバージョンアップ手法について」の発表資料になります。 #KAGのLT会

https://kddi-agile.connpass.com/event/345657/

Transcript

1. Amazon Aurora のバージョン アップ手法について 2025.02.27 KAGのLT会 #3 KDDIアジャイル開発センター 名古屋オフィス 鈴木 正樹
2. 1 KDDI Agile Development Center Corporation 自己紹介 ◼ 氏名：鈴木 正樹 ◼ 所属：KDDIアジャイル開発センター（KAG） 名古屋オフィス ◼ 役割：クラウドアーキテクト ＆ バックエンドエンジニア AWS（特にサーバーレスやInfrastructure as Code）が大好きで、主にそれらに関する 情報発信を積極的に行っています。 好きなサービスはAWS LambdaとAWS CDK。主にJAWS-UG 名古屋支部やCDK支部で活動。 ◼ Certification： ◼ AWS Solution Architect Associate（2023） ◼ AWS Community Builder（2023～） ◼ : @makky12（SUZUKI Masaki@クラウドエンジニア） ◼ Blog：https://makky12.hatenablog.com/
3. 2 KDDI Agile Development Center Corporation 本日のアジェンダ • 直近の Aurora バージョンアップの必要性 • Aurora バージョンアップ手法の紹介 • まとめ
4. 3 KDDI Agile Development Center Corporation 注意事項 お話しすること • Amazon Auroraのバージョンアップ・延長サポート・バージョンアップ手法について お話ししないこと • 具体的なバージョンアップ手順、具体的なトラブル事例 その他 • 発表資料・発言内容は、すべて個人の見解・知見になります（正式な情報は、AWS公式サイトをご確認ください） • 本発表は、BuriKaigi 2025 における私のセッション「Amazon Aurora バージョンアップについて、改めて理解す る」の抜粋版になります。（内容の詳細は、BuriKaigi 2025 の公開資料 をご確認ください）
5. 4 KDDI Agile Development Center Corporation 直近の Aurora バージョンアップの必要性
6. 5 KDDI Agile Development Center Corporation 直近の Aurora バージョンアップの必要性（MySQL/PostgreSQL） Aurora MySQL：ver5.7 が 昨年10月末で標準サポート終了 ◦ とっくに標準サポート終わってます（現在、延長サポート期間） Aurora PostgreSQL：ver12 が今月末で標準サポート終了 ◦ まだ対応していない場合、早急な対策が必要（明日が期限） ◦ Aurora PostgreSQLは、毎年2月末に何かしら標準サポートが終了する（来年はver13） 上記に対応していない場合、早急なバージョンアップが必要！
7. 6 KDDI Agile Development Center Corporation Q: 期間内にバージョンアップしないとどうなるの？ A: 延長サポート費用が発生します 標準サポート終了バージョンを使い続ける場合「延長サポート費用」が別途発生する ◦ 1時間単位で費用が発生＆払わないとAuroraを使用できない ◦ 東京リージョンでdb.r6g.xlargeを1ヶ月使用した場合、700.80ドル（≒104,633円）（※1, ※2） 延長サポートも、ずっと続くわけではない ◦ MySQLは2年3か月、PostgreSQLは3年で終了 ◦ あくまでも「バージョンアップまでの一時的な暫定処理」という立ち位置 AWS的にも「標準サポート終了前のバージョンアップ」を強く推奨 ※1：ライター/リーダーが1インスタンスずつ存在する場合の料金 ※2：話題？のDeepSeek R1で推奨の48xlargeインスタンスの場合、28,032ドル（≒4,185,331円）だそうです。
8. 7 KDDI Agile Development Center Corporation Aurora バージョンアップ手法の紹介
9. 8 KDDI Agile Development Center Corporation Aurora バージョンアップ手法 今回主に紹介するのは下記2つ ◦ Blue/Greenデプロイ ◦ クローンクラスター作成（※1） 【参考】インプレースアップグレード（稼働中のクラスターを直接更新する）について ◦ 成功すれば、一番手っ取り早い＆コストも抑えられる ◦ 失敗時＆バージョンを元に戻す際のリカバリーリスクが大きいため、本番環境ではお勧めできない ※1：バージョンアップ専用の手法という訳ではないです。（通常のAurora運用でも使用される）
10. 9 KDDI Agile Development Center Corporation Blue/Greenデプロイ 稼働環境（Blue）とステージング環境（Green）を作成し、切り替える方式 ◦ Auroraの他、Amazon ECSなどでも採用されている
11. 10 KDDI Agile Development Center Corporation Blue/Greenデプロイのメリット データレプリケーション（≒同期）の手動実行が不要 ◦ Blue環境→Green環境へのデータレプリケーションは自動で実施される ◦ Green環境は読み取り専用になっているので、データのconflictが起こる心配もない • ただしAdminユーザーは書き込み＆読み取り専用設定を変更可能なので注意！ 稼働環境に影響を与えない ◦ バージョンアップはGreen環境に対して行うので、稼働環境には一切影響しない ◦ 切り替え時のダウンタイムも、通常1分未満で終わる（環境次第）
12. 11 KDDI Agile Development Center Corporation Blue/Greenデプロイのデメリット コストがかかる ◦ クラスター/インスタンス/ストレージをもう1つ作成することになるので、その分コストがかかる • 「バージョンアップ時の一時的なもの」と割り切る（※1） ◦ レプリケーション/ダウンタイム/稼働環境への影響と加味して決める ダウンタイムが2回発生するケースがある（Aurora MySQLの場合） ◦ パラメータグループの「binlog_format」（バイナリログの有無を設定するキー）を有効にする必要がある • デフォルトは無効 ◦ クラスターを再起動しないと反映されない（一時的にAuroraを停止する必要がある） ※1：Green環境を停止/削除すれば、最低限のコストで済む
13. 12 KDDI Agile Development Center Corporation クローンクラスター作成 Auroraクラスターのクローンを作成する方式（バックアップ目的で使用） ◦ クローン(B)は元クラスター(A)のデータを参照するため、レプリケーションが不要（図1） ◦ クローン後に元クラスターで更新されたデータは参照できない（図2） ◦ クローンのストレージ料金は、クローンで更新されたデータ（4[B]）に対してのみ発生（図3） 図1 図2 図3
14. 13 KDDI Agile Development Center Corporation クローンクラスター作成のメリット 運用次第で、データレプリケーションが不要に ◦ クローンは元クラスターのデータを参照するため「元クラスターで更新が発生しない」なら、レプリケーション が不要に ◦ （例）バージョンアップ時に、ある程度長い時間サービスを止められる場合 Blue/Greenデプロイと比べて、コストが安い ◦ クローンクラスターでデータ更新が発生しなければ、追加のストレージ料金は発生しない ◦ レプリケーション不要なら、クラスター/インスタンス料金もギリギリまで発生しない
15. 14 KDDI Agile Development Center Corporation クローンクラスター作成のデメリット 「元クラスターで更新が発生しない」環境が必要 ◦ 完全なデータ同期は「元クラスターで更新が発生しない」事が前提になる • クローン後に元クラスターでデータ更新が発生した場合、手動でのレプリケーション処理が必要 ◦ 「元クラスターで更新が発生しない」条件を満たすのが難しい ある程度まとまった時間のダウンタイムが発生 ◦ クローンクラスター/インスタンス作成には、ある程度まとまった時間が必要 ◦ バージョンアップ・動作確認も含めると、それなりの時間ダウンタイムが発生する（※1） ※1：私が実施した際は、なんだかんだで数時間かかりました
16. 15 KDDI Agile Development Center Corporation Aurora バージョンアップ手法のまとめ 手法 メリット デメリット ユースケース Blue/Green ・自動レプリケーション ・短いダウンタイム ・稼働環境への影響がほぼない ・コストがかかる ・ダウンタイムが2回発生する （場合がある） ・中～大規模環境 ・本番環境 クローン ・レプリケーション不要 （な場合がある） ・低コスト ・ダウンタイムがそれなりにある ・「元クラスターで更新が発生しない」 環境が必要 ・小～中規模環境 ・社内システム インプレース ・一番手っ取り早い ・追加コストがほぼ不要 ・環境の修復リスクが大きい ・本番環境には不向き ・開発/テスト環境 ・小規模環境
17. 16 KDDI Agile Development Center Corporation まとめ
18. 17 KDDI Agile Development Center Corporation まとめ Auroraバージョンアップは、標準サポート終了前に実施する ◦ 標準サポート期間が終了すると、結構割高な延長サポート費用が発生してしまう ◦ 手間だけど、Auroraバージョンアップは極力標準サポート終了前に実施する アプリの規模・環境に応じて、適切な手法を選ぶ ◦ Blue/Green・クラスタークローン・インプレースなど、様々な手法が存在 ◦ アプリの規模・運用環境・ダウンタイムの許容時間など、さまざま要素を加味して適切な手法を選択する
19. Be a Change Leader. アジャイルに力を与え 共に成長し続ける社会を創る