Schema Migration — 本質・タイプ・データベーススキーマ遷移ツール

Schema Migrationとは

Schema Migrationは、さまざまな環境に順次適用されるバージョン付きファイルを通じてデータベース構造の変更を管理する実践です。各ファイルにはSQLコマンドのセットが含まれています: テーブルの作成、列の追加、インデックスの変更、削限の更新など。遷移ツールは適用されたバージョンを追跡し、各変更が確実に1回だけ実行されることを保証します。

テーブル内容を移動するData Migrationとは異なり、Schema Migrationは構造（DDL操作）のみを管理します。これは根本的な違いです: Schema MigrationはData Migrationよりも先に実行され、ターゲットスキーマを作成し、そこにデータがロードされます。Redgate (2024)によると、プロダクションデータベースの62%のインシデントが、遷移スクリプトなしの手動スキーマ変更に関連しています。

遷移のバージョン付け

各Schema Migrationには固有の識別子が付与されます—通常はバージョン（V1、V2）またはタイムスタンプです。ツールは特定のテーブル（flyway_schema_history、alembic_version）に適用済み遷移のリストを保存します。起動時に、classpath内のファイルとリストを比較し、新しいもののみを適用します。等価性は重要な特性です: 再実行しても副作用はありません。

スキーマ変更のタイプ

一般的なSchema Migration操作: テーブルの作成 (CREATE TABLE)、列の追加 (ALTER TABLE ADD COLUMN)、型の変更、インデックスの作成、外部キーの追加、シーケンスの更新。より複雑な遷移には、データを保存しながらの列の名称変更、テーブルの分割、シャード間でのスキーマの複製が含まれます。

なぜデータベーススキーマ遷移が必要か

Schema Migrationがなければ、開発者はマニュアルでデータベースを変更します—コンソールでDDLを編集し、dev環境で列を追加し、メモリからstagingにコピーします。結果: 環境間のスキーマのおい、デプロイ中の変更の失用、プロダクションでの遷移のバグ。Schema Migrationは3つの主な問題を解決します: 一貫性、再現性、およびオーディット。

環境間の一貫性

データベース構造がコードで記述されていれば、dev、staging、プロダクションで同じになります。開発者が変更を適用したようと思っていても、ツールが省略された遷移をすべて順次実行します。プロダクションで列が欠けているがコードが必要とする場合、アプリケーションはエラーで失敗します。自動検証によってこのシナリオが排除されます。

新しい開発者のための再現性

新しいチームメンバーが flyway migrate を実行すると、プロダクションダンプや手動DDLクエリーなしで、数秒で現在のスキーマを取得できます。これは特にマイクロサービスアーキテクチャで重要です。そこでは各サービスが独自のデータベースを持ち、スキーマは数十の遷移から構築されます。完全な再現性により、オンボーディングが数日から数分に縮短されます。

変更のオーディット

各Schema Migrationは、アプリケーションコードと一緒にバージョン管理システムに保管されます。Pull Requestを開いて、スキーマ変更の正確なSQLコマンドを確認し、コードレビューができます。インシデントが発生した場合、最後に適用された遷移がどれで、誰が作成したかを簡単に特定できます。Git履歴は、プロジェクト全体のデータベース変更の完全なトレースを提供します。

スキーマ遷移ツール

様々な言語とプラットフォーム対応のSchema Migrationツールが数十種類存在します。選択は、テクノロジースタック、遷移記述形式、ロールバックの要件によって異なります。主なカテゴリと人気のツールを見てみましょう。

ツールの選び方

Java/Kotlinスタックには—Flywayが最もライトで予測可能です。頻繁にロールバックが必要なプロジェクトには—Liquibase。アーキテクチャにロールバックが組み込まれています。Python/Djangoには—Alembicが標準的なSQLAlchemyツールです。DevOpsエンジニアがいないスタートアップには—最も設定が少ないツールを選んでください: Flywayはスクリプトファイルとmigrateコマンドだけで始まります。

コマーシャル解決策

オープンソースツールの他に、コマーシャル解決策（Redgate SQL Change Automation、Datical DB、DBmaestro）も存在します。これらは、視覚的なスキーマ比較、自動競合解決、CI/CDパイプライン連携を提供します。しかし、大多数のプロジェクトでは、FlywayまたはAlembicで追加ライセンスなしで100%のニーズをカバーできます。

