オンプレミスからクラウドへ：Oracle DB移行の課題と解決アプローチ / 開発者向けブログ・イベント

自己紹介

こんにちは。Javaバックエンドエンジニアとして、APIやバッチの開発・運用に携わっています。今回は、オンプレミスのOracle DBをOracle Cloud Infrastructure（OCI）へ移行する際に直面した一部の課題と、その解決策についてご紹介します。

概要

オンプレミス環境からOCIへの移行は、多くの企業にとって重要なプロジェクトです。その過程では、通信レイテンシの増加や限られたリソースによる検証の難しさ、外部システム連携の制約など、様々な技術的課題が存在します。本記事では、Webアプリケーションの観点からこれらの課題にアプローチし、ドメインレジストラ業務のバッチ処理を例に挙げて性能検証を行った事例を紹介します。

1. オンプレミスからOCIへの移行における課題
2. Webアプリケーションにおける稼働制約と検証戦略
3. 検証手順と計算方法の詳細
4. 重要バッチ処理の性能評価と課題対応
5. 移行プロジェクトを成功させるためのアドバイス
6. まとめ

1. オンプレミスからOCIへの移行における課題

Oracle DBの移行に際しては、通信レイテンシの増大という一般的な課題があります。またレガシーシステムの場合、外部システムとの連携部分をスタブで代替することが難しいことがあるため、効率的な検証手順を構築する必要があるかもしれません。そのためクラウド移行にはシステム間の複雑な調整が求められます。

2. Webアプリケーションにおける稼働制約と検証戦略

外部システムとの連携が難しい状況において、プロジェクトでは概算に基づく性能検証を行いました。具体的にはドメインレジストラとして重要でかつ通信レイテンシの影響を受けやすい対象としてドメイン廃止と自動更新バッチが1日以内に完了することを目標に、OCI環境でのパフォーマンスを確認しました。

3. 検証手順と計算方法の詳細

OCI移行によって増加する遅延を見積もるため、以下のデータを確認しました。

過去1年間のバッチ処理の最大実行時間を確認
過去1年間の最大ドメイン数の確認
SQL実行数の抽出
通信レイテンシの確認（DB側の事前検証で実績値あり）

これらのデータを用いて、通信レイテンシの影響を次の式で算出しました。

OCIでの遅延分時間 = SQL数 * ドメイン数 * 通信レイテンシ

OCIにおける最大実行時間 = OCI遅延時間 + バッチ処理の最大実行時間

※検証の過程でSQL実行数の抽出の際、ログのSQLログを確認した際に想定よりも少ない数であることが判明しましたが、これはORM(Object-Relational Mapping)のデフォルト機能である遅延ロード分の出力漏れが原因であっため、ORMを用いたアプリケーションでは注意が必要です