OCI Cloud Migrations

解決する課題

オンプレミスや他クラウドで稼働している多数の仮想マシン（VM）を OCI へ移すとき、対象の棚卸し・移行可否の評価・実際の移し替えを場当たり的に進めると、抜け漏れや停止時間の超過、見積もりのブレが生じます。OCI Cloud Migrations は、これら一連の作業を 1 つのプロジェクトとして一元管理することで解決します。

• 既存環境にどんな VM が何台あるのか、CPU・メモリ・ディスク構成を自動で検出して棚卸ししたい
• 移行先 OCI でどの Compute シェイプが妥当か、概算コストはいくらか、移行できるかを事前に評価したい
• 本番を長時間止めずに、データをコピーしながら少ない停止時間で切り替えたい
• 多数の VM 移行の進捗を、誰がどこまで進んだかダッシュボードで可視化したい

AWS で言えば、移行全体の進捗を集約する Migration Hub と、サーバをブロックレベルでレプリケーションして移行する Application Migration Service（MGN） を合わせた役割に相当します。OCI ではこれらが Cloud Migrations という単一サービスにまとまっている点が特徴です。

主要概念と用語

• 検出（Discovery）: 既存環境の VM を見つけ出し、CPU・メモリ・ディスク・OS などの構成情報（インベントリ）を収集する工程。VMware vCenter などの仮想化基盤や他クラウドを対象にできる
• アセット（Asset）: 検出によって取り込まれた個々の移行対象（VM やそのディスク）を表す論理単位。インベントリ上で管理される
• 移行プロジェクト（Migration Project）: 一連の移行作業をまとめる入れ物。どのアセットを、どのコンパートメント・どの設定で OCI に移すかをこの単位で管理する
• 移行プラン（Migration Plan）: プロジェクト内のアセットに対する移行戦略。ターゲットの Compute シェイプ、ネットワーク、ストレージのマッピングや概算コストを定義する
• アセスメント（評価）: 各アセットが OCI に移行可能かをチェックし、推奨シェイプや概算コストを提示する工程
• レプリケーション（Replication）: ソース VM のディスクを OCI 側へ継続的にコピーする処理。ブロックレベルで差分を同期し続け、切り替え時の停止時間を抑える
• ハイドレーションエージェント / レプリケーションエージェント: ソース側やレプリケーション処理に用いるコンポーネント。ソースのディスクデータを OCI 側のターゲットへ転送する役割を担う
• カットオーバー（移行の確定）: レプリケーション済みのデータをもとに、OCI 上で起動可能な Compute インスタンスとして最終的に立ち上げる工程

仕様・制限・クォータ

• 主な移行対象は VM 単位のサーバ移行（リホスト / lift-and-shift） で、移行先は OCI Compute インスタンスになる。アプリの作り替え（リファクタ）を行うサービスではない
• ソース環境としては VMware（vCenter）系の仮想基盤や他クラウドの VM などを検出・移行対象にできる。対応するソースの種類やバージョンは更新されるため公式ドキュメントを確認する
• レプリケーションはブロックレベルの継続同期で、初回フルコピー後は差分を取り込み、停止時間（カットオーバー時の最終同期）を小さくできる
• 移行はリージョン・コンパートメント単位で管理される。同時に扱えるアセット数や進行中のレプリケーション数などにはサービス上の上限があり、大規模移行では波（ウェーブ）に分けて段階移行するのが定石
• 検出・評価で得られるシェイプ推奨や概算コストは目安であり、実際の最終的なサイジングは性能要件に応じて見直す
• 具体的な対応ソース・上限値・推奨スペックなどは変動するため、断定せず公式の最新値を参照する

内部の仕組み

Cloud Migrations は、大きく 検出 → 評価 → レプリケーション → カットオーバーの流れで動きます。

• 検出フェーズでは、vCenter などのソースに接続して VM のインベントリを収集し、アセットとして取り込む。これにより移行対象の全体像（台数・スペック）が把握できる
• 評価フェーズでは、各アセットに対して移行可否をチェックし、ターゲットの推奨 Compute シェイプと概算コストを算出する。移行プランとしてターゲット設定（ネットワーク・ストレージのマッピング）を整える
• レプリケーションフェーズでは、ソース VM のディスクをブロックレベルで OCI 側へコピーする。初回はフルコピー、その後は差分を継続的に同期し続けるため、ソースを動かしたままデータを先行転送できる
• カットオーバーでは、同期済みデータをもとに OCI 上で Compute インスタンスとして起動する。直前に最終差分を同期してから切り替えるため、停止時間を短くできる

レプリケーション中はソース側のディスクデータが OCI のターゲット（ボリューム）へ転送され、最終的にブート可能なインスタンスとして組み上げられます。進捗や状態はプロジェクト単位で集約され、各アセットの段階（検出済み・評価済み・レプリケーション中・移行完了）が一覧できます。

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

