※ 本記事は、Alberto Veratelliによる”Azure SQL Database migration to OCI: Resource estimation and migration approach“を翻訳したものです。

2024年2月1日

最近では、マルチクラウドおよび、あるハイパースケーラから別のハイパースケーラへの移行サービスが頻繁に行われています。お客様は、技術的にも経済的にも最良の結果を得たいと考えています。オラクルは最近、サービスをMicrosoft AzureからOracle Cloud Infrastructure (OCI)に移行したいお客様をサポートしました。Azure SQL Databaseをベースにしたワークロードはほとんどありませんでした。Azure SQL Databaseは、アップグレード、パッチ適用、バックアップ、モニタリングなど、ほとんどのデータベース管理機能を処理するフルマネージド型のPlatform-as-a-Service (PaaS)データベース・エンジンで、ユーザーの関与なしに利用できます。

ほとんどの場合、移行サービスとソリューションは、あるハイパースケーラから別のハイパースケーラに正確にマッピングすることを意味します。ハイパースケーラは、特に顧客に提供し、顧客にサービスを提供する方法において、多くの違いがあります。

特にAzure SQL Databaseの場合、デプロイメント・モデルは非常に重要であり、評価する必要があります。詳細は、次のオプションを参照してください:

  • 仮想コア (vCore)ベース: このデプロイメント・モデルでは、プロビジョニングされたコンピュート層かサーバーレス・コンピュート層かを選択できます:

    • プロビジョニングされたコンピュート層: ワークロードに対して常にプロビジョニングされるコンピュート・リソースの正確な量を選択します。

    • サーバーレス・コンピュート層: 構成可能なコンピュート範囲でのコンピュート・リソースの自動スケーリングを指定します。サーバーレス・コンピュート層は、ストレージのみが請求される非アクティブな期間にデータベースを自動的に一時停止し、アクティビティが返されたときにデータベースを自動的に再開します。単位時間当たりのvCore単価は、プロビジョニングされたコンピュート層のサーバーレス・コンピュート層の単価より低くなります。

  • データベース・トランザクション・ユニット (DTU)ベース: このデプロイメント・モデルは、一般的なワークロードに対してバランスの取れた、バンドルされたコンピュート・リソースとストレージ・リソースを提供します。

Charts comparing DTU and vCore models

このブログ投稿では、vCoreまたはDTUモデルでデプロイされたAzure SQL Databaseを移行する方法について調査しています。2つのモデルを分析してみましょう。これは、OCIへの移行アプローチを評価する際に重要です。

vCoreモデル

仮想コア(vCore)は論理CPUを表し、ハードウェアの世代と、コア数、メモリー、ストレージ・サイズなどのハードウェアの物理的特性を選択できます。vCoreモデルでは、柔軟性、制御性、個々のリソース消費の透明性、およびオンプレミスのワークロード要件をクラウドに変換する簡単な方法が提供されます。このモデルでは、ワークロードのニーズに基づいてコンピュート、メモリーおよびストレージ・リソースを選択できます。

SQL DatabaseのvCoreモデルでは、汎用、ビジネス・クリティカルおよびハイパースケール・サービス層を選択できます。詳細は、vCoreサービス層を参照してください。

vCoreモデルでは、コストは、次の要素の選択および使用方法によって異なります:

  • サービス階層

  • ハードウェア構成

  • コンピュート・リソース(vCoresの数およびメモリーの量)

  • 予約済データベース・ストレージ

  • 実際のバックアップ・ストレージ

DTUモデル

DTUモデルは、データベース・トランザクション・ユニット(DTU)を使用して計算コストを計算およびバンドルします。データベース・トランザクション・ユニット(DTU)は、CPU、メモリー、読取りおよび書込みの混合メジャーを表します。DTUモデルは、様々なレベルのアプリケーション・パフォーマンスを促進するために、事前構成された一連のコンピュート・リソースと含まれるストレージを提供します。事前に構成されたバンドルと固定支払を毎月シンプルにしたい場合は、DTUモデルがニーズにより適している可能性があります。

DTU購買モデルでは、Azure SQL DatabaseのBasic、StandardおよびPremiumサービス層を選択できます。詳細は、DTUサービス層を参照してください。ストレージはDTUの価格に含まれています。Standard層およびPremium層にストレージを追加できます。

リソース見積り

