データベースマイグレーションに専用のチェックリストが必要な理由

ある開発者がカラムを削除する変更をプッシュしました。デプロイパイプラインはグリーンで通過し、アプリケーションは正常にデプロイされました。しかし、データベースマイグレーションはすでに実行されており、そのカラムは消えています。そのカラムをまだ参照している旧バージョンのアプリケーションは起動できなくなります。チームは、データベースを復元せずにアプリケーションをロールバックするだけでは済まないことに気づきます。そしてデータベースを復元するということは、マイグレーション実行後に書き込まれたデータをすべて失うことを意味します。

このシナリオは、データベースの変更をアプリケーションコードの変更と同じように扱っているチームで発生します。リスクプロファイルは根本的に異なります。アプリケーションコードが壊れた場合、以前のバージョンを再デプロイできます。データベースマイグレーションが壊れた場合、実行された操作を常に元に戻せるとは限りません。データが失われる可能性があります。制約が違反される可能性があります。スキーマが変更され、バックアップからの完全復元なしでは単純なロールバックが不可能になる場合もあります。

だからこそ、データベースマイグレーションには独自のテンプレートが必要なのです。汎用的なデプロイチェックリストではありません。スキーマ変更、データ変換、そして本番データを変更することによる不可逆的な結果の性質に特化したものが必要です。

マイグレーションをコードデプロイのように扱うことの問題点

コードデプロイは比較的安全です。なぜなら、それらは元に戻せるからです。バージョン2をデプロイし、バグがあれば、バージョン1を再デプロイします。アプリケーションは古いコードで再起動し、ユーザーは作業を続けられます。

データベースマイグレーションはそうはいきません。一度マイグレーションが実行されると：

• 削除されたカラムは、復元なしでは回復できません
• リネームされたテーブルは、古い名前を使用するクエリを壊します
• 値を削除または変更するデータ変換は、マイグレーションを再実行しても元に戻せません
• インデックスの作成または削除は、数時間または数日にわたってクエリパフォーマンスを変化させる可能性があります

リスクは技術的なものだけではありません。運用上のリスクもあります。失敗したマイグレーションはアプリケーション全体をダウンさせ、テーブルを長時間ロックし、復旧のために開発者、DBA、運用チーム間の調整を必要とする可能性があります。

5ステップのデータベースマイグレーションテンプレート

優れたマイグレーションテンプレートは、厳格なスクリプトではありません。それは、驚きの可能性を減らすためのチェックとアクションのシーケンスです。各ステップには明確な目的があり、どのステップをスキップしてもリスクが高まります。

次のフローチャートは、5ステップのテンプレートと主要な決定ポイントを示しています。

ステップ1: 何よりも先にバックアップ

マイグレーションを実行する前に、データベースをバックアップする必要があります。これはコンプライアンスのためのチェックボックスではありません。他のすべてが失敗したときの最後のセーフティネットです。

バックアップは、マイグレーション前の正確な状態に復元可能でなければなりません。つまり：

リバーシブルなマイグレーションスクリプトは、前方変更とロールバックをペアにし、必要に応じて元に戻す方法を明確にします。

-- Up: デフォルト値を持つカラムを追加
ALTER TABLE users ADD COLUMN last_login_at TIMESTAMP DEFAULT NULL;

-- Down: カラムを削除（これに依存するコードがない場合のみ安全）
ALTER TABLE users DROP COLUMN last_login_at;

• バックアップファイルは、作成されるだけでなく、有効性がテストされている必要があります
• 復元手順は文書化され、練習されている必要があります
• リスクの高いマイグレーションの場合、自動化された日次バックアップに頼るよりも、マイグレーションの直前に手動でバックアップを取る方が良いです

毎晩自動バックアップを取っているチームもいます。それは日常業務には問題ありません。しかし、テーブルを削除したり数百万行を変更するマイグレーションの場合は、マイグレーションを開始する直前にバックアップを取ってください。バックアップは、マイグレーション自体の影響を受けない場所に保存する必要があります。