Flywayによる遷移

Flywayを使ったKotlinでの実践的なSchema Migrationの例を見てみましょう。PostgreSQLデータベースにorderテーブルを追加する遷移を作成します。Flywayは自動的にflyway_schema_historyテーブルを作成し、適用されたバージョンを追跡します。

-- V1__Create_Orders_Table.sql
CREATE TABLE orders (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id         UUID NOT NULL,
    total_amount    DECIMAL(10,2) NOT NULL,
    currency        VARCHAR(3) NOT NULL DEFAULT 'USD',
    status          VARCHAR(20) NOT NULL DEFAULT 'pending',
    created_at     TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id)
);

dataSource設定を通じてKotlinプロジェクトにFlywayを接続します。設定後、flyway:migrateコマンドでclasspathからすべての新しい遷移が適用されます。

// FlywayConfig.kt — Spring BootでのFlyway設定
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import org.flywaydb.core.Flyway

@Configuration
class FlywayConfig {
    @Bean
    fun flyway(dataSource: DataSource): Flyway {
        return Flyway.configure()
            .dataSource(dataSource)
            .locations("classpath:db/migration")
            .baselineOnMigrate(true)
            .load()
    }
}

PythonプロジェクトのためのAlembic

Alembicは、SQLAlchemyの上に構築されたPython用のSchema Migrationツールです。その主な特徴は、SQLAlchemyモデルと現在のデータベーススキーマを比較してスクリプトを自動生成することです。AlembicはDjango、FastAPI、Flaskプロジェクトに適しています。

初期化と遷移の作成

初期化 (alembic init alembic) と接続ストリングの設定後、alembic revision --autogenerate コマンドでSQLAlchemyモデルをスキャンし、遷移スクリプトを生成します。開発者は生成されたコードを確認し、alembic upgrade head で適用するだけです。Autogenerateにより、手動DDL書きの時間を削減できます。

# models.py — 自動生成用SQLAlchemyモデル
from sqlalchemy import Column, Integer, String, DateTime, Enum
from sqlalchemy.orm import DeclarativeBase
import enum

class OrderStatus(enum.Enum):
    pending = "pending"
    paid = "paid"
    shipped = "shipped"

class Base(DeclarativeBase):
    pass

class Order(Base):
    __tablename__ = "orders"
    id = Column(Integer, primary_key=True)
    status = Column(Enum(OrderStatus), nullable=False)
    created_at = Column(DateTime, nullable=False)

スキーマ遷移の最良実践

経験あるチームは、リスクを低減し、デバッグを簡単にするSchema Migrationルールを開発してきました。これらの実践を守ることは、成熟したエンジニアリング文化の証です。5つの主なルールは、遷移の設計、テスト、デプロイをカバーします。

1つの遷移 = 1つの変更

各Schema Migrationは、まったく1つの論理変更を行うべきです: テーブルの作成、列の追加、インデックスの変更。複数の操作をひとつの遷移に混ぜると、ロールバックが複雑になります—例えば2番目の操作が失敗した場合、1番目はすでに適用されており、別途ロールバックが必要になります。小さなステップが信頼できる遷移の基礎です。

公開された遷移を編集しない

一度プロダクションに適用された遷移は、変更できません—問題を修正する新しい遷移を作成するだけです。公開された遷移を編集すると、トラッカーが壊れます: \u5225のデータベースの開発者はハッシュが合わないことを見るでしょう。不変の遷移は、すべての環境で予測可能な動作を保証します。

プロダクションコピーでのテスト

Schema Migrationをプロダクションに適用する前に、プロダクションデータのコピーで実行してください。目的は、実行速度、テーブルロックの有無、変更の正確さを検証することです。大きなテーブルの場合、ALTER TABLEが書き込みを数時間ブロックする可能性があります—テストで事前に検知できます。プロダクションダンプでのStagingは必須ステップです。

新しい列にNOT NULLを使わない

デフォルト値なしでNOT NULLを持つ新しい列は、遷移失敗のおなじみの原因です。既存のレコードでは値がNULLになり、NOT NULLはエラーを引き起こします。最良実践: 列をデフォルト値とnullableで作成し、データを埋めた後に別の遷移でNOT NULLを追加します。