【AWSデータ移行】あえて「手作業×スクリプト」のハイブリッドで挑む！構造の異なる稼働中システムへ安全に移行した2ヶ月の全記録

この記事でわかること

• AWSクロスアカウント・別リージョン環境における、異種スキーマ間のデータ移行戦略

• 稼働中システムのID衝突を防ぎ、準備2ヶ月・本番2日を完遂したリスク管理

• 完全自動化ツールを見送り、「Excelマッピング×動的スクリプト」によるデータ再構築術 

   目次

はじめに

データ移行の要件と障壁

移行手法を考える

実践：移行作業本番

まとめ

   はじめに

私は現在、AWS上で稼働する、研究者向け材料計算プラットフォームを開発・運用するプロジェクトに参画しています。

旧システムから新システムへのメジャーアップデートを無事にリリースし、チームがようやく一息ついていた頃のことです。 

ある日、マネージャーから「旧システムのデータ移行」を提案されました。

確かに、2つのシステムを並行稼働させる必要はありません。コストや運用保守の観点からも、システムを1つに統合したほうがメリットが大きいです。旧システムに残っている貴重な計算結果ファイルは、新システムへ早急に移行すべきでした。 

以前、プライベートな検証環境で模擬的な移行をした経験もありました。神経を使うタスクではあるけれど、エンジニアとしてやりがいを感じる重要なミッションだと感じた私は、何の疑いもなく元気に返答しました。 

「お任せください！」

この後、待ち受けている絶望的な壁の存在も知らずに・・・

   データ移行の要件と障壁

移行の対象となるリソースは以下の２つです。

・Amazon Aurora（データベース） 

　→グループ情報、ユーザー情報、計算ジョブのメタデータ など

・Amazon EFS（ストレージ） 

　→計算結果ファイル

ここまでは何も問題ありません。Webシステムではごく一般的な構成です。

しかし、真の恐怖は対象リソースそのものではなく、これらを「どのような条件下で」移行しなければならないかという前提条件にありました。

１．移行先はすでに「本番稼働中」 

新システムはすでにリリースされており、新しいユーザーが日々計算ジョブを回しています。つまり、システムを止めて「まっさらな状態からDBを丸ごと上書き（リストア）」することは許されません。既存のデータと、移行するデータを同居させる必要があります。 

２．インフラが「別アカウント・別リージョン」

移行元と移行先でAWSアカウントもリージョンも異なるため、ネットワーク（VPC）が分断されています。ローカルや同一VPC内で気軽にデータを流し込める環境ではありませんでした。 

３．全件ではなく「一部ユーザーのみ」を抽出移行

 旧システムにいる全ユーザーを一括で移すのではなく、「特定のグループのデータだけ」のように、条件に合致するデータだけをピンポイントで抜き出す必要がありました 。

４．データ構造が全く違う（フラット構造から親子構造へ）

旧システムでは独立に保存されていた計算ジョブのデータが、新システムでは「プロジェクト ＞ サブグループ ＞ 計算ジョブ」のように、厳密な親子関係（階層構造）を持つように構造が根本からリファクタリングされていました。 

この段階でただのデータ移行ではなく、データの『再構築』をしながら、稼働中のDBに外科手術をするということに気が付きました。

   移行手法を考える

AWSにおけるデータベース移行といえば、いくつかの「王道」が存在します。例えば、Auroraのスナップショットからの復元、データダンプ（mysqldump 等）による一括インポート、あるいは高機能なデータ移行サービスである AWS DMS (Database Migration Service) の活用などです。  

しかし、今回の移行プロジェクトにおいて、これらのツールをそのまま適用することは、稼働中のシステムに深刻な影響を与えるリスクがありました。理由は大きく2つあります。 

課題①：ID衝突（Primary Key Collision）のリスク

前述の通り、移行先の新システムにはすでに稼働中のユーザーデータが存在します。このユーザーデータは旧システムと完全に一致せず、レコードの内容に差異がありました。

ここに旧システムのデータをそのままダンプして流し込むとどうなるでしょうか。旧システムで採番された「ユーザーID: 100」のデータが、新システムですでに活動している別の「ユーザーID: 100」のデータと衝突（Duplicate Key Error）を起こすか、最悪の場合は既存データを意図せず上書きしてしまいます。

本番環境のデータを破壊するリスクが少しでもある以上、ツールを用いた機械的な「全件コピー」という選択肢は早々に除外されました。

課題②：移行ツールは「ビジネスの文脈」を自動判定できない 

仮に、何らかの変換処理を挟んでIDの衝突問題をクリアできたとしても、最大の壁である「フラット構造から親子構造への変換」は自動化が極めて困難でした。

新システムでは、計算ジョブのデータを登録する前提として、親となる「プロジェクト」や「サブグループ」のデータがDB上に存在している必要があります。しかし、旧システムのデータにはそもそもその概念が存在しません。

「この計算ジョブは、新システムのどのプロジェクトに紐づけるのが正解か？」 

「親となるグループデータは、どのような名前で新しく生成すべきか？」

