AzCopy で 2つの Azure Files 間のデータ同期にかかる時間を計測してみた

はじめに

"大きなファイル共有" で GRS を有効化できない場合（※）など、Japan East と West 双方に 2つのストレージアカウントを作成し、AzCopy を利用してデータ同期を行うことで、GRS/GZRS 相当の冗長性実現を狙うことがあります。この場合、GRS/GZRS と比較して、RPO に以下のような違いがあります。

冗長性の持たせ方	RPO	備考
GRS/GZRS	15分 (SLAなし)	ストレージアカウントは、1つ。フェールオーバー後も、同一 URL でアクセスできる。
azcopy	azcopy 実行頻度とコピーにかかる所要時間次第	ストレージアカウントは、2つ。フェールオーバーは、アクセス先 URL を変えることで実現。

AzCopy で 2つの Azure Files 間のデータ同期にかかる時間、気になりますね。
というわけで、計測してみました。参考までメモしておきます。

※ 大きなファイル共有の GRS がパブリックプレビューで登場しました！ - 2023/05/24

https://zenn.dev/microsoft/articles/largefileshare-grs

AzCopy 計測 環境前提

以下を用意して検証してみました。

ストレージアカウント

同一リージョン内でのデータ同期の場合と、異なるリージョン間でのデータ同期の場合、両方を検証できるよう、計3つ作成しています。

• Azure Files x3 (東日本x2 + 西日本x1)
  • SKU : Standard ファイル共有
  • ファイル共有 : 100TB (大きなファイル共有)
  • ファイル共有 : CIFS
  • パフォーマンス : トランザクション
  • レプリケーション : LRS
  • 最大IOPS : 20,000
  • 最大スループット : 300MB/s (イングレス + エグレス)

仮想マシン

AzCopy を 実行する仮想マシンは、以下のように 3種 用意して比較しました。

• 仮想マシン① SKU : Standard_B2ms
• 仮想マシン② SKU : Standard_D2ds_v5
• 仮想マシン③ SKU : Standard_D16ds_v5

使用する AzCopy コマンド

AzCopy コマンド

$sourceUri = 'https://<storageaccountname1>.file.core.windows.net/<share1>'
$sourceSAS = '?sv=....'

$destUri = 'https://<storageaccountname2>.file.core.windows.net/<share2>'
$destSAS = '?sv=....'

$StartTime = Get-Date

.\azcopy sync "$sourceUri$sourceSAS" "$destUri$destSAS" --recursive --preserve-smb-permissions=true --preserve-smb-info=true --delete-destination=true

$StopTime = Get-Date
Write-Host ($StopTime - $StartTime).ToString("d'日'h'時間'm'分's'秒'fff")

azcopy で同期(sync オプション)を実行した場合、ファイルの更新有無の比較が行われ、その後、ファイルのコピーが行われます。

実行結果 例1： Standard_D2ds_v5 で 1万Files (10GB) をコピー

.\azcopy sync "$sourceUri$sourceSAS" "$destUri$destSAS" --recursive --preserve-smb-permissions=true --preserve-smb-info=true --delete-destination=true

INFO: Any empty folders will be processed, because source and destination both support folders. For the same reason, properties and permissions defined on folders will be processed

Job c2749df6-27c8-244b-7b64-5f947638503c has started
Log file is located at: C:\Users\AzureAdmin\.azcopy\c2749df6-27c8-244b-7b64-5f947638503c.log


