Data Migration — 本質、方法、およびデータ移行プロセス

Data Migrationとは

Data Migrationとは、あるソースから別のソースへデータを転送し、完了後にその整合性、一貫性、可用性を確保するプロセスです。単純なコピーとは異なり、移行にはフォーマット変換、重複排除、参照整合性チェック、結果の検証が含まれます。

Data Migrationの必要性は、DBMSのアップグレード（例：MySQL 5.7からMySQL 8.0）、クラウドプロバイダーの変更、モノリスからマイクロサービスへの移行、NoSQLスキーマへの切り替え時に発生します。Stripe（2024）によると、89%の企業が少なくとも2年に1回はデータ移行に直面し、43%がそれを技術アップデートの中で最も困難な段階と認めています。

データ移行の主な目的

第一の目的は、より最新のストレージソリューションに移行することでパフォーマンスを向上させることです。第二は、インフラプロバイダーを変更する際の運用コスト削減です。第三は、データを特定の法域に保存する必要がある場合の規制要件（GDPR、152-FZ）への準拠を確保することです。

移行と統合の違い

統合は、稼働中の2つのシステム間での継続的な同期を伴います。移行は、一度きりの転送とその後のソースの廃止です。統合はソースのデータを削除しませんが、移行はターゲットシステムをプライマリ状態に移行して終了します。この基本的な違いが、ツールと検証アプローチの選択を決定します。

データ移行のETLモデル

あらゆるData Migrationの基本アーキテクチャは、ETLモデル（抽出、変換、ロード）に基づいています。抽出 — ソースからデータを取得。変換 — ターゲットスキーマに変換。ロード — 宛先にロード。各フェーズには独自の品質管理方法があります。

抽出：データ抽出

抽出段階では、ソースデータベース、ファイルストレージ、またはAPIからデータが読み取られます。増分抽出（CDC — Change Data Capture）を使用すると、変更されたレコードのみを転送できるため、トラフィック量が削減されます。完全ダンプは少量のデータに適していますが、テラバイト規模のデータベースでは、DebeziumやKafka Connectによるストリーミングレプリケーションが推奨されます。

変換：スキーマ変換

変換には、列の名前変更、データ型の変更、値の正規化、集約が含まれます。たとえば、MySQLからPostgreSQLに移行する場合、数値型DECIMALはNUMERICに変換し、日付形式はISO 8601に変換する必要があります。Talend（2024）によると、移行時間の70%は転送ではなく変換に費やされます。

ロード：宛先へのロード

ロードはバッチ（batch insert）またはストリーミングで実行されます。重複を排除するために冪等性キーが使用されます。ロード後は検証ステップが必須です：レコード数の比較、チェックサムの計算、ビジネスルールのチェック。検証なしでは、Data Migrationは不完全と見なされます。

データ移行戦略

Data Migration戦略の選択は、システムダウンタイム、ロールバックの複雑さ、準備作業の量を決定します。主な戦略は、Big Bang、Trickle、Parallel Runです。それぞれ異なるシナリオで適用可能です。

Big Bang移行

Big Bangは、旧システムを一度停止し、データを転送して新システムを起動する方法です。少量のデータと単純なスキーマに適しています。リスク：障害発生時、バックアップからの完全復旧までシステムが利用できなくなります。2024年、GitLabは14時間のダウンタイムウィンドウでAWS RDSからGCP Cloud SQLに5TBのデータを移行するためにBig Bangを使用しました。

Trickle移行

Trickleは、少量ずつストリーミング同期を行う方法です。新旧両方のシステムが並行して動作し、変更がリアルタイムでレプリケートされます。データの安定化後、古いソースは停止されます。このアプローチには双方向同期と競合解決が必要です。ダウンタイムなしでデータベーススキーマを更新する際のContinuous Deliveryで使用されます。

Parallel Run

Parallel Run — 両方のシステムが同時に動作し、アプリケーションは両方のソースへの書き込みと読み取りを行います。宛先でのデータ検証後、古いソースは停止されます。これは最も安全な戦略ですが、2つのインフラストラクチャの維持が必要なため最も高価でもあります。重要な金融システムの移行時に使用されます。

データ移行の種類

アプリケーション開発では、転送オブジェクトとコンテキストに基づいて、いくつかの種類のData Migrationが区別されます。各タイプには独自の方法論とツールがあります。タイプを理解することが、正しい戦略を選択するための第一歩です。

データベース移行（Database Migration）

