Upgrade to Pro — share decks privately, control downloads, hide ads and more …

RDS/Aurora バージョンアップのポイント

hmatsu47
PRO
January 17, 2023

RDS/Aurora バージョンアップのポイント

JAWS-UG 朝会 #41 2023/1/17

hmatsu47
PRO

January 17, 2023
Tweet

More Decks by hmatsu47

Other Decks in Technology

Transcript

  1. RDS/Aurora バージョンアップのポイント JAWS-UG 朝会 #41 2023/1/17 まつひさ(hmatsu47)

  2. 自己紹介 松久裕保(@hmatsu47) • https://qiita.com/hmatsu47 名古屋で Web インフラのお守り係をしています JAWS-UG 名古屋・浜松を中心に活動しています ◦

    「RDBMS(MySQL)の話をする人」として認知されているようです ◦ 以前「MySQL 8.0 の薄い本」を作っていました(8.0.24 まで更新) ▪ Qiita の記事: https://qiita.com/hmatsu47/items/ceb75caf46e3c761095d 2
  3. 近況 • 朝会 #32 で話した Aurora MySQL v1 → v3

    移行が完了 ◦ 2022/10 : メインのプロダクトの移行が完了 ◦ 2022/12 : テスト環境など内部 DB の移行がすべて完了 ◦ 2023/1(先週末): 別プロダクトの移行が完了 →移行はほぼ完了(お試し環境を 1 つ残すのみ) 3
  4. 本日のネタ • バージョンアップで考慮する主要なポイントを 5 つ ◦ データ完全性・機能の互換性・性能・停止時間・切り戻し • 色々なバージョンアップ手法のメリットと注意点 ◦

    インプレースアップグレード・クローン後アップグレード ◦ Blue/Green デプロイ・新旧 DB への同時並行書き込み • バージョンアップ計画を進める際のポイント ◦ 作業分担と協力体制・情報共有・事前準備とリハーサル 4
  5. おことわり • バージョンアップの具体的な手順は示しません • バージョンアップに使えるマネージドサービスの具体例 や機能について不明点・疑問点がある場合は、契約中の AWS パートナーか AWS サポートに確認してください

    5
  6. 考慮ポイント① データ完全性 • 完全性を保ったデータ移行は意外と難しい ◦ サービスを完全停止してバックアップを取り新環境に復元できる →完全性を保つのは比較的容易 ◦ 実際には許容できるサービス停止時間は限られる ◦

    データ変換処理のバグや不都合な仕様に当たる可能性も • 事後のデータ整合確認の併用も検討 ◦ ダンプ比較・行数比較・DMS による検証など 6
  7. 考慮ポイント① データ完全性 • 完全性を保ったデータ移行は意外と難しい ◦ サービスを完全停止してバックアップを取り新環境に復元できる →完全性を保つのは比較的容易 ◦ 実際には許容できるサービス停止時間は限られる ◦

    データ変換処理のバグや不都合な仕様に当たる可能性も • 事後のデータ整合確認の併用も検討 ◦ ダンプ比較・行数比較・DMS による検証など 7 Aurora や RDS のリリースノートを読むと、 アップグレードに関する不具合の解消報告が いくつか見つかるね! https://docs.aws.amazon.com/ja_jp/AmazonRDS/late st/AuroraMySQLReleaseNotes/AuroraMySQL.Updat es.3022.html
  8. 考慮ポイント① データ完全性 • 完全性を保ったデータ移行は意外と難しい ◦ サービスを完全停止してバックアップを取り新環境に復元できる →完全性を保つのは比較的容易 ◦ 実際には許容できるサービス停止時間は限られる ◦

    データ変換処理のバグや不都合な仕様に当たる可能性も • 事後のデータ整合確認の併用も検討 ◦ ダンプ比較・行数比較・DMS による検証など 8 容量が小さいテーブルならテーブルダンプは 整合確認にも使えるね! https://zenn.dev/hmatsu47/articles/mysql-dump-for-v erup-check でもデータの全件 COUNT(*) は意外と時間が 掛かったりするから注意してね! https://zenn.dev/hmatsu47/articles/mysql80-count-slo wdown
  9. 考慮ポイント② 機能の互換性 • バージョン間差異の影響がどれだけあるか? ◦ SQL 文の非互換・RDBMS としての機能の非互換 ◦ アプリケーションや管理監視システムの改修・修正が必要に

    • アプリケーション改修・リリースタイミング ◦ 可能ならバージョンアップ前に、バージョンアップ前後の両方で 動く形に改修してリリース ▪ バージョンアップと同時に新機能を使うアプリケーションをリリースしない 9
  10. 考慮ポイント② 機能の互換性 • バージョン間差異の影響がどれだけあるか? ◦ SQL 文の非互換・RDBMS としての機能の非互換 ◦ アプリケーションや管理監視システムの改修・修正が必要に

    • アプリケーション改修・リリースタイミング ◦ 可能ならバージョンアップ前に、バージョンアップ前後の両方で 動く形に改修してリリース ▪ バージョンアップと同時に新機能を使うアプリケーションをリリースしない 10 MySQL をバージョンアップすると Datadog でロックのメトリクスが一部取れなくなる、 なんてこともあるから注意してね!
  11. 考慮ポイント② 機能の互換性 • バージョン間差異の影響がどれだけあるか? ◦ SQL 文の非互換・RDBMS としての機能の非互換 ◦ アプリケーションや管理監視システムの改修・修正が必要に

    • アプリケーション改修・リリースタイミング ◦ 可能ならバージョンアップ前に、バージョンアップ前後の両方で 動く形に改修してリリース ▪ バージョンアップと同時に新機能を使うアプリケーションをリリースしない 11
  12. 考慮ポイント② 機能の互換性 • バージョン間差異の影響がどれだけあるか? ◦ SQL 文の非互換・RDBMS としての機能の非互換 ◦ アプリケーションや管理監視システムの改修・修正が必要に

    • アプリケーション改修・リリースタイミング ◦ 可能ならバージョンアップ前に、バージョンアップ前後の両方で 動く形に改修してリリース ▪ バージョンアップと同時に新機能を使うアプリケーションをリリースしない 12 DB のバージョンアップのついでに新機能を リリースしちゃおう!…ってやりがちだけど 切り戻しが必要になったときに大変だから、 できればやめておこうね!
  13. 考慮ポイント③ 性能 • バージョンアップで性能が変わるケースがある ◦ 高速化するという触れ込みでも性能低下するケースが結構ある • SQL 文の実行計画が変わるケースがある ◦

    設定のチューニングやアプリケーションの改修が必要 ▪ パラメーターの調整やオプティマイザヒント(ヒント句)の使用など • 事前の性能テストは重要 ◦ 結果を見てインスタンスサイズを調整する 13
  14. 考慮ポイント③ 性能 • バージョンアップで性能が変わるケースがある ◦ 高速化するという触れ込みでも性能低下するケースが結構ある • SQL 文の実行計画が変わるケースがある ◦

    設定のチューニングやアプリケーションの改修が必要 ▪ パラメーターの調整やオプティマイザヒント(ヒント句)の使用など • 事前の性能テストは重要 ◦ 結果を見てインスタンスサイズを調整する 14 オプティマイザヒントの使い方は事前に調べて おこうね! https://qiita.com/hmatsu47/items/9b1090111f2683d386 bc
  15. 考慮ポイント④ 停止時間 • ①で触れたとおり、許容できる停止時間は限られる ◦ 常にインプレースアップグレードができるわけではない ▪ 時間短縮のため Blue/Green デプロイなど別の手法が必要になることも

    ▪ 手法別のメリット・デメリットについては後述 15
  16. 考慮ポイント⑤ 切り戻し • 残念ながらバージョンアップが失敗することはよくある ◦ 時間超過、整合確認失敗による作業中止 ◦ バージョンアップ後の不具合発生による切り戻し • どの程度停止時間・データ欠落を許容するか?に合わせ

    事前に(想定ケース別の)切り戻し手順を定めておく ◦ 例)スナップショットから復元(数日程度の停止とデータ欠落を許容) ◦ 例)Blue/Green で逆方向レプリケーション(新→旧)を設定 16
  17. 考慮ポイント⑤ 切り戻し • 残念ながらバージョンアップが失敗することはよくある ◦ 時間超過、整合確認失敗による作業中止 ◦ バージョンアップ後の不具合発生による切り戻し • どの程度停止時間・データ欠落を許容するか?に合わせ

    事前に(想定ケース別の)切り戻し手順を定めておく ◦ 例)スナップショットから復元(数日程度の停止とデータ欠落を許容) ◦ 例)Blue/Green で逆方向レプリケーション(新→旧)を設定 17 逆方向レプリケーションは、バージョン間の 互換性の問題で難しいこともあるね!
  18. 考慮ポイントについて整理 • 重視するポイントはバージョンアップ対象ごとに異なる ◦ 完全性が重要なケースもあれば、停止時間が重要なケースも ◦ バージョン間の互換性は対象によって異なる ▪ 例)Aurora MySQL

    v1 → v2 の互換性は高い ▪ 例)Aurora MySQL v2 → v3(RDS for MySQL 5.7 → 8.0) は細かい差異が 多いので念入りな調査と準備が必要 • 重視するポイントに合ったバージョンアップ手法を選択 18
  19. 考慮ポイントについて整理 • 重視するポイントはバージョンアップ対象ごとに異なる ◦ 完全性が重要なケースもあれば、停止時間が重要なケースも ◦ バージョン間の互換性は対象によって異なる ▪ 例)Aurora MySQL

    v1 → v2 の互換性は高い ▪ 例)Aurora MySQL v2 → v3(RDS for MySQL 5.7 → 8.0) は細かい差異が 多いので念入りな調査と準備が必要 • 重視するポイントに合ったバージョンアップ手法を選択 19 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
  20. 手法① インプレースアップグレード • 既存 DB・クラスタをそのままバージョンアップ • メリット ◦ 作業が簡単 •

    注意点 ◦ 所要時間が不定 ◦ バージョンアップが失敗した場合、旧バージョンの DB をスナッ プショットから復元する必要が生じる可能性も 20
  21. 手法① インプレースアップグレード • 既存 DB・クラスタをそのままバージョンアップ • メリット ◦ 作業が簡単 •

    注意点 ◦ 所要時間が不定 ◦ バージョンアップが失敗した場合、旧バージョンの DB をスナッ プショットから復元する必要が生じる可能性も 21 アップグレード前の状態によって時間が掛かったり、 同時にいっぱいアップグレードしようとすると処理が 待たされたりするから注意してね!
  22. 手法② クローン後にインプレースアップグレード • クローン後にアップグレードして DB 接続を切り替える • メリット ◦ 作業トラブルに備えて古いバージョンの

    DB・クラスタを残せる • 注意点 ◦ 所要時間が不定(長くなりがち) ◦ アプリケーションで DB のエンドポイントをハードコーディング している場合は修正が必要(または DB・クラスタ名を入れ替える) 22
  23. 手法② クローン後にインプレースアップグレード • クローン後にアップグレードして DB 接続を切り替える • メリット ◦ 作業トラブルに備えて古いバージョンの

    DB・クラスタを残せる • 注意点 ◦ 所要時間が不定(長くなりがち) ◦ アプリケーションで DB のエンドポイントをハードコーディング している場合は修正が必要(または DB・クラスタ名を入れ替える) 23 ハードコーディングは やめよう!
  24. 手法③ Blue/Green デプロイ • 旧バージョンの DB からコピーした DB をアップグレード し、旧

    DB →新 DB 間をレプリケーションする ◦ 短時間サービス停止し、参照先を新 DB に切り替え • メリット ◦ サービス停止時間が短い ◦ MySQL 系ならフルマネージドの Blue/Green デプロイが使える 24
  25. 手法③ Blue/Green デプロイ • 旧バージョンの DB からコピーした DB をアップグレード し、旧

    DB →新 DB 間をレプリケーションする ◦ 短時間サービス停止し、参照先を新 DB に切り替え • メリット ◦ サービス停止時間が短い ◦ MySQL 系ならフルマネージドの Blue/Green デプロイが使える 25 自前 Aurora MySQL v1 → v3 Blue/Green デプロイ環境構築例 (準備が完了したら短時間サービス停止して、 v2 → v2 → v3 の binlog レプリケーションを 止めて、EC2/Fargate からの DB アクセスを 実線の矢印から点線の矢印に切り替える) Aurora MySQL v3 や MySQL 8.0 への バージョンアップって大変なんだね! Aurora MySQL v1 → v3 のバージョン アップなんて、良い子は (ry
  26. 手法③ Blue/Green デプロイ • 旧バージョンの DB からコピーした DB をアップグレード し、旧

    DB →新 DB 間をレプリケーションする ◦ 短時間サービス停止し、参照先を新 DB に切り替え • メリット ◦ サービス停止時間が短い ◦ MySQL 系ならフルマネージドの Blue/Green デプロイが使える 26 フルマネージドの Blue/Green デプロイって便利だね! https://qiita.com/hmatsu47/items/cb69c0a4f0042b7666e7 https://qiita.com/hmatsu47/items/922c4f23a1e66f948947
  27. 手法③ Blue/Green デプロイ • 注意点 ◦ データ不整合の可能性がある(自前 Blue/Green や DMS

    の場合は特に) ▪ 旧→新切り替え時に整合確認したほうが良い ◦ PostgreSQL 系は論理レプリケーションで DDL がほぼ使えない ◦ DMS(CDC)を使う場合、DMS の仕様上の制約がある ▪ CDC で複製可能な DDL やデータ(値)の範囲が限られるなど ◦ アプリケーションで DB のエンドポイントをハードコーディング している場合は対応が必要(フルマネージド Blue/Green デプロイ除く) 27
  28. 手法③ Blue/Green デプロイ • 注意点 ◦ データ不整合の可能性がある(自前 Blue/Green や DMS

    の場合は特に) ▪ 旧→新切り替え時に整合確認したほうが良い ◦ PostgreSQL 系は論理レプリケーションで DDL がほぼ使えない ◦ DMS(CDC)を使う場合、DMS の仕様上の制約がある ▪ CDC で複製可能な DDL やデータ(値)の範囲が限られるなど ◦ アプリケーションで DB のエンドポイントをハードコーディング している場合は対応が必要(フルマネージド Blue/Green デプロイ除く) 28 DMS って意外と難しそう! https://zenn.dev/hmatsu47/articles/mysql-dms-timezone https://zenn.dev/hmatsu47/articles/mysql-dms-cdc-timestamp-mi smatch
  29. 手法③ Blue/Green デプロイ • 注意点 ◦ データ不整合の可能性がある(自前 Blue/Green や DMS

    の場合は特に) ▪ 旧→新切り替え時に整合確認したほうが良い ◦ PostgreSQL 系は論理レプリケーションで DDL がほぼ使えない ◦ DMS(CDC)を使う場合、DMS の仕様上の制約がある ▪ CDC で複製可能な DDL やデータ(値)の範囲が限られるなど ◦ アプリケーションで DB のエンドポイントをハードコーディング している場合は対応が必要(フルマネージド Blue/Green デプロイ除く) 29 フルマネージドの Blue/Green デプロイだと、 スイッチオーバーでエンドポイント名を自動で 入れ替えてくれるから便利だね!
  30. 手法④ 新旧 DB への同時並行書き込み • アプリケーションを改修し、新旧両方の DB に同時並行で データを書き込み ◦

    切り替え前は旧 DB、切り替え後は新 DB のデータを読み取り ◦ 新 DB への読み書きに異常がなければ旧 DB への読み書き処理を 削除 30
  31. 手法④ 新旧 DB への同時並行書き込み • メリット ◦ 無停止(ゼロダウンタイム)バージョンアップが実現可能 • 注意点

    ◦ アプリケーション実装の手間が掛かる ◦ 新旧 DB 書き込み時の処理時間が延びる ◦ データ不整合の可能性があるが、無停止での整合確認が難しい 31
  32. 手法④ 新旧 DB への同時並行書き込み • メリット ◦ 無停止(ゼロダウンタイム)バージョンアップが実現可能 • 注意点

    ◦ アプリケーション実装の手間が掛かる ◦ 新旧 DB 書き込み時の処理時間が延びる ◦ データ不整合の可能性があるが、無停止での整合確認が難しい 32 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/
  33. 手法について整理 • それぞれの特性を考慮して最適な手法を選択する 有利 ◎>◦>•>△>▲ 不利 33 バージョンアップ手法 完全性 停止時間

    手間 ① インプレースアップグレード ◎ △ ◎ ② クローン後インプレースアップグレード ◎ ▲ ◦ ③ Blue/Green デプロイ •〜◦ ◦ △〜• ④ 新旧 DB 同時並行書き込み △ ◎ ▲
  34. 計画進行のポイント① 作業分担と協力体制 • 組織体制や対象システムの特性・規模に合わせる ◦ 専任の DBA がいる組織と開発者がすべてを担当する組織 ▪ チーム横断で

    DBA が主導するのか特定のチームメンバーが主導するのか ◦ 対象 DB ・DB クラスタの数 ▪ DB ごとに対応を考えるのか統一手順・ルールを定めて対応していくのか ▪ 数が多い場合のスケジュール調整(特定の日にバージョンアップが集中する のを避ける) 34
  35. 計画進行のポイント① 作業分担と協力体制 • 組織や対象システムの特性・規模に合わせる ◦ 専任の DBA がいる組織と開発者がすべてを担当する組織 ▪ チーム横断で

    DBA が主導するのか特定のチームメンバーが主導するのか ◦ 対象 DB ・DB クラスタの数 ▪ DB ごとに対応を考えるのか統一手順・ルールを定めて対応していくのか ▪ 数が多い場合のスケジュール調整(特定の日にバージョンアップが集中する のを避ける) 35 特定の日に集中すると、インプレースアップグレードや スナップショットの復元が全然進まなくなることがある よ!
  36. 計画進行のポイント① 作業分担と協力体制 • 責任分界点を明確に ◦ DBA と開発チームの役割分担 ◦ 開発チーム間での役割分担 ▪

    例)情報収集はチーム A 主導、共通ルールの策定はチーム B 主導 • セクショナリズムを避ける ◦ ✖「◦◦は DBA が対処すべきだからうちには関係ない」 ▪ 例)性能問題 : 設定とアプリケーションにまたがる→協力なしの解決は困難 36
  37. 計画進行のポイント① 作業分担と協力体制 • 責任分界点を明確に ◦ DBA と開発チームの役割分担 ◦ 開発チーム間での役割分担 ▪

    例)情報収集はチーム A 主導、共通ルールの策定はチーム B 主導 • セクショナリズムを避ける ◦ ✖「◦◦は DBA が対処すべきだからうちには関係ない」 ▪ 例)性能問題 : 設定とアプリケーションにまたがる→協力なしの解決は困難 37 「性能問題の解決は DBA の責任範囲」みたいな責任分界点 を作らないようにしないとね!
  38. 計画進行のポイント② 情報共有 • 参加メンバーが理解可能なレベルに落とし込んで共有 ◦ 「一次ソースを示す」にこだわりすぎない ◦ 「わからないことをわからないと言う」のは意外と難しい • フィードバックを集めて生かす

    ◦ 当初想定しなかった問題は必ず出てくる ◦ 実作業で発見した問題点を全体で共有 38
  39. 計画進行のポイント③ 事前準備とリハーサル • プロジェクトの 9 割以上は事前準備 ◦ 事前に準備していないことの実行は困難 ▪ 例)切り戻しが必要になった時点で初めて手順を考える→事故る

    • リハーサルと事前の動作確認はできる限り何度も実施 ◦ 一度リハーサルしただけでは気付かない(顕在化しない)バグを 踏み抜くことが稀によくある 39
  40. 計画進行のポイント③ 事前準備とリハーサル • プロジェクトの 9 割以上は事前準備 ◦ 事前に準備していないことの実行は困難 ▪ 例)切り戻しが必要になった時点で初めて手順を考える→事故る

    • リハーサルと事前の動作確認はできる限り何度も実施 ◦ 一度リハーサルしただけでは気付かない(顕在化しない)バグを 踏み抜くことが稀によくある 40 関係ないけど、サメの 9 割は人に無害なんだよ! ぼくは違うけどね!
  41. 計画進行のポイントについて整理 • 組織体制やバージョンアップ対象に適した計画を • 責任分界点を明確に • お互いに協力する体制づくり • 情報は理解可能な形で共有 •

    フィードバックを集めて全体で共有 • 事前準備が 9 割以上・リハーサルは繰り返し実施 41 みんなでなかよく がんばってね!
  42. 参考リンク(発表者作成資料) • 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
  43. 参考リンク(発表者作成資料) • 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
  44. 参考リンク(発表者作成資料) • 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