Amazon Aurora バージョンアッ プについて、改めて理解する 2025.02.01 BuriKaigi 2025 KDDIアジャイル開発センター 名古屋オフィス 鈴木 正樹 ～ バージョンアップ手法と文字コードへの影響 ～

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/

2 KDDI Agile Development Center Corporation 本日のアジェンダ • はじめに：Aurora バージョンアップについて • Aurora バージョンアップ手法の紹介 • Aurora バージョンアップで発生する問題 • 具体的な問題事例（Aurora MySQL 5.7→8.0） • まとめ

3 KDDI Agile Development Center Corporation 注意事項 お話しすること • Amazon Auroraのバージョンアップ手法 • Amazon Auroraバージョンアップによって起こる問題＆Aurora MySQLでの具体的なトラブル事例 お話ししないこと • 具体的なバージョンアップ手順 • Aurora PostgreSQL/Aurora Serverlessでの具体的なトラブル事例 その他 • 発表資料・発言内容は、すべて個人の見解・知見になります • Amazon Auroraの正式な情報は、AWS公式サイトをご確認ください

4 KDDI Agile Development Center Corporation はじめに：Aurora バージョンアップについて

5 KDDI Agile Development Center Corporation Aurora MySQL v5.7 ユーザーの皆さん、 Ver8.xバージョンアップ、もう終わりましたよね？

6 KDDI Agile Development Center Corporation Aurora PostgreSQL v12ユーザーの皆さん、 バージョンアップ、もう終わりましたか？

7 KDDI Agile Development Center Corporation Auroraバージョンアップは、割と直近で必要となっている Aurora MySQL ver5.7が、2024/10/31で標準サポート終了 ◦ 苦労した人も多いと思います（私もその一人） Aurora PostgreSQLも、ver12が今月末でサポート終了 ◦ まだ対応していない場合、早めの対策が必要 ◦ Aurora PostgreSQLは、毎年2月に何かしら標準サポートが終了する（来年はver13） Auroraバージョンアップは、決して他人事ではない

8 KDDI Agile Development Center Corporation Q: バージョンアップしないとどうなるの？ A: 延長サポート費用が発生します 標準サポート終了バージョンを使い続ける場合「延長サポート費用」が別途発生する ◦ 1時間単位で費用が発生＆払わないとAuroraを使用できない ◦ 東京リージョンでdb.r6g.xlargeを1ヶ月使用した場合、700.80ドル（≒108,768円）（※1, ※2） 延長サポートも、ずっと続くわけではない ◦ MySQLは2年3か月、PostgreSQLは3年で終了 ◦ あくまでも「バージョンアップまでの一時的な暫定処理」という立ち位置 AWS的にも「標準サポート終了前のバージョンアップ」を強く推奨 ※1：ライター/リーダーが1インスタンスずつ存在する場合の料金 ※2：今話題のDeepSeek R1で推奨の48xlargeインスタンスの場合、28,032ドル（≒4,350,707円）だそうです。

9 KDDI Agile Development Center Corporation Aurora バージョンアップ手法の紹介

10 KDDI Agile Development Center Corporation Aurora バージョンアップ手法 今回主に紹介するのは下記2つ ◦ Blue/Greenデプロイ ◦ クローンクラスター作成（※1） 【参考】インプレースアップグレード（稼働中のクラスターを直接更新する）について ◦ 通称「漢アップグレード」 ◦ 成功すれば、一番手っ取り早い＆コストも抑えられる ◦ 失敗時＆バージョンを元に戻す際のリカバリーリスクが大きいため、本番環境ではお勧めできない ※1：バージョンアップ専用の手法という訳ではないです。（通常のAurora運用でも使用される）

11 KDDI Agile Development Center Corporation Blue/Greenデプロイ 稼働環境（Blue）とステージング環境（Green）を作成し、切り替える方式 ◦ Auroraの他、Amazon ECSなどでも適用されている

12 KDDI Agile Development Center Corporation Blue/Greenデプロイのメリット データレプリケーション（≒同期）を自動で実施 ◦ Blue環境→Green環境へのデータレプリケーションは自動で実施される ◦ Green環境は読み取り専用になっているので、データのconflictが起こる心配もない • ただしAdminユーザーは書き込み＆読み取り専用設定を変更可能なので注意！ 稼働環境に影響を与えない ◦ バージョンアップはGreen環境に対して行うので、稼働環境には一切影響しない ◦ 切り替え時のダウンタイムも、通常1分未満で終わる（環境次第） 中～大規模な本番環境に向いている ◦ レプリケーションの自動実施、ダウンタイムの少なさ、稼働環境への影響の少なさなど ◦ 仮にバージョンアップが失敗しても、環境を再切り替えすれば元に戻る

