Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

momochi29
January 26, 2023

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

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

momochi29

January 26, 2023
Tweet

Other Decks in Technology

Transcript

  1. 初めてのデータ移行
    プロジェクトから得た学び
    id: momochi29
    2023/1/25 Hatena Engineer Seminar #23
    1

    View Slide

  2. プロフィール
    ● id: momochi29
    ● 所属: マンガメディア開発
    ● 職種: Webアプリケーション
    エンジニア
    ● 2022年4月入社
    2

    View Slide

  3. プロジェクト背景
    ● あるサービスが終了する
    ● ユーザー情報と課金契約を移行する必要がある
    ● 移行日はユーザーに告知済みで必達
    3

    View Slide

  4. 特に難しかったポイント
    ● 不確実性が高い
    ● 自信を持って移行したい
    4

    View Slide

  5. 不確実性が高い
    5

    View Slide

  6. 不確実性を高める要因
    ● 何もかも初めて
    ○ 課金、データ移行の知識/経験がない
    ● 移行日はずらせない
    ● 実現可能なのかわかっていない
    ○ 課金契約を移行した前例がない
    6

    View Slide

  7. 不確実性を高める要因
    ● 何もかも初めて
    ○ 課金、データ移行の知識/経験がない
    ● 移行日はずらせない
    ● 実現可能なのかわかっていない
    ○ 課金契約を移行した前例がない
    7

    View Slide

  8. 不確実性を下げるには?
    ● 何もかも初めて → 詳しい人と協力する?
    ○ 課金、データ移行の知識/経験がない
    ● 移行日はずらせない
    ● 実現可能なのかわかっていない
    ○ 課金契約を移行した前例がない
    8

    View Slide

  9. 一人でやるのは難しそう
    9
    ● エッジケースが多い
    ○ ドメイン知識が強く要求される
    ● 間に合わなさそう
    ○ 見積もりをして消化具合を見る
    ■ 例) バーンアップチャート

    View Slide

  10. 助けを求める
    10
    ● 増員をお願いする
    ○ エントリに現状を書いて増員をお願いした
    ● ドメイン知識を持った人に聞く
    ○ 壁打ちで高速に知識を得る
    ○ 移行時の考慮漏れを減らす

    View Slide

  11. 不確実性を下げるには?
    ● 何もかも初めて → 詳しい人と協力する?
    ○ 課金、データ移行の知識/経験がない
    ● 移行日はずらせない
    ● 実現可能なのかわかっていない
    ○ 課金契約を移行した前例がない
    11

    View Slide

  12. 不確実性を下げるには?
    ● 何もかも初めて → 詳しい人と協力する?
    ○ 課金、データ移行の知識/経験がない
    ● 移行日はずらせない → 本当にずらせない?
    ● 実現可能なのかわかっていない
    ○ 課金契約を移行した前例がない
    12

    View Slide

  13. 移行に使える時間は限られている
    13
    ● 移行に使える時間は多くない
    ○ 移行完了の時間が決まっている
    ● 移行だけをやればいいわけではない
    ○ 何かしらミスが発生する
    ○ リカバリの時間も必要
    やることを最小にして確実に終わるスケジュールを組みたい

    View Slide

  14. 移行日にやることを最小化する
    14
    ● かたまり毎に分割して移行する
    ○ ユーザー情報移行フェーズ
    ○ 課金契約移行フェーズ
    ● 移行日に何を移行したいかを明確にする
    ○ ユーザー情報の移行は移行日前でも可能とわかった
    ● 移行日を調整する
    ○ 関係者が多いのでコミュニケーション役が1人いると良い

    View Slide

  15. 不確実性を下げるには?
    ● 何もかも初めて → 詳しい人と協力する?
    ○ 課金、データ移行の知識/経験がない
    ● 移行日はずらせない → 本当にずらせない?
    ● 実現可能なのかわかっていない
    ○ 課金契約を移行した前例がない
    15

    View Slide

  16. 不確実性を下げるには?
    ● 何もかも初めて → 詳しい人と協力する?
    ○ 課金、データ移行の知識/経験がない
    ● 移行日はずらせない → 本当にずらせない?
    ● 実現可能なのかわかっていない → プロトタイプ作る?
    ○ 課金契約を移行した前例がない
    16

    View Slide

  17. ● まずは実現できそうかを
    知りたい
    ○ 実装したあとにダメとわか
    るのは悲しい
    ● 不確実性の高いものから
    取り組む
    ○ 不確実性が高い ≒ 難しい
    ので大変なのは事実
    ○ 実現できるかわからない不
    安を解消する
    あとはやるだけにしたい
    17
    https://xtech.nikkei.com/it/article/COLUMN/20131001/508039/ より引用
    不確実性コーン

    View Slide

  18. プロトタイプを2回作る
    18
    ● 1回目: 繋がりを確認して自分が納得するため
    ○ 自分の中で実装のイメージを付けることが目的
    ○ どれだけ適当でも気にしないしテストも不要
    ● 2回目: ちゃんと考えてみんなが納得するため
    ○ ソースコードレベルで議論することが目的
    ○ 本気で命名や処理を考えるけどテストはなくても良い
    1回目で素早く実現可能性を検証し、2回目で品質の高い実装をする

    View Slide

  19. 不確実性を下げることができた
    ● 何もかも初めて
    ○ → 仲間を頼ってプロジェクト全体の不確実性を下げる
    ● 移行日はずらせない
    ○ → 移行日に移行するものを明確して移行時の不確実性を下げる
    ● 実現可能なのかわかっていない
    ○ → プロトタイプを作って実装時の不確実性を下げる
    19

    View Slide

  20. もっとうまくやるなら
    ● もっと早く助けを求めるとより良かった
    ○ 投機的に増員してもらうのがよかった
    ○ 増員して早く終われば解散すればいいだけ
    20

    View Slide

  21. 自信を持って移行したい
    21

    View Slide

  22. 不安がつきない
    ● 移行時に課金が発生するのでミスできない
    ● 漏れなく全員移行できるかな
    ● etc…
    22

    View Slide

  23. どうしたら自信を持てる?
    ● 移行の状態を人間が管理しなくて良い
    ● 何回実行しても壊れない
    ● 本番環境で問題ないか事前に知りたい
    23

    View Slide

  24. どうしたら自信を持てる?
    ● 移行の状態を人間が管理しなくて良い
    ● 何回実行しても壊れない
    ● 本番環境で問題ないか事前に知りたい
    24

    View Slide

  25. どうしたら自信を持てる?
    ● 移行の状態を人間が管理しなくて良い → 状態を記録する?
    ● 何回実行しても壊れない
    ● 本番環境で問題ないか事前に知りたい
    25

    View Slide

  26. すべての状態を記録する必要性
    ● 成功か失敗かだけわかればいい?
    ○ 例) 移行後に成功/失敗をファイルに出力する
    ● リカバリが必要になったら?
    ○ リカバリしたら失敗から成功に遷移する
    ○ 数が増えれば増えるほど状態が複雑になる
    26

    View Slide

  27. 移行用のテーブルを作る
    ● 移行用のテーブルを作る
    ○ 移行のために必要な情報
    ○ 移行フェーズごとで得た情報
    ■ 例) 課金契約移行が成功したら課金情報が得られる
    ○ 移行ステータス
    ■ 移行フェーズごとに成功/失敗が記録される
    ○ エラーコード
    ■ 例) 課金時にクレジットカードが不正でエラーになった
    ● 追記専用で更新はしない
    ○ 更新すると情報が失われる
    ○ 操作した記録をすべて残す
    27

    View Slide

  28. どうしたら自信を持てる?
    ● 移行の状態を人間が管理しなくて良い → 状態を記録する?
    ● 何回実行しても壊れない
    ● 本番環境で問題ないか事前に知りたい
    28

    View Slide

  29. どうしたら自信を持てる?
    ● 移行の状態を人間が管理しなくて良い → 状態を記録する?
    ● 何回実行しても壊れない → 冪等性を持たせる?
    ● 本番環境で問題ないか事前に知りたい
    29

    View Slide

  30. 冪等性を持たせる
    ● 移行処理全体を冪等にする
    ● 課金処理を冪等にする
    30

    View Slide

  31. 移行処理全体を
    冪等にする
    ● ステートマシンを
    実装
    ○ 処理ごとに成功/失敗の
    状態を遷移
    ○ 処理対象の状態以外は
    対象にならないことを
    保証
    31
    ステートマシン

    View Slide

  32. 課金処理の事情
    ● 課金契約を外部
    サービスと連携し
    ている
    ○ 気を付けないと不整合
    が発生する
    32
    外部サービスとの連携

    View Slide

  33. 課金処理を
    冪等にする
    ● どこでロールバック
    しても状態がずれな
    いようにする
    ○ 処理の順番に気を付ける
    ○ 2相コミットを利用する
    33
    2相コミット

    View Slide

  34. どうしたら自信を持てる?
    ● 移行の状態を人間が管理しなくて良い → 状態を記録する?
    ● 何回実行しても壊れない → 冪等性を持たせる?
    ● 本番環境で問題ないか事前に知りたい
    34

    View Slide

  35. どうしたら自信を持てる?
    ● 移行の状態を人間が管理しなくて良い → 状態を記録する?
    ● 何回実行しても壊れない → 冪等性を持たせる?
    ● 本番環境で問題ないか事前に知りたい → 本番環境で確認する?
    35

    View Slide

  36. 本番環境で事前に検証する
    ● テスト用のアカウントを用意する
    ○ 必要な分だけ用意する
    ■ 同値分割、境界値分析の要領
    ● 移行にかかる時間を計測する
    ○ 当日の移行に必要な時間を見積もる
    ■ 計測した結果を平均処理時間として並列数を考慮して見積もり
    36

    View Slide

  37. 自信を持って移行できた
    ● 移行の状態を人間が管理しなくて良い
    ○ → 状態がすべて記録されているので漏れはないだろう
    ● 何回実行しても壊れない
    ○ → 移行できるものしか移行できないので安心して実行できる
    ● 本番環境で問題ないか知りたい
    ○ → 事前に本番環境で動いたので大丈夫だろう
    37

    View Slide

  38. もっとうまくやるなら
    ● 移行用のテーブルに移行後も参照が必要な情報を持たせ
    てしまった
    ○ 移行は完了したのに移行用のテーブルを削除できない
    ○ TRY
    ■ 移行後も参照が必要な情報は通常のテーブルに記録する
    ■ 移行用のテーブルからデータを入れる
    38

    View Slide

  39. 振り返り
    39

    View Slide

  40. 振り返り
    ● 仲間を頼ることも大事
    ○ 仲間じゃん
    ○ 仲間を信じる
    ■ 自分の仕事のスコープ外のことを考えすぎない
    ■ 自分のやること、考えることを減らす
    ● 移行プロジェクトは大変
    ○ 最低3人は必要
    ■ 1. コミュニケーション役
    ■ 2. 主担当
    ■ 3. 相談役
    40

    View Slide