Database Migrationは、異なるベンダーのDBMS間での転送です：OracleからPostgreSQL、SQL ServerからMySQL、MongoDBからDynamoDB。複雑さは、互換性のないデータ型、SQL方言、インデックスメカニズムにあります。ツール：AWS DMS、Debezium、Liquibase。

アプリケーションデータ移行（Application Data Migration）

同じアプリケーションの異なるバージョン間でのデータ転送 — たとえば、エンティティ構造の変更を伴うコードの更新時など。多くの場合、アプリケーション言語での移行スクリプトの実行を伴います：Ruby on RailsのActive Record Migrations、Java用のFlyway、.NETのEntity Framework Migrations。これらのスクリプトはスキーマとデータを順次変換します。

クラウドデータ移行（Cloud Data Migration）

Cloud Data Migrationは、オンプレミスインフラからクラウドへ、またはクラウド間でのデータ転送です。AWS Snowball、Azure Data Box、Google Transfer Applianceは、テラバイト規模のデータの物理的な運搬に使用されます。オンライン移行には、VPNトンネルとレプリケーションが使用されます。Gartnerによると、2027年までに70%の移行がハイブリッドクラウド環境で実行されるでしょう。

データ移行の計画

計画なしのData Migrationは確実な失敗です。計画には、現在のスキーマの監査、データプロファイリング、戦略の選択、環境の準備、テスト、ロールバック計画の承認が含まれます。McKinseyの調査（2024）によると、54%の失敗した移行は正式な計画の欠如が原因です。

監査とプロファイリング

移行前に、ソースシステムの監査が必要です：データ量、テーブル数、エンティティ間の依存関係、NULL可能フィールドのタイプ、重複の有無を確認します。プロファイリングは、キーフィールドのNULL値、形式の不一致、壊れたリンクなどの異常を特定します。これらのデータが完全ダンプのベースラインを形成します。

テスト環境の準備

本番データのコピーでテスト移行を本稼働前に行います。目的は、ETLパイプラインのパフォーマンス、変換の正確性、ロード速度を確認することです。Big Bangの前に最低3回の完全なテストサイクルが推奨されます。各サイクルには、完全な転送、検証、ロールバックが含まれます。

ロールバック計画

ロールバックとは、重大なエラーが検出された場合に元のシステムに戻すことです。ロールバック計画には以下が含まれます：開始前のソースの完全バックアップ、スキーマ復旧スクリプト、旧システムを再び有効にするための手順書、ユーザー通知のためのコミュニケーション計画。承認されたロールバック計画なしに、Data Migrationを本番環境で開始すべきではありません。

データ移行のコード例

Flywayと組み合わせたKotlinでのData Migrationの実践例を見てみましょう。移行スクリプトV1はusersテーブルを作成し、レガシーフォーマットからデータを転送します。Flywayは適用された移行を自動的に追跡し、冪等性を保証します。

// V1__Migrate_Users.kt — レガシーフォーマットからのデータ移行
import org.flywaydb.core.api.migration.BaseJavaMigration
import java.sql.Connection
import java.sql.PreparedStatement

class V1__MigrateUsers : BaseJavaMigration() {
    override fun migrate(connection: Connection) {
        val legacyUsers = connection.prepareStatement(
            "SELECT id, name, legacy_role FROM users_legacy"
        ).executeQuery()

        val insertStmt: PreparedStatement = connection.prepareStatement(
            "INSERT INTO users (id, name, role, migrated_at) VALUES (?, ?, ?, NOW())"
        )

        while (legacyUsers.next()) {
            insertStmt.setInt(1, legacyUsers.getInt("id"))
            insertStmt.setString(2, legacyUsers.getString("name"))
            val role = mapLegacyRole(legacyUsers.getString("legacy_role"))
            insertStmt.setString(3, role)
            insertStmt.executeUpdate()
        }
    }
}

SQLAlchemyを使用してCSVからPostgreSQLにデータを転送するPythonでの移行例。スクリプトはファイルから抽出し、型を変換してターゲットテーブルをロードします。

# migrate_data.py — 変換を伴うCSVのPostgreSQLへのロード
import pandas as pd
from sqlalchemy import create_engine

engine = create_engine("postgresql://user:pass@host/db")
df = pd.read_csv("legacy_orders.csv")

df["order_date"] = pd.to_datetime(df["order_date"])
df["amount"] = df["amount"].astype("float")
df.to_sql("orders", engine, if_exists="append", index=False)

print("データ移行が完了しました")