スキーマの移行

ソフトウェア エンジニアリングにおいて、スキーマ移行(データベース移行、データベース変更管理とも呼ばれる) とは、バージョン管理された増分的かつ場合によっては元に戻せるリレーショナル データベース スキーマの変更の管理を指します。スキーマ移行は、データベースのスキーマを新しいバージョンまたは古いバージョンに更新または戻す必要があるときに、データベース上で実行されます。

移行は、スキーマ移行ツールを使用してプログラム的に実行されます。指定された目的のスキーマ バージョンでツールが呼び出されると、ツールは、目的の状態になるまで、適切な一連のスキーマ変更の連続的な適用または反転を自動化します。

ほとんどのスキーマ移行ツールは、データベース内の既存データに対するスキーマ変更の影響を最小限に抑えることを目的としています。それにもかかわらず、データベース列の削除などのスキーマ変更によってデータが破壊される可能性があるため (つまり、そのテーブルのすべての行のその列に格納されているすべての値が削除される)、一般的にデータの保存は保証されません。代わりに、ツールはデータの意味を保存したり、新しい要件を満たすために既存のデータを再編成したりするのに役立ちます。データの意味はエンコードできないことが多いため、ツールの構成には通常、手動による介入が必要です。

スキーマの移行により、間違いを修正し、要件の変更に応じてデータを適応させることができます。これは、特にアジャイル環境におけるソフトウェアの進化に不可欠な要素です (以下を参照)。

スキーマ移行を本番データベースに適用することは、常にリスクを伴います。開発データベースとテスト データベースは、一般的に小さく、クリーンです。それらのデータベース内のデータはより理解しやすく、他のすべてが失敗した場合でも、データ量は人間が処理できるほど小さいです。本番データベースは通常、巨大で、古く、驚きに満ちています。驚きは、さまざまなソースから発生する可能性があります。

• 古いバージョンのソフトウェアによって書き込まれ、適切に消去されなかった破損したデータ
• 誰も知らないデータ内の暗黙の依存関係
• 指定されたツールを使用せずにデータベースを直接変更する人
• スキーマ移行ツールのバグ
• データの移行方法に関する想定の誤り

これらの理由から、移行プロセスには高度な規律、徹底したテスト、そして健全なバックアップ戦略が必要です。

定常状態では、アプリケーションの 1 つのバージョンは、スキーマの 1 つのバージョンのみを認識します。したがって、最も基本的な戦略は、アプリケーションをシャットダウンし、スキーマの移行を実行してから、アプリケーションの新しいバージョンを起動することです。この戦略は単純ですが、ダウンタイムが発生します。システムの重要度と使用パターンに応じて、さまざまな期間のダウンタイムが許容される場合がありますが、まったく許容されない場合もあります。そのような場合は、次のゼロ ダウンタイム戦略のいずれかを使用できます。

二重書き（ダブルライティングとも呼ばれます）の一般的な手順は次のとおりです。

1. 古い形式と新しい形式の両方でデータを保持できるようにスキーマを準備します。これは、既存のデータに影響を与えずに、列またはテーブルの新しいバージョンを追加することを意味する場合があります。
2. 古い形式と新しい形式の両方でデータを書き込むアプリケーションの新しいバージョンを展開します (そのため、デュアル書き込みと呼ばれます)。これらの書き込みの一貫性を確保することが重要です。この時点以降、新しく書き込まれたすべてのデータは、古い形式と新しい形式の両方で存在することになります。
3. データベースでバックフィルを実行します。つまり、古い形式から、以前存在し、最近更新されていない新しい形式にデータをコピーします。そのため、まだ二重書き込みは行われません。この時点以降、データベースには、古い形式と新しい形式の両方のデータの完全なレプリカが存在します。
4. 新しい形式でのデータの読み取りに切り替え、二重書き込みを停止するアプリケーションの新しいバージョンを展開します。分散システムでは、二重書き込みを停止する前に読み取りパスを切り替えることが重要であるため、この手順は 2 つに分割される場合があります。
5. スキーマから古い形式のデータを削除します。

二重読み取り (二重読み取りとも呼ばれる) は二重書き込みに似ており、次の手順に従います。

1. 古い形式と新しい形式の両方でデータを保持できるようにスキーマを準備します。上記と同じです。
2. 古い形式と新しい形式の両方を読み取ろうとする (そのため、デュアル読み取りと呼ばれます) アプリケーションの新しいバージョンを展開し、現在存在するどちらの形式でも動作します。
3. 古い形式の書き込みを停止し、代わりに新しい形式の書き込みを開始するアプリケーションの別のバージョンを展開します。デュアル読み取りでは、新しく書き込まれた行に対して新しい形式を読み取る必要があることが認識されるため、すべてが正常に動作し続けるはずです。
4. データベースでバックフィルを実行します。古い形式で書き込まれたすべてのデータを新しい形式に移動します。
5. 古いデータの読み取りを停止するアプリケーションの変更をもう一度展開します。
6. スキーマから古い形式のデータを削除します。

