はじめに

従来、Microsoft社のAzure Storage Moverは、オンプレミス環境のファイルストレージをAzureのストレージに移行することを目的とした機能として提供されていました。

今回、新たにAWSのオブジェクトストレージAmazon S3から、AzureのBlob Storageへ移行することを目的としたクラウド間移行機能(現時点ではプレビュー)が登場しました。

Amazon S3からAzure Blob Storageへの移行可能なサービスとしては、他にAWS社のAWS DataSyncがあります。

今回、Azure Storage Moverのクラウド間移行機能(プレビュー)を以下の観点で検証してみましたので、そこで得られた知見を記事として纏めてみました。

データ転送検証(移行機能が正しく動作すること。)
パフォーマンス検証(AWSとAzueのサービスで転送時間等に差異はあるかなど。)

クラウド間移行機能概要

Azure Storage Moverのクラウド間移行機能は、Amazon S3からAzure Blob Storageへの移行を行うための拡張機能です。従来のオンプレミスからAzure Storageへの移行を行うためには、Azure Storage Moverのエージェントをオンプレミス側に導入する必要がありますが、当クラウド間移行機能においてはエージェントは不要です。機能の構成イメージは下記の通りです。

コンポーネントとしては以下が必要です。

移行元のAWS側
- Amazon S3バケツ
  - AWSのオブジェクトストレージ
移行先のAzure側
- Storage Mover
  - Azureのストレージ移行を司るサービス
- マルチクラウドコネクター
  - 当機能を使用する場合に必要なAWSとAzureのストレージ間を接続するコネクター
- Blob Storage　(Binary large obeject Storage)
  - Azureのオブジェクトストレージ
    ※Storage Accountと呼ばれるストレージの器を「Blob」というオプションを指定してプロビジョニングした後、移行先のフォルダとしてBlob Containerを作成する。

また、現在はプレビュー機能ということで、主に以下の制限があります。

移行元のAmazon S3のデータは、標準クラスや低頻度アクセスクラス(Azureにおけるホット層やクール層に相当)に存在するものである必要がある。
プライベート接続はサポートされていない。

検証構成

今回の検証構成は下記のとおりです。

Azure Storage Moverは米国東部リージョンに配置。
移行元のAmazon S3バケツ、移行先のAzure Blob Storageいずれも米国東部リージョンに配置。
転送用のデータは、AWS CLIのインストール用msiファイル(39.37MB)とする。

現在、Azure Storage Moverは日本のリージョンは選択できないようでした。それ故、選択メニューにおいて「お勧め」と記載されているリージョンの中から、今回は米国東部リージョン(US-east)を採用しました。
なるべくAzure Storage Moverと近い場所に、AWSとAzureのストレージを配置したほうが良いかなと思い、同じ米国東部リージョンに配置しています。

環境設定

Azure Storage Moverリソースの作成

まずは、データ移行を行う上で必須のAzureサービスである、Azure Storage Moverをプロビジョニングしていきます。Azureポータルの検索画面で「Azure Storage Mover」でサーチして、該当サービスが見つかったら作成ボタンを押下します。以下は作成画面イメージです。

実は、この画面において、「コピーログを有効にする」にチェックを入れて、Log Analyticsワークスペースにデータ転送実行時のログを保存するように設定していたのですが、転送完了後に生成されるログテーブルの中身をLog Analytics上でサーチしても全く転送完了時間帯のログを参照できませんでした。。。

後は、設定した内容を確認して問題なければ「確認と生成」ボタンを押下します。

正常に作成が完了すると、下記のように3つのリソースが作成されます。

マルチクラウドコネクターの作成

今回のクラウド間移行機能でのみ必要となるリソースです。作成は、Azure Storage Moverリソースの参照先画面から行います。「マルチクラウド移行(プレビュー)」タブをクリック→「マルチクラウドコネクタを作成」ボタンを押下します。

ここからは必要項目を記入していきます。

接続するAWS側のAmazon S3バケツを保有しているAWSアカウントIDを入力して次に進みます。

今回の機能では、「インベントリ」と「ストレージ・データ管理(プレビュー)」の2つのソリューションを使用することが必須となります。まずは、インベントリのアクションを追加するため、赤枠の「追加」ボタンを押下します。