1122 Files Scanned at Source, 0 Files Scanned at Destination
2755 Files Scanned at Source, 0 Files Scanned at Destination
4242 Files Scanned at Source, 0 Files Scanned at Destination
5683 Files Scanned at Source, 0 Files Scanned at Destination
7525 Files Scanned at Source, 0 Files Scanned at Destination
8981 Files Scanned at Source, 0 Files Scanned at Destination
0.0 %, 0 Done, 0 Failed, 10010 Pending, 10010 Total, 2-sec Throughput (Mb/s): 0
1.9 %, 191 Done, 0 Failed, 9819 Pending, 10010 Total, 2-sec Throughput (Mb/s): 871.7695
6.9 %, 691 Done, 0 Failed, 9319 Pending, 10010 Total, 2-sec Throughput (Mb/s): 2045.2152
11.6 %, 1154 Done, 0 Failed, 8856 Pending, 10010 Total, 2-sec Throughput (Mb/s): 1891.2636
16.2 %, 1611 Done, 0 Failed, 8399 Pending, 10010 Total, 2-sec Throughput (Mb/s): 1861.1084
21.3 %, 2125 Done, 0 Failed, 7885 Pending, 10010 Total, 2-sec Throughput (Mb/s): 2104.4779
29.6 %, 2952 Done, 0 Failed, 7058 Pending, 10010 Total, 2-sec Throughput (Mb/s): 3381.4204
37.8 %, 3774 Done, 0 Failed, 6236 Pending, 10010 Total, 2-sec Throughput (Mb/s): 3366.3564
45.9 %, 4588 Done, 0 Failed, 5422 Pending, 10010 Total, 2-sec Throughput (Mb/s): 3333.3117
53.9 %, 5386 Done, 0 Failed, 4624 Pending, 10010 Total, 2-sec Throughput (Mb/s): 3268.2357
61.7 %, 6174 Done, 0 Failed, 3836 Pending, 10010 Total, 2-sec Throughput (Mb/s): 3224.6049
69.7 %, 6964 Done, 0 Failed, 3046 Pending, 10010 Total, 2-sec Throughput (Mb/s): 3234.3239
77.8 %, 7782 Done, 0 Failed, 2228 Pending, 10010 Total, 2-sec Throughput (Mb/s): 3349.388 
85.7 %, 8574 Done, 0 Failed, 1436 Pending, 10010 Total, 2-sec Throughput (Mb/s): 3243.706
93.0 %, 9296 Done, 0 Failed, 714 Pending, 10010 Total, 2-sec Throughput (Mb/s): 2955.5932
97.9 %, 9796 Done, 0 Failed, 214 Pending, 10010 Total, 2-sec Throughput (Mb/s): 2047.1739
100.0 %, 10010 Done, 0 Failed, 0 Pending, 10010 Total, 2-sec Throughput (Mb/s): 743.006  

Job c2749df6-27c8-244b-7b64-5f947638503c Summary
Files Scanned at Source: 10000
Files Scanned at Destination: 0
Elapsed Time (Minutes): 0.7685
Number of Copy Transfers for Files: 10000
Number of Copy Transfers for Folder Properties: 10 
Total Number Of Copy Transfers: 10010
Number of Copy Transfers Completed: 10010
Number of Copy Transfers Failed: 0
Number of Deletions at Destination: 0
Total Number of Bytes Transferred: 10240000000
Total Number of Bytes Enumerated: 10240000000
Final Job Status: Completed

0日0時間0分46秒754

実行結果 例2： Standard_D2ds_v5 で 1万Files (10GB) をファイル比較のみ

.\azcopy sync "$sourceUri$sourceSAS" "$destUri$destSAS" --recursive --preserve-smb-permissions=true --preserve-smb-info=true --delete-destination=true

INFO: Any empty folders will be processed, because source and destination both support folders. For the same reason, properties and permissions defined on folders will be processed

Job 340d6f72-20b6-f64d-7f8c-65ab74eac320 has started
Log file is located at: C:\Users\AzureAdmin\.azcopy\340d6f72-20b6-f64d-7f8c-65ab74eac320.log


