商用DB→OSS DB（オープンソースDB）マイグレーションのススメ
クラウドサービスを利用している企業では、更なるコストメリットを求めてライセンス費用の削減も検討課題の一つである。
特に、商用データベースをご利用されている企業では、毎年発生する保守費用が年々増加傾向にあり、コスト負担も大きいことから、OSS DB(オープンソースDB)へのマイグレーションを検討するも、DBエンジンを変更する事への難易度が高いこと、DBを利用している各周辺システムの影響が大きいなど、移行へのハードルが高いと考え、毎年高額な保守費用を計上している企業は少なくない。
ここでは、商用DBからOSS DBへ切り替えた事例をご説明し、どのようなステップでDB移行を実現したのか、そのノウハウを一部ご紹介する。
商用DB→OSS DB（オープンソースDB）マイグレーションのススメ
はじめに
オンプレの商用DBがEOSを迎えるにあたり、特に商用DBのライセンス・保守費用を削減したいユーザーにとっては、MySQLやPostgreSQLなどOSS DBが一つの選択肢として、検討するだけの機能を有するようになってきた。
また、運用負荷の軽減も考慮すると、OSS DBのAWSマネージドサービスを利用することが有効な手段となる。
1．OSS DBのAWSマネージドサービスを利用するメリット
OSS DB の AWSマネージドサービスの選択肢としては、Amazon Aurora（MySQL/PostgreSQL）、Amazon RDS（MySQL/PostgreSQL）がある。それらを使用することで、以下のメリットが考えられる。特に、Amazon Auroraでは、高可用性、高拡張性が実現できる。
- 商用DBで発生していた高額なライセンス(初期/保守)費用が不要
- ハードウェア管理／保守期限による入れ替え、OS・ソフトウェアのパッチ適用作業からの脱却
- Auroraに限り、3つのAZに6個のレプリケーションデータを保持し、フェイルオーバーを30秒以内で完了する高可用性
- Auroraに限り、最大64TBまで自動的にストレージをスケールする拡張性
2．導入ステップ
ステップ１は、使用するデータベースが変わることにより、オブジェクトの変換が必要となること。変換を手動で実施するのは膨大な作業で非現実的なため、AWSから提供されている 変換用のツール 「AWS Schema Conversion Tool」を使用して、自動変換を行う。
その結果、変換出来ないオブジェクトが出た場合、手動変換することで作業量を削減できる。そして、オブジェクト変換が終わった対象アプリケーションから動作を確認する。
次のステップ2で、ソースDB(移行元)データをターゲットDB(移行先)のデータ形式に合わせて変換してデータ移行を行うため、「AWS Database Migration Service」を使用する。
（ア）ステップ１：オブジェクト変換
- AWS Schema Conversion Toolを使用し、スキーマ、ビュー、ストアドプロシージャ、ファンクションをターゲットDBに自動変換
- 自動変換処理の結果、誤った変換や、変換されないオブジェクトもあるので、その際は手動で書き換えを行う
（イ）ステップ２：データ移行
- ソースDBデータをターゲットDBのデータ形式に合わせて変換し、データを移行
（ネットワーク環境や、データ量、停止できる時間により、最適な方法を検討）
※AWS Database Migration Serviceは、トランザクションをオンラインで移行することも可能
3．導入事例：製造業S社
「2．導入ステップ」でご紹介した手法の導入事例として、製造業S社のオンプレミスSQL ServerからAmazon Aurora (MySQL)へのマイグレーションをご紹介する。
利用ユーザー数は約2千名、データ容量は約2TBを保有しているDBであった。
Amazon Aurora MySQLを採用した理由として、以下の背景があった。
- 年々データが増加していく
⇒Amazon Auroraでは、自動的に64TBまで拡張し、利用したデータ量のみ課金される - 各国のリージョン間でデータを共有したい
⇒Amazon Auroraのクロスリージョンレプリケーションを利用する - 過去データを蓄積し、ビッグデータ基盤となるデータレイクを活用した多角的な分析構想
⇒Amazon Auroraが、S3バケットとの親和性が高い
構成図
次フェーズ構成図：東京リージョンのAurora MySQLを複数の他リージョンへレプリケーション
（ア）ステップ１：オブジェクト変換
- SQL ServerからAurora MySQLへ、移行対象テーブルのテーブル定義を変換する。
検証環境で、AWS Schema Conversion Toolを使用して、テーブル定義の変換を実施し、Aurora MySQLに各テーブルを作成した。
今回実施したSQL ServerからAurora MySQLへのデータ型の変換では、AWS Schema Conversion Toolの自動変換のままで問題は発生しなかった。
（イ）ステップ２：データ移行
- DMSの検証結果より、膨大なデータ量と停止時間を要件が惜しくも達成できず、データ移行バッチを作成し、データ移行を実施
- ①データの抽出・圧縮
- ②データの転送
- ③データの取込
データ量が膨大なため、オンプレSQL Serverから直接VPC上のAurora MySQLにデータを取り込むと、データ転送に膨大な時間がかかるため、①のオンプレ側でデータの抽出・圧縮してからVPC上にデータ転送することで、②のデータ転送時間を大幅に軽減させた。
おわりに
今までは、一律Oracle、SQL Serverなどの商用DBを使用するのが一般的で、高額なライセンス・保守費用を払うしかなかったが、使用用途により、OSS DBが一つの選択肢として、考えられるようになった。
使い慣れた商用DBからOSS DBへの切り替えは、新たな技術を習得する必要が生まれるが、それ以上にハードウェア管理／保守期限による入れ替えや、ライセンス(初期/保守)費用の削減は、同一環境で長期利用する上でメリットが大きい。
また、AWS上のサービスを利用することで、国を跨るデータのやり取りなど、簡易に設定のみで実現できるのも魅力的である。
AWSのDBを検討する際には、ぜひ、OSS DBへのマイグレーションも１つの候補として、検討いただきたい。
ノウハウの一部をご紹介させていただいたが、安全に移行するには、各環境の特徴を考慮し、移行する必要がある。
当社が提供するDBマイグレーションサービスでは、お客様のシステムにとって最適な移行方法を考えながら、DB移行を実現します。
AWS上でのDB移行を計画する際には、お気軽にご相談ください。
DBマイグレーションサービス：
https://ecloudp.com/service/db_migration.html
DBマイグレーション 他の導入事例：株式会社ドトールコーヒー様
https://ecloudp.com/media/customer/sector06/a56
以 上