ここでは、Azureで使用するAWSサービスを選択します。デフォルトでは「サポートされているすべてのAWSサービスを追加する」にチェックが入っていますが、今回の機能ではS3しか使用されないので、チェックを外し、AWSサービスのプルダウンメニューから「S3」のみを選択しました。

画面左側のインフォメーションメッセージに、「Storage moverでは、定期的な同期が有効になっているインベントリが必要です」との記載があることから、「定期的な同期」の箇所はこのままにします。
下の「リソースフィルター」では、Amazon S3バケツが配置されているAWSリージョンを選択します。こちらもデフォルトでは「サポートされているすべてのAWSリージョンを含めます」にチェックが入っていますが、このチェックを外して、Amazon S3バケツを配置した「us-east-1」のみを選択しました。その後、「保存」ボタンを押下します。

次は「ストレージ・データ管理(プレビュー)」のアクションを追加するため「追加」ボタンを押下します。

「ストレージ・データ管理(プレビュー)」の「追加」ボタンは押下できたものの、「編集」ボタンはグレー表示となり中身は開けません。開けない理由も表示されないのが気になりますが、データ転送自体には影響ありませんでした。謎です。

更に先に進むと、AWSからマルチクラウドコネクタにアクセスするためのアクセス許可を定義するためのCloudFormationテンプレートをダウンロードするように指示されているので、それに従いテンプレートをダウンロードします。

ダウンロードしたテンプレートを使用して、AWS側でCloudFormationスタックを作成します。任意の名前でスタック名を定義したら、後は単純にCloudFormationを実行するだけです。実行した結果、以下3種類の論理IDの付与されたリソースが作成されました。

MicrosoftOIDCProvider
AzureStorageDataManagementRole
AssetManagementRole

その後、更に先に進み、設定した内容が正しいことを確認後、「作成」ボタンを押下します。

無事作成が終わると下記のように3つのリソースが作成されます。

Azure Storage Moverエンドポイントの作成

リソースグループからAzure Storage Moverリソース参照先画面に遷移後、Azure Storage Moverのソースエンドポイントとターゲットエンドポイントの2つを作成します。

ソースエンドポイント：移行元のAmazon S3との紐づけに使用
ターゲットエンドポイント：移行先のAzure Blob Storageとの紐づけに使用

※AWS DataSyncのロケーションに相当するものです。

ソースエンドポイントの作成

画面左側の「ストレージエンドポイント」を選択→「ソースエンドポイント」タブを選択→「エンドポイントの作成」ボタンを押下し、必要な情報を設定します。

ソースの種類には「AWS S3(プレビュー)」を選択し、マルチクラウドコネクタ、S3バケットの選択においては、プルダウンメニューから適切なものを選択します。その後、「作成」ボタンを押下してソースエンドポイントを作成します。作成完了後、下記のように表示されていればOKです。(表示されるまでに多少のタイムラグがあります。)

ターゲットエンドポイントの作成

「ターゲットエンドポイント」タブを選択→「エンドポイントの作成」ボタンを押下し、必要な情報を設定します。

ここでは、Azureサブスクリプション(※)、ストレージアカウントに適切なものを選択し、ターゲットの種類では「Blobコンテナー」を選択します。Blobコンテナーのプルダウンメニューから作成済のコンテナーを選択します。

※AWSのアカウントIDに相当するものです。

その後、「作成」ボタンを押下してターゲットエンドポイントを作成します。作成完了後、下記のように表示されていればOKです。(表示されるまでに多少のタイムラグがあります。)

Azure Storage Moverプロジェクトの作成

データ移行JOBを一元管理するためにAzure Storage Moverのプロジェクトというものを作成します。画面左側の「プロジェクトエクスプローラー」を選択→「プロジェクトの作成」を押下→任意のプロジェクト名を記入して「作成」ボタンを押下します。

作成完了後、下記のように表示されていればOKです。(表示されるまでに多少のタイムラグがあります。)

データ移行JOBの作成

先ほど作成したプロジェクトに遷移後、画面上の赤枠箇所の「ジョブ定義の作成」ボタンを押下し、データ移行JOBを作成します。(AWS DataSyncにおけるタスク定義に相当します。)

