$30 off During Our Annual Pro Sale. View Details »

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)

    View Slide

  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

    View Slide

  3. 近況
    ● 朝会 #32 で話した Aurora MySQL v1 → v3 移行が完了
    ○ 2022/10 : メインのプロダクトの移行が完了
    ○ 2022/12 : テスト環境など内部 DB の移行がすべて完了
    ○ 2023/1(先週末): 別プロダクトの移行が完了
    →移行はほぼ完了(お試し環境を 1 つ残すのみ)
    3

    View Slide

  4. 本日のネタ
    ● バージョンアップで考慮する主要なポイントを 5 つ
    ○ データ完全性・機能の互換性・性能・停止時間・切り戻し
    ● 色々なバージョンアップ手法のメリットと注意点
    ○ インプレースアップグレード・クローン後アップグレード
    ○ Blue/Green デプロイ・新旧 DB への同時並行書き込み
    ● バージョンアップ計画を進める際のポイント
    ○ 作業分担と協力体制・情報共有・事前準備とリハーサル
    4

    View Slide

  5. おことわり
    ● バージョンアップの具体的な手順は示しません
    ● バージョンアップに使えるマネージドサービスの具体例
    や機能について不明点・疑問点がある場合は、契約中の
    AWS パートナーか AWS サポートに確認してください
    5

    View Slide

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

    View Slide

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

    View Slide

  8. 考慮ポイント① データ完全性
    ● 完全性を保ったデータ移行は意外と難しい
    ○ サービスを完全停止してバックアップを取り新環境に復元できる
    →完全性を保つのは比較的容易
    ○ 実際には許容できるサービス停止時間は限られる
    ○ データ変換処理のバグや不都合な仕様に当たる可能性も
    ● 事後のデータ整合確認の併用も検討
    ○ ダンプ比較・行数比較・DMS による検証など
    8
    容量が小さいテーブルならテーブルダンプは
    整合確認にも使えるね!
    https://zenn.dev/hmatsu47/articles/mysql-dump-for-v
    erup-check
    でもデータの全件 COUNT(*) は意外と時間が
    掛かったりするから注意してね!
    https://zenn.dev/hmatsu47/articles/mysql80-count-slo
    wdown

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  12. 考慮ポイント② 機能の互換性
    ● バージョン間差異の影響がどれだけあるか?
    ○ SQL 文の非互換・RDBMS としての機能の非互換
    ○ アプリケーションや管理監視システムの改修・修正が必要に
    ● アプリケーション改修・リリースタイミング
    ○ 可能ならバージョンアップ前に、バージョンアップ前後の両方で
    動く形に改修してリリース
    ■ バージョンアップと同時に新機能を使うアプリケーションをリリースしない
    12
    DB のバージョンアップのついでに新機能を
    リリースしちゃおう!…ってやりがちだけど
    切り戻しが必要になったときに大変だから、
    できればやめておこうね!

    View Slide

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

    View Slide

  14. 考慮ポイント③ 性能
    ● バージョンアップで性能が変わるケースがある
    ○ 高速化するという触れ込みでも性能低下するケースが結構ある
    ● SQL 文の実行計画が変わるケースがある
    ○ 設定のチューニングやアプリケーションの改修が必要
    ■ パラメーターの調整やオプティマイザヒント(ヒント句)の使用など
    ● 事前の性能テストは重要
    ○ 結果を見てインスタンスサイズを調整する
    14
    オプティマイザヒントの使い方は事前に調べて
    おこうね!
    https://qiita.com/hmatsu47/items/9b1090111f2683d386
    bc

    View Slide

  15. 考慮ポイント④ 停止時間
    ● ①で触れたとおり、許容できる停止時間は限られる
    ○ 常にインプレースアップグレードができるわけではない
    ■ 時間短縮のため Blue/Green デプロイなど別の手法が必要になることも
    ■ 手法別のメリット・デメリットについては後述
    15

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  21. 手法① インプレースアップグレード
    ● 既存 DB・クラスタをそのままバージョンアップ
    ● メリット
    ○ 作業が簡単
    ● 注意点
    ○ 所要時間が不定
    ○ バージョンアップが失敗した場合、旧バージョンの DB をスナッ
    プショットから復元する必要が生じる可能性も
    21
    アップグレード前の状態によって時間が掛かったり、
    同時にいっぱいアップグレードしようとすると処理が
    待たされたりするから注意してね!

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  30. 手法④ 新旧 DB への同時並行書き込み
    ● アプリケーションを改修し、新旧両方の DB に同時並行で
    データを書き込み
    ○ 切り替え前は旧 DB、切り替え後は新 DB のデータを読み取り
    ○ 新 DB への読み書きに異常がなければ旧 DB への読み書き処理を
    削除
    30

    View Slide

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

    View Slide

  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/

    View Slide

  33. 手法について整理
    ● それぞれの特性を考慮して最適な手法を選択する
    有利 ◎>○>●>△>▲ 不利
    33
    バージョンアップ手法 完全性 停止時間 手間
    ① インプレースアップグレード ◎ △ ◎
    ② クローン後インプレースアップグレード ◎ ▲ ○
    ③ Blue/Green デプロイ ●〜○ ○ △〜●
    ④ 新旧 DB 同時並行書き込み △ ◎ ▲

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  38. 計画進行のポイント② 情報共有
    ● 参加メンバーが理解可能なレベルに落とし込んで共有
    ○ 「一次ソースを示す」にこだわりすぎない
    ○ 「わからないことをわからないと言う」のは意外と難しい
    ● フィードバックを集めて生かす
    ○ 当初想定しなかった問題は必ず出てくる
    ○ 実作業で発見した問題点を全体で共有
    38

    View Slide

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

    View Slide

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

    View Slide

  41. 計画進行のポイントについて整理
    ● 組織体制やバージョンアップ対象に適した計画を
    ● 責任分界点を明確に
    ● お互いに協力する体制づくり
    ● 情報は理解可能な形で共有
    ● フィードバックを集めて全体で共有
    ● 事前準備が 9 割以上・リハーサルは繰り返し実施
    41
    みんなでなかよく
    がんばってね!

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide