OCI Application Migration

解決する課題

OCI Application Migration（後に Classic Migration Service へ改称）は、Oracle Cloud Infrastructure Classic（OCI-C） などの旧世代環境で稼働していた Oracle の PaaS アプリケーションを、現行の OCI へ移すためのマネージドな移行サービスでした。

• 旧 OCI Classic 上の Oracle Java Cloud Service（JCS）や SOA Cloud Service（SOACS）、Integration Classic などを、手作業の再構築なしに現行 OCI へ移したい
• 移行対象のアプリを**ソース環境から自動で発見（ディスカバリ）**して棚卸ししたい
• 移行作業を1 つのワークフローとして管理し、進捗や失敗を追跡したい

主要概念と用語

• OCI Classic（OCI-C）: Oracle Cloud の旧世代基盤。本サービスはここで動く PaaS アプリの移行元として扱った
• ソース（Source）: 移行元の環境を表すリソース。OCI Classic 環境などへの接続情報を保持し、移行できるアプリの一覧を発見する
• アプリケーション発見（Discovery）: ソースに登録された環境から、移行可能なアプリ（JCS・SOACS・Integration Classic など）を列挙する工程
• 移行（Migration）リソース: 1 つのアプリを移行元から OCI へ移す、エンドツーエンドのワークフローを表す設定単位
• 移行の実行（Migrate Application）: 移行リソースに基づき、対象アプリを実際に OCI 上へ移し替える操作
• ワークリクエスト（Work Request）: 移行のような非同期操作の実行状況を追跡する仕組み。進捗・ログ・エラーを参照できる
• JCS / SOACS / Integration Classic: 移行対象となった代表的な Oracle PaaS サービス（Java Cloud Service、SOA Cloud Service、Integration Classic）

仕様・制限・クォータ

• 主たる用途は OCI Classic（および Oracle@Customer）上の Oracle PaaS アプリを OCI へ移行することで、汎用的な VM 移行やデータベース移行を目的としたサービスではない
• 移行できるアプリの種類は、JCS・SOACS・Integration Classic などサービス側がサポートする範囲に限られた。対応バージョンや前提条件はサービスのサポート範囲に依存する
• ソース環境への接続情報と資格情報が必要で、発見と移行のためにソースへ到達できることが前提となる
• 操作はソースと移行という 2 種類のリソースを中心に構成され、非同期処理はワークリクエストで追跡する
• テナンシ/リージョンごとに**サービス制限（リミット）**があり得たが、本サービスは提供を終了しているため、新規の制限引き上げ等は対象外となる

内部の仕組み

• 利用者はまずソースを作成し、移行元（OCI Classic 環境など）への接続情報を登録する
• ソースに対してアプリケーション発見を行い、移行可能なアプリの一覧を取得する
• 移したいアプリごとに移行（Migration）リソースを作成し、移行先や構成を設定する
• **移行の実行（Migrate Application）**を呼び出すと、対象アプリが OCI 上へ移し替えられる。この処理は非同期で進む
• 進行中の処理はワークリクエストで状態・ログ・エラーを確認でき、失敗時はログから原因を切り分けられた
• ソースと移行はそれぞれコンパートメント間で移動でき、IAM による権限管理の単位に合わせて配置できた

設計パターン / ベストプラクティス

• 移行前に発見（ディスカバリ）でアプリを棚卸しし、対象範囲と前提条件を把握してから移行に進む
• 本番移行の前に、検証環境で一度通して所要時間と手順を確認する
• ソースへの接続資格情報は**OCI Vault（Secrets）**で管理し、平文で扱わない
• 移行はワークリクエストで追跡し、失敗時はログから原因を特定して再実行する
• 移行後はアプリの動作と設定を検証してから旧環境を停止する
• 現行の移行ニーズに対しては、本サービスではなく OCI Cloud Migrations（VM 移行）や OCI Database Migration（DB 移行） など、目的に合った現行サービスを選定する

運用・監視

• 移行や発見などの非同期処理はワークリクエストで進捗・ログ・エラーを確認し、失敗時は該当処理のログから切り分ける
• 接続エラー時は、ソースの接続情報・ネットワーク到達性・資格情報を順に確認する
• イベントや通知と連携し、移行の完了・失敗を検知して運用フローに組み込む
• 切り替え後は旧環境をすぐ削除せず、一定期間は切り戻し可能な状態で保持する

コスト

• 移行そのものよりも、移行先で稼働させる OCI 上のリソースが継続コストの主因となる
• 本サービスは提供を終了しているため、新規の移行コストは発生しない

セキュリティ

• ソースへの接続資格情報は**OCI Vault（Secrets）**で管理し、平文で保持しない
• 操作権限は IAM ポリシー（グループ/動的グループ＋ポリシー）で最小権限に設計し、ソースや移行リソースへのアクセスを限定する
• 移行先の OCI リソースでは保存時暗号化・転送時の TLS を有効にし、移行後も暗号化された状態を維持する
• 接続元は**セキュリティリスト / ネットワークセキュリティグループ（NSG）**で必要最小限に絞る

関連サービス・比較

OCI Application Migration は OCI Classic 上の PaaS アプリ移行に特化していました。汎用的な VM 移行を一元管理する現行サービスは OCI Cloud Migrations であり、用途が異なります。

• 旧 PaaS アプリの移行という限定的な用途だったため、AWS に厳密な相当サービスはない。汎用的な VM 移行という観点では OCI Cloud Migrations が現行の選択肢となる
• データベースの移行が目的であれば OCI Database Migration、ファイル/オブジェクトの大量転送であれば OCI Data Transfer など、目的別の現行サービスを選ぶ

ハンズオン / CLI例

提供終了済みのサービスのため、以下は当時の oci CLI による操作イメージを示す参考例です（現在は実行できません）。

# ソース（移行元の OCI Classic 環境）を作成
oci application-migration source create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name source-occ \
  --source-details file://source-details.json

# ソースから移行可能なアプリを発見（列挙）
oci application-migration source list-source-applications \
  --source-id "$SOURCE_OCID"

# 移行（Migration）リソースを作成
oci application-migration migration create \
  --compartment-id "$COMPARTMENT_OCID" \
  --source-id "$SOURCE_OCID" \
  --application-name my-jcs-app \
  --display-name jcs-to-oci

# 移行を実行し、ワークリクエストで状態を追跡
oci application-migration migration migrate-application \
  --migration-id "$MIGRATION_OCID"

oci work-requests work-request get \
  --work-request-id "$WORK_REQUEST_OCID"