こんにちは。SCSKの丸山です。
前回、クラウド・データベース・マイグレーション・サービス(以下CDMS)の Google Cloud対応開始についてお知らせをしました。
CDMSでは、単純なリフトの移行からリアーキテクチャが必要なシフトまであらゆるDB移行に対応しておりますが、その中でも特に注目されているのが異種DBマイグレーションです。
- よりクラウド環境のメリットを享受したいのでクラウドネイティブのDBを選択したい
- ライセンスコスト削減のために、クラウド移行の際に商用DBからOSS DBへ変更したい
と考えるお客様は年々増加傾向にあり、弊社への問合せも非常に増えております。Google Cloudでは、PostgreSQL完全互換のAlloyDBの登場により、Oracle DBをはじめとする商用DBからAlloyDBへ異種DBマイグレションを実施したいと考える方もいるのではないのでしょうか？
ライセンスコスト削減もできてクラウドメリットを享受できるなんていい事ずくし！とお考えの皆様。少々、お待ちください。
異種DBマイグレーションは移行後のメリットも大きいのですが、実は移行にうまくいかないケースもあります。それは、異種DBマイグレーションの「つまづきポイント」を押さえていないからにつきます。
事前に移行のポイントを把握・理解し、下準備をしっかり整えることが、異種DBマイグレーションを成功へと導きます。
今回は、その異種DBマイグレーションの越えなければならない３つのハードルについてお伝えします。
異種DBマイグレーションには、3つのハードルがある
「Oracle DBからAlloyDBへデータベースを変更したい」というようなデータベース製品を変更する「異種DBマイグレーション」ですが、同じRDBMSでも、内部アーキテクチャや使用できるSQL句には差異があります。
例えば、SQLは国際標準として規格化されているSQL標準にのっとっていたとしても、各DB固有の機能に基づいた固有の関数や記述方式がありますし、オプディマイザが異なれば実行計画や内部で採用されているアルゴリズムも異なります。そのため、単純にデータを移行したら使用できるというものではありません。移行元、移行先双方のDBの特徴や機能を理解した上で、DB間の差異のハードルを越えていく必要があります。
そのハードルは、大きく分けて3種類ありますが、それぞれ見つけやすさ、対応のしやすさが異なります。
それでは、その３つのハードルについて説明します。
ハードル１：変換観点(見つけやすさ：〇 対処しやすさ：〇)
これは一番わかりやすいですね。移行前と移行先では、使用できる関数が異なったり、そのDBでしか使用できないSQLがあったりしますので、同等の仕組みを移行先DBで考える必要があります。簡単な置換で済むものから、複雑なため手作業で直す必要があるもの、同じ機能がないためアプリケーション含めて修正が必要なものまでパターンは多岐にわたります。重要な点は以下の2点です。
- 事前のアセスメントで移行難易度の高いオブジェクトがないか確認する
- 変換パターンを洗い出し、作業工数を明確にする
１については、「外部のJAVAソースを利用している」「MVの高速リフレッシュを利用している」など、移行先のDBにはない機能を多用している場合、移行そのものが難しくなるケースがあります。その場合、異種DBマイグレーションは行わないという決断も重要です。
２については、機械的な変換を行い効率化することで短縮化すること、手作業の変換にどれくらいかかるかを想定し、事前に作業工数を明確化することです。変換ツールを用いることでより効率的に変換することもできます。この変換観点についてはDDLやDMLを実行するとエラーになるので、見つけやすいので早めの対処もできます。
ハードル２：仕様観点(見つけやすさ：△ 対処しやすさ：△)
移行元と移行先での仕様差異により、同じSQL文でも結果が異なるケースです。注意点として、ハードル１と違いSQLの実行時にエラーは出ません。そのため、アプリケーションの単体テストまで気が付かず、対処が遅れるケースも考えられます。事前に差異を把握し、移行方針を検討しておくことが重要です。代表的なものとしては、NULLと空文字の扱い、除算の結果の持ち方などがあります。
ハードル３：性能観点(見つけやすさ：× 対処しやすさ：×)
見つけ方も対処も一番難しいのが性能です。性能テストについては、本番と同じ規模のデータやワークロードが必要なため、性能テスト自身がそもそも大変なことは皆さんもご存じかと思います。これは、異種DBマイグレーションについても例外ではありません。オプティマイザの実装はDBごとに異なりますので、実行計画ももちろん異なります。そのため、移行後に予期せぬ性能劣化に出会う事があるのです。
特にOracle DBでは、非効率なSQLを記述していてもオプディマイザによって最適なSQLに内部で書き換えてくれるケースもあり、性能テストによってはじめて問題が発覚するケースも少なくありません。社内やプロジェクト内で、共通のSQLの記述規約を持っていなかったり、一般的なSQLのアンチパターンを知らない経験の浅いエンジニアが書いていたSQLがありそうなケースは要注意です。もちろん、オプティマイザの違いによる得意不得意のSQLもありますので、DBの違いによる性能劣化の可能性もあります。このような事象に対応するため、事前にPoCを通して、現在記述しているSQLに問題がなさそうか確認する必要があります。
まとめ
3つのハードルで重要なのは、上記のハードルを事前に把握し、PoCなどを通してリスクを軽減し、移行実現性を確認しておくことです。
SCSKでは、Oracle DBからPostgreSQLへの移行実績があり、このそれぞれのハードルに対する知見が蓄積されています。このノウハウは、他DBからAlloyDBへの移行の際にも大いに役に立つ情報です。AlloyDBへの移行を検討中の方、是非ご相談ください。