システムリプレイスに伴うデータ移行の方法

既存システムをマイクロサービスへと切り分ける際、
DBに保存されているデータの移行に苦労したため振り返りの備忘録です。

DMSによるデータ同期を選択

システム切り替えでのサービス停止をさけるため、
DMSで更新を同期し、既存システムのデータを新システムへと流し込む選択をしました。

MSK + ECSでスキーマ変更に対応

テーブル定義自体に更新があったため、
データ同期と同時に、MSK + ECSでデータの加工を行っています。

発生した課題

当初、アプリケーション構築の1ストーリーとして計画しましたが
手順、計画ともに課題があり難航しました。

検証までにかかる時間が長い

全てのデータが作成されるまで検証が行えず、検証実施まで数日の待ち時間が発生します。

実施段階では、要求仕様時点で洗いもれのレコードや、
本番環境特有の不具合など、想定以上の手戻りが発生しています。

進捗の推移が何度でも0に戻る

通常の開発業務では不具合が検知された場合、タスクを積んでゴールを更新しますが、
データ移行では不備が見つかるたび、0から再作成が必要です。

データ移行やスキーマ変更との付き合い方

やっておいて良かった点、次回以降取り入れたい点です。

テストコード作成

1タスクの認識だったためテストはローカルでの確認のみでしたが、
デバッグ設定の解除漏れによる再作成などが発生したため
テストコード書いておくべきだったと思います。

スキーマ変更とテーブル同期の分離

データ加工とテーブル同期を完全に分離していたため、
移行先DBの構築進捗やステータスに引きずられず作業が実施できました。

アプリケーション構築とのプロジェクト分離

DB定義後から着手可能で、結合テストまでに完了していればいいため
アプリケーション開発とは完全に切り分けて計画した方が
予備工数を設定しやすくなりそうです。

採用PR

弊社で一緒に働く仲間を募集しています。
全てのオタクを幸せにしたい方、是非ご覧ください！