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

by momochi29

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

不確実性が高い 5

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

振り返り 39

Slide 40

Slide 40 text

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