ステップ2: 現実的な環境でドライラン

ドライランとは、本番を可能な限り忠実にミラーリングした非本番環境でマイグレーションを実行することを意味します。目的は、本番環境に影響が出る前に問題を発見することです。

キーワードは「現実的」です。10行のデータベースでマイグレーションを実行しても、1000万行のデータベースでどのように動作するかはわかりません。空のデータベースでは2秒で完了するマイグレーションが、本番データでは20分かかる可能性があります。その20分間、テーブルはロックされ、クエリはキューイングされ、アプリケーションは応答しなくなる可能性があります。

適切なドライラン環境には以下が必要です：

• 本番と同一のスキーマ
• 本番に近いデータ量、または少なくとも変更対象の最大テーブルを代表するデータ量
• 特にCPUとI/Oに関して、同様のハードウェアまたはリソース制約

マイグレーションを実行します。各ステートメントの所要時間を記録します。ロック競合を監視します。エラーを確認します。ドライランで問題が明らかになった場合は、本番に触れる前に修正します。

ステップ3: 本番でマイグレーションを実行

これが重要な瞬間です。マイグレーションは、トラフィックが少ない時間帯に実行する必要があります。マイグレーション自体が失敗するからではなく、影響を受けるユーザーが少ないほど、問題が発生した場合の影響が小さくなるからです。

実行中は、積極的に監視します：

• 各ステートメントの完了にかかる時間は？
• 他のクエリをブロックするロックはあるか？
• アプリケーションはまだリクエストを処理しているか、それとも接続がタイムアウトしているか？
• アプリケーションログでエラー率が上昇しているか？

マイグレーションが予想よりも長くかかる場合、最終的には完了すると想定しないでください。中断または一時停止する計画を立ててください。一部のマイグレーションは、より小さなバッチに分割できます。その他は、一時的にアプリケーションをメンテナンスモードにする必要がある場合があります。

ステップ4: 結果を検証

グリーンの終了コードを信頼しないでください。マイグレーションはエラーなく完了しても、データベースが壊れた状態のままになる可能性があります。検証とは、スキーマが期待通りであること、およびアプリケーションが接続して機能することを確認することを意味します。

以下の方法で検証します：

• 新しいカラムが正しいデータ型で存在することを確認
• データ変換が期待値を生成したことを確認
• 変更されたスキーマを実行するテストクエリを実行
• アプリケーションをデータベースに接続し、接続エラーがないか確認

マイグレーションで制約が追加された場合は、既存のデータがそれらを満たしていることを確認します。マイグレーションで制約が削除された場合は、アプリケーションがそれらなしでも正しく動作することを確認します。

ステップ5: 短期的な影響を監視

スキーマ変更は、マイグレーションが完了した時点でシステムへの影響が止まるわけではありません。クエリ実行計画を変更し、インデックスの使用状況を変え、新しいロックパターンを導入する可能性があります。これらの影響はすぐには現れない場合があります。

次の数時間は監視します：

• データベースに新しいスロークエリはあるか？
• アプリケーションのエラー率は以前より高いか？
• 以前は存在しなかったデッドロックはあるか？
• アプリケーションは通常のレイテンシ範囲内で応答しているか？

既存の監視ツールを使用します。手動でログを確認することに依存しないでください。マイグレーション時間と相関する劣化に対してアラートを設定します。

データベースマイグレーションの実践的チェックリスト

まとめ

データベースマイグレーションはコードデプロイではありません。それらは異なるアプローチを必要とする不可逆的な結果をもたらします。バックアップ、ドライラン、実行、検証、監視という5ステップのテンプレートは、チームにリスクを低減する構造化された方法を提供します。どんなに小さなマイグレーションでも、すべてのマイグレーションにこれを使用してください。チェックリストが必要ないほど単純に見えるマイグレーションこそ、最も大きな損害を引き起こすことがよくあります。