データベース移行で失敗しないための法則

今日はデータベースを移行するべき場合とそうでない場合を見極めるにはどうすればいいか。見極めずにデータベースの移行に手をつけると失敗してしまうことになるが、自ら失敗を望んでいる人は居ないだろう。データベースの移行において失敗しないためにはどうすればいいか？

これまでの投稿（「OracleからMySQLに移行することは可能なのか？」および「DB移行の7つのステップ」）ではデータベースを移行する際の大まかな流れについて説明したが「実際うちのシステムで使ってるデータベースは移行できるの？できないの？」という疑問は依然残ったままだと思う。どんな時に移行が簡単なのかということが分かれば、移行するかどうかの決断を下しやすいことだろう。

1. パッケージソフトウェアを利用している場合

パッケージソフトウェアのバックエンドデータベースとしてOracleのようなプロプラエタリなデータベースソフトウェアを利用している場合、そのパッケージソフトウェアが他のデータベース（例えばMySQL）もサポートしていれば移行は簡単である。全ての必要な機能の実装やQAテストは、ソフトウェアベンダ側で完了している。この場合、データベース移行の7つのステップのうち次のような操作が必要になる。

• Step 1. データベース構築
• Step 3. データ移行（アプリケーション専用の移行ツールを使う。）
• Step 6. 監視やバックアップなどの運用設計の見直し（ただしアプリケーション専用のツールがあれば必要なし。）

省いた箇所は必要がないということである。当然といえば当然であるが、ソフトウェアが既にMySQLに対応していれば、MySQLへの移行は簡単である。キモはそのパッケージソフトウェアがMySQLをサポートしているかどうかということだ。

2. ORMを利用したアプリケーション

アプリケーションにおいて、ORM（O/Rマッピングフレームワーク）を利用している場合、アプリケーション側ではデータベースの挙動をそれほど気にしなくてもいいので移行は簡単である。例えばHibernate、Toplink、KuinaDAO、iBATIS、S2Dao、ActiveRecord（Ruby On Rails）などだ。その場合、基本的にはデータの移行とフレームワーク側の設定を変更するだけで、アプリケーション側の変更はほとんど完了である。従って、ORMを利用している場合には7つのステップのうち、次の手順を実施することになるだろう。

• Step 1. データベース構築
• Step 2. 接続設定の変更
• Step 3. データ移行
• Step 4. SQL文の書き換え（ただし殆ど必要ない場合が多い。）
• Step 6. 監視やバックアップなどの運用設計の見直し
• Step 7. QAテスト（チューニングが必要になる場合あり。）

ORMを利用していれば基本的にはSQL文の書き換えという面倒な作業はあまり発生しない。iBATISのように、自分でSQL文を書くことを前提にしているORMを利用する場合でもSQL文の格納場所は集約されており、アプリケーションの随所にSQL文が散らばってるわけではないので作業は比較的楽である。ORMを利用している場合、データベースの移行は狙い目である！

3. ストアドプロシージャを利用していない

アプリケーションにおいてORMを用いていない場合でも、ストアドプロシージャやトリガなど癖のあるものを利用していなければ移行はそれほど難しくない。逆にストアドプロシージャやトリガを多用利用しているような場合、移行は絶望的だ。諦めたほうがいい。

この場合、1〜7のステップのうち、5. ストアドプロシージャや解析関数の移行以外は全て必要になる。

余談であるが、そもそも業務ロジックがデータベース側にあるということは、アプリケーションの設計パターンがよくないといえる。なのでこのような場合には、データベースだけを入れ替えるのではなくアプリケーションごと再設計して、きっちりとN層アーキテクチャまたはMVCになるように作り直すべきだろう。

4. レガシーマイグレーション

レガシーマイグレーションとはメインフレームからの移行のことを指すが、リエンジニアリング方式やリライト方式ではシステムをまるごと入れ替えるのでデータベースの移行は比較的容易に行える。レガシーマイグレーションには次の手法があるが、前者２つが狙い目というわけである。

• リエンジニアリング方式・・・業務の中身やプロセスを見直し、アプリケーションの仕様を一から再構築する。
• リライト方式・・・現在のビジネスロジックを元に、プログラムやデータベースなどをオープン系システム向けに書き直す。
• リホスト方式・・・COBOLで書かれたプログラムをそのまま他のオープン系システムで動作するようにする。

アプリケーションの設計を1からやりなおすのであれば、データベースが違っても手間はそれほど変わらない。このような場合はデータベースの移行とは言わないかも知れないが、今はそんな細かいところを突っ込んではいけない。

同様に、レガシーマイグレーションでなくてもアプリケーションを再構築するときはデータベース移行のチャンスである。そのような場合にはORMを利用するのがオススメである。ORMを使えば開発の手間を減らせるだけでなく、後に特定のデータベースに縛られてしまうことがなくなるからである。

5. 地獄編

これまで移行が簡単なパターンをいくつか挙げてきたが、移行が簡単ではないパターンは逆の場合であるといえる。つまりこういうケースである。

• 自社でアプリケーションを開発している。
• ORMやアプリケーションフレームワークを利用していない。
• ロジックのほとんどをストアドプロシージャやトリガで実装している。
• データベースだけをリプレースしたい。

このような場合には決してデータベースの移行は困難を極めることになるので手をつけるべきではない。もし手をつけてしまったら地獄をさまようことになるだろう。

まとめ。

データベースの移行が簡単な場合とそうでない場合のパターンを紹介した。もちろん、実際のシステムではもっと様々なパターンが考えられるが、自分のシステムにおいて移行が簡単かどうかを見極める際の参考になればと思う。失敗しない秘訣は、わざわざ不必要に難しいことにチャレンジしないことである。確実にlow-hanging fruitsを刈り取ればいいのである。特にORMを利用している場合などはlow-hanging fruitsの典型であるので、データベースの移行を検討してみて欲しい。