0 Files Scanned at Source, 521 Files Scanned at Destination
0 Files Scanned at Source, 1449 Files Scanned at Destination
0 Files Scanned at Source, 1989 Files Scanned at Destination
0 Files Scanned at Source, 3679 Files Scanned at Destination
0 Files Scanned at Source, 5472 Files Scanned at Destination
0 Files Scanned at Source, 7227 Files Scanned at Destination
0 Files Scanned at Source, 8624 Files Scanned at Destination
0 Files Scanned at Source, 10000 Files Scanned at Destination
1054 Files Scanned at Source, 10000 Files Scanned at Destination
3316 Files Scanned at Source, 10000 Files Scanned at Destination
3977 Files Scanned at Source, 10000 Files Scanned at Destination
5699 Files Scanned at Source, 10000 Files Scanned at Destination
6729 Files Scanned at Source, 10000 Files Scanned at Destination
7371 Files Scanned at Source, 10000 Files Scanned at Destination
9492 Files Scanned at Source, 10000 Files Scanned at Destination
100.0 %, 0 Done, 0 Failed, 0 Pending, 0 Total, 2-sec Throughput (Mb/s): 0

Job 340d6f72-20b6-f64d-7f8c-65ab74eac320 Summary
Files Scanned at Source: 10000
Files Scanned at Destination: 10000
Elapsed Time (Minutes): 0.5475
Number of Copy Transfers for Files: 0
Number of Copy Transfers for Folder Properties: 0 
Total Number Of Copy Transfers: 0
Number of Copy Transfers Completed: 0
Number of Copy Transfers Failed: 0
Number of Deletions at Destination: 0
Total Number of Bytes Transferred: 0
Total Number of Bytes Enumerated: 0
Final Job Status: Completed

0日0時間0分33秒796

ファイルの更新が全くなかった（差分なし）としても、ファイルの比較をするだけで、一定の時間を要することになります。ファイル数が多くなると、比較するだけでかなりの時間を要することが予想されます。

AzCopy 計測検証

今回は fsutil を使って 1MB のファイルを 100万個 用意し、いくつかのパターンで azcopy sync を実行して結果を記録してみました。なお、100万ファイル（1TB）パターンは、試行に時間がかかり過ぎたので全パターン網羅は断念しました…

• 比較 + ファイルコピー(差分あり) は、宛先となるストレージが空の状態で、同期を行った場合の時間を示しています。
• ファイル比較のみ（差分なし） は、双方のストレージに全く同じファイルがある状態で、同期を行った場合の時間を示しています。なお、 ファイル比較のみ（差分なし） は、双方のストレージに全く同じファイルがあるため、比較 + ファイルコピー(差分あり) に比べて、比較時には倍のファイル数の列挙が必要になります。

AzCopy 計測結果

• 仮想マシン① SKU : Standard_B2ms

コピーのパターン	リージョン	1,000Files (1GB)	1万Files (10GB)	10万Files (100GB)	100万Files (1TB)
比較 + ファイルコピー(差分あり)	東日本 → 東日本	8秒344	44秒539	9分20秒886	2時間2分0秒306
	東日本 → 西日本	8秒239	1分28秒508	20分13秒494	未計測
ファイル比較のみ（差分なし）	東日本 → 東日本	4秒328	30秒391	6分51秒360	未計測
	東日本 → 西日本	4秒441	37秒772	8分42秒311	未計測

• 仮想マシン② SKU : Standard_D2ds_v5

コピーのパターン	リージョン	1,000Files (1GB)	1万Files (10GB)	10万Files (100GB)	100万Files (1TB)
比較 + ファイルコピー(差分あり)	東日本 → 東日本	10秒935	46秒754	8分12秒552	未計測
	東日本 → 西日本	8秒337	1分55秒686	25分57秒963	2時間6分48秒329
ファイル比較のみ（差分なし）	東日本 → 東日本	6秒901	47秒291	6分56秒170	未計測
	東日本 → 西日本	4秒240	33秒796	6分20秒549	未計測

• 仮想マシン③ SKU : Standard_D16ds_v5

コピーのパターン	リージョン	1,000Files (1GB)	1万Files (10GB)	10万Files (100GB)	100万Files (1TB)
比較 + ファイルコピー(差分あり)	東日本 → 東日本	4秒032	14秒193	1分30秒314	13分52秒186
	東日本 → 西日本	4秒146	16秒148	1分58秒266	未計測
