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
Modern Linux
oracle4engineer
PRO
0
160
Django's GeneratedField by example - DjangoCon US 2025
pauloxnet
0
160
メルカリIBISの紹介
0gm
0
190
Generative AI Japan 第一回生成AI実践研究会「AI駆動開発の現在地──ブレイクスルーの鍵を握るのはデータ領域」
shisyu_gaku
0
330
COVESA VSSによる車両データモデルの標準化とAWS IoT FleetWiseの活用
osawa
1
400
Unlocking the Power of AI Agents with LINE Bot MCP Server
linedevth
0
120
サラリーマンの小遣いで作るtoCサービス - Cloudflare Workersでスケールする開発戦略
shinaps
2
470
Terraformで構築する セルフサービス型データプラットフォーム / terraform-self-service-data-platform
pei0804
1
200
Automating Web Accessibility Testing with AI Agents
maminami373
0
1.3k
「どこから読む?」コードとカルチャーに最速で馴染むための実践ガイド
zozotech
PRO
0
570
企業の生成AIガバナンスにおけるエージェントとセキュリティ
lycorptech_jp
PRO
2
200
使いやすいプラットフォームの作り方 ー LINEヤフーのKubernetes基盤に学ぶ理論と実践
lycorptech_jp
PRO
1
150
Featured
See All Featured
Context Engineering - Making Every Token Count
addyosmani
3
60
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Docker and Python
trallard
46
3.6k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
3k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
930
Building Applications with DynamoDB
mza
96
6.6k
Raft: Consensus for Rubyists
vanstee
140
7.1k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.1k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
53k
A Modern Web Designer's Workflow
chriscoyier
696
190k
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