「脱商用データベース」オンプレミス運用の商用データベースをAWS上（PostgreSQL）へ！移行のポイントとは

商用データベース脱却

当社は３０年近く、「マイグレーション」をビジネスの一つの柱として取り組んできました。様々なアプリケーションのマイグレーションのご相談をいただく中で、近年は商用データベースから脱却していきたいというご相談が増えてきています。

特に、高額な費用をかけて、メーカーの保守サポートを受けながらオンプレミス環境で運用してきたミッションクリティカルなシステムをAWSのAurora（PostgreSQL）やRDS（PosgreSQL）に移行していきたいというご相談が増えてきています。

今回は、このような、オンプレミスで運用されてきた商用データベースをAWS上のPostgreSQLに移行していく際のポイントを解説していきたいと思います。

まず、データベースの種類を変更すると、定義体やSQL文が変わってしまう部分があり、アプリケーション側の移行も必要になってくるため、「データベースの移行」と「アプリケーションの移行」に分けて対応していく必要があります。

データベースの移行

オンプレミスのデータベースをAWS上の異なるデータベースに移行していくには、大きく以下の流れで進めていきます。

①SCTを使用した定義体の移行
②修正が必要な型定義の変換設計
③シノニムの代替設計
④ストアドプロシージャの変換設計～修正
⑤その他エラー個所の変換設計・修正
⑥DMSを使用したデータの移行

②修正が必要な型定義の変換設計 については、例えば、Number型からInteger型に変換されたフィールドについて、Integerの範囲である2,147,483,647を超える数字が入るのであればBigint型に変換するよう、定義を修正します。

③シノニムの代替設計 については、PostgreSQLではシノニムの概念がないため、基本的にViewで代替機能を実現するよう、設計します。

④ストアドプロシージャの変換設計～修正 については、一番苦労するところです。データベースの種類が変わると、記述内容が大きく変わってしまう部分があります。

当社では、ストアドプロシージャの規模にもよりますが、エラーとなる部分をパターン化し、パターンごとに一括変換できるツールを使用して修正を行っていきます。

アプリケーションの移行

アプリケーション移行では、データベースへの接続プログラムが変更になることはもちろんですが、上述の通り、SQL文が変わってしまう部分があり、プログラムの修正が必要となります。

SQL文の修正については、非互換となる構文が使用されているか、影響調査を行い、必要な修正を行っていきますが、動的にSQLを作成しているプログラムなどもあり、簡単に影響調査できない場合もあるため、必要に応じて、実際に発行されたSQLの履歴を取得し、そちらから調査を行います。

また、プログラム側変数の型定義の修正が必要となる場合など、SQLの構文以外にも対応が必要なケースがありますので、SQL修正後は現行と修正後のシステムで同様の動作をするか、全体的に比較して検証を行い、エラーとなる要素を抽出して対応を行っていきます。

プログラムの修正については、ストアドプロシージャの修正と同様に、基本的には非互換となるパターンごとに一括変換できるツールを使用して修正を行っていきます。

なお、ソート順の考え方などはデータベースの種類によって違いがあり、そのような個所は現行と合わせることが難しいため、事前にユーザー側にご了承いただきます。

このような商用データベースからの脱却については、SaaSやパッケージ製品で商用データベースを利用している企業からもご相談をいただくことが多くなってきました。

コスト削減としてはもちろん、運用のリスク低減に向けても、クラウド上のデータベースに移行を検討される企業が増えてきているようです。

現状のデータベースのコストや運用に課題があれば、クラウドOSSデータベースへの移行も、一つの解決策になります。。