データマイグレーションの成功戦略~サービスリニューアルで失敗しないための実践ガイド~

Transcript

1. データマイグレーションの成功戦略 サービスリニューアルで失敗しないための実践ガイド 株式会社はてな id:tkzwtks / 瀧澤崇 YAPC::Hakodate 2024
2. 自己紹介 - id:tkzwtks（瀧澤 崇） - 好きなCPANモジュール -List::UtilsBy - 普段はレガシーサービスを触ったり触らなかっ たりしています - アイコンはグランパスくんのぬいぐるみの写真 です 2
3. あらすじ 3
4. あらすじ 私はtkzwtks。現職入社以降、Webアプリケーションエンジニア としてWebサービスの運用改善をガンガンやるぞって意気込んで いたけど、気がついたら新旧サービス間のデータ移行プロジェク トを次々担当することに！一体どうなっちゃうの〜？ 4
5. 本日お話すること - これまで関わったデータ移行事例をご紹介しつつ、その経験に よって得た「データ移行を成功に導くテクニック」をご紹介し ます - 個別の細かい話は結構割愛するので、ぜひ懇親会などでお話し ましょう 5
6. ここでいうデータ移行とは - システムリニューアル等に伴う、旧システムから新システムへ のデータ移動 -旧システムのデータを新システムでも使えるように移動 6
7. 事例1: はてなダイアリー終了 7
8. 事例1: はてなダイアリー終了 - はてなダイアリー -2003年にスタートしたブログサービス -2019年に終了 - ダイアリーを終了する上で、ダイアリーのコンテンツをはてな ブログに移行するプロジェクト 8
9. 移行にあたっての課題 - ダイアリーからブログに移行する仕組み 自体は存在していた - 移行していないダイアリーをはてなブロ グに移行する - ということをブログをサービスしながら 進める必要がある -停止メンテは極力なし 9
10. まず見積もりから始める - 見積もりのためにデータ量を把握するところから -移行にどれくらい時間がかかるか等が一切わからなかった - ダイアリーごとにテーブルが作られる仕様だったため、データ量 の把握が難しい -データ量を把握するためだけのスクリプトを実装して実行 - 大変だったがこれが後で効いた 10
11. 移行処理 - 元々の移行処理を利用したので、ダイアリー単位で移行を実行 -移行処理のワークフローを作り、複数ダイアリーを並列に移行 -TheSchwartz + WorkerManager - ワークフローといっても前工程の最後に次工程のジョブを入れ るだけ 11
12. 移行処理 - 全体の進捗管理はDB -移行対象のダイアリーを全て登録 -実行前/完了/失敗のダイアリーを管理 - エントリは直列で移行するようになっていた -人によってエントリ数が違うため、処理時間も変わる 12
13. 2019年7月に完了 13
14. わかったこと - 見積もりの精度は高くなかったが、ざっくりとでも見積もりを 立てることで進捗管理がしやすくなる - 移行単位ごとにデータ量が変わってしまうことがあり、その結 果全体の移行見積もりが難しくなる - WorkerManagerはスケールさせるのが少し面倒 - 並列数の調整をしたくなることがある 14
15. 無事終わりほっとしたのも束の間、 次のデータ移行プロジェクトが tkzwtksを待っていたのであった 15
16. 事例2: 魔法のiらんど - KADOKAWA様が運営する「女の子のための小説サイト」 - 2020年3月にリニューアル -ここで新システムに移行 16
17. 主な課題 - 物量 -約20年分のユーザーデータ・小説を新システムに移行 - データ間の依存関係 -作者に紐づく作品数、作品に紐づくエピソード数が違う -データ移行そのものにかかる時間が読みづらい 17
18. 技術的な要求 - 依存するデータを順番に移行したい -前が終わったら次の処理を開始してほしい - 並列に移行処理を進行したい -移行時間を短くしたい -イテレーション回数を増やしたい 18
19. 前回を振り返ってみる - WorkerManager + TheSchwartzはやめたい -並列数の調整でプロセスの再起動が必要になる -スケールさせるのがやや面倒 19
20. 前回を振り返ってみる - ワークフローは自分で用意したくない -前回は一本道だったので問題なかった -魔法のiらんどはデータの種類も多いので、依存しないなら並 行して移行したい 20
21. ユーザーごとで並列にするのは"遅い" - ユーザーによって作品数・エピソード数が違う -並列に移行したとしても、かかる時間はエピソード数などが多 いユーザーに律速される -全体の進捗も追いづらい - 速く移行するにはどうしたら... 21
22. 依存データを先に全部移したらいいのでは - ユーザーごとに移行したいのは依存データが先 に移行されている必要があるから - ということは、依存するデータを全部移行して から次のステップに進んだらいいのでは？ -そういうワークフローを作る - これはなんかうまくいきそう 22
23. 「スケールしたい時に自動でスケー ルしてほしいな〜。実行ごとに引数 を変えられて、依存を考慮しながら 順次移行してくれて、一部は並行し て実行したいな〜。そんなことがで きるソリューションはないかな〜」 23
24. そこでAWS Batch + StepFunctions + S3 24
25. AWS Batch + StepFunctions + S3 - AWS Batch -フルマネージド型バッチ処理サービス -動的にリソースをプロビジョニングしてくれる - AWS StepFunctions -サーバーレスでワークフローを設計・実行できる -AWSのサービスと連携しやすい 25
26. AWS Batch + StepFunctions + S3 - 進捗管理はS3+JSONファイル -実行状態はS3のキーで表現し、各処理にはS3のキーだけ渡す - ツリー構造にして、キーの一部で移行前・成功・失敗などの状態を表現 -/target=episode/status=ready/abcdefg.... のような -中身は移行対象のデータのプライマリキーと移行先のマップ - S3のキーの一覧を取得して数えるだけで現時点の進捗がわかる 26
27. AWS Batch + StepFunctions + S3 - AWS StepFunctionsでワークフローを作る -依存関係のあるマイグレーションを順に実行していく -タスクでAWS Batchをキック -Mapを利用してS3のキーをタスクに渡す 27
28. Map - この作戦の肝とも言える部分 - JSON配列を入力とし、、配列要素を MapのそれぞれのIterationに渡す - 各Iterationは同期的に実行可能 - Iterationが終了した後、配列に要素が 残っていれば次のIterationを実行 28
29. 最終的な作戦 - 並列実行可能な単位でグルーピングしてバッチサイズをできるだけ揃える -依存するデータは前のステップで移行されていれば、「誰の作品か」とか 「どのエピソードか」とかが関係なくなる - バッチサイズを揃えることで移行対象数に差がある場合のバラつきを減らす - これにより移行時間の見積もりもシンプルに -(キーの数 / 最大並列数) * 1バッチあたりの処理時間 -一部サンプリングして移行した結果を利用して見積もりできた 29
30. ステートマシン - ステートマシンを二段構成にする - 各工程を親で管理し、細かい処理は 子に寄せる - 親ステートマシン - 工程間の依存を管理する 30
31. ステートマシン - 子ステートマシン - 細かい処理はこちらに書かれている - batchジョブをMapで並列に発行 し、終了を待つ 31
32. 得られたもの - 移行処理の実装をシンプルにできる -指定のプライマリキーのデータをbulk insertしていけばよい - ワークフローと移行処理を分離できる -動作確認しやすい -テストも書きやすい 32
33. 得られたもの - 失敗時のリトライ範囲を最小限にできる -処理が冪等である前提だが -失敗した範囲のキーだけなんらか修正後再実行すればよい 33
34. これは結構うまくいった - AWS Batchを使う方法はダイアリー移行の時点でも考えていた が、その時は見送り、このタイミングで採用できた - できるだけ並列移行できたため、最初想定していたスピードよ りも早く実行できた - StepFunctionsは最初は見送ろうと思っていたが、このタイミ ングでMapが使えるようになったので採用した 34
35. さらに - 新たなテクニックを試すこともできた -移行先がRDSだったので、ある工程まで終わったらRDSのスナ ップショットを取っておく -一部移行をやり直したいとなった場合でも、違う種類のデータ が混じらないのでバックアップから再開可能 35
36. 反省点もあった - 本当にもれなく移行できたか、正しく移行できたかの検証 -移行前後で数が変わるわけではないので、移行元と移行先の件 数を比較することでOKとした -一部をサンプリングして検証して、問題なければOKとしていた - レコード数は合っていたし、サンプリング検証も問題なかった が、もう一歩踏み込んだ検証ができたのでは、とも考えた 36
37. 無事に終了し、リニューアル完了 37
38. 大規模データ移行が終わって一安心 していたtkzwtks。しかし数年後、 また新たなデータ移行プロジェクト がtkzwtksを待っていたのであった 38
39. 実例3: 少年ジャンプʴ - 集英社の少年ジャンプʴ編集部様が運営するマンガサービス - ブラウザ版は2017年よりはてなが運用している - 2024年3月にアプリにもはてなのGigaViewer for Appsを提供 -そのタイミングでシステムもはてなのシステムに移管 39
40. 課題 - 物量 -ユーザー数が非常に多い(累計2700万DLを超えている) -漫画の購入履歴、閲覧履歴、定期購読情報など - メンテナンスウィンドウをできるだけ短くしたい -売り上げに直結する - 確実な移行 -サービスの信頼性に直結する 40
41. 移行そのものは前と同じように進める - 魔法のiらんどと同様のやり方で依存するデータを順次移行 -お互いに依存しないデータは並行して移行 - （細かくは触れないが）変更されないデータは停止メンテナン ス前に事前移行する -購入履歴等 41
42. 確実に移行したことを検証したい - 購入履歴等、信頼性に直結するデータが多く、確実に移行され なければならない - 今回は「確実に移行されたことを検証する」役目をメインとし て参加した 42
43. 移行後の検証について 考えるチャンス到来 43
44. 全件検証する 全ユーザーに対して、ユーザーごとに新旧のデータを参照する - データが存在していることを検証 - 旧システムのデータを変換し、想定した変換になっていること を検証 - 参照がメインなので移行よりも時間はかからない 44
45. 2024年3月に完了 45
46. 冒頭の「どうなっちゃうの〜」はど うなっちゃったか 46
47. 何度か経験することで、データ移行 プロジェクトの進め方・勝ちパター ンが見えてきた 47
48. 新システムへのデータ移行 やるべきことは - 旧システムと新システム間のギャップを把握し - ギャップを埋めつつ確実に新システムに移行する 48
49. データ移行は準備が9割 49
50. データ移行は準備が9割 - 現状を把握する -移行元データの種類・構造・量 -移行先システム - 見積もりを行う -量をベースにかかる時間を見積もる 50
51. データ移行は準備が9割 - 計画を立てる -移行の進め方・手順 -停止メンテナンスの有無 - 移行の準備をする -移行ロジックの実装 -進捗管理の仕組みを用意 51
52. データ移行は準備が9割 - 移行する -準備をすればするほど安心 - 検証する -要求レベルにもよるが、全件検証できるならそれが確実 52
53. データの「把握」は考古学 - 基本はスキーマや仕様を見る、でよいが... - 定義から想像できないデータが出てくることもある -NOT NULLのカラムに空文字/統一された謎の文字列 -なぜか2030年のデータがある 53
54. データの「把握」は考古学 - 長年運用されているとスキーマだけではわからないものが必ず存在する -運用・改善していく上でこういうのはやりがち -調査・把握 → 移行・検証のを繰り返すしかない - こういうデータを作らないように務めるのも重要 -あなたがいなくなってもデータは残る -データ移行だけの話でない、日々の改善にもつながる話 54
55. まとめ 55
56. まとめ - 旧システムから新システムへデータを移行するとなった場合の 進め方について、実例と実際にやったことを紹介した -よくあるWebサービス開発と似ているが、考慮した方がいい範 囲が少し違う - サービスを未来につなぐために、システム刷新することもある はずで、その時に思い出してもらえると幸い 56