Share
Embed
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