Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
いかにして不足・不整合なくデータ移行したか
Search
momochi29
October 15, 2024
Programming
1
1.4k
いかにして不足・不整合なくデータ移行したか
Hatena Engineer Seminar #31 「少年ジャンプ+」 サーバーサイド編
https://hatena.connpass.com/event/331414/
momochi29
October 15, 2024
Tweet
Share
More Decks by momochi29
See All by momochi29
データのマスタが変わっても継続的に分析したい!
tjmtmmnk
1
230
初めてのデータ移行プロジェクトから得た学び
tjmtmmnk
0
980
Other Decks in Programming
See All in Programming
snacks.nvim内のセットアップ不要なプラグインを紹介 / introduce_snacks_nvim
uhooi
0
260
新卒から4年間、20年もののWebサービスと 向き合って学んだソフトウェア考古学
oguri
7
5.8k
気がついたら子供が社会人になって 自分と同じモバイルアプリエンジニアになった件 / Parent-Child Engineers
koishi
0
250
Introduction to C Extensions
sylph01
3
150
CTFのWebにおける⾼難易度問題について
hamayanhamayan
1
830
Duke on CRaC with Jakarta EE
ivargrimstad
0
1.1k
Cloudflare Pagesのサイトを NotebookLMから読みやすくする Cloudflare Meet-up Tokyo Vol.7
xiombatsg
0
100
安全に倒し切るリリースをするために:15年来レガシーシステムのフルリプレイス挑戦記
sakuraikotone
5
1.6k
英語文法から学ぶ、クリーンな設計の秘訣
newnomad
1
240
複数ドメインに散らばってしまった画像…! 運用中のPHPアプリに後からCDNを導入する…!
suguruooki
0
320
Lambdaの監視、できてますか?Datadogを用いてLambdaを見守ろう
nealle
2
980
AtCoder Heuristic First-step Vol.1 講義スライド(山登り法・焼きなまし法編)
takumi152
2
790
Featured
See All Featured
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
What's in a price? How to price your products and services
michaelherold
244
12k
Into the Great Unknown - MozCon
thekraken
35
1.7k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.2k
Adopting Sorbet at Scale
ufuk
75
9.3k
Product Roadmaps are Hard
iamctodd
PRO
51
11k
Site-Speed That Sticks
csswizardry
4
440
How to Think Like a Performance Engineer
csswizardry
22
1.4k
GraphQLの誤解/rethinking-graphql
sonatard
69
10k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
116
51k
The Cost Of JavaScript in 2023
addyosmani
48
7.6k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Transcript
いかにして不足・不整合 なくデータ移行したか 発表者: momochi29 1
自己紹介 id:momochi29 • データ移行の検証など • マンガメディア開発の チーム歴は5年程度 • 「ワールドトリガー」 が好き
2
ゴール ユーザから見て移管前後でデータが変わって いない 3
そのためには? 本番移行までに 移行時の直すべきエラー・原因不明のエラー をすべて洗い出し、解消する 4
全体像 5
サイクルの全体像 移行 検証 エラー 修正 完了! エラーがない エラーがある 6
サイクルの全体像 移行 検証 エラー 修正 完了! エラーがない エラーがある 7
サイクルの全体像 移行 検証 エラー 修正 完了! エラーがない エラーがある ここを話します 8
検証 9
検証が必要な背景 期間1 エラーなし 期間2 エラーなし ・・・ データ移行(分割移行) 10
検証が必要な背景 期間1 エラーなし 期間2 エラーなし ・・・ 期間ごとにエラーがないので おそらく不整合はないだろう データ移行(分割移行) 11
検証が必要な背景 期間1 エラーなし 期間2 エラーなし ・・・ 期間ごとにエラーがないので おそらく不整合はないだろう データ移行(分割移行) ユーザ単位ですべてのデータに不整合
がないことは保証できていない 12
検証が必要な背景 期間1 エラーなし 期間2 エラーなし ・・・ 期間ごとにエラーがないので おそらく不整合はないだろう データ移行(分割移行) そもそも…
移行処理にバグがあってデグレしてい るかもしれない 13
検証が必要な背景 1. ユーザ単位ですべてのデータに不整合がない ことを保証できていない 2. 移行処理にバグがあってデグレしているかも しれない 14
何を検証するのか 1. ユーザに対する検証 2. 移行自体に対する検証 15
ユーザに対する検証 • ユーザが持っているデータが移行前後で変化 していないことをユーザごとに検証する 16
ユーザに対する検証 • ズレるとユーザに不利益がある箇所を重点的 に検証する ◦ 例) レンタル期限が一致するか ▪ ズレるとレンタルしていたはずの話が読めなくなったり… 17
移行自体に対する検証 • 移行が仕様通りに実装されているかを検証す る 18
仕様通りに実装されているかの検証 移行元テーブル 移行先テーブル 移行先テーブル ︙ 変換ルールに則って移行 19
移行元テーブル 移行先テーブル 移行先テーブル ︙ 変換ルールに則って移行 単体テストによって ルールに従っている か検証している 仕様通りに実装されているかの検証 20
移行元テーブル 移行先テーブル 移行先テーブル ︙ 変換ルールに則って移行 単体テストによって ルールに従っている か検証している 仕様通りに実装されているかの検証 これで充分?
21
仕様通りに実装されているかの検証 • No • 移行処理に実装漏れがあると、テストが存在 しないので仕様に従っているか確認されない ◦ 移行先観点でのテストになるので漏れやすい 22
仕様通りに実装されているかの検証 移行元テーブル 移行先テーブル 変換ルールに則って移行 移行先テーブルから 移行元テーブルを再現できる か検証する 23
テーブルの再現による検証 • 移行先のテーブルからデータを集めて変換 ルールを適用して移行元のテーブルを作る • これによって移行元との差分がわかり、移行 漏れを無くせる 24
検証失敗時には? • エラーを記録する • 分類しやすいようにフォーマットを統一 25
直す価値のあるエラーを得る • 直す価値のあるエラーとは、直さないと本番 環境でも発生するエラー • 移行元の本番環境のスナップショットを使っ て、移行→検証することで価値のあるエラー を得る 26
検証を動かす • データ移行を動かしているStep Functions + AWS Batchに検証ジョブを追加した ◦ 数百の検証ジョブを並行で動かすことで十分高速に検 証できた
• ただ、リソース上の問題があったのでチュー ニングした 27
検証のチューニング • 移行に利用しているDBのCPU使用率が張り付 いている ◦ → 検証は読み込み専用DBを使う • 検証のタスクがOOM ◦
→ メモリ使用量の上限を引き上げ ◦ → あえてN+1にする 28
エラー修正 29
エラー修正 • エラー数を0にするのがゴール • 多種多様なエラーをうまくハンドリングする には? 30
エラーフォーマットの統一 • ジョブの種類 • エラーメッセージ • エラーコード ◦ レコードが存在しない、一致しないの2種類 •
デバッグのために必要な情報 ◦ エラーになった場所、レコードのID 31
CloudWatch Logs Insights • ジョブの種類、エラーごとに first_seen, last_seen, エラー総数を出す 32
CloudWatch ダッシュボード • Logs Insightsで作ったクエリの実行結果を集 約できる • ここだけ見ればオッケーにできる ◦ 移行・検証のエラーに対するクエリ結果と、その他に
必要な情報をウィジェットとして追加した 33
CloudWatch ダッシュボード 34
ゴールが数値で見える嬉しさ • 移行作業は長いトンネルを歩く感覚がある • エラー数が減るとゴールに近付いていること を実感できてよかった 35
修正サイクルを回す エラー 修正 移行 ダッシュ ボード 確認 エラーがある 完了! エラーがない
36
修正サイクルを回す エラー 修正 移行 ダッシュ ボード 確認 新規のエラー: first_seenから判断 既存のエラーが直っていない:
last_seenから判断 完了! エラーがない 37
あとはエラーがなくなる までひたすらやる 38
結果 • 本番環境での移行で未知のエラーに遭遇せず に移行を完了することができた ◦ 本番同等のデータを使ってエラーが無くなるまでサイ クルを回した賜物 • データ移行に起因する大きな問題はなかった 39
まとめ • ユーザに対する検証と移行自体に対する検証 の2面からの検証によって、不足・不整合なく 移行できた • 移行元の本番環境のデータを使って修正サイ クルを回すことで未知のエラーに遭遇するこ となく移行できた 40