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

by tkzwtks

Slide 1

Slide 1 text

データマイグレーションの成功戦略サービスリニューアルで失敗しないための実践ガイド株式会社はてな id:tkzwtks / 瀧澤崇 YAPC::Hakodate 2024

Slide 2

Slide 2 text

自己紹介 - id:tkzwtks（瀧澤崇） - 好きなCPANモジュール -List::UtilsBy - 普段はレガシーサービスを触ったり触らなかったりしています - アイコンはグランパスくんのぬいぐるみの写真です 2

Slide 3

Slide 3 text

あらすじ 3

Slide 4

Slide 4 text

あらすじ私はtkzwtks。現職入社以降、WebアプリケーションエンジニアとしてWebサービスの運用改善をガンガンやるぞって意気込んでいたけど、気がついたら新旧サービス間のデータ移行プロジェクトを次々担当することに！一体どうなっちゃうの〜？ 4

Slide 5

Slide 5 text

本日お話すること - これまで関わったデータ移行事例をご紹介しつつ、その経験によって得た「データ移行を成功に導くテクニック」をご紹介します - 個別の細かい話は結構割愛するので、ぜひ懇親会などでお話しましょう 5

Slide 6

Slide 6 text

ここでいうデータ移行とは - システムリニューアル等に伴う、旧システムから新システムへのデータ移動 -旧システムのデータを新システムでも使えるように移動 6

Slide 7

Slide 7 text

事例1: はてなダイアリー終了 7

Slide 8

Slide 8 text

事例1: はてなダイアリー終了 - はてなダイアリー -2003年にスタートしたブログサービス -2019年に終了 - ダイアリーを終了する上で、ダイアリーのコンテンツをはてなブログに移行するプロジェクト 8

Slide 9

Slide 9 text

移行にあたっての課題 - ダイアリーからブログに移行する仕組み自体は存在していた - 移行していないダイアリーをはてなブログに移行する - ということをブログをサービスしながら進める必要がある -停止メンテは極力なし 9

Slide 10

Slide 10 text

まず見積もりから始める - 見積もりのためにデータ量を把握するところから -移行にどれくらい時間がかかるか等が一切わからなかった - ダイアリーごとにテーブルが作られる仕様だったため、データ量の把握が難しい -データ量を把握するためだけのスクリプトを実装して実行 - 大変だったがこれが後で効いた 10

Slide 11

Slide 11 text

移行処理 - 元々の移行処理を利用したので、ダイアリー単位で移行を実行 -移行処理のワークフローを作り、複数ダイアリーを並列に移行 -TheSchwartz + WorkerManager - ワークフローといっても前工程の最後に次工程のジョブを入れるだけ 11

Slide 12

Slide 12 text

移行処理 - 全体の進捗管理はDB -移行対象のダイアリーを全て登録 -実行前/完了/失敗のダイアリーを管理 - エントリは直列で移行するようになっていた -人によってエントリ数が違うため、処理時間も変わる 12

Slide 13

Slide 13 text

2019年7月に完了 13

Slide 14

Slide 14 text

わかったこと - 見積もりの精度は高くなかったが、ざっくりとでも見積もりを立てることで進捗管理がしやすくなる - 移行単位ごとにデータ量が変わってしまうことがあり、その結果全体の移行見積もりが難しくなる - WorkerManagerはスケールさせるのが少し面倒 - 並列数の調整をしたくなることがある 14

Slide 15

Slide 15 text

無事終わりほっとしたのも束の間、次のデータ移行プロジェクトが tkzwtksを待っていたのであった 15

Slide 16

Slide 16 text

事例2: 魔法のiらんど - KADOKAWA様が運営する「女の子のための小説サイト」 - 2020年3月にリニューアル -ここで新システムに移行 16

Slide 17

Slide 17 text

主な課題 - 物量 -約20年分のユーザーデータ・小説を新システムに移行 - データ間の依存関係 -作者に紐づく作品数、作品に紐づくエピソード数が違う -データ移行そのものにかかる時間が読みづらい 17

Slide 18

Slide 18 text

技術的な要求 - 依存するデータを順番に移行したい -前が終わったら次の処理を開始してほしい - 並列に移行処理を進行したい -移行時間を短くしたい -イテレーション回数を増やしたい 18

Slide 19

Slide 19 text

前回を振り返ってみる - WorkerManager + TheSchwartzはやめたい -並列数の調整でプロセスの再起動が必要になる -スケールさせるのがやや面倒 19

Slide 20

Slide 20 text