この組み合わせアプローチでは、アプリケーションはデュアル読み取りとデュアル書き込みの両方に変更されます。両方の個別の戦略により、データベースが中断することなくオンラインのままになることが保証されるため、組み合わせアプローチでも同じことが実現されます。この戦略により、バックフィルをより細かく制御できるようになり、バックフィルをより小さなバッチに分割できます。また、機能フラグを使用して、読み取りパスと書き込みパスの両方をより自由に、互いに別々に切り替えることができます。これは、一貫性のあるトランザクションで通常のデュアル書き込みだけでは確実に実行できない場合にも役立ちます。

• 上記のすべての戦略により、ダウンタイムゼロの移行が実現します。
• 二重書き込みの利点は、データの古いバージョンと新しいバージョンが隣り合って存在するため、新しい形式にコミットする前にそれらの比較を実行して一貫性を確保できる点です。ただし、これにはストレージ要件が 2 倍になるという代償が伴います。
• デュアル読み取りでは、どの時点でも各データの 1 つのバージョンのみが存在するため、ストレージ要件は増加しません。
• 組み合わせたアプローチでは、バックフィルをより小さなバッチで実行できるため、ストレージの増加を制御できますが、複雑さが増すという代償が伴います。

データベースを基盤とするソフトウェア アプリケーションを開発する場合、開発者は通常、進化するデータベース スキーマに合わせてアプリケーションのソースコードを開発します。コードは通常、データベース スキーマとやり取りする必要があるときはいつでも、データベース スキーマに存在する列、テーブル、制約について厳密な予測を持っているため、コードが開発されたデータベース スキーマのバージョンのみが、そのバージョンのソース コードと完全に互換性があると見なされます。

ソフトウェア テストでは、開発者は単体テスト用に互換性のあるデータベース システムの存在を模擬する場合がありますが、これより高度なテスト(統合テストやシステム テストなど) では、テスト対象のソース コードのバージョンと概略的に互換性のあるローカルまたはリモートのテスト データベースに対してアプリケーションをテストするのが一般的です。高度なアプリケーションでは、移行自体が移行テストの対象となる場合があります。

スキーマ移行テクノロジーにより、データ モデルを事前に完全に設計する必要がなくなり、ソフトウェア開発ライフサイクル全体を通じてプロジェクト要件の変化に合わせて適応できるようになります。

ソフトウェア開発者のチームは通常、バージョン管理システムを使用して、ソース コードのバージョンに加えられた変更を管理し、共同作業を行います。異なる開発者が、同じソース コードの異なる、比較的古い、または新しいブランチで開発を行い、開発中に変更や追加を行うことができます。

開発中のソフトウェアがデータベースとやり取りすると仮定すると、ソース コードのすべてのバージョンは、互換性のある少なくとも 1 つのデータベース スキーマに関連付けることができます。

適切なソフトウェア テストの実践では、テスト データベースでスキーマ移行を実行して、スキーマがソース コードと互換性があることを確認できます。このプロセスを効率化するために、通常、自動テスト フェーズの前提条件として、自動ソフトウェア ビルドの一部としてスキーマ移行ツールが呼び出されます。

スキーマ移行ツールは、バージョン管理システムがソース コードのバージョン管理の問題を解決するのと同じように、データベース スキーマのバージョン管理の問題を解決すると言えます。実際には、多くのスキーマ移行ツールは、スキーマ変更のテキスト表現 (SQL ステートメントを含むファイルなど) に依存しているため、スキーマ変更のバージョン履歴は、VCS 内のプログラム ソース コードと一緒に効果的に保存できます。このアプローチにより、特定のコード ブランチの互換性のあるデータベース スキーマを回復するために必要な情報が、ソース ツリー自体から回復可能になります。このアプローチのもう 1 つの利点は、競合するスキーマ変更を同時に処理できることです。開発者は、通常のテキスト ベースの競合解決ツールを使用して、違いを調整できます。

スキーマ移行ツールは、進化するスキーマの履歴 (つまり、スキーマの進化)を追跡する機能として考えることができます。

開発者は、新しいテスト データベースを最初から作成するために、テスト データベース全体を削除する必要がなくなりました (例: DDL 生成ツールのスキーマ作成スクリプトを使用する)。さらに、テスト データの生成に時間がかかる場合、開発者は、スキーマに対する小さな非破壊的な変更のためにテスト データを再生成する必要がなくなります。

• マーティン・ファウラー: 進化的データベース設計
• アクティブレコードの移行