13 KDDI Agile Development Center Corporation Blue/Greenデプロイのデメリット コストがかかる ◦ クラスター/インスタンス/ストレージをもう1つ作成することになるので、その分コストがかかる • 「バージョンアップ時の一時的なもの」と割り切る（※1） ◦ レプリケーション/ダウンタイム/稼働環境への影響と加味して決める ダウンタイムが2回発生するケースがある（Aurora MySQLの場合） ◦ パラメータグループの「binlog_format」（バイナリログの有無を設定するキー）を有効にする必要がある • デフォルトは無効 ◦ クラスターを再起動しないと反映されない（一時的にAuroraを停止する必要がある） ※1：Green環境を停止/削除すれば、最低限のコストで済む

14 KDDI Agile Development Center Corporation クローンクラスター作成 Auroraクラスターのクローンを作成する方式（バックアップ目的で使用） ◦ クローン(B)は元クラスター(A)のデータを参照するため、レプリケーションが不要（図1） ◦ クローン後に元クラスターで更新されたデータは参照できない（図2） ◦ クローンのストレージ料金は、クローンで更新されたデータ（4[B]）に対してのみ発生（図3） 図1 図2 図3

15 KDDI Agile Development Center Corporation クローンクラスター作成のメリット 運用次第で、データレプリケーションが不要に ◦ クローンは元クラスターのデータを参照するため「元クラスターで更新が発生しない」なら、レプリケーション が不要に ◦ （例）バージョンアップ時に、ある程度長い時間サービスを止められる場合 コストが安い ◦ クローンクラスターでデータ更新が発生しなければ、追加のストレージ料金は発生しない ◦ レプリケーション不要なら、クラスター/インスタンス料金もギリギリまで発生しない 小～中規模な環境/社内システム環境に向いている ◦ ある程度まとまったダウンタイムが必要なため、24H365D稼働するような大規模な環境では不向き ◦ バージョンアップ時にサービス停止を許容できる、小～中規模な環境や社内システムなどに向いていそう

16 KDDI Agile Development Center Corporation クローンクラスター作成のデメリット 「元クラスターで更新が発生しない」環境が必要 ◦ 完全なデータ同期は「元クラスターで更新が発生しない」事が前提になる • クローン後に元クラスターで更新されたデータは参照できないため • クローン後に元クラスターでデータ更新が発生した場合、手動でのレプリケーション処理が必要 ◦ 「元クラスターで更新が発生しない」条件を満たすのが難しい ある程度まとまった時間のダウンタイムが発生 ◦ クローンクラスター/インスタンス作成には、ある程度まとまった時間が必要 ◦ バージョンアップ・動作確認も含めると、それなりの時間ダウンタイムが発生する（※1） ※1：私が実施した際は、なんだかんだで数時間かかりました

17 KDDI Agile Development Center Corporation Aurora バージョンアップ手法のまとめ 手法 メリット デメリット ユースケース Blue/Green ・自動レプリケーション ・短いダウンタイム ・稼働環境への影響がほぼない ・コストがかかる ・ダウンタイムが2回発生する （場合がある） ・中～大規模環境 ・本番環境 クローン ・レプリケーション不要 （な場合がある） ・低コスト ・ダウンタイムがそれなりにある ・「元クラスターで更新が発生しない」 環境が必要 ・小～中規模環境 ・社内システム インプレース ・一番手っ取り早い ・追加コストがほぼ不要 ・環境の修復リスクが大きい ・本番環境には不向き ・開発/テスト環境 ・小規模環境

18 KDDI Agile Development Center Corporation Aurora バージョンアップで発生する問題

19 KDDI Agile Development Center Corporation Aurora バージョンアップで発生する問題 ※一般的な事例 バージョンアップが失敗する ◦ 「手順通りにやっても失敗する」「原因がよくわからない」etc. • 割とよくある現象（環境依存、中の仕様がこっそり変わった…etc.） ◦ 対策：リハーサルを実施し、事前に発見・対策しておく アプリが正常に動かない・文字化けなど ◦ 「エラーになる」「動作が遅い/バージョンアップ前と異なる」「文字化けする」etc. ◦ 内部仕様・アーキテクチャの変更、モジュール側が未対応、など（※1） ◦ 事前に公式サイトなどで調べておく、開発環境でテストし、確認・対策しておく ※1：特に文字コードはRFCや世間の流れなどの影響を受けやすい（詳細は次の「具体例」で挙げます）

