Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
初めてのデータ移行プロジェクトから得た学び
Search
momochi29
January 26, 2023
Technology
0
1k
初めてのデータ移行プロジェクトから得た学び
2023/1/25 Hatena Engineer Seminar #23
https://hatena.connpass.com/event/271696/
momochi29
January 26, 2023
Tweet
Share
More Decks by momochi29
See All by momochi29
いかにして不足・不整合なくデータ移行したか
tjmtmmnk
1
1.5k
データのマスタが変わっても継続的に分析したい!
tjmtmmnk
1
310
Other Decks in Technology
See All in Technology
Kiroと学ぶコンテキストエンジニアリング
oikon48
4
1.8k
Snowflakeの生成AI機能を活用したデータ分析アプリの作成 〜Cortex AnalystとCortex Searchの活用とStreamlitアプリでの利用〜
nayuts
0
120
クラウドセキュリティを支える技術と運用の最前線 / Cutting-edge Technologies and Operations Supporting Cloud Security
yuj1osm
2
240
DeNA での思い出 / Memories at DeNA
orgachem
PRO
6
1.9k
【Grafana Meetup Japan #6】Grafanaをリバプロ配下で動かすときにやること ~ Grafana Liveってなんだ ~
yoshitake945
0
210
事業価値と Engineering
recruitengineers
PRO
7
5.3k
kubellが考える戦略と実行を繋ぐ活用ファーストのデータ分析基盤
kubell_hr
0
120
allow_retry と Arel.sql / allow_retry and Arel.sql
euglena1215
0
140
実践AIガバナンス
asei
3
270
現場が抱える様々な問題は “組織設計上” の問題によって生じていることがある / Team-oriented Organization Design 20250827
mtx2s
7
69k
DuckDB-Wasmを使って ブラウザ上でRDBMSを動かす
hacusk
1
140
人と組織に偏重したEMへのアンチテーゼ──なぜ、EMに設計力が必要なのか/An antithesis to the overemphasis of people and organizations in EM
dskst
7
840
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
53
8.9k
Become a Pro
speakerdeck
PRO
29
5.5k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Side Projects
sachag
455
43k
How STYLIGHT went responsive
nonsquared
100
5.8k
For a Future-Friendly Web
brad_frost
179
9.9k
Typedesign – Prime Four
hannesfritz
42
2.8k
Imperfection Machines: The Place of Print at Facebook
scottboms
268
13k
The Cult of Friendly URLs
andyhume
79
6.6k
Raft: Consensus for Rubyists
vanstee
140
7.1k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Transcript
初めてのデータ移行 プロジェクトから得た学び id: momochi29 2023/1/25 Hatena Engineer Seminar #23 1
プロフィール • id: momochi29 • 所属: マンガメディア開発 • 職種: Webアプリケーション
エンジニア • 2022年4月入社 2
プロジェクト背景 • あるサービスが終了する • ユーザー情報と課金契約を移行する必要がある • 移行日はユーザーに告知済みで必達 3
特に難しかったポイント • 不確実性が高い • 自信を持って移行したい 4
不確実性が高い 5
不確実性を高める要因 • 何もかも初めて ◦ 課金、データ移行の知識/経験がない • 移行日はずらせない • 実現可能なのかわかっていない ◦
課金契約を移行した前例がない 6
不確実性を高める要因 • 何もかも初めて ◦ 課金、データ移行の知識/経験がない • 移行日はずらせない • 実現可能なのかわかっていない ◦
課金契約を移行した前例がない 7
不確実性を下げるには? • 何もかも初めて → 詳しい人と協力する? ◦ 課金、データ移行の知識/経験がない • 移行日はずらせない •
実現可能なのかわかっていない ◦ 課金契約を移行した前例がない 8
一人でやるのは難しそう 9 • エッジケースが多い ◦ ドメイン知識が強く要求される • 間に合わなさそう ◦ 見積もりをして消化具合を見る
▪ 例) バーンアップチャート
助けを求める 10 • 増員をお願いする ◦ エントリに現状を書いて増員をお願いした • ドメイン知識を持った人に聞く ◦ 壁打ちで高速に知識を得る
◦ 移行時の考慮漏れを減らす
不確実性を下げるには? • 何もかも初めて → 詳しい人と協力する? ◦ 課金、データ移行の知識/経験がない • 移行日はずらせない •
実現可能なのかわかっていない ◦ 課金契約を移行した前例がない 11
不確実性を下げるには? • 何もかも初めて → 詳しい人と協力する? ◦ 課金、データ移行の知識/経験がない • 移行日はずらせない →
本当にずらせない? • 実現可能なのかわかっていない ◦ 課金契約を移行した前例がない 12
移行に使える時間は限られている 13 • 移行に使える時間は多くない ◦ 移行完了の時間が決まっている • 移行だけをやればいいわけではない ◦ 何かしらミスが発生する
◦ リカバリの時間も必要 やることを最小にして確実に終わるスケジュールを組みたい
移行日にやることを最小化する 14 • かたまり毎に分割して移行する ◦ ユーザー情報移行フェーズ ◦ 課金契約移行フェーズ • 移行日に何を移行したいかを明確にする
◦ ユーザー情報の移行は移行日前でも可能とわかった • 移行日を調整する ◦ 関係者が多いのでコミュニケーション役が1人いると良い
不確実性を下げるには? • 何もかも初めて → 詳しい人と協力する? ◦ 課金、データ移行の知識/経験がない • 移行日はずらせない →
本当にずらせない? • 実現可能なのかわかっていない ◦ 課金契約を移行した前例がない 15
不確実性を下げるには? • 何もかも初めて → 詳しい人と協力する? ◦ 課金、データ移行の知識/経験がない • 移行日はずらせない →
本当にずらせない? • 実現可能なのかわかっていない → プロトタイプ作る? ◦ 課金契約を移行した前例がない 16
• まずは実現できそうかを 知りたい ◦ 実装したあとにダメとわか るのは悲しい • 不確実性の高いものから 取り組む ◦
不確実性が高い ≒ 難しい ので大変なのは事実 ◦ 実現できるかわからない不 安を解消する あとはやるだけにしたい 17 https://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相コミットを利用する
33 2相コミット
どうしたら自信を持てる? • 移行の状態を人間が管理しなくて良い → 状態を記録する? • 何回実行しても壊れない → 冪等性を持たせる? •
本番環境で問題ないか事前に知りたい 34
どうしたら自信を持てる? • 移行の状態を人間が管理しなくて良い → 状態を記録する? • 何回実行しても壊れない → 冪等性を持たせる? •
本番環境で問題ないか事前に知りたい → 本番環境で確認する? 35
本番環境で事前に検証する • テスト用のアカウントを用意する ◦ 必要な分だけ用意する ▪ 同値分割、境界値分析の要領 • 移行にかかる時間を計測する ◦
当日の移行に必要な時間を見積もる ▪ 計測した結果を平均処理時間として並列数を考慮して見積もり 36
自信を持って移行できた • 移行の状態を人間が管理しなくて良い ◦ → 状態がすべて記録されているので漏れはないだろう • 何回実行しても壊れない ◦ →
移行できるものしか移行できないので安心して実行できる • 本番環境で問題ないか知りたい ◦ → 事前に本番環境で動いたので大丈夫だろう 37
もっとうまくやるなら • 移行用のテーブルに移行後も参照が必要な情報を持たせ てしまった ◦ 移行は完了したのに移行用のテーブルを削除できない ◦ TRY ▪ 移行後も参照が必要な情報は通常のテーブルに記録する
▪ 移行用のテーブルからデータを入れる 38
振り返り 39
振り返り • 仲間を頼ることも大事 ◦ 仲間じゃん ◦ 仲間を信じる ▪ 自分の仕事のスコープ外のことを考えすぎない ▪
自分のやること、考えることを減らす • 移行プロジェクトは大変 ◦ 最低3人は必要 ▪ 1. コミュニケーション役 ▪ 2. 主担当 ▪ 3. 相談役 40