任意のジョブ名を記述し、移行の種類は「クラウド間(プレビュー)」を選択して先に進みます。ここからは既に作成しておいたソースエンドポイントとターゲットエンドポイントを指定します。

更に進み、コピーモードには「ソースをターゲットにミラーリングする」を選択し、次に進みます。

指定した内容を確認後、作成ボタンを押下し、移行ジョブを作成します。作成完了後、下記のようにジョブ定義名が表示されていればOKです。(多少のタイムラグはあります。)

ここまで実施すれば、検証環境の設定作業は完了です。

検証実施

データ転送検証

作成した移行ジョブに遷移し、赤枠箇所の「ジョブの開始」ボタンを押下し、ストレージアカウントとBlobコンテナーへのアクセスロールの割り当てに成功したら、「開始」ボタンを押下します。

その後、下記のようにしばらくジョブはキューされます。

この機能を利用する際にはAzure Storage Moverのエージェントは不要ですが、「割り当てられたエージェントがジョブをピックアップするのを待機しています。」と表示されます。しかも、体感的にこの時間が結構長く感じられました。

何度かリフレッシュすると「実行中」のステータスに変わり、最終的に「成功」のステータスに変わりました。

処理時間は「実行履歴」タブを選択すると確認できます。赤枠箇所に見られる通り、35秒と表示されていることがわかります。

移行先のAzure Blob StorageのBlobコンテナーの中身を見ると、問題なくデータが作成されていることが確認できました。

ということで、基本的なデータ転送処理はOKです。

パフォーマンス検証

転送するデータは、AWS CLIのインストール用msiファイル(39.37MB)とし、以下のパターンを試してみました。

CASE1 Azure Storage Moverのクラウド間移行機能(プレビュー)を使用するケース

上記検証構成(Azure Storage Mover、移行元/移行先のストレージがいずれも米国東部リージョンに配置)の場合
- データ転送に要した時間：35秒
Azure Storage Moverは米国東部リージョンに、移行元/移行先のストレージは東京リージョンに配置した場合
- データ転送に要した時間：35秒

Azure Storage Moverの作成画面において、「Storage Moverは、移行速度に影響を与えずに、任意のリージョンにデプロイできます。移行を実行するために、他のAzureリソースと併置する必要はありません。」との記載がありましたが、上記の結果からそれが実証されたことになります。

CASE2 AWS DataSyncを使用するケース

Amazon S3からAzureのBlob Storageに対してデータ転送を行う場合、AWS DataSyncもエージェント不要で転送を行うことが可能です。AWS DataSyncを使用したAmazon S3とAzure Blob Storage間の転送設定については、以前に投稿した下記の記事をご参考ください。

上記の記事では、転送元をAzure Blob Storage、転送先をAmazon S3として記載していますが、転送元と転送先を入れ替えた場合も、各々の環境で設定が必要となる項目は変わりません。ですので、設定時の画面イメージやデータ転送の実行方法については上記記事をご参照ください。

今回は、下記の構成で検証を実施しました。

転送元のAWS、転送先のAzure、いずれも米国東部リージョンとする。

検証した結果、AWS DataSyncの場合は、11秒でデータ転送が完了しました。

AWS DataSyncのダッシュボードでは、転送時間だけでなく、データスループット、ファイルスループットについても確認することができますが、Azure Storage Moverのダッシュボードからは、転送時間しか確認することができませんでした。

おわりに

今回は、Azure Storage Moverのクラウド間移行機能(プレビュー)を使用して、Amazon S3からAzure Blob Storageへのデータ移行検証を実施しました。どちらもエージェントレスで転送可能な点は良いのですが、転送時間に着目すると、現時点ではAWS Data Syncの方が優位な結果となりました。インターネット環境は同じなので、Azure Storage Moverのクラウド間移行機能の何かしらの内部処理において時間がかかっているものと思われます。

ですが、今回はプレビュー機能ということで、GAになった暁には転送時間も改善されて速くなっているかもしれません。また、Azure Storage Moverも将来的には日本のリージョンにプロビジョニングできるようになることを期待しています。