データベースマイグレーションの進め方

最近、お客様からデータベースのマイグレーションについての相談を受けることが多くなっています。
お客様ごとにビジネス状況が異なるため事情は様々ですが、高額なコストがネックとなりマイグレーションを判断されることが多いようです。

今回はお客様からも要望の多い、オンプレミスのOracle ExadataからクラウドのAmazon RDSへのマイグレーションのプロセスを解説します。

なぜオンプレミスのOracle Exadataからマイグレーションする必要があるのか

・Amazon RDSへのクラウドシフトのメリット
　Oracle Exadataは、Oracle Databaseに最適化されたソフトウェアとハードウェアで構成されるデータベースプラットフォームです。
　オンプレミスのExadataは非常に高い処理性能を実現していますが、同時にライセンスやハードウェアも高価になります。さらに、アプリケーションがクラウド環境に存在する場合は、オンプレミス→クラウド間に専用線が必要となり、この専用線にコストもかかり、回線障害のリスクが伴います。
　オンプレミスからクラウドへのマイグレーションにより、サーバーや専用線の削減につながるため、コスト面において大きな減額につながります。また保守面においてもハードウェアの保守、運用負荷が軽減できます。

　お客様からはAWSへのクラウド化をご希望されるケースが多くありますが、オンプレミスのExadataからAmazon RDSへのマイグレーションでも同様に、コスト削減、可用性/保守面において大きなメリットを得ることができます。

マイグレーション方法

マイグレーションへの技術的アプローチとしては、主に以下の方法が考えられます。

　・Oracle Databaseのパフォーマンス・データの分析
　　AWR（Automatic Workload Repository)を使用して、現状のデータベースのワークロード分析とOracle Exadataの固有機能によるパフォーマンス影響を分析します。

　・パフォーマンス課題抽出と対応策の検討
　　AWR分析結果をもとに、マイグレーション前にパフォーマンス課題をできるだけ解決し、対応策を検討しておきます。マイグレーションの難易度を下げることでコスト抑制にもつながります。

　・マイグレーション先Oracleサービス選定とサイジング
　　Oracle Exadata機能への依存度などを考慮し、移行先のデータベース製品、インフラアーキテクチャ、ライセンス、サイズなどを選定します。

　・AWS Database Migration Service等のマイグレーションツールの選定
　　現状のデータ構造、マイグレーション先の選定状況により実施の可否を決定します。

データベースマイグレーションのステップバイステッププロセス

マイグレーションの流れは、次の通りです。

①　インフラ観点でマイグレーション方法や環境を検討し、開発環境にてデータマイグレーションを実施します。
②　マイグレーション実施後、正しくマイグレーションが行われているかを検証します。
③　アプリ観点で接続を含む改修方法を検討し、機能的なテストを実施します。
④　①～③の完了後、パフォーマンステストを行い、結果を得てチューニングを実施します。 
⑤　チューニングは繰り返し実施し、性能面での問題を洗い出して、本番環境でのマイグレーション時のリスクを軽減します。

リスクと対策

データマイグレーション時にリスクとなりえるものは事前にチェックを行い、対応することが重要です。チェックポイントを見てみましょう。

◇データマイグレーション
・巨大なテーブルはないか？
　巨大なテーブルは、マイグレーションをする際に時間がかかります。
　本番環境ではテーブルが大きいと、マイグレーションにかかる時間にばらつきが出てしまう場合があり、マイグレーションスケジュールに大きな影響が出る可能性があります。

・更新頻度の多いテーブルはないか？
　更新頻度が多いテーブルの場合、同期に時間がかかってしまい、こちらもまたマイグレーション完了までのスケジュールに影響が出る場合があります。

【マイグレーション時間が長期化した場合】
　マイグレーション時間の長期化に伴うサイト停止時間の延長
　　→停止時間を最小限にするためにマイグレーション方法の検討が必要。

◇データ構造
・特殊なファイル構造やテーブル構成はないか？
　Amazon RDS for OracleはOSにログインができないためサーバー内のファイルにアクセスができません。Oracleの内部ファイルをカスタマイズして、特殊なファイルアクセスを行っている場合などは改修が必要です。