ファイル比較のみ（差分なし）	東日本 → 東日本	2秒155	14秒258	1分42秒810	25分12秒454
	東日本 → 西日本	2秒126	14秒129	2分24秒405	未計測

使用する VM にもよりますが、Standard_D16ds_v5 で 100万ファイル（1TB）くらいまでであれば、GRS に近い冗長性を作れそうです。

azcopy による共有全体の比較は、場合によっては、かなりのコストがかかると思われます。
ストレージアカウントは、操作 10,000 件あたり2円程度がかかりますが、これがファイル数が多い場合にはかなり効いてきます。

仮想マシン③ SKU : Standard_D16ds_v5だけ、別パターンとして、容量が大きい（100ファイル、各1GB、計100GB）パターンも計測してみました。
小さいファイルの方が、コピー速度が速い結果になりました。どこかでキャッシュが効いているのでしょうか？

• 仮想マシン③ SKU : Standard_D16ds_v5

コピーのパターン	リージョン	100Files (100GB)
比較 + ファイルコピー(差分あり)	東日本 → 東日本	6分21秒509
	東日本 → 西日本	9分37秒840
ファイル比較のみ（差分なし）	東日本 → 東日本	2秒825
	東日本 → 西日本	2秒265

まとめ

AzCopy で 2つの Azure Files 間のデータ同期にかかる時間を計測してみました。
未調整のまま実施した結果ですので、実際の環境では、もっと早くなる可能性があります。
ただ、ファイル数や容量が大きくなると、差分検出だけでもかなりの時間がかかり、AzCopy で GRS相当の冗長性を実現するには、相応のコストがかかりそうです。

ぜひともパブリックプレビューとなった、大きなファイル共有の geo 冗長性 に期待したいところですね。

参考1. 準備につかったコマンド

今回は fsutil を用いてテスト用ファイルを作成しましたが、 azcopy bench の方が良かったかもしれません。

fsutil を使うパターン

:1GB のテスト用ファイルを生成する

1GB のテスト用ファイルを生成する

fsutil file createnew X:\temp\testfile1.txt 1024000000

1GB のファイルを 1000 個生成する

1GB のファイルを 1000 個生成する

for /L %i in (1, 1, 1000) do fsutil file createnew X:testfile_%i.dat 1024000000

10個のフォルダを作成し、各フォルダ内に 1GB のファイルを 10 個生成する

10個のフォルダを作成し、各フォルダ内に 1GB のファイルを 10 個生成する

for /L %i in (1, 1, 10) do (
 mkdir X:\tmp\testfolder_%i
 for /L %j in (1, 1, 10) do (
    fsutil file createnew X:\tmp\testfolder_%i\testfile_%j.dat 1024000000
 )
)

10個のフォルダを作成し、各フォルダ内に さらに 10個のフォルダを作成する。　そのフォルダ内には 1MB のファイルを 1000 個生成する

10個のフォルダを作成し、各フォルダ内に さらに 10個のフォルダを作成する。　そのフォルダ内には 1MB のファイルを 1000 個生成する

for /L %%i in (1, 1, 10) do (
 mkdir X:\tmp\testfolder_%%i
    for /L %%j in (1, 1, 1000) do (
        mkdir X:\tmp\testfolder_%%i\testfolder_%%j
        for /L %%k in (1, 1, 1000) do (
            fsutil file createnew X:\tmp\testfolder_%%i\testfolder_%%j\testfile_%%k.dat 1024000
        )
    )
)

azcopy bench を使うパターン

ベンチマークフォルダを作成し、そのフォルダ内には 1GB のファイルを 100 個生成する

ベンチマークフォルダを作成し、そのフォルダ内には 1GB のファイルを 100 個生成する

azcopy bench