• ウェーブ（波）分割で段階移行: 全 VM を一度に移さず、依存関係の小さいシステムから小さな単位で移行し、手順とリスクを検証しながら拡大する
• 依存関係を先に整理: 相互に通信するシステムは同じウェーブにまとめ、移行中に片方だけ OCI、もう片方はオンプレという分断状態が長く続かないようにする
• 事前にテスト移行: 本番カットオーバー前にテスト用に起動して、起動・ネットワーク・アプリ動作を確認してから本番を切り替える
• ネットワーク経路の確保: レプリケーションのデータ転送量は大きいため、十分な帯域を確保し、必要に応じて FastConnect などの専用接続で安定させる
• 評価結果を鵜呑みにしない: 推奨シェイプは目安なので、ピーク性能要件に合わせて手直しし、過剰・過少サイジングを避ける
• 移行後の最適化を前提に: まずリホストで OCI に載せ、その後でマネージドサービス（Autonomous Database や OKE など）への置き換えを段階的に検討する

運用・監視

• 移行の進捗はプロジェクト/アセット単位の状態（検出済み・評価済み・レプリケーション中・完了）で追跡する。多数 VM の全体像をダッシュボードで把握する
• レプリケーションの進捗と差分同期の遅延を監視する。回線の細さやソース負荷で同期が滞ると、カットオーバー時の停止時間が伸びる
• 操作の記録（誰がいつ移行プロジェクトを変更・実行したか）は OCI Audit で追跡する
• 主要な状態変化を Events で受けて Notifications に通知し、レプリケーション失敗やカットオーバー完了をチームに知らせる運用にできる
• 移行後インスタンスは通常の OCI Compute として Monitoring / Logging で監視対象に組み込み、移行前の性能・可用性と比較する
• 失敗時の切り分けは、(1) ソースへの検出接続、(2) ソースから OCI へのレプリケーション経路と認証、(3) ターゲット側のシェイプ・容量・権限、の順で確認する

コスト

Cloud Migrations の移行管理機能そのものよりも、移行先で稼働させる OCI リソースとデータ転送・一時的な二重稼働がコストの中心になります。

セキュリティ

• IAM ポリシーとコンパートメントで、移行プロジェクトを操作できる主体と、移行先となるコンパートメント・リソース範囲を最小権限に絞る
• ソース環境（vCenter など）へ接続するための資格情報は安全に管理し、機密値は Vault（Secrets） に保管して直書きを避ける
• レプリケーションの転送経路を保護する。データ転送は暗号化された経路で行い、必要に応じて FastConnect や VPN で経路を閉域化する
• 移行先の Compute / Block Volume はデフォルトで保存時暗号化され、Vault（KMS）の顧客管理キーも利用できる
• 移行後インスタンスは、移行前の古い認証情報やローカルアカウントが残りやすいため、移行を機に資格情報をローテーションし、不要なものを削除する

Well-Architected の観点

• 運用上の優秀性（Operational Excellence）: 検出・評価・移行をプロジェクトとして一元管理し、進捗を可視化して属人化を防ぐ。ウェーブ単位の手順化で再現性を高める
• 信頼性（Reliability）: ブロックレベルのレプリケーションとテスト起動により、停止時間を抑えつつ移行の確実性を高める。失敗時はやり直し可能な単位で進める
• セキュリティ（Security）: 最小権限の IAM、資格情報の Vault 管理、転送経路の保護、移行後の認証情報ローテーションで安全に移し替える
• コスト最適化（Cost Optimization）: 事前評価で適切なシェイプを選び、二重稼働期間を短縮して重複コストを抑える

試験で問われるポイント

関連サービス・比較

OCI Cloud Migrations は、AWS では役割が 2 つのサービスに分かれている領域を 1 つにまとめています。全体の集約は Migration Hub、移行実行は MGN に相当します。

OCI 内では、移行先の Compute / Block Volume、経路確保の FastConnect / VPN Connect、機密管理の Vault（Secrets）、進捗連携の Events / Notifications、監査の Audit と組み合わせて使います。移行後の最適化として Autonomous Database や OKE などのマネージドサービスへの置き換えも視野に入れます。

ハンズオン / CLI例

検出ソースや移行プロジェクトは oci cloud-migrations 配下のコマンドで操作できます。次は移行プロジェクトを作成し、内容を確認する例です（リソース名はサブコマンドのヘルプで確認しながら進めるとよいです）。

# 0) 利用可能なサブコマンドを確認（リソース名の把握に有用）
oci cloud-migrations --help

# 1) 移行プロジェクトを作成する
#    移行対象アセットや結果を入れる「入れ物」を用意する
oci cloud-migrations migration create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "onprem-vmware-wave1"

# 2) 作成した移行プロジェクトの一覧と状態を確認する
oci cloud-migrations migration list \
  --compartment-id "$COMPARTMENT_OCID" \
  --output table

# 3) 個別の移行プロジェクトの詳細を取得する
oci cloud-migrations migration get \
  --migration-id "$MIGRATION_OCID"

# 4) 検出ソースの登録やレプリケーションプランの作成は、
#    discovery-schedule / migration-plan などのサブコマンドで進める
#    （対象に応じて oci cloud-migrations <resource> --help で確認）