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