こんにちは、アーキテクトのやまぱんです。
皆さんお盆休み満喫されておりますでしょうか。

今回は azcopy を使って、Azure Files 共有へデータを転送してみたので、その結果を共有したいと思います。
この手の検証は実際のデータやスペックを合わせないと意味がないのですが、これくらいでるんだーと誰かの参考になれば幸いです。

実際に大量のデータを転送する場合に備えた速度検証を行う場合は実際の環境になるべく合わせて検証してみてください。また、同じ条件下で検証してもクラウドストレージの特性上どうしても結果にばらつきは出てしまいます。

補足コメントや質問、いいね、拡散、是非お願いします🥺！
間違ってたら優しく教えてください！

モチベーション

前回こんな記事を書きました。

今回は実際に図ってみました
誰かの参考になれば嬉しいです。

<2024/09/02 追記>
また、ディレクトリ数が大量にある場合の検証結果として
以下の記事も作成しました

検証内容など

azcopy version 10.26.0
Azure Files (standard ファイル共有) 、東日本リージョンに作成(前回の記事でも記載したようにストレージアカウント単位でイングレススループットは 7152MiB/s です）
OS Linux (Rhel と Ubuntu)
azcopy のコマンドを OS 上で実施し、Azure Files へディレクトリを指定してその配下のファイルをまとめて転送
使用したデータ
下記コマンドでランダムファイルを作成、1ファイルあたりの大きさは固定でファイル数を変えて数パターン実施しました。
以下は100KB のファイルを 2000 個作る例

shell

for i in $(seq 1 2000); do
    dd if=/dev/urandom of=file_$i bs=100K count=1
done

スループット測定
azcopy 終了時に表示される時間で、ファイル総容量を割って算出。

シナリオ

シナリオ１

東日本リージョン上の Azure VM から実施。
VM SKU はStandard D64s v5 (64 vcpu 数、256 GiB メモリ)、OS は RHEL、データディスクは Premium SSD（最大スループットは200MBps)

以下のコマンドで実施
azcopy copy "＜転送するディレクトリ名＞" "https://<ストレージアカウント名>.file.core.windows.net/＜ファイル共有名＞/<転送先ディレクトリ名>?＜SAS＞" --recursive

シナリオ 2

シナリオ1との違いはオプション引数 --log-level ERRORの違いです。
東日本リージョン上の Azure VM から実施。
VM SKU はStandard D64s v5 (64 vcpu 数、256 GiB メモリ)、OS は RHEL、データディスクは Premium SSD（最大スループットは200MBps)

azcopy copy "＜転送するディレクトリ名＞" "https://<ストレージアカウント名>.file.core.windows.net/＜ファイル共有名＞/<転送先ディレクトリ名>?＜SAS＞" --recursive --log-level ERROR

--log-level オプション
既定では、AzCopy ログレベルは INFO に設定されます。ディスク領域を節約、転送時のパフォーマンスを向上するためにログ詳細度を下げたい場合は、--log-level オプションを使用してこの設定を上書きます。

使用可能なログレベルは、DEBUG、INFO、WARNING、ERROR、NONE です。

参考：https://learn.microsoft.com/ja-jp/azure/storage/common/storage-use-azcopy-files#upload-the-contents-of-a-directory

シナリオ 3

私の自宅(関西)の PC (Windows) 上の　WSL(Windows Linux Subsystem) のLinux (Ubuntu)から実施。
NWの理論最大値は100Mbps＝12.5MB/s、なおかつ Wifi環境

実行コマンドはシナリオ１と同じ下記。
azcopy copy "＜転送するディレクトリ名＞" "https://<ストレージアカウント名>.file.core.windows.net/＜ファイル共有名＞/<転送先ディレクトリ名>?＜SAS＞" --recursive

測定結果

シナリオ 1

こちらがベースとなる検証結果

#	ファイルサイズ	ファイル数	合計ファイルサイズ (MB)	時間(分)	スループット(MB/s)
case1	100KB	2000	196	0.1667	19.60
case2	100KB	4000	391	0.2	32.58
case3	100KB	32000	3126	0.7002	74.41
case4	100KB	512000	50015	5.1344	162.35

シナリオ 2

#	ファイルサイズ	ファイル数	合計ファイルサイズ	時間(分)	スループット(MB/s)
case1	100KB	2000	196	0.1667	19.60
case2	100KB	4000	391	0.2	32.58
case3	100KB	32000	3126	0.4334	120.21
case4	100KB	512000	50015	4.3341	192.33

case 1,2 の場合ではスループットは変わらないが、case3,case4の場合だと --log-level ERROR が有効になっているためにスループットが向上したことが推察されます。

シナリオ 3

#	ファイルサイズ	ファイル数	合計ファイルサイズ (MB)	時間(分)	スループット(MB/s)
case1	100KB	2000	196	0.4669	7.00
case2	100KB	4000	391	0.8005	8.14
case3	100KB	32000	3126	5.1389	10.14
case4	100KB	512000	50015	77.6004	10.74

シナリオ3を実施した環境では回線速度が理論値最大でも100Mbps＝12.5Mbpsです。
さらにWifi接続環境なので、そこそこ出ている方だと思われます。

azcopy benchmark

今回実際にデータを準備してスループットを測定しましたが、azcopy には benchmark 機能があります。
簡易的にスループットを測定したい時には最適です。

ベンチマークテストを実行する - MS Learn
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-use-azcopy-optimize#run-benchmark-tests

azcopy benchmark 'https://<storage-account-name>.blob.core.windows.net/<container-name>'

azcopy による大量のファイル転送時スループット測定の Tips

大前提
まず、大前提としてTips としては以下の公式ドキュメント、MS Learnが参考になります。
今回の --log-level パラメータに関しても記載されています。

・大量のファイル向けに最適化する - MS Learn
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-use-azcopy-optimize#optimize-for-large-numbers-of-files

azcopy 複数実行による並列化について
また、並列度を上げれば早くなるのでは？と思い単一OS内で複数のazcopy プロセスを立ち上げで実行したくなる人もいるかもしれませんが、こちらはあまりオススメできません。また、azcopy 自体に並列処理する仕組みがあります。このことについては以下に記載があります。

・複数のクライアントを使用してジョブを並列で実行する
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-use-azcopy-optimize#use-multiple-clients-to-run-jobs-in-parallel

AzCopy は、クライアントで実行されるインスタンスが 1 つだけの場合に最高のパフォーマンスを発揮します。ファイルを並列で転送する場合は、複数のクライアントを使用し、それぞれに対して AzCopy のインスタンスを 1 つだけ実行します。

その他参考

azcopy copy - MS Learn

あとがき

今回の検証では、ストレージアカウントの性能限界までのスループットを引き出すことはできませんでした。
今回ディスクのスループット上限だったり、回線速度の方がはるかに遅かったためです。
実際にストレージアカウントの性能限界を試すには複数台の端末(できれば高スループットのデータディスクを搭載したVMなど)から大量のファイルを送る方法をとる方法などが考えられるかと思います。

おわり！