移行したデータは本当に同じ？｜システム統合・差分移行・切戻し

新しいシステムにデータが入ったら、移行は成功でしょうか。件数が合っていても内容が違うことがあり、コピー中にも注文は増えます。切替後の業務を続けられる条件を、機能とデータの両方から確認します。

事例：二つの受注システムを、一つへ統合する

部門AとBが別々に受注を管理しています。注文登録と在庫連携は新システムへ移し、過去の帳票参照は当面、旧システムに残します。移す機能、残す機能、廃止する機能を担当者と確認します。

データの最初のコピーは20GB。転送の実効速度は200MB/sです。コピー中の更新を差分として記録し、差分反映を追い付かせた後、更新を短時間止めて切り替える方式を考えます。

画面をまとめるだけで、統合できる？

同じ「売上」でも、税込か税抜か、出荷時か受注時かで意味が異なる場合があります。画面名をそろえる前に、データの意味、確定のタイミング、取消しの扱いをそろえます。

1. 機能

   入力・承認・集計・連携の担当を分けます。共通化する範囲と、部門固有の処理を明示します。

2. データ

   項目の意味、単位、時刻、状態、必須条件を合わせます。欠損や不正な値をどう処置するかも決めます。

3. 接続先

   外部API、ファイル、バッチ、帳票への影響を確認します。旧形式のまま必要な接続も切替条件に含めます。

新しい処理と、残す旧処理の境界を明確にします。両方が同じ注文を自由に更新すると、どちらが正しい状態か判断できません。切替時点ごとの更新元と同期の責任を決めます。

両部門に「注文ID 101」があるときは？

部門Aの101と部門Bの101は別の注文です。そのまま共通テーブルへ入れると衝突するため、旧システムと旧IDの組を、新しい内部IDへ対応付けます。例えばA・101→1001、B・101→2001です。

新しい内部IDと参照列は整数のまま扱います。移行用の対応表に旧システムの区別を持ち、注文本体だけでなく明細などの外部キー参照も変換します。移行を再実行しても同じ対応になる設計が必要です。

元のIDを画面の表示番号として残す場合は、内部キーと区別します。表示番号の維持と、一意な内部キーの採番を同じ問題として扱わないことがポイントです。

件数が一致すれば、内容も正しい？

初期時点の注文は1000件、金額合計12,500,000円です。コピー後に10件・180,000円を追加し、2件・60,000円を削除したなら、期待値は1008件、12,620,000円です。ここでは取消しを物理削除する条件とします。

同じ件数と合計でも、注文の取り違えが隠れる場合があります。キーごとの値、明細との関係、状態別の件数、重要な金額を比較します。タイムゾーンや丸めなど、変換仕様に合う照合条件も必要です。

同じ基準時点で照合することが重要です。旧側だけ更新中のまま比べると、正常な差分を欠落と誤認します。照合に使うスナップショットと、その後に反映した更新範囲を対応させます。

コピー中の更新を、どう追い付かせる？

初期コピーは20,000MB÷200MB/s=100秒です。差分の残りが3000件、更新の発生が毎秒100件、反映が毎秒150件なら、残りは毎秒50件ずつ減り、3000÷50=60秒で追い付きます。

更新が止まっていないのに3000÷150で計算すると、追随中に増える更新を落としています。反映能力が発生量以下なら、滞留は減りません。順序、削除、重複、途中再開の扱いも検証します。

更新停止時の残りが120件なら、反映は120÷150=0.8秒。照合5秒と接続先の変更2秒を足して7.8秒です。これは挙げた工程だけの計算で、停止の通知、接続の解放、再接続などがあれば加算します。

データの複製だけでは、何が足りない？

使う製品と方式ごとに、移る対象を確認します。例えばPostgreSQLの論理レプリケーションでは、テーブル構造のDDLやシーケンスの状態が自動ですべて同期されるわけではありません。採番や構造変更の準備も別に必要です。

権限、設定、定期バッチ、監視、バックアップ、外部接続も移行対象です。コピーしたテーブルだけが正常でも、帳票が動かない、通知が二重に送られるなどの業務影響は残ります。

切替後に問題が出たら、旧側へ戻せる？

切替後の新しい注文を失わず戻せる条件を決めます。新側へ登録した注文が旧側にないなら、接続先を戻すだけでは注文が消えて見えます。逆方向の反映や再移行、業務停止・照合の手順が必要です。

問題を判断する指標、戻す責任者、判断期限、利用者への連絡を事前に決めます。切戻しが複雑な変更では、前へ進めて修復する選択も含め、リハーサルで実行時間と整合性を確かめます。

演習1：件数と金額

条件：1000件・12,500,000円から、10件・180,000円追加、2件・60,000円削除です。

問い：照合する期待値を答えてください。

解答例：1008件、12,620,000円です。

根拠：1000+10-2、12,500,000+180,000-60,000です。

誤答の理由：追加だけを足すと、削除が移行されていない状態を正しいと判断します。

演習2：IDの衝突

条件：AとBにそれぞれ注文ID 101とその明細があります。

問い：移行時にどの参照を変換しますか。

解答例：元のシステムと旧IDから新しい整数IDを決め、明細の参照先も同じ対応で変換します。

根拠：本体と参照の組が一致して初めて関係が保たれます。

誤答の理由：本体だけを採番し直すと、明細が別の注文へ結び付く可能性があります。

演習3：差分の追随

条件：残り3000件、発生100件/s、反映150件/sで一定です。

問い：追い付く時間を答えてください。

解答例：60秒です。

根拠：正味の減少は150-100=50件/sです。

誤答の理由：3000÷150=20秒は、更新の発生が止まった場合の計算です。

演習4：更新停止の時間

条件：停止時の残り120件、反映150件/s、照合5秒、切替2秒です。

問い：これらの工程の合計を答えてください。

解答例：7.8秒です。

根拠：120÷150+5+2です。その他の工程は別に加算します。

誤答の理由：反映の0.8秒だけを停止時間とすると、照合と接続先の変更が抜けます。

演習5：対象外の同期

条件：PostgreSQLの論理レプリケーションでデータを移します。

問い：テーブル構造と採番について確認することは何ですか。

解答例：DDLを別に適用する計画と、切替後のシーケンスが衝突しない状態を確認します。

根拠：テーブルの行の同期と、構造・シーケンスの同期は同一ではありません。

誤答の理由：行が一致したからすべての設定も同期済みとすると、切替後の登録で問題が起こり得ます。

演習6：切戻し後の注文

条件：切替後、新側だけへ注文が20件追加されました。

問い：単に旧側へ接続を戻してよいですか。

解答例：その20件を保全・反映し、状態を照合する手順なしには戻せません。

根拠：旧側のデータが切替後の更新を含んでいません。

誤答の理由：切戻しを接続先の変更だけと考えると、受け付けた注文を失うおそれがあります。

出典と仕様を確認する

IPA：APシラバス Ver.7.2

Google Cloud：データベース移行の原則と切替

PostgreSQL：論理レプリケーションの制限

AWS：データ同期とスキーマ変更

関連テーマを続けて学ぶ

リリースと切戻しの判断

トランザクションと回復