【ファイルアクセスに伴う問題が顕在化した場合】
　クラウド化に伴うプログラム修正の必要性
　　→事前に確認し、アプリケーション検証時に合わせて試験を行う。

◇SQL観点
・複雑なSQLはどの程度存在するのか、ロングランをしているSQLはないか？
　Exadataの時点でロングランをしているSQLは、 Amazon RDSへ移行した際に更なる性能劣化を引き起こす可能性があります。

・フルスキャンをしているSQL、もしくはボリュームの大きいレンジスキャンはないか？
　ExadataはSmart Scanにより、大量データの検索を高速で処理できます。
　そのためSQLによっては、索引検索を行うより、フルスキャンのほうが早い場合もあります。
　ただ、これは通常のパフォーマンスチューニングの考え方とは異なるため、 Amazon RDSに移行したときに本機能が使用できなくなることで、大幅な性能劣化が発生する場合があります。

【顕在化した場合】
　SQLの性能劣化
　　→事前にチューニングを行い、実行計画などを性能測定時に検証する。

テスト方法

検証環境及び本番環境における試験を検討します。

◇マイグレーション後のテストのポイント
・機能試験
　基本的には、対象アプリケーションの機能試験は必須です。
　普段利用している全機能試験などがあれば本試験への流用は可能です。
　また、試験範囲をどの程度にするかについても判断が必要です。
　マイグレーション期間と合わせて、全機能網羅的に試験するか、主要機能を中心にピックアップして実施するかを判断します。
　なおアプリケーションの改修を行う場合は、網羅試験に加えて改修箇所の試験を行います。

・データ整合性試験
　検証環境でのマイグレーションにおいて、マイグレーションデータの整合性を確認する試験を実施する必要があります。
　テーブルごとのデータの件数及びピックアップしたデータの内容を確認します。
　このテストは本番での実施試験にも流用できます。

・性能試験
　検証環境での性能試験は重要です。
　例えば、現状で処理に時間がかかっているバッチについては、処理時間の測定が必要です。

　Web機能の負荷試験において、参照系の機能試験を優先して実施します。
　更新系処理の試験は本番環境での実施が難しいため、優先度を下げて検討します。
　試験は、パフォーマンステストツールを用いて行います。
　負荷テストツールはApache JMeterなどを用いて実施するとよいでしょう。

　アプリケーションを利用した試験が難しい場合は、SQLのみを抽出し、疑似的にSQLのみを多重実行することで負荷状況を確認します。
　この時にAmazon RDS Performance Insightsを用いて、負荷の高いSQLを特定し、チューニングを実施します。

注意が必要なポイント！！

　・AWRを用いて適切に現行システムの分析を行うことで、サイジング、パフォーマンスなどのリスクを回避できる
　・ボリュームや更新頻度によって、移行時間に影響が出やすいため注意が必要
　・Smart Scanによって高速に動作しているフルスキャンSQLの性能劣化には注意が必要

最後に

　オンプレミスのOracle ExadataからAmazon RDSへのクラウドシフトは、コスト面、可用性において大きなメリットを享受できる一方、マイグレーション作業には大きなリスクを伴います。
　ただし、各工程において正しい手順で実施することで、マイグレーション作業のリスクは軽減できます。
　リリース後も継続的に運用保守していく必要がありますが、クラウド化することによりハードウェアの運用から解放されるためメリットは大きいです。

　富士ソフトのBizDevOpsサービスでは、クラウドの運用保守の面においても長年の経験を活かして支援します。オンプレミスのOracle ExadataからAmazon RDSへのクラウドシフトでは、運用保守までを意識したシステム開発のベストプラクティスを提供し、ビジネスの成果に直結するシステムの安定化に貢献します。

　オンプレミスのOracle　ExadataからAmazon RDSへのクラウドシフトなどで不明点がございましたら、富士ソフトBizDevOpsにご相談ください。

富士ソフトBizDevOpsはこちら

 

 

この記事の執筆者