高度な移行ツールは、データ型を変換することは得意ですが、システムの歴史的経緯やビジネス要件の文脈までは汲み取ってくれません。文脈を持たないデータを無理やり流し込めば、アプリケーション側で「親が存在しない孤児データ」として致命的なエラーを引き起こすことになります。

結論：「ツールによる完全自動化」を見送る決断

システム移行においては、「いかにツールを活用して自動化・省力化するか」がベストプラクティスとされがちです。しかし、スキーマが根本から変わり、新たな親子関係が追加されるような複雑な要件において、ツールへの過信はシステム障害に直結します。

私はここで、あえて高度な自動化ツールを見送る決断をしました。

そこで採用したのが、表計算ソフト（Excel）を用いた「手動での新旧IDマッピング」という、非常に泥臭い手法だったのです。

一見効率的ではないと感じるかもしれませんが、全ての手順で後述するシェルスクリプトを組んでいるため、移行対象となるグループに対応した新旧IDマッピング表を更新するだけでデータ移行が実現できます。

＼AWSの設定でお困りですか？専門エンジニアがサポートします／

今すぐ相談する

   実践：移行作業本番

移行作業に丸2日を要し、その間、旧システムと新システムを停止して以下の作業を実施しました。

STEP 1：旧システムでのバックアップ取得と共有

稼働中の旧システムから、データベース（Aurora）の最新スナップショットと、計算結果ファイル（EFS）のバックアップを取得します。これらを、移行先である新システムのAWSアカウントから復元できるようにクロスアカウントでアクセスポリシーを付与し、安全に共有します。

STEP 2：新システム内での「一時作業場」の構築

共有されたバックアップを、新システムの本番VPC内に「作業用の一時DB 」として復元します。同時に、EFSのデータも踏み台サーバー（EC2）上の専用ディレクトリにマウントし、本番環境から完全に隔離されたデータ加工用の環境を構築します。 

STEP 3：旧データの抽出と「新旧IDマッピング表」の作成

一時DBから移行対象となるユーザーやジョブの情報を抽出し、エクセル上で「旧システムのID」と「新システムで新しく割り当てるID」を紐付けるマッピング表を作成します。 

▼実際に使用したマッピング表

STEP 4：受け皿の作成と、本番DBへの一括流し込み

新システムの要件（親子構造）を満たすため、本番DBに過去データを格納するための「ダミーの親プロジェクト」をひとつ作成します。その後、STEP 3で作ったマッピング表を元に、一時DBのデータを変換しながら本番DBへ安全に INSERT していくスクリプトを実行します。 

実際に使用したコマンド例：（※一部名称をマスキングしています） 

このようにシェルスクリプトを組み、実際の値をマッピング表から参照することで、グループ毎に動的な値を引用することができました。上記に類似したシェルスクリプトを他の手順でも準備して実行しました。

STEP 5：EFSの一括リネームと本番合流 

踏み台サーバーに、旧EFSのバックアップと新システムの本番EFSを同時にマウントします。次に、マッピング表をもとに専用スクリプトを実行し、フォルダ名を新システムのUUIDへと変換しながらデータをコピー（cp -r）しました。

コピー後は、新旧のファイル数や容量を比較して欠損がないかを確実にチェック。最後に、ファイルの所有権（chown）とパーミッション（chmod）を新仕様に合わせて書き換え、本番環境へ安全に合流させています。

▼ターミナルの実行ログ

＼AWSの設定でお困りですか？専門エンジニアがサポートします／

テラテクのエンジニア派遣について

   まとめ

今回のデータ移行プロジェクトは、要件定義から検証、そして本番環境への完全移行まで、インフラエンジニア1名・約2ヶ月という期間で完遂しました。

稼働中のシステムに対する複雑な要件を短期間で乗り切れた最大の理由は、早々に「移行ツールによる完全自動化」を諦めたことにあります。

エンジニアであれば誰しも、最新のツールを駆使し、ボタン一つで全てが完結するような「スマートで高度なアーキテクチャ」を組み上げたいという誘惑に駆られるものです。もちろん、単純なデータ移行であればそれがベストプラクティスです。

しかし、今回のようにフラットな構造から親子構造へスキーマが変わり、動的なIDマッピングが必要になるケースでは、無理にツールだけで完結させようとすると、かえってアーキテクチャが複雑化し障害リスクが高まってしまいます。 

今回選択した「手作業とスクリプトのハイブリッド」は一見すると泥臭い手法ですが、結果として既存システムに影響を与えることなく、最も確実でスピーディに移行を終える最短ルートになりました。

この記事が複雑なデータ移行プロジェクトに直面しているエンジニアの皆様にとって、具体的な解決策のヒントになれば幸いです。

最後までお読みいただき、ありがとうございました。

この記事を書いた人

M.R（AWSエンジニア）

🏅保持資格

・AWS Certified Cloud Practitioner

・AWS Certified SysOps Administrator - Associate

・AWS Certified Solutions Architect - Associate

・基本情報技術者試験 

保険業界向け業務システムのアプリケーション開発を経て、現在は研究者向け材料計算プラットフォームのプロジェクトに参画。インフラ構築からアプリ開発・運用まで、領域を問わずフルスタックに担当しています。

＼サービス紹介資料　ダウンロード／