RDS/Aurora バージョンアップのポイント
21.1K Views
January 17, 23
スライド概要
JAWS-UG 朝会 #41 2023/1/17
Qiita や Zenn でいろいろ書いてます。 https://qiita.com/hmatsu47 https://zenn.dev/hmatsu47 MySQL 8.0 の薄い本 : https://github.com/hmatsu47/mysql80_no_usui_hon Aurora MySQL v1 → v3 移行計画 : https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book https://speakerdeck.com/hmatsu47
関連スライド
各ページのテキスト
RDS/Aurora バージョンアップのポイント JAWS-UG 朝会 #41 2023/1/17 まつひさ（hmatsu47）
自己紹介 松久裕保（@hmatsu47） ● https://qiita.com/hmatsu47 名古屋で Web インフラのお守り係をしています JAWS-UG 名古屋・浜松を中心に活動しています ○ 「RDBMS（MySQL）の話をする人」として認知されているようです ○ 以前「MySQL 8.0 の薄い本」を作っていました（8.0.24 まで更新） ■ Qiita の記事： https://qiita.com/hmatsu47/items/ceb75caf46e3c761095d 2
近況 ● 朝会 #32 で話した Aurora MySQL v1 → v3 移行が完了 ○ 2022/10 : メインのプロダクトの移行が完了 ○ 2022/12 : テスト環境など内部 DB の移行がすべて完了 ○ 2023/1（先週末）: 別プロダクトの移行が完了 →移行はほぼ完了（お試し環境を 1 つ残すのみ） 3
本日のネタ ● バージョンアップで考慮する主要なポイントを 5 つ ○ データ完全性・機能の互換性・性能・停止時間・切り戻し ● 色々なバージョンアップ手法のメリットと注意点 ○ インプレースアップグレード・クローン後アップグレード ○ Blue/Green デプロイ・新旧 DB への同時並行書き込み ● バージョンアップ計画を進める際のポイント ○ 作業分担と協力体制・情報共有・事前準備とリハーサル 4
おことわり ● バージョンアップの具体的な手順は示しません ● バージョンアップに使えるマネージドサービスの具体例 や機能について不明点・疑問点がある場合は、契約中の AWS パートナーか AWS サポートに確認してください 5
考慮ポイント① データ完全性 ● 完全性を保ったデータ移行は意外と難しい ○ サービスを完全停止してバックアップを取り新環境に復元できる →完全性を保つのは比較的容易 ○ 実際には許容できるサービス停止時間は限られる ○ データ変換処理のバグや不都合な仕様に当たる可能性も ● 事後のデータ整合確認の併用も検討 ○ ダンプ比較・行数比較・DMS による検証など 6
考慮ポイント① データ完全性 ● 完全性を保ったデータ移行は意外と難しい ○ サービスを完全停止してバックアップを取り新環境に復元できる →完全性を保つのは比較的容易 ○ 実際には許容できるサービス停止時間は限られる ○ データ変換処理のバグや不都合な仕様に当たる可能性も Aurora や RDS のリリースノートを読むと、 ● 事後のデータ整合確認の併用も検討 アップグレードに関する不具合の解消報告が いくつか見つかるね！ ○ https://docs.aws.amazon.com/ja_jp/AmazonRDS/late ダンプ比較・行数比較・DMS による検証など st/AuroraMySQLReleaseNotes/AuroraMySQL.Updat es.3022.html 7
考慮ポイント① データ完全性 ● 完全性を保ったデータ移行は意外と難しい ○ 容量が小さいテーブルならテーブルダンプは サービスを完全停止してバックアップを取り新環境に復元できる 整合確認にも使えるね！ https://zenn.dev/hmatsu47/articles/mysql-dump-for-v erup-check →完全性を保つのは比較的容易 ○ でもデータの全件 COUNT(*) は意外と時間が 掛かったりするから注意してね！ 実際には許容できるサービス停止時間は限られる https://zenn.dev/hmatsu47/articles/mysql80-count-slo wdown ○ データ変換処理のバグや不都合な仕様に当たる可能性も ● 事後のデータ整合確認の併用も検討 ○ ダンプ比較・行数比較・DMS による検証など 8
考慮ポイント② 機能の互換性 ● バージョン間差異の影響がどれだけあるか？ ○ SQL 文の非互換・RDBMS としての機能の非互換 ○ アプリケーションや管理監視システムの改修・修正が必要に ● アプリケーション改修・リリースタイミング ○ 可能ならバージョンアップ前に、バージョンアップ前後の両方で 動く形に改修してリリース ■ バージョンアップと同時に新機能を使うアプリケーションをリリースしない 9
考慮ポイント② 機能の互換性 ● バージョン間差異の影響がどれだけあるか？ ○ SQL 文の非互換・RDBMS としての機能の非互換 ○ アプリケーションや管理監視システムの改修・修正が必要に ● アプリケーション改修・リリースタイミング ○ 可能ならバージョンアップ前に、バージョンアップ前後の両方で MySQL をバージョンアップすると Datadog 動く形に改修してリリース でロックのメトリクスが一部取れなくなる、 ■なんてこともあるから注意してね！ バージョンアップと同時に新機能を使うアプリケーションをリリースしない 10
考慮ポイント② 機能の互換性 ● バージョン間差異の影響がどれだけあるか？ ○ SQL 文の非互換・RDBMS としての機能の非互換 ○ アプリケーションや管理監視システムの改修・修正が必要に ● アプリケーション改修・リリースタイミング ○ 可能ならバージョンアップ前に、バージョンアップ前後の両方で 動く形に改修してリリース ■ バージョンアップと同時に新機能を使うアプリケーションをリリースしない 11
考慮ポイント② 機能の互換性 DB のバージョンアップのついでに新機能を ● バージョン間差異の影響がどれだけあるか？ リリースしちゃおう！…ってやりがちだけど ○ 切り戻しが必要になったときに大変だから、 SQL 文の非互換・RDBMS としての機能の非互換 できればやめておこうね！ ○ アプリケーションや管理監視システムの改修・修正が必要に ● アプリケーション改修・リリースタイミング ○ 可能ならバージョンアップ前に、バージョンアップ前後の両方で 動く形に改修してリリース ■ バージョンアップと同時に新機能を使うアプリケーションをリリースしない 12
考慮ポイント③ 性能 ● バージョンアップで性能が変わるケースがある ○ 高速化するという触れ込みでも性能低下するケースが結構ある ● SQL 文の実行計画が変わるケースがある ○ 設定のチューニングやアプリケーションの改修が必要 ■ パラメーターの調整やオプティマイザヒント（ヒント句）の使用など ● 事前の性能テストは重要 ○ 結果を見てインスタンスサイズを調整する 13
考慮ポイント③ 性能 オプティマイザヒントの使い方は事前に調べて ● バージョンアップで性能が変わるケースがある おこうね！ https://qiita.com/hmatsu47/items/9b1090111f2683d386 bc ○ 高速化するという触れ込みでも性能低下するケースが結構ある ● SQL 文の実行計画が変わるケースがある ○ 設定のチューニングやアプリケーションの改修が必要 ■ パラメーターの調整やオプティマイザヒント（ヒント句）の使用など ● 事前の性能テストは重要 ○ 結果を見てインスタンスサイズを調整する 14
考慮ポイント④ 停止時間 ● ①で触れたとおり、許容できる停止時間は限られる ○ 常にインプレースアップグレードができるわけではない ■ 時間短縮のため Blue/Green デプロイなど別の手法が必要になることも ■ 手法別のメリット・デメリットについては後述 15
考慮ポイント⑤ 切り戻し ● 残念ながらバージョンアップが失敗することはよくある ○ 時間超過、整合確認失敗による作業中止 ○ バージョンアップ後の不具合発生による切り戻し ● どの程度停止時間・データ欠落を許容するか？に合わせ 事前に（想定ケース別の）切り戻し手順を定めておく ○ 例）スナップショットから復元（数日程度の停止とデータ欠落を許容） ○ 例）Blue/Green で逆方向レプリケーション（新→旧）を設定 16
考慮ポイント⑤ 切り戻し ● 残念ながらバージョンアップが失敗することはよくある ○ 時間超過、整合確認失敗による作業中止 ○ 逆方向レプリケーションは、バージョン間の 互換性の問題で難しいこともあるね！ バージョンアップ後の不具合発生による切り戻し ● どの程度停止時間・データ欠落を許容するか？に合わせ 事前に（想定ケース別の）切り戻し手順を定めておく ○ 例）スナップショットから復元（数日程度の停止とデータ欠落を許容） ○ 例）Blue/Green で逆方向レプリケーション（新→旧）を設定 17
考慮ポイントについて整理 ● 重視するポイントはバージョンアップ対象ごとに異なる ○ 完全性が重要なケースもあれば、停止時間が重要なケースも ○ バージョン間の互換性は対象によって異なる ■ 例）Aurora MySQL v1 → v2 の互換性は高い ■ 例）Aurora MySQL v2 → v3（RDS for MySQL 5.7 → 8.0） は細かい差異が 多いので念入りな調査と準備が必要 ● 重視するポイントに合ったバージョンアップ手法を選択 18
考慮ポイントについて整理 Aurora MySQL v3 や MySQL 8.0 へのバージョンアップって 大変なんだね！ Aurora MySQL v1 → v3 のバージョンアップなんて、良い子 は真似しないでね！ ● 重視するポイントはバージョンアップ対象ごとに異なる ○https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book 完全性が重要なケースもあれば、停止時間が重要なケースも https://zenn.dev/hmatsu47/books/aurora-mysql-do-book ○ バージョン間の互換性は対象によって異なる ■ 例）Aurora MySQL v1 → v2 の互換性は高い ■ 例）Aurora MySQL v2 → v3（RDS for MySQL 5.7 → 8.0） は細かい差異が 多いので念入りな調査と準備が必要 ● 重視するポイントに合ったバージョンアップ手法を選択 19
手法① インプレースアップグレード ● 既存 DB・クラスタをそのままバージョンアップ ● メリット ○ 作業が簡単 ● 注意点 ○ 所要時間が不定 ○ バージョンアップが失敗した場合、旧バージョンの DB をスナッ プショットから復元する必要が生じる可能性も 20
手法① インプレースアップグレード ● 既存 DB・クラスタをそのままバージョンアップ ● メリット アップグレード前の状態によって時間が掛かったり、 ○ 同時にいっぱいアップグレードしようとすると処理が 待たされたりするから注意してね！ 作業が簡単 ● 注意点 ○ 所要時間が不定 ○ バージョンアップが失敗した場合、旧バージョンの DB をスナッ プショットから復元する必要が生じる可能性も 21
手法② クローン後にインプレースアップグレード ● クローン後にアップグレードして DB 接続を切り替える ● メリット ○ 作業トラブルに備えて古いバージョンの DB・クラスタを残せる ● 注意点 ○ 所要時間が不定（長くなりがち） ○ アプリケーションで DB のエンドポイントをハードコーディング している場合は修正が必要（または DB・クラスタ名を入れ替える） 22
手法② クローン後にインプレースアップグレード ● クローン後にアップグレードして DB 接続を切り替える ● メリット ○ 作業トラブルに備えて古いバージョンの DB・クラスタを残せる ● 注意点 ハードコーディングは やめよう！ ○ 所要時間が不定（長くなりがち） ○ アプリケーションで DB のエンドポイントをハードコーディング している場合は修正が必要（または DB・クラスタ名を入れ替える） 23
手法③ Blue/Green デプロイ ● 旧バージョンの DB からコピーした DB をアップグレード し、旧 DB →新 DB 間をレプリケーションする ○ 短時間サービス停止し、参照先を新 DB に切り替え ● メリット ○ サービス停止時間が短い ○ MySQL 系ならフルマネージドの Blue/Green デプロイが使える 24
手法③ Blue/Green デプロイ ● 旧バージョンの DB からコピーした をアップグレード 自前 AuroraDB MySQL v1 → v3 Blue/Green デプロイ環境構築例 し、旧 DB →新 DB 間をレプリケーションする ○ （準備が完了したら短時間サービス停止して、 v2 → v2 → v3に切り替え の binlog レプリケーションを 短時間サービス停止し、参照先を新 DB 止めて、EC2/Fargate からの DB アクセスを 実線の矢印から点線の矢印に切り替える） ● メリット ○ サービス停止時間が短い Aurora MySQL v3 や MySQL 8.0 への ○ MySQL 系ならフルマネージドの Blue/Green デプロイが使える バージョンアップって大変なんだね！ Aurora MySQL v1 → v3 のバージョン アップなんて、良い子は (ry 25
手法③ Blue/Green デプロイ ● 旧バージョンの DB からコピーした DB をアップグレード し、旧 DB →新 DB 間をレプリケーションする フルマネージドの Blue/Green デプロイって便利だね！ https://qiita.com/hmatsu47/items/cb69c0a4f0042b7666e7 ○https://qiita.com/hmatsu47/items/922c4f23a1e66f948947 短時間サービス停止し、参照先を新 DB に切り替え ● メリット ○ サービス停止時間が短い ○ MySQL 系ならフルマネージドの Blue/Green デプロイが使える 26
手法③ Blue/Green デプロイ ● 注意点 ○ データ不整合の可能性がある（自前 Blue/Green や DMS の場合は特に） ■ 旧→新切り替え時に整合確認したほうが良い ○ PostgreSQL 系は論理レプリケーションで DDL がほぼ使えない ○ DMS（CDC）を使う場合、DMS の仕様上の制約がある ■ CDC で複製可能な DDL やデータ（値）の範囲が限られるなど ○ アプリケーションで DB のエンドポイントをハードコーディング している場合は対応が必要（フルマネージド Blue/Green デプロイ除く） 27
手法③ Blue/Green デプロイ ● 注意点 DMS って意外と難しそう！ ○ https://zenn.dev/hmatsu47/articles/mysql-dms-timezone データ不整合の可能性がある（自前 Blue/Green や DMS の場合は特に） https://zenn.dev/hmatsu47/articles/mysql-dms-cdc-timestamp-mi ■ 旧→新切り替え時に整合確認したほうが良い smatch ○ PostgreSQL 系は論理レプリケーションで DDL がほぼ使えない ○ DMS（CDC）を使う場合、DMS の仕様上の制約がある ■ CDC で複製可能な DDL やデータ（値）の範囲が限られるなど ○ アプリケーションで DB のエンドポイントをハードコーディング している場合は対応が必要（フルマネージド Blue/Green デプロイ除く） 28
手法③ Blue/Green デプロイ ● 注意点 ○ データ不整合の可能性がある（自前 Blue/Green や DMS の場合は特に） ■ 旧→新切り替え時に整合確認したほうが良い ○ PostgreSQL 系は論理レプリケーションで DDL がほぼ使えない ○ フルマネージドの Blue/Green デプロイだと、 DMS（CDC）を使う場合、DMS の仕様上の制約がある スイッチオーバーでエンドポイント名を自動で 入れ替えてくれるから便利だね！ ■ CDC で複製可能な DDL やデータ（値）の範囲が限られるなど ○ アプリケーションで DB のエンドポイントをハードコーディング している場合は対応が必要（フルマネージド Blue/Green デプロイ除く） 29
手法④ 新旧 DB への同時並行書き込み ● アプリケーションを改修し、新旧両方の DB に同時並行で データを書き込み ○ 切り替え前は旧 DB、切り替え後は新 DB のデータを読み取り ○ 新 DB への読み書きに異常がなければ旧 DB への読み書き処理を 削除 30
手法④ 新旧 DB への同時並行書き込み ● メリット ○ 無停止（ゼロダウンタイム）バージョンアップが実現可能 ● 注意点 ○ アプリケーション実装の手間が掛かる ○ 新旧 DB 書き込み時の処理時間が延びる ○ データ不整合の可能性があるが、無停止での整合確認が難しい 31
手法④ 新旧 DB への同時並行書き込み pt-table-checksum を RDS/Aurora で使うの、何だか ● メリット 難しそうだね！ ○ https://www.percona.com/blog/2020/09/08/data-consistency-for-r 無停止（ゼロダウンタイム）バージョンアップが実現可能 ds-for-mysql-pt-table-checksum-pt-query-digest/ ● 注意点 ○ アプリケーション実装の手間が掛かる ○ 新旧 DB 書き込み時の処理時間が延びる ○ データ不整合の可能性があるが、無停止での整合確認が難しい 32
手法について整理 ● それぞれの特性を考慮して最適な手法を選択する 有利 ◎＞○＞●＞△＞▲ 不利 バージョンアップ手法 完全性 停止時間 手間 ① インプレースアップグレード ◎ △ ◎ ② クローン後インプレースアップグレード ◎ ▲ ○ ●〜○ ○ △〜● △ ◎ ▲ ③ Blue/Green デプロイ ④ 新旧 DB 同時並行書き込み 33
計画進行のポイント① 作業分担と協力体制 ● 組織体制や対象システムの特性・規模に合わせる ○ 専任の DBA がいる組織と開発者がすべてを担当する組織 ■ チーム横断で DBA が主導するのか特定のチームメンバーが主導するのか ○ 対象 DB ・DB クラスタの数 ■ DB ごとに対応を考えるのか統一手順・ルールを定めて対応していくのか ■ 数が多い場合のスケジュール調整（特定の日にバージョンアップが集中する のを避ける） 34
計画進行のポイント① 作業分担と協力体制 ● 組織や対象システムの特性・規模に合わせる 特定の日に集中すると、インプレースアップグレードや ○ スナップショットの復元が全然進まなくなることがある 専任の DBA がいる組織と開発者がすべてを担当する組織 よ！ ■ チーム横断で DBA が主導するのか特定のチームメンバーが主導するのか ○ 対象 DB ・DB クラスタの数 ■ DB ごとに対応を考えるのか統一手順・ルールを定めて対応していくのか ■ 数が多い場合のスケジュール調整（特定の日にバージョンアップが集中する のを避ける） 35
計画進行のポイント① 作業分担と協力体制 ● 責任分界点を明確に ○ DBA と開発チームの役割分担 ○ 開発チーム間での役割分担 ■ 例）情報収集はチーム A 主導、共通ルールの策定はチーム B 主導 ● セクショナリズムを避ける ○ ✖「○○は DBA が対処すべきだからうちには関係ない」 ■ 例）性能問題 : 設定とアプリケーションにまたがる→協力なしの解決は困難 36
計画進行のポイント① 作業分担と協力体制 ● 責任分界点を明確に ○ DBA と開発チームの役割分担 ○「性能問題の解決は 開発チーム間での役割分担 DBA の責任範囲」みたいな責任分界点 を作らないようにしないとね！ ■ 例）情報収集はチーム A 主導、共通ルールの策定はチーム B 主導 ● セクショナリズムを避ける ○ ✖「○○は DBA が対処すべきだからうちには関係ない」 ■ 例）性能問題 : 設定とアプリケーションにまたがる→協力なしの解決は困難 37
計画進行のポイント② 情報共有 ● 参加メンバーが理解可能なレベルに落とし込んで共有 ○ 「一次ソースを示す」にこだわりすぎない ○ 「わからないことをわからないと言う」のは意外と難しい ● フィードバックを集めて生かす ○ 当初想定しなかった問題は必ず出てくる ○ 実作業で発見した問題点を全体で共有 38
計画進行のポイント③ 事前準備とリハーサル ● プロジェクトの 9 割以上は事前準備 ○ 事前に準備していないことの実行は困難 ■ 例）切り戻しが必要になった時点で初めて手順を考える→事故る ● リハーサルと事前の動作確認はできる限り何度も実施 ○ 一度リハーサルしただけでは気付かない（顕在化しない）バグを 踏み抜くことが稀によくある 39
計画進行のポイント③ 事前準備とリハーサル ● プロジェクトの 9 割以上は事前準備 ○ 事前に準備していないことの実行は困難 ■ 例）切り戻しが必要になった時点で初めて手順を考える→事故る ● リハーサルと事前の動作確認はできる限り何度も実施 ○ 一度リハーサルしただけでは気付かない（顕在化しない）バグを 踏み抜くことが稀によくある 関係ないけど、サメの 9 割は人に無害なんだよ！ ぼくは違うけどね！ 40
計画進行のポイントについて整理 ● 組織体制やバージョンアップ対象に適した計画を ● 責任分界点を明確に みんなでなかよく ● お互いに協力する体制づくり ● 情報は理解可能な形で共有 がんばってね！ ● フィードバックを集めて全体で共有 ● 事前準備が 9 割以上・リハーサルは繰り返し実施 41
参考リンク（発表者作成資料） ● Aurora MySQL v1 → v3（3.02.1 移行計画編） https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book ● Aurora MySQL v1 → v3（3.02.1 移行事例編） https://zenn.dev/hmatsu47/books/aurora-mysql-do-book ● 小ネタ／Aurora MySQL v1/v2 から v3 に移行する際のユーザ権限トラブルについて https://qiita.com/hmatsu47/items/d3f34f39c28a4b802966 ● 小ネタ／MySQL でバージョンアップ時のデータ整合確認に mysqldump を使う https://zenn.dev/hmatsu47/articles/mysql-dump-for-verup-check 42
参考リンク（発表者作成資料） ● MySQL 8.0 で SELECT COUNT(*) が失速する https://zenn.dev/hmatsu47/articles/mysql80-count-slowdown ● 小ネタ／AWS DMS（CDC）で MySQL to MySQL 移行時のタイムゾーン指定 https://zenn.dev/hmatsu47/articles/mysql-dms-timezone ● AWS DMS（CDC）で MySQL to MySQL 移行時の TIMESTAMP 不一致問題 https://qiita.com/hmatsu47/items/d3f34f39c28a4b802966 ● 小ネタ／MySQL 8.0（Aurora MySQL v3）にバージョンアップしたときの実行計画調 整にオプティマイザヒントを使う https://qiita.com/hmatsu47/items/9b1090111f2683d386bc 43
参考リンク（発表者作成資料） ● Aurora の Blue/Green デプロイで少し遊んでみた https://qiita.com/hmatsu47/items/cb69c0a4f0042b7666e7 ● Aurora の Blue/Green デプロイで少し遊んでみた（スイッチオーバー編） https://qiita.com/hmatsu47/items/922c4f23a1e66f948947 ● Aurora の Blue/Green デプロイで少し遊んでみた（Aurora MySQL v1 → v3 Blue/Green 失敗編） https://qiita.com/hmatsu47/items/9a5afb73d2774600fdd9 44