◆当ブログの内容
・データベースマイグレーションの定義や種類の説明
・データベースマイグレーションがなぜ必要なのか、どのような点がリスクになるのか、を解説
・リスクの最小化や、成功のポイントの説明
◆はじめに
「サポート期限が迫っている」「クラウド移行でコストを最適化したい」などといった背景から、DBマイグレーションは避けて通れない経営課題となっています。
しかし、安易な移行は「性能劣化」や「データ不整合」を招き、ビジネスを停滞させるリスクも孕んでいます。DBマイグレーションが成功し、無事に安定稼働するには、どのようにすればよいでしょうか。
本記事では、当社の考える安心安全なマイグレーション方法を解説します。
◆目次
DBマイグレーションの種類
DBマイグレーションの必要性
DBマイグレーションは何が難しいのか
DBをマイグレーションする方法
DBマイグレーションを成功に導くためには
◆DBマイグレーションの種類
DBマイグレーションとは、データベースの構造・データ・実行環境を、マイグレーション（移動、移転）する作業です。
種類としては、大きく３種類あると言われています。
①ハードウェア環境、ソフトウェア環境の移行
②異種DBへの移行
③DBの構造変更
それぞれの例は以下の通りです。
①ハードウェア環境、ソフトウェア環境の移行
・新サーバへのリプレイス
・オンプレからクラウドへのリフトアップ、
クラウドからオンプレへの回帰
・データベースを上位バージョンにアップ
②異種DBへの移行
・他のデータベース製品への乗り換え
③DBの構造変更
・テーブル構造の分割、統合
・正規化／非正規化
・カラム追加、桁数変更
※索引（インデックス）の追加変更はチューニングの一環であり、
当社ではマイグレーションとは別ものと考えています。
◆DBマイグレーションの必要性
DBマイグレーションが必要とされるのは、お客様の業務システムが下記の状況であることが多いです。
技術的陳腐化への対応：
・ハードウェアやミドルウェアのサポート終了後も古いバージョンを使い続けることは、脆弱性対応が受けられない可能性があり、セキュリティリスクの増大が懸念されます。
コスト最適化：
・ライセンス費用削減や、DBベンダー固定化からの脱却により、コストの最適化につながります。
商用DBからオープンソースDBへの移行を検討されるお客様は多くいらっしゃいます。
スケーラビリティ確保：
・業務の拡大によるデータ量の増加への対応や、経営戦略の立案のための新たなデータ活用対応など、可用性拡張性の高い構成への変更が必要とされます。
◆DBマイグレーションは何が難しいのか
DBマイグレーションが難しい理由は、単なる「データのコピー」ではなく、マイグレーションの基本原則である、 「業務を止めず、整合性を担保し、性能を維持する」ために、
データ・アプリケーション・運用を同時に移行する必要があるためです。
具体的には、次の7つのポイントが難易度を高めます。
１．ダウンタイムの制約
グローバルに事業を展開していることが多い現代の企業では、24時間稼働の業務システムも多くあります。そのため、システムを停止できる時間が制限されます。限られた時間で実行するためにも、移行方法の慎重な検討が重要です。
２．データ量の問題
データ量が多い場合、移行時間だけでなく、ストレージの容量や移行中のネットワーク負荷、移行方法を慎重に検討する必要があります。
３．アプリケーションとの整合性
データベースに変更があれば、アプリケーションにも修正が必要になります。SQL文の見直しは最新のプログラムソースで確認することになりますが、DB内部のプロシージャの確認、移行には注意が必要です。
４．データ整合性の保証
移行時には、データ欠損がないこと、件数が一致すること、金額などの数値項目の合計が正しいこと等、データ整合性を保証することが必要です。新旧比較で確認する場合が多いです。
ただし、オブジェクト構成を変更した場合などは件数が一致するとは限りませんので、正しく移行されていることの判断基準も、予め決めておく必要があります。
５．DB製品ごとの仕様差
異種間DBのマイグレーションでは、データベース製品が異なるため、仕様や機能に違いがあります。
SQL構文、データ型、DB製品独自の関数、NULLの扱いなどです。
特に、ストアドプロシージャやDB製品独自の関数を多用している場合、アプリケーションのSQL文を大量に書き換える必要があります。
６．データ型の違い
DB製品それぞれで、データ型が異なっています。データ型の名称だけでなく、その桁数や精度も異なります。そのため、データの一部が欠けたり、桁あふれが発生する恐れがあります。
７．パフォーマンスの再調整
異種DBへのマイグレーションの場合はもちろんですが、同じDB製品のバージョン変更でもオプティマイザが変更されている場合があります。このため、以前と同様もしくはそれ以上のパフォーマンスが出るように調整が必要です。
◆DBをマイグレーションする方法
DBマイグレーションの方法にはいくつかの種類があります。ハードウェア環境や業務システムの要件によって、いずれかを選択する場合や、これらを組みあわせて移行する場合もあります。
１．ダンプ＆リストア方式（オフライン移行）
既存DBからデータをエクスポートし、新しいDBへインポートします。
移行中は基本的にシステム停止が必要であり、大規模なデータベースでは時間がかかることがネックです。
２．レプリケーション方式（オンライン移行）
旧DBから新DBへデータをリアルタイム同期させる方法です。
ダウンタイムは短いですが、移行時の運用設計が必要になります。
３．段階移行方式
アプリケーションを段階的に新DBへ移行する方法です。
一時的に新旧が混じるため、構成が複雑になります。アプリケーションは移行期間用の修正が必要になる場合もあります。
４．スキーママイグレーション
アプリケーション開発の中で、DB構造をバージョン管理しながら移行する方法です。
アジャイル開発やDevOps環境での利用が多い方法です。
◆DBマイグレーションを成功に導くためには
DBマイグレーションを成功に導くためには、重要なポイントがいくつかあります。
１．現行システムの徹底的な事前調査
まずは、現在のDB利用状況を正確に把握しましょう。オブジェクト類、ビュー、プロシージャやトリガーなどのDB内部の状況、およびアプリケーション内のSQL文、BI、ETLツールなどDB外からのアクセス状況です。
２．移行方式の設計
調査したシステムの状況と、業務上可能なダウンタイム状況等に合わせた最適な移行方式を設計しましょう。
設計した結果は移行手順書にまとめます。移行リハーサルもこの手順書に沿って実施しましょう。
３．SQL互換性とデータ型の確認
異なるDB製品間では、SQL仕様が完全には一致しません。
DB接続方式の確認、データ型の確認、製品独自の関数の列挙、SQL文の表記方法の確認などを行い、互換性の有無と書き換えの指針を決めておきましょう。
４．移行時間の見積もり
開発環境でのテストも参考にして、移行作業時間の見積もりを行いましょう。
データ量だけでなく、ネットワーク負荷、インデックス作成時間、整合性検証の時間もそれぞれしっかりと見積もりましょう。
５．移行リハーサルと性能検証
移行作業を行う前には、移行リハーサルを行いましょう。
リハーサルの結果を以って、移行設計の再確認や、移行時間の見直しも行います。移行後のDBパフォーマンスも確認できます。
６．切り戻し計画の策定
移行作業でのトラブルに備え、現行システムへ戻すための手順も計画しておきましょう。
切り戻しの方法と作業手順によっては、切り戻しも時間がかかります。そのため、GO／NotGOの判断期限の設定も重要です。
これらの重要ポイントを踏まえて、DBマイグレーションを成功に導きましょう。
