こんにちは、アーキテクトのやまぱんです。
皆さんお盆休み満喫されておりますでしょうか。
今回は 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 個作る例
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
-
--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 です。
シナリオ 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など)から大量のファイルを送る方法をとる方法などが考えられるかと思います。
おわり！