20 KDDI Agile Development Center Corporation 具体的な問題事例（Aurora MySQL 5.7→8.0）

21 KDDI Agile Development Center Corporation 事例1: select count(*) クエリが遅い MySQL ver8.0.x（Aurora MySQL 3.07.x）で「select count(*)」クエリが遅い現象が発生 ◦ MySQL 8.0.39（Aurora MySQL 3.08.0）で修正済。 対応 ◦ 全ソースコードからselect count(*) クエリの使用箇所を抽出 ◦ 実際の速度を測定し、影響度・緊急度度を調査 ◦ 影響度・緊急度が高いものについては、代替コード（※1）への書き換えを実施し、テスト＆リリース ※1：具体的なカラムを指定する（count(id)など）、別コードへの書き換え、SWRの使用…etc.

22 KDDI Agile Development Center Corporation 事例2: デフォルト文字コードの変更 デフォルト文字コードが「utf8」から「utf8mb4」に変更 ◦ utf8mb4は、utf8に4バイト文字を対応させたもの（絵文字など） • 世間的な絵文字の普及もあり、変更されたものと思われる ◦ utf8は非推奨となり、いずれuft8mb4に置き換わる予定（MySQL公式より）（※1） 対策 ◦ パラメータグループで、文字コード設定をutf8mb4に設定 ◦ パラメータグループで設定できない項目は、クエリで直接変更 ◦ 開発環境において、上記の設定で動作確認を実施 ※1：MySQL 8.xでは「utf8」ではなく「utf8mb3」になります。（「utf8」は「utf8mb3」のエイリアス）

23 KDDI Agile Development Center Corporation 事例3: デフォルト照合順序の変更 デフォルト照合順序が「utf8_general_ci」から「utf8mb4_0900_ai_ci」に変更 ◦ 「照合順序」は、ざっくりいうと「ORDER BY」でのソート結果に影響する ◦ バージョンアップ前後で一覧表示画面などの挙動が変わってしまう（データ表示順序が異なる） 対策 ◦ パラメータグループで、文字照合順序設定を「utf8mb4_genaral_ci」に設定 ◦ 「default_collation_for_utf8mb4」は、必要に応じてmysqldumpなどの処理を実施（※1, ※2） ◦ 開発環境において、上記の設定で動作確認を実施 ※1：参考： MySQLの照合順序の設定をそろそろちゃんと整理しておく ※2：幸い、私が実施した環境ではテーブルレベルで照合順序が設定されていたため、特に対処は不要でした。

24 KDDI Agile Development Center Corporation まとめ

25 KDDI Agile Development Center Corporation まとめ Auroraバージョンアップは、標準サポート終了前に実施する ◦ 標準サポート期間が終了すると、結構割高な延長サポート費用が発生してしまう ◦ 手間だけど、Auroraバージョンアップは極力標準サポート終了前に実施する アプリの規模・環境に応じて、適切な手法を選ぶ ◦ Blue/Green・クラスタークローン・インプレースなど、様々な手法が存在 ◦ アプリの規模・運用環境・ダウンタイムの許容時間など、さまざま要素を加味して適切な手法を選択する バージョンアップは計画的に実施する ◦ バージョンアップ作業に問題はつきものなので、「リハーサルを実施する」など計画性を持って実施する ◦ 特に文字コード絡みは解決が大変なので、早めに情報収集し対策する

札幌オフィス SAPPORO OFFICE 秋田オフィス AKITA OFFICE 高崎オフィス TAKASAKI OFFICE 金沢オフィス KANAZAWA OFFICE 舞鶴オフィス MAIZURU OFFICE 広島オフィス HIROSHIMA OFFICE 福岡オフィス FUKUOKA OFFICE 那覇オフィス NAHA OFFICE 仙台オフィス SENDAI OFFICE 東京本社 TOKYO MAIN OFFICE 三島オフィス MISHIMA OFFICE 名古屋オフィス NAGOYA OFFICE 大阪オフィス OSAKA OFFICE

採用募集中！ エンジニア・デザイナー

Be a Change Leader. アジャイルに力を与え 共に成長し続ける社会を創る