いかにして不足・不整合なくデータ移行したか

by momochi29

Slide 1

Slide 1 text

いかにして不足・不整合なくデータ移行したか発表者: momochi29 1

Slide 2

Slide 2 text

自己紹介 id:momochi29 ● データ移行の検証など ● マンガメディア開発のチーム歴は5年程度 ● 「ワールドトリガー」が好き 2

Slide 3

Slide 3 text

ゴールユーザから見て移管前後でデータが変わっていない 3

Slide 4

Slide 4 text

そのためには？本番移行までに移行時の直すべきエラー・原因不明のエラーをすべて洗い出し、解消する 4

Slide 5

Slide 5 text

全体像 5

Slide 6

Slide 6 text

サイクルの全体像移行検証エラー修正完了！エラーがないエラーがある 6

Slide 7

Slide 7 text

サイクルの全体像移行検証エラー修正完了！エラーがないエラーがある 7

Slide 8

Slide 8 text

サイクルの全体像移行検証エラー修正完了！エラーがないエラーがあるここを話します 8

Slide 9

Slide 9 text

検証 9

Slide 10

Slide 10 text

検証が必要な背景期間1 エラーなし期間2 エラーなし・・・データ移行(分割移行) 10

Slide 11

Slide 11 text

検証が必要な背景期間1 エラーなし期間2 エラーなし・・・期間ごとにエラーがないのでおそらく不整合はないだろうデータ移行(分割移行) 11

Slide 12

Slide 12 text

検証が必要な背景期間1 エラーなし期間2 エラーなし・・・期間ごとにエラーがないのでおそらく不整合はないだろうデータ移行(分割移行) ユーザ単位ですべてのデータに不整合がないことは保証できていない 12

Slide 13

Slide 13 text

検証が必要な背景期間1 エラーなし期間2 エラーなし・・・期間ごとにエラーがないのでおそらく不整合はないだろうデータ移行(分割移行) そもそも… 移行処理にバグがあってデグレしているかもしれない 13

Slide 14

Slide 14 text

検証が必要な背景 1. ユーザ単位ですべてのデータに不整合がないことを保証できていない 2. 移行処理にバグがあってデグレしているかもしれない 14

Slide 15

Slide 15 text

何を検証するのか 1. ユーザに対する検証 2. 移行自体に対する検証 15

Slide 16

Slide 16 text

ユーザに対する検証 ● ユーザが持っているデータが移行前後で変化していないことをユーザごとに検証する 16

Slide 17

Slide 17 text

ユーザに対する検証 ● ズレるとユーザに不利益がある箇所を重点的に検証する ○ 例) レンタル期限が一致するか ■ ズレるとレンタルしていたはずの話が読めなくなったり… 17

Slide 18

Slide 18 text

移行自体に対する検証 ● 移行が仕様通りに実装されているかを検証する 18

Slide 19

Slide 19 text

仕様通りに実装されているかの検証移行元テーブル移行先テーブル移行先テーブル ︙ 変換ルールに則って移行 19

Slide 20

Slide 20 text

移行元テーブル移行先テーブル移行先テーブル ︙ 変換ルールに則って移行単体テストによってルールに従っているか検証している仕様通りに実装されているかの検証 20

Slide 21

Slide 21 text

移行元テーブル移行先テーブル移行先テーブル ︙ 変換ルールに則って移行単体テストによってルールに従っているか検証している仕様通りに実装されているかの検証これで充分？ 21

Slide 22

Slide 22 text

仕様通りに実装されているかの検証 ● No ● 移行処理に実装漏れがあると、テストが存在しないので仕様に従っているか確認されない ○ 移行先観点でのテストになるので漏れやすい 22

Slide 23

Slide 23 text

仕様通りに実装されているかの検証移行元テーブル移行先テーブル変換ルールに則って移行移行先テーブルから移行元テーブルを再現できるか検証する 23

Slide 24

Slide 24 text

テーブルの再現による検証 ● 移行先のテーブルからデータを集めて変換ルールを適用して移行元のテーブルを作る ● これによって移行元との差分がわかり、移行漏れを無くせる 24

Slide 25

Slide 25 text

検証失敗時には？ ● エラーを記録する ● 分類しやすいようにフォーマットを統一 25

Slide 26

Slide 26 text

直す価値のあるエラーを得る ● 直す価値のあるエラーとは、直さないと本番環境でも発生するエラー ● 移行元の本番環境のスナップショットを使って、移行→検証することで価値のあるエラーを得る 26

Slide 27

Slide 27 text

検証を動かす ● データ移行を動かしているStep Functions + AWS Batchに検証ジョブを追加した ○ 数百の検証ジョブを並行で動かすことで十分高速に検証できた ● ただ、リソース上の問題があったのでチューニングした 27

Slide 28

Slide 28 text

検証のチューニング ● 移行に利用しているDBのCPU使用率が張り付いている ○ → 検証は読み込み専用DBを使う ● 検証のタスクがOOM ○ → メモリ使用量の上限を引き上げ ○ → あえてN+1にする 28

Slide 29

Slide 29 text

エラー修正 29

Slide 30

Slide 30 text

エラー修正 ● エラー数を0にするのがゴール ● 多種多様なエラーをうまくハンドリングするには？ 30

Slide 31

Slide 31 text

エラーフォーマットの統一 ● ジョブの種類 ● エラーメッセージ ● エラーコード ○ レコードが存在しない、一致しないの2種類 ● デバッグのために必要な情報 ○ エラーになった場所、レコードのID 31

Slide 32

Slide 32 text

CloudWatch Logs Insights ● ジョブの種類、エラーごとに ﬁrst_seen, last_seen, エラー総数を出す 32

Slide 33

Slide 33 text

CloudWatch ダッシュボード ● Logs Insightsで作ったクエリの実行結果を集約できる ● ここだけ見ればオッケーにできる ○ 移行・検証のエラーに対するクエリ結果と、その他に必要な情報をウィジェットとして追加した 33

Slide 34

Slide 34 text

CloudWatch ダッシュボード 34

Slide 35

Slide 35 text

ゴールが数値で見える嬉しさ ● 移行作業は長いトンネルを歩く感覚がある ● エラー数が減るとゴールに近付いていることを実感できてよかった 35

Slide 36

Slide 36 text

修正サイクルを回すエラー修正移行ダッシュボード確認エラーがある完了！エラーがない 36

Slide 37

Slide 37 text

修正サイクルを回すエラー修正移行ダッシュボード確認新規のエラー: ﬁrst_seenから判断既存のエラーが直っていない: last_seenから判断完了！エラーがない 37

Slide 38

Slide 38 text

あとはエラーがなくなるまでひたすらやる 38

Slide 39

Slide 39 text

結果 ● 本番環境での移行で未知のエラーに遭遇せずに移行を完了することができた ○ 本番同等のデータを使ってエラーが無くなるまでサイクルを回した賜物 ● データ移行に起因する大きな問題はなかった 39

Slide 40

Slide 40 text

まとめ ● ユーザに対する検証と移行自体に対する検証の2面からの検証によって、不足・不整合なく移行できた ● 移行元の本番環境のデータを使って修正サイクルを回すことで未知のエラーに遭遇することなく移行できた 40