はじめに

  • こんにちは、エンタープライズクラウド事業部の新川です。先月5月23日に開催されたOracleのDeveloper Day 2025 に参加しました。今年のDeveloper Day 2025は、日本オラクル株式会社でオフラインのみ開催されました。
  • 本記事は、私の2つ目のイベントレポートです。15:05–15:45 に行われたブレイクアウトセッションの[T1-2]になります。今回特に、注目していたセッションになります。
    • タイトル: AWSからOCIへの移行を成功に導く！クラウドマイグレーションのベストプラクティス
    • スピーカー: 日本オラクル株式会社　山田 様、新井 様

 

セッション概要

  • セッションの冒頭で、私は1枚目のスライドにくぎ付けになりました。AWS、Azure、Google Cloud といった他のパブリッククラウドからOCI へ移行した企業の具体的な名前とコスト削減率が示されました。まさに数字がOCI 移行の説得力を物語っていました！
  • 続いて表示された、『Cost Performance – AWS vs OCI』スライドでは、AWS でよく利用するサービスをOCI に置き換えた場合の具体的な金額が比較記載されており、その高いコストパフォーマンスが伝わってきました。この資料を見れば、まだOCI を利用したことがないユーザーでも、OCIへの興味が湧いてくること間違いなしです。

 

  • そして、「こんな資料を待っていた！」と感じたのは、 AWS のメジャーなサービスとOCI のサービスを対応付けしたサービスポートフォリオです。クラウドを利用する方であれば関心は高いでしょうから、手元に置いておきたい1枚です。
  • 補足ですが、OCI では公式サイトからAWS、Azure、Google Cloud のサービス比較を簡単に調べることができます。覚えておいて損はない情報です。

  • さて、ここからがセッションの本題です。前半では、AWS のEC2からOCI のCompute VM にマイグレーションするための考え方、具体的な移行方法の説明があり、後半にMySQL の移行方式について説明がありました。この記事では、前半部分に焦点をあててご紹介します。

 

EC2からOCI のCompute VM へ移行方式

移行の考え方

  • OCI Computeは、仮想マシンやベアメタルマシンなど、多様なコンピューティングリソースを提供するサービスです。AWS に例えると、Amazon EC2 に相当します。
  • Oracleでは、コンピュート・リソースを表す用語にOracle CPU（OCPU）があります。クラウド業界では仮想CPU（vCPU）を用いることが多いのですが、OCPUは物理CPUコアを指します。一般的にIntelやAMD のCPUではハイパースレッディング技術が有効なため、1つのCPUコアは2スレッドで動作します。このスレッドが仮想CPU（vCPU）と呼ばれます。AWSでは、コンピュート・リソースを仮想CPU（vCPU）で表すため、AWS のEC2からOCI のCompute VM へマイグレーションする場合、2 vCPU = 1 OCPU として換算が必要です。
  • OCIではフレキシブルシェイプが採用されており、OCPUの数・メモリサイズを柔軟にインスタンスへ割り当てることが可能です。ユーザーは必要なリソースを無駄なく利用できるため、コスト効率の面で非常に助かります。

移行の方式

  • Amazon EC2 からOCI のCompute VM へマイグレーションする場合、3つの移行方式が説明されました。まず、従来からある2つの移行方式についてです。
    • 1. 新規作成および手動移行
      • OCI にインスタンスを新規に作成し、rsyncやrcloneを利用し、手動でアプリケーションやデータを移行する方式。
      • メリットは移行に合わせて、OSバージョンの最新化が行えること。新規で作成するため、Oracleでサポートされるプラットフォームイメージが利用可能なこと。
      • デメリットはインスタンス作成からデータ移行まで、手動で作業が必要なこと。
    • 2. カスタムイメージ移行
      • AWSなど既存の環境から仮想マシンイメージを出力し、カスタムイメージとしてインポートする方式。
      • メリットはVMDK、QCOW2など仮想ディスクのファイル形式にできれば、様々な環境からOCIへの持ち込みが可能なこと。
      • デメリットは、イメージサイズに400GBまでの制限があること。大量のインスタンスを移行する場合、全体の作業量が多くなること。

 

  • 続いて紹介されたのは、3つ目の移行方式です。
    • 3. Oracle Cloud Migrations Service（略して、OCM）
      • OCM を利用して、オンプレミスや他社クラウドの仮想マシンをOCI のインスタンスへ移行するネイティブなサービスを利用する方式。
      • メリットはOCI コンソールからGUIベースで利用可能なこと。移行元であるAWS環境のAmazon EC2をOCIの管理画面で自動検出、可視化できる。
      • 自動でインスタンス作成からデータ移行まで行えること。そして、複数のインスタンスを一括で移行可能なこと。
    • OCMで理解すべきは、「制限された商業上合理的なサポート」であること。
      • これは、OCIでインスタンスを起動してsshでアクセスできる状態までのサポートとなります。公式サイトのこちらにも記載があります。
      • OSやアプリケーションレベルのサポートは含まれないため、その後の設定やトラブルシューティングはユーザー側で行う必要がありますね。
    • OCMでサポートされるソース環境、OSのバージョン、サポートされているターゲットのコンピュートシェイプについては、公式サイトの最新情報を参照ください。

  • OCMを使用した移行フローは、以下となります。
  • A→B→Cの3ステップで構成され、OCI コンソールから操作できることが魅力的です。

 

  • 紹介された3つの移行方式について、それぞれの特徴がまとめられたスライドもありました。
  • 移行方式は、移行の規模やOSのサポートを考慮しつつ、案件の要件に応じて最適なものを選択することが重要だと感じました。

MySQL の移行方式

まとめ

  • 今回のセッションを通して、他のパブリッククラウドから移行を意識したOCI サービスや資料が充実しており、多くのユーザーやエンジニアにとって関心が高く、刺さる内容だと感じました。
  • 特に、サーバーやデータベースのデータ移行はクラウド移行における大きな課題の1つになるため、Oracle Cloud Migrations Service（OCM）のようにデータ移行までカバーされたサービスや移行を支援するツールの存在は、大変魅力的に感じました。

押さえておきたい！

  • そして、今回のセッションで得た一番の収穫かもしれません。Oracleで移行プロジェクトに取り組んでいるクラウドエンジニアの方々がQiita に移行記事を作成されており、OCI クラウド移行ガイドとして、なんと！50件以上も公開されています。間違いなく、活用させていただきます！
  • 【OCI クラウド移行ガイド】 移行記事一覧 
  • AWSからOCIへの移行を検討されている方にとって、少しでも参考になれば幸いです。