システムリプレイスに伴うデータ移行の方法
既存システムをマイクロサービスへと切り分ける際、
DBに保存されているデータの移行に苦労したため振り返りの備忘録です。
DMSによるデータ同期を選択
システム切り替えでのサービス停止をさけるため、
DMSで更新を同期し、既存システムのデータを新システムへと流し込む選択をしました。
MSK + ECSでスキーマ変更に対応
テーブル定義自体に更新があったため、
データ同期と同時に、MSK + ECSでデータの加工を行っています。
発生した課題
当初、アプリケーション構築の1ストーリーとして計画しましたが
手順、計画ともに課題があり難航しました。
検証までにかかる時間が長い
全てのデータが作成されるまで検証が行えず、検証実施まで数日の待ち時間が発生します。
実施段階では、要求仕様時点で洗いもれのレコードや、
本番環境特有の不具合など、想定以上の手戻りが発生しています。
進捗の推移が何度でも0に戻る
通常の開発業務では不具合が検知された場合、タスクを積んでゴールを更新しますが、
データ移行では不備が見つかるたび、0から再作成が必要です。
データ移行やスキーマ変更との付き合い方
やっておいて良かった点、次回以降取り入れたい点です。
テストコード作成
1タスクの認識だったためテストはローカルでの確認のみでしたが、
デバッグ設定の解除漏れによる再作成などが発生したため
テストコード書いておくべきだったと思います。
スキーマ変更とテーブル同期の分離
データ加工とテーブル同期を完全に分離していたため、
移行先DBの構築進捗やステータスに引きずられず作業が実施できました。
アプリケーション構築とのプロジェクト分離
DB定義後から着手可能で、結合テストまでに完了していればいいため
アプリケーション開発とは完全に切り分けて計画した方が
予備工数を設定しやすくなりそうです。
採用PR
弊社で一緒に働く仲間を募集しています。
全てのオタクを幸せにしたい方、是非ご覧ください！