初めてのデータ移行プロジェクトから得た学び

2023/1/25 Hatena Engineer Seminar #23
https://hatena.connpass.com/event/271696/

Transcript

1. 初めてのデータ移行 プロジェクトから得た学び id: momochi29 2023/1/25 Hatena Engineer Seminar #23 1
2. プロフィール • id: momochi29 • 所属: マンガメディア開発 • 職種: Webアプリケーション エンジニア • 2022年4月入社 2
3. プロジェクト背景 • あるサービスが終了する • ユーザー情報と課金契約を移行する必要がある • 移行日はユーザーに告知済みで必達 3
4. 特に難しかったポイント • 不確実性が高い • 自信を持って移行したい 4
5. 不確実性が高い 5
6. 不確実性を高める要因 • 何もかも初めて ◦ 課金、データ移行の知識／経験がない • 移行日はずらせない • 実現可能なのかわかっていない ◦ 課金契約を移行した前例がない 6
7. 不確実性を高める要因 • 何もかも初めて ◦ 課金、データ移行の知識／経験がない • 移行日はずらせない • 実現可能なのかわかっていない ◦ 課金契約を移行した前例がない 7
8. 不確実性を下げるには？ • 何もかも初めて → 詳しい人と協力する？ ◦ 課金、データ移行の知識／経験がない • 移行日はずらせない • 実現可能なのかわかっていない ◦ 課金契約を移行した前例がない 8
9. 一人でやるのは難しそう 9 • エッジケースが多い ◦ ドメイン知識が強く要求される • 間に合わなさそう ◦ 見積もりをして消化具合を見る ▪ 例) バーンアップチャート
10. 助けを求める 10 • 増員をお願いする ◦ エントリに現状を書いて増員をお願いした • ドメイン知識を持った人に聞く ◦ 壁打ちで高速に知識を得る ◦ 移行時の考慮漏れを減らす
11. 不確実性を下げるには？ • 何もかも初めて → 詳しい人と協力する？ ◦ 課金、データ移行の知識／経験がない • 移行日はずらせない • 実現可能なのかわかっていない ◦ 課金契約を移行した前例がない 11
12. 不確実性を下げるには？ • 何もかも初めて → 詳しい人と協力する？ ◦ 課金、データ移行の知識／経験がない • 移行日はずらせない → 本当にずらせない？ • 実現可能なのかわかっていない ◦ 課金契約を移行した前例がない 12
13. 移行に使える時間は限られている 13 • 移行に使える時間は多くない ◦ 移行完了の時間が決まっている • 移行だけをやればいいわけではない ◦ 何かしらミスが発生する ◦ リカバリの時間も必要 やることを最小にして確実に終わるスケジュールを組みたい
14. 移行日にやることを最小化する 14 • かたまり毎に分割して移行する ◦ ユーザー情報移行フェーズ ◦ 課金契約移行フェーズ • 移行日に何を移行したいかを明確にする ◦ ユーザー情報の移行は移行日前でも可能とわかった • 移行日を調整する ◦ 関係者が多いのでコミュニケーション役が1人いると良い
15. 不確実性を下げるには？ • 何もかも初めて → 詳しい人と協力する？ ◦ 課金、データ移行の知識／経験がない • 移行日はずらせない → 本当にずらせない？ • 実現可能なのかわかっていない ◦ 課金契約を移行した前例がない 15
16. 不確実性を下げるには？ • 何もかも初めて → 詳しい人と協力する？ ◦ 課金、データ移行の知識／経験がない • 移行日はずらせない → 本当にずらせない？ • 実現可能なのかわかっていない → プロトタイプ作る？ ◦ 課金契約を移行した前例がない 16
17. • まずは実現できそうかを 知りたい ◦ 実装したあとにダメとわか るのは悲しい • 不確実性の高いものから 取り組む ◦ 不確実性が高い ≒ 難しい ので大変なのは事実 ◦ 実現できるかわからない不 安を解消する あとはやるだけにしたい 17 https://xtech.nikkei.com/it/article/COLUMN/20131001/508039/ より引用 不確実性コーン
18. プロトタイプを2回作る 18 • 1回目: 繋がりを確認して自分が納得するため ◦ 自分の中で実装のイメージを付けることが目的 ◦ どれだけ適当でも気にしないしテストも不要 • 2回目: ちゃんと考えてみんなが納得するため ◦ ソースコードレベルで議論することが目的 ◦ 本気で命名や処理を考えるけどテストはなくても良い 1回目で素早く実現可能性を検証し、2回目で品質の高い実装をする
19. 不確実性を下げることができた • 何もかも初めて ◦ → 仲間を頼ってプロジェクト全体の不確実性を下げる • 移行日はずらせない ◦ → 移行日に移行するものを明確して移行時の不確実性を下げる • 実現可能なのかわかっていない ◦ → プロトタイプを作って実装時の不確実性を下げる 19
20. もっとうまくやるなら • もっと早く助けを求めるとより良かった ◦ 投機的に増員してもらうのがよかった ◦ 増員して早く終われば解散すればいいだけ 20
21. 自信を持って移行したい 21
22. 不安がつきない • 移行時に課金が発生するのでミスできない • 漏れなく全員移行できるかな • etc… 22
23. どうしたら自信を持てる？ • 移行の状態を人間が管理しなくて良い • 何回実行しても壊れない • 本番環境で問題ないか事前に知りたい 23
24. どうしたら自信を持てる？ • 移行の状態を人間が管理しなくて良い • 何回実行しても壊れない • 本番環境で問題ないか事前に知りたい 24
25. どうしたら自信を持てる？ • 移行の状態を人間が管理しなくて良い → 状態を記録する？ • 何回実行しても壊れない • 本番環境で問題ないか事前に知りたい 25
26. すべての状態を記録する必要性 • 成功か失敗かだけわかればいい？ ◦ 例) 移行後に成功／失敗をファイルに出力する • リカバリが必要になったら？ ◦ リカバリしたら失敗から成功に遷移する ◦ 数が増えれば増えるほど状態が複雑になる 26
27. 移行用のテーブルを作る • 移行用のテーブルを作る ◦ 移行のために必要な情報 ◦ 移行フェーズごとで得た情報 ▪ 例) 課金契約移行が成功したら課金情報が得られる ◦ 移行ステータス ▪ 移行フェーズごとに成功／失敗が記録される ◦ エラーコード ▪ 例) 課金時にクレジットカードが不正でエラーになった • 追記専用で更新はしない ◦ 更新すると情報が失われる ◦ 操作した記録をすべて残す 27
28. どうしたら自信を持てる？ • 移行の状態を人間が管理しなくて良い → 状態を記録する？ • 何回実行しても壊れない • 本番環境で問題ないか事前に知りたい 28
29. どうしたら自信を持てる？ • 移行の状態を人間が管理しなくて良い → 状態を記録する？ • 何回実行しても壊れない → 冪等性を持たせる？ • 本番環境で問題ないか事前に知りたい 29
30. 冪等性を持たせる • 移行処理全体を冪等にする • 課金処理を冪等にする 30
31. 移行処理全体を 冪等にする • ステートマシンを 実装 ◦ 処理ごとに成功/失敗の 状態を遷移 ◦ 処理対象の状態以外は 対象にならないことを 保証 31 ステートマシン
32. 課金処理の事情 • 課金契約を外部 サービスと連携し ている ◦ 気を付けないと不整合 が発生する 32 外部サービスとの連携
33. 課金処理を 冪等にする • どこでロールバック しても状態がずれな いようにする ◦ 処理の順番に気を付ける ◦ 2相コミットを利用する 33 2相コミット
34. どうしたら自信を持てる？ • 移行の状態を人間が管理しなくて良い → 状態を記録する？ • 何回実行しても壊れない → 冪等性を持たせる？ • 本番環境で問題ないか事前に知りたい 34
35. どうしたら自信を持てる？ • 移行の状態を人間が管理しなくて良い → 状態を記録する？ • 何回実行しても壊れない → 冪等性を持たせる？ • 本番環境で問題ないか事前に知りたい → 本番環境で確認する？ 35
36. 本番環境で事前に検証する • テスト用のアカウントを用意する ◦ 必要な分だけ用意する ▪ 同値分割、境界値分析の要領 • 移行にかかる時間を計測する ◦ 当日の移行に必要な時間を見積もる ▪ 計測した結果を平均処理時間として並列数を考慮して見積もり 36
37. 自信を持って移行できた • 移行の状態を人間が管理しなくて良い ◦ → 状態がすべて記録されているので漏れはないだろう • 何回実行しても壊れない ◦ → 移行できるものしか移行できないので安心して実行できる • 本番環境で問題ないか知りたい ◦ → 事前に本番環境で動いたので大丈夫だろう 37
38. もっとうまくやるなら • 移行用のテーブルに移行後も参照が必要な情報を持たせ てしまった ◦ 移行は完了したのに移行用のテーブルを削除できない ◦ TRY ▪ 移行後も参照が必要な情報は通常のテーブルに記録する ▪ 移行用のテーブルからデータを入れる 38
39. 振り返り 39
40. 振り返り • 仲間を頼ることも大事 ◦ 仲間じゃん ◦ 仲間を信じる ▪ 自分の仕事のスコープ外のことを考えすぎない ▪ 自分のやること、考えることを減らす • 移行プロジェクトは大変 ◦ 最低3人は必要 ▪ 1. コミュニケーション役 ▪ 2. 主担当 ▪ 3. 相談役 40