前回を振り返ってみる - ワークフローは自分で用意したくない -前回は一本道だったので問題なかった -魔法のiらんどはデータの種類も多いので、依存しないなら並行して移行したい 20

Slide 21

Slide 21 text

ユーザーごとで並列にするのは"遅い" - ユーザーによって作品数・エピソード数が違う -並列に移行したとしても、かかる時間はエピソード数などが多いユーザーに律速される -全体の進捗も追いづらい - 速く移行するにはどうしたら... 21

Slide 22

Slide 22 text

依存データを先に全部移したらいいのでは - ユーザーごとに移行したいのは依存データが先に移行されている必要があるから - ということは、依存するデータを全部移行してから次のステップに進んだらいいのでは？ -そういうワークフローを作る - これはなんかうまくいきそう 22

Slide 23

Slide 23 text

「スケールしたい時に自動でスケールしてほしいな〜。実行ごとに引数を変えられて、依存を考慮しながら順次移行してくれて、一部は並行して実行したいな〜。そんなことができるソリューションはないかな〜」 23

Slide 24

Slide 24 text

そこでAWS Batch + StepFunctions + S3 24

Slide 25

Slide 25 text

AWS Batch + StepFunctions + S3 - AWS Batch -フルマネージド型バッチ処理サービス -動的にリソースをプロビジョニングしてくれる - AWS StepFunctions -サーバーレスでワークフローを設計・実行できる -AWSのサービスと連携しやすい 25

Slide 26

Slide 26 text

AWS Batch + StepFunctions + S3 - 進捗管理はS3+JSONファイル -実行状態はS3のキーで表現し、各処理にはS3のキーだけ渡す - ツリー構造にして、キーの一部で移行前・成功・失敗などの状態を表現 -/target=episode/status=ready/abcdefg.... のような -中身は移行対象のデータのプライマリキーと移行先のマップ - S3のキーの一覧を取得して数えるだけで現時点の進捗がわかる 26

Slide 27

Slide 27 text

AWS Batch + StepFunctions + S3 - AWS StepFunctionsでワークフローを作る -依存関係のあるマイグレーションを順に実行していく -タスクでAWS Batchをキック -Mapを利用してS3のキーをタスクに渡す 27

Slide 28

Slide 28 text

Map - この作戦の肝とも言える部分 - JSON配列を入力とし、、配列要素を MapのそれぞれのIterationに渡す - 各Iterationは同期的に実行可能 - Iterationが終了した後、配列に要素が残っていれば次のIterationを実行 28

Slide 29

Slide 29 text

最終的な作戦 - 並列実行可能な単位でグルーピングしてバッチサイズをできるだけ揃える -依存するデータは前のステップで移行されていれば、「誰の作品か」とか「どのエピソードか」とかが関係なくなる - バッチサイズを揃えることで移行対象数に差がある場合のバラつきを減らす - これにより移行時間の見積もりもシンプルに -(キーの数 / 最大並列数) * 1バッチあたりの処理時間 -一部サンプリングして移行した結果を利用して見積もりできた 29

Slide 30

Slide 30 text

ステートマシン - ステートマシンを二段構成にする - 各工程を親で管理し、細かい処理は子に寄せる - 親ステートマシン - 工程間の依存を管理する 30

Slide 31

Slide 31 text

ステートマシン - 子ステートマシン - 細かい処理はこちらに書かれている - batchジョブをMapで並列に発行し、終了を待つ 31

Slide 32

Slide 32 text

得られたもの - 移行処理の実装をシンプルにできる -指定のプライマリキーのデータをbulk insertしていけばよい - ワークフローと移行処理を分離できる -動作確認しやすい -テストも書きやすい 32

Slide 33

Slide 33 text

得られたもの - 失敗時のリトライ範囲を最小限にできる -処理が冪等である前提だが -失敗した範囲のキーだけなんらか修正後再実行すればよい 33

Slide 34

Slide 34 text

これは結構うまくいった - AWS Batchを使う方法はダイアリー移行の時点でも考えていたが、その時は見送り、このタイミングで採用できた - できるだけ並列移行できたため、最初想定していたスピードよりも早く実行できた - StepFunctionsは最初は見送ろうと思っていたが、このタイミングでMapが使えるようになったので採用した 34

Slide 35

Slide 35 text

さらに - 新たなテクニックを試すこともできた -移行先がRDSだったので、ある工程まで終わったらRDSのスナップショットを取っておく -一部移行をやり直したいとなった場合でも、違う種類のデータが混じらないのでバックアップから再開可能 35

Slide 36

Slide 36 text

反省点もあった - 本当にもれなく移行できたか、正しく移行できたかの検証 -移行前後で数が変わるわけではないので、移行元と移行先の件数を比較することでOKとした -一部をサンプリングして検証して、問題なければOKとしていた - レコード数は合っていたし、サンプリング検証も問題なかったが、もう一歩踏み込んだ検証ができたのでは、とも考えた 36

Slide 37

Slide 37 text

無事に終了し、リニューアル完了 37

Slide 38

Slide 38 text

大規模データ移行が終わって一安心していたtkzwtks。しかし数年後、また新たなデータ移行プロジェクトがtkzwtksを待っていたのであった 38

Slide 39

Slide 39 text

実例3: 少年ジャンプʴ - 集英社の少年ジャンプʴ編集部様が運営するマンガサービス - ブラウザ版は2017年よりはてなが運用している - 2024年3月にアプリにもはてなのGigaViewer for Appsを提供 -そのタイミングでシステムもはてなのシステムに移管 39

Slide 40

Slide 40 text

課題 - 物量 -ユーザー数が非常に多い(累計2700万DLを超えている) -漫画の購入履歴、閲覧履歴、定期購読情報など - メンテナンスウィンドウをできるだけ短くしたい -売り上げに直結する - 確実な移行 -サービスの信頼性に直結する 40

Slide 41

Slide 41 text

移行そのものは前と同じように進める - 魔法のiらんどと同様のやり方で依存するデータを順次移行 -お互いに依存しないデータは並行して移行 - （細かくは触れないが）変更されないデータは停止メンテナンス前に事前移行する -購入履歴等 41

Slide 42

Slide 42 text

確実に移行したことを検証したい - 購入履歴等、信頼性に直結するデータが多く、確実に移行されなければならない - 今回は「確実に移行されたことを検証する」役目をメインとして参加した 42

Slide 43

Slide 43 text

移行後の検証について考えるチャンス到来 43

Slide 44

Slide 44 text

全件検証する全ユーザーに対して、ユーザーごとに新旧のデータを参照する - データが存在していることを検証 - 旧システムのデータを変換し、想定した変換になっていることを検証 - 参照がメインなので移行よりも時間はかからない 44

Slide 45

Slide 45 text

2024年3月に完了 45

Slide 46

Slide 46 text

冒頭の「どうなっちゃうの〜」はどうなっちゃったか 46

Slide 47

Slide 47 text

何度か経験することで、データ移行プロジェクトの進め方・勝ちパターンが見えてきた 47

Slide 48

Slide 48 text

新システムへのデータ移行やるべきことは - 旧システムと新システム間のギャップを把握し - ギャップを埋めつつ確実に新システムに移行する 48

Slide 49

Slide 49 text

データ移行は準備が9割 49

Slide 50

Slide 50 text

データ移行は準備が9割 - 現状を把握する -移行元データの種類・構造・量 -移行先システム - 見積もりを行う -量をベースにかかる時間を見積もる 50

Slide 51

Slide 51 text

データ移行は準備が9割 - 計画を立てる -移行の進め方・手順 -停止メンテナンスの有無 - 移行の準備をする -移行ロジックの実装 -進捗管理の仕組みを用意 51

Slide 52

Slide 52 text

データ移行は準備が9割 - 移行する -準備をすればするほど安心 - 検証する -要求レベルにもよるが、全件検証できるならそれが確実 52

Slide 53

Slide 53 text

データの「把握」は考古学 - 基本はスキーマや仕様を見る、でよいが... - 定義から想像できないデータが出てくることもある -NOT NULLのカラムに空文字/統一された謎の文字列 -なぜか2030年のデータがある 53

Slide 54

Slide 54 text

データの「把握」は考古学 - 長年運用されているとスキーマだけではわからないものが必ず存在する -運用・改善していく上でこういうのはやりがち -調査・把握 → 移行・検証のを繰り返すしかない - こういうデータを作らないように務めるのも重要 -あなたがいなくなってもデータは残る -データ移行だけの話でない、日々の改善にもつながる話 54

Slide 55

Slide 55 text

まとめ 55

Slide 56

Slide 56 text

まとめ - 旧システムから新システムへデータを移行するとなった場合の進め方について、実例と実際にやったことを紹介した -よくあるWebサービス開発と似ているが、考慮した方がいい範囲が少し違う - サービスを未来につなぐために、システム刷新することもあるはずで、その時に思い出してもらえると幸い 56