$sourceUri = 'https://<storageaccount>.file.core.windows.net/<share>'
$sourceSAS = '?sv=....'

.\azcopy bench "$sourceUri$sourceSAS" --file-count 100 --delete-test-data=false --size-per-file 1G

実行結果例

...
98.8 %, 85 Done, 0 Failed, 15 Pending, 0 Skipped, 100 Total, 2-sec Throughput (Mb/s): 1408.4209
99.1 %, 88 Done, 0 Failed, 12 Pending, 0 Skipped, 100 Total, 2-sec Throughput (Mb/s): 1351.3936
99.5 %, 91 Done, 0 Failed, 9 Pending, 0 Skipped, 100 Total, 2-sec Throughput (Mb/s): 1337.8221 
99.8 %, 95 Done, 0 Failed, 5 Pending, 0 Skipped, 100 Total, 2-sec Throughput (Mb/s): 1487.3939
100.0 %, 100 Done, 0 Failed, 0 Pending, 0 Skipped, 100 Total, 2-sec Throughput (Mb/s): 665.8466


Job 39fb3be9-96ce-2848-7439-e11a6b3a72c7 summary
Elapsed Time (Minutes): 13.2361
Number of File Transfers: 100
Number of Folder Property Transfers: 0
Number of Symlink Transfers: 0
Total Number of Transfers: 100
Number of File Transfers Completed: 100
Number of Folder Transfers Completed: 0
Number of File Transfers Failed: 0
Number of Folder Transfers Failed: 0
Number of File Transfers Skipped: 0
Number of Folder Transfers Skipped: 0
TotalBytesTransferred: 107374182400
Final Job Status: Completed

Diagnostic stats:
IOPS: 32
End-to-end ms per request: 273
Network Errors: 0.00%
Server Busy: 0.00%

Performance benchmark results: 
Note: The benchmark feature is currently in Preview status.

Main Result:
  Code:   FileShareOrNetwork
  Desc:   Throughput may have been limited by File Share throughput limits, or by the network 
  Reason: No other factors were identified that are limiting performance, so the bottleneck is assumed to be either the throughput of the Azure File Share OR the available network bandwi
dth. To test whether the File Share or the network is the bottleneck, try running a benchmark to Blob Storage over the same network. If that is much faster, then the bottleneck in this r
un was probably the File Share. Check the published Azure File Share throughput targets for more info. In this run throughput of 1091 Mega bits/sec was obtained with 9 concurrent connect
ions.

This benchmark tries to find optimal performance, computed without touching any local disk. When reading 
and writing real data, performance may be different. If disk limits throughput, AzCopy will display a message on screen.

参考2. AzCopy の関連リンク

• AzCopy を使ってみる

  • AzCopy を使ってみる
  • AzCopy とファイル ストレージでデータを転送する
  • azcopy sync

• AzCopy と RoboCopy

  • RoboCopy を使用して Azure ファイル共有に移行する

• パフォーマンスを最適化
  今回は特に細かな調整はせずに、デフォルトの設定で実行していましたが、本番では以下を参照して最適化したほうがよさそう。

  • Azure Storage で AzCopy のパフォーマンスを最適化する
  • Azure ファイル共有のスケール ターゲット

参考3. 他 Blob, Queue, Table 等も含めた冗長性オプション

今回 Azure Files について記載しましたが、他 Blob, Queue, Table 等も含めた選択肢は、以下がわかりやすいかと思います。

https://jpaztech.github.io/blog/storage/introduction-of-azure-storage-redundancy/#ストレージ-アカウントの種類およびレプリケーションの種類に対するデータ-サービスのサポート状況

また、以下も意外と見落としがちな点です。

Azure Files では、読み取りアクセス geo 冗長ストレージ (RA-GRS) または読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) はサポートされていません。
ストレージ アカウントのレプリケーションの種類にて RA-GRS / RA-GZRS を選択いただいた場合、Azure Files では GRS / GZRS の機能がご利用いただけます。