OracleからPostgreSQLへのことなるRDBMSへのデータベースの移行に関する考え方を記載します。
#データベース移行の目標
OracleからPostgreSQLへのことなるRDBMSへの移行を実現する場合、RDBMSそのものの優劣を比較するのではなく、データベースを利用しているシステムそのものの目線で、「As-Is(現状)」と「To-Be（あるべき姿）」を把握する必要があります。この「As-Is(現状)」と「To-Be（あるべき姿）」に対するFit&Gap確認して、課題を明確化するようにします。
Fit&Gapの分析で出てきたGapに対して、Gapを埋めるために、どのように対処していくかを検討していきますが、To-Beに限りなく近づけることで、膨大な修正費用がかかってしまう事も多くあります。現実的な落としどころである「Can-Be（現実的解）」を模索することも重要です。
#移行タスクの全体の流れ
移行タスク全体の流れは大きく以下のような流れで進行させます。
また、実際の作業に取り掛かる前に、より全体の作業に対する規模感、スケジュール感などを算出するために、PoCを実施するのも有効な手段です。
PoCを実施する場合、現行調査フェーズ、計画フェーズ、移行検証フェーズの３つの観点フェーズを中心に実施する事になります。
また、可能な限り性能テストも行います。一般的にPL/SQLなどはOracleに比べてPostgreSQLの方がロジック実行にて遅くなることが多い為、どれぐらい遅くなるのか、ロジック実行の見直し（ループ処理などを１つのSQLで実行可能にするなど）による性能が改善可能かを確認します。
※移行検証フェーズに関してはPoCでは全て実施は行わず一部のみを対象とし全体を類推することもあります。
##現状調査
現状調査では主に以下の事を実施します。
-
現行リソースの調査
現状のサーバに搭載されているCPU数とメモリ、ストレージの容量を把握します。ここから、実際の利用状況を確認し、必要なCPU数、メモリ、ストレージを算出します。例えば、Oracle Databaseが4コア2CPUのサーバ上で稼働しており、CPU使用率が25%程度が最大の場合には、まずはAzure for PostgreSQLのスペックは2仮想コア程度からスタートするのが望ましいと考えられます。また、メモリ、ストレージに関しても現状利用状況と合わせた形でAzure for PostgreSQLのスペックを選定するのが望ましい事になります。足りなければすぐにスケールアップ可能なのもクラウドの大きなメリットな為、緻密に計算する必要は無くあくまで目安を立てるのが重要です。目安を立てるために、現状のスペック及び利用状況を把握します。- Azure for PostgreSQLでは最大接続数も重要
Azure for PostgreSQLでは最大接続数もスペック選定の重要な要素です。
スペックによって最大接続数が決まっています。
- Azure for PostgreSQLでは最大接続数も重要
-
ソースDBの調査
ソースとなるOracle DBの調査も重要な要素です。以下の項目を対象となるOracle DBから情報を収集し、移行できないオブジェクトの有無などの確認を行います。- オブジェクトの総数
- テーブルやインデックスの容量
- 文字コード
- 利用オプション
- 初期化パラメータ
- Dumpファイル（メタデータのみ）
特にDumpファイルは重要でこのDumpファイルのデータでメタデータのみのOracle Databaseのコピーを作成し、Ora2PGなどのツールにより自動でのマイグレーション変換率を計測します。
#移行難易度の判定
移行難易度は、主にこれらの要素により判定します。
移行元のOracleでOracle特有のオプションを利用していた場合、代替手段を考える必要がある為、移行難易度は上昇します。また、本番移行時の停止時間や、移行判定の基準等もヒアリングし、総合的な移行難易度を判定します。
同じデータ量、移行難易度でも、本番移行に丸1日かけることができる場合、移行後の確認等に時間を掛けることができますが、半日しか停止できない場合、移行後の確認にかけることのできる時間は減少してしまい品質の担保を工夫する必要が出てきます。
また、移行判定（パフォーマンスなど）が厳しい場合、移行リハーサル等を重ねてより洗練していく必要がありますので、難易度としては高くなります。
#移行コストの見積
移行難易度や移行までに準備できる期間等を考慮し、移行コストの見積もりを実施します。
POCの場合、POC対象としたシステムの移行結果などを踏まえ、実際の本番移行に向けた精緻なコストの見積を算出します。
#移行計画
実際に移行を行っていくうえで、計画をしっかり決め実施していく必要があります。PoCの結果やヒアリングした内容をもとに計画を策定していきます。
例えば、対象のシステムが保守期限切れになる場合には、期限切れになる前に移行をしなければなりません。そのために移行準備にかけられる期間・移行のテストにかけられる期間を算出し、移行までのスケジュールを決めておく必要があります。
また作業を実施する部署やベンダーが複数ある場合には、各作業の作業範囲を明確化して、役割分担をしておく必要があります。
その他にも本番移行時のシステムを停止しておける時間や、万が一システムの移行に問題があった際に復旧できるようにコンティンジェンシープランの策定、移行が完了した際に何を持って移行が成功しているのかを決めるための判定基準など決めておく必要があります。
#最後に
今回はデータベース移行までの流れを記載しました。
##次回は
移行時に使用するツール群について記載します。