既存のAzure SQL Databaseワークロードの移行を評価する場合、それらをOCIにマップするためにリソースをサイズ設定するには、それらをどのように購入するかが重要です。vCore購入モデルは、vCoresなどのOCIリソースにOCPU、ストレージ、メモリーに簡単に変換できますが、DTUは変換されません。DTUモデルは、CPU、メモリー、読取り、書込みなど、様々なリソースの混合メジャーを表し、リソースのサイズ設定をより複雑にします。

次の変換に示すように、各層には、vCoreを必要とするDTUの数に関する様々な要件があります:

  • Basic層またはStandard層の100 DTUごとに、少なくとも1つのvCoreが必要です。

  • Premium層の125 DTUごとに、少なくとも1つのvCoreが必要です。

この規則は概算です。DTUデータベースに使用される特定のハードウェアは考慮されません。データベース・サイズを見積もる正しい方法は、各DTUデータベースで次のマッピング問合せを実行して、正しい数値を取得することです:

WITH dtu_vcore_map AS
(
SELECT rg.slo_name,
       CAST(DATABASEPROPERTYEX(DB_NAME(), 'Edition') AS nvarchar(40)) COLLATE DATABASE_DEFAULT AS dtu_service_tier,
       CASE WHEN slo.slo_name LIKE '%SQLG4%' THEN 'Gen4' --Gen4 is retired.
            WHEN slo.slo_name LIKE '%SQLGZ%' THEN 'Gen4' --Gen4 is retired.
            WHEN slo.slo_name LIKE '%SQLG5%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%SQLG6%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%SQLG7%' THEN 'standard_series'
            WHEN slo.slo_name LIKE '%GPGEN8%' THEN 'standard_series'
       END COLLATE DATABASE_DEFAULT AS dtu_hardware_gen,
       s.scheduler_count * CAST(rg.instance_cap_cpu/100. AS decimal(3,2)) AS dtu_logical_cpus,
       CAST((jo.process_memory_limit_mb / s.scheduler_count) / 1024. AS decimal(4,2)) AS dtu_memory_per_core_gb
FROM sys.dm_user_db_resource_governance AS rg
CROSS JOIN (SELECT COUNT(1) AS scheduler_count FROM sys.dm_os_schedulers WHERE status COLLATE DATABASE_DEFAULT = 'VISIBLE ONLINE') AS s
CROSS JOIN sys.dm_os_job_object AS jo
CROSS APPLY (
            SELECT UPPER(rg.slo_name) COLLATE DATABASE_DEFAULT AS slo_name
            ) slo
WHERE rg.dtu_limit > 0
      AND
      DB_NAME() COLLATE DATABASE_DEFAULT <> 'master'
      AND
      rg.database_id = DB_ID()
)
SELECT dtu_logical_cpus,
       dtu_memory_per_core_gb,
       dtu_service_tier,
       CASE WHEN dtu_service_tier = 'Basic' THEN 'General Purpose'
            WHEN dtu_service_tier = 'Standard' THEN 'General Purpose or Hyperscale'
            WHEN dtu_service_tier = 'Premium' THEN 'Business Critical or Hyperscale'
       END AS vcore_service_tier,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.7
            WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus
       END AS standard_series_vcores,
       5.05 AS standard_series_memory_per_core_gb,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
            WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.8
       END AS Fsv2_vcores,
       1.89 AS Fsv2_memory_per_core_gb,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.4
            WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.9
       END AS M_vcores,
       29.4 AS M_memory_per_core_gb
FROM dtu_vcore_map;

DTUモデルで購入された次の Azure SQL Databaseのサイズを設定する必要があるとします:

  • Standard S0: 10 DTUs

  • Standard S2: 50 DTUs

マッピング問合せでは、次のサンプル結果が返されます(わかりやすくするために非表示の列もあります):

 dtu_logical_cpus  

 dtu_memory_per_core_gb 

 standard_series_vcores 

 standard_series_memory_per_core_gb 

          0.50

                   1.30

                0.500

                             5.05

          1.00

                   2.65

                1.000

                             5.05

 

これら2つのデータベースをOCIにマップするには、standard_series列を考慮する必要があります。つまり、10-DTUデータベースをマッピングするには、コア当たり0.5 vCoresおよび5.05-GB RAMが必要で、50-DTUデータベースをマッピングするには、コア当たり1 vCoreおよび5.05-GB RAMが必要です。1 OCPUが2 vCoresと等しいことを考慮すると、これらの数値をOCIに変換するのは簡単です。

 

移行プロセス

ターゲット・データベースの選択

これで、ターゲット・データベースをホストするために必要なリソースがわかりました。必要なOCIサービスを特定できます。ソースのAzure SQL Databaseは、高可用性インフラストラクチャ上で完全なPaaSサービスとして動作するため、ターゲット・データベース・プラットフォームを要件に応じて正確に評価します。次のスキーマは、選択プロセスに役立ちます:

Flowchart for target database selection

詳細は、Deploying a highly available Microsoft SQL Server database on OCI using Always On availability groupsを参照してください。

bacpacのエクスポートとインポートを使用した移行アプローチ

ターゲット・データベースがOCI上のMicrosoft SQL Serverの場合、最も簡単なオプションは、ソースAzure SQL Databaseのバックアップ・パッケージ(bacpac)ファイルを作成することです。関連するデータベースを選択してエクスポートすることで、Azureポータルで直接作成できます:

Export database creation screen

作成時には、BACPACファイルをOCIでホストされているMS SQL Server仮想マシン(VM)に移動してから、データ層のインポート・アプリケーション・ガイドを使用してインポートする必要があります。詳細な手順については、「BACPACファイルをインポートして新しいユーザー・データベースを作成」を参照してください。

Oracle GoldenGateを使用した移行アプローチ

ターゲット・データベースがOracle Autonomous Database、Oracle MySQL Database、またはPostgreSQLのデータベースである場合、Oracle GoldenGateを使用してソースAzure SQL DatabaseをOCIデータベースに移行することをお薦めします。詳細は、Oracle GoldenGateの製品ページを参照してください。

Oracle Cloudコンソールを使用して、Oracle GoldenGateで使用するAzure SQL Database接続を作成します。

  1. OCI GoldenGateの「Overview」ページで、「Connections」を選択します。

    GoldenGate connection creation.

    「Get started」セクションで「Create Connection」を選択し、ステップ3にスキップすることもできます。

  2. 「Connections」ページで、「Create Connection」を選択します。

  3. 「Create Connection」パネルで、「General Information」フィールドに入力します:

    • 接続の名前を入力します。

    • (オプション)この接続を他の接続と区別するのに役立つ説明を入力します。

    • 接続を作成するコンパートメントを選択します。

    • 「Type」で、「Azure SQL Database」を選択します。

    • (オプション)「Show advanced options」を選択してキーを管理するか、タグを追加します。

    • 「Security」で、次のいずれかのオプションを選択します:

      • 「Use Oracle-managed encryption key」を選択して、すべての暗号化キー管理をOracleに残します。

      • 「Use customer-managed encryption key」を選択して、OCI Vaultに格納されている特定の暗号化キーを選択し、接続資格証明を暗号化します。

    • 「Tags」で、タグを追加してリソースを整理します。

  4. 「Next」を選択します。

  5. 「Connection Details」フィールドに入力します。

    • データベース・スキーマ名を入力します。

    • データベース・ホストおよびポート番号を入力します。

    • 「Database username」に、Azure SQL Databaseユーザー名を入力します。

    • データベース・ユーザー・パスワードには、Azure SQL Databaseのパスワードを入力します。

    • 「SSL details」については、「Security protocol」および「SSL mode」を選択します:

      • Plain

      • TLS、サーバー証明書を検証するかどうかを選択します

    • 「Network connectivity」の場合は、「traffic routing method」を選択します。

      • Oracleネットワーク(公開されているリソースの場合)。

      • 顧客がサブネットを割り当て、VCNを介してトラフィックをルーティングしてプライベート・リソースにアクセスし、サブネットを選択します。

  6. 「Create」をクリックします。

接続が作成されると、「Connections」リストに表示され、Oracle GoldenGateデプロイメントで使用できます。必要に応じて、GoldenGateデプロイメントを作成します:

GoldenGate deployment screen

ソースとして作成された接続をGoldenGateデプロイメントに割り当てていることを確認してください。移行プロセスを完了するには、Oracle GoldenGateの公式ドキュメントを参照してください。

まとめ

OCIには、Azure SQL Database PaaSサービスの移行時にターゲット・データベースとして使用できる多くの有効な選択肢があります。最も重要なステップは、ソース・データベースに必要なリソースのサイズ設定、ターゲット・データベース・サービスの選択、および移行のアプローチです。

移行プロセスのサポートに関するドキュメントおよび参照の詳細は、次のリソースを参照してください: