Amazon S3 へデータ転送速度が早いと噂の s5cmd を使って aws s3 cp と比べてみた
はじめに
S3 バケットへのファイル転送において一般的な aws s3 cp
コマンドと、高速転送可能な s5cmd
の転送速度を検証しました。海外リージョンの S3 バケットへ小さなファイルを大量転送時に利用したところ、転送が想像より早かったです。そんな私の中でホットな s5cmd が本当に早いのか気になりました。
条件を整えて aws s3 cp と s5cmd cp でファイル転送した転送時間と転送速度を計測してみました。
ところで s5cmd ってなに
s5cmd は、S3 と S3 互換オブジェクトストレージ、ローカルファイルシステム上のファイル操作できるコマンドラインツールです。マルチコアをフル活用した並列処理により非常に高速に転送できること強みです。 Mac なら homebrew で簡単にインストールできます。
検証結果早見
実行環境に依りますが、小さなファイルを大量転送では顕著な差がありました。
1GB のファイルを 5 個転送した結果です。大きなファイルでも想像よりも早かったです。
コマンド | 転送時間 | 転送速度 | 改善効果 |
---|---|---|---|
aws s3 cp | 11.01秒 | 464.8 MB/s | - |
s5cmd | 3.77秒 | 1353.4 MB/s | 2.9倍高速 |
500KB のファイルを 10,000 個転送した結果です。圧倒的に早かったです。
コマンド | 転送時間 | 転送速度 | 改善効果 |
---|---|---|---|
aws s3 cp | 82.64秒 | 59.3 MB/s | - |
s5cmd | 3.86秒 | 1272.7 MB/s | 21.4倍高速 |
検証環境
構成図
S3 バケットへの転送経路のネットワークを安定させるために、EC2 から VPC エンドポイント経由して S3 バケットアクセスする構成としました。
EC2 インスタンス
以下の要件でインスタンスタイプを選定したところ m8gd.8xlarge になりました。
- ストレージ性能に引っ張られないようにインスタンスストアを持っていること
- ネットワーク帯域幅がバーストタイプではなく安定していること
- なるべく新しいインスタンスタイプ
項目 | 仕様 |
---|---|
インスタンスタイプ | m8gd.8xlarge |
vCPU | 32 |
メモリ | 128 GiB |
プロセッサ | AWS Graviton4 |
ネットワーク帯域幅 | 15 Gbps |
Amazon EBS 帯域幅 | 10 Gbps |
インスタンスストレージ | あり(NVMe SSD) |
OS | Ubuntu 24.04 LTS ARM64 |
アップロード対象のテストファイルについて
アップロードするファイルは、大容量パターンと小容量多数パターンの 2 種類を用意しました。これらのファイルをインスタンスストアに保存して S3 バケットへ転送して計測することとしました。
- 1GB ファイル × 5 個(合計 5GB)
- 500KB ファイル × 10,000 個(合計約 4.8GB)
事前準備
Graviton(ARM)マシンだったこともあり、基本的な準備手順を載せておきます。
インスタンスストアのマウント
# インスタンスストアをマウント
sudo mkfs.ext4 /dev/nvme0n1
sudo mkdir -p /scratch
sudo mount /dev/nvme0n1 /scratch
sudo chown ubuntu:ubuntu /scratch
AWS CLI インストール
# AWS CLI v2 インストール
curl "https://awscli.amazonaws.com/awscli-exe-linux-aarch64.zip" -o "awscliv2.zip"
unzip -q awscliv2.zip
sudo ./aws/install
s5cmd インストール
# s5cmd v2.3.0 インストール
wget https://github.com/peak/s5cmd/releases/download/v2.3.0/s5cmd_2.3.0_Linux-arm64.tar.gz
tar -xzf s5cmd_2.3.0_Linux-arm64.tar.gz
sudo mv s5cmd /usr/local/bin/
sudo chmod +x /usr/local/bin/s5cmd
詳細なインストール手順はリンクをご確認ください。
peak/s5cmd: Parallel S3 and local filesystem execution tool.
テストファイル作成
テストファイルを作成し、インスタンスストアをマウントしたディレクトリ(/scratch
)配下に保存しました。
# 大容量ファイル作成(1GB × 5個)
for i in $(seq 1 5); do
dd if=/dev/zero of=/scratch/large_file_${i}.dat bs=1M count=1024
done
# 小容量ファイル作成(500KB × 10,000個)
for i in $(seq 1 10000); do
dd if=/dev/zero of=/scratch/small_file_${i}.dat bs=1K count=500
done
データ転送計測
地道にデータ転送した時間を計測しました。
# aws s3 cp 実行例
time -p aws s3 cp /scratch/large-files/ s3://devio-bucket-for-mountpoint/large-files-test1/ --recursive
# s5cmd 実行例
time -p s5cmd cp "/scratch/large-files/*" s3://devio-bucket-for-mountpoint/large-files-s5cmd-test1/
実行結果
大容量ファイルと、小容量多数ファイルの 2 パターンをそれぞれ 3 回アップロードした実行時間と転送速度です。
長いので折りたたみ
大容量ファイル転送結果
aws s3 cp の結果
テスト回数 | 実行時間(秒) | 転送速度(MB/s) |
---|---|---|
1回目 | 10.86 | 470.8 |
2回目 | 11.60 | 440.7 |
3回目 | 10.58 | 483.0 |
平均 | 11.01 | 464.8 |
s5cmd cp の結果
テスト回数 | 実行時間(秒) | 転送速度(MB/s) |
---|---|---|
1回目 | 3.69 | 1382.1 |
2回目 | 3.75 | 1361.7 |
3回目 | 3.88 | 1316.5 |
平均 | 3.77 | 1353.4 |
小容量多数ファイル転送の結果
AWS S3 cp の結果
テスト回数 | 実行時間(秒) | 転送速度(MB/s) |
---|---|---|
1回目 | 81.59 | 60.1 |
2回目 | 84.54 | 58.0 |
3回目 | 81.79 | 59.9 |
平均 | 82.64 | 59.3 |
s5cmd cp の結果
テスト回数 | 実行時間(秒) | 転送速度(MB/s) |
---|---|---|
1回目 | 3.97 | 1235.8 |
2回目 | 3.72 | 1318.3 |
3回目 | 3.88 | 1263.9 |
平均 | 3.86 | 1272.7 |
実行結果比較
大容量ファイル転送(1GB × 5個)
1GB ファイルを 5 個アップロードするだけでも、並列実行できる s5cmd が優位でした。
コマンド | 転送時間 | 転送速度 | 備考 |
---|---|---|---|
aws s3 cp | 11.01 秒 | 464.8 MB/s | - |
s5cmd | 3.77 秒 | 1353.4 MB/s | 2.9倍高速 |
小容量多数ファイル転送(500KB × 10,000個)
10,000 個のファイル転送では劇的な差が現れました。s5cmd は並列実行な分、転送速度が大容量ファイルパターンと変わりありません。そのため、転送時間もほぼ変わらない早さです。
コマンド | 転送時間(秒) | 転送速度 | 備考 |
---|---|---|---|
aws s3 cp | 82.64 秒 | 59.3 MB/s | - |
s5cmd | 3.86 秒 | 1272.7 MB/s | 21.4倍高速 |
まとめ
AWS S3 へのデータ転送において、s5cmd は一般的な AWS CLI に比べ転送速度の向上が大いに期待できます。特に大量の小さなファイルの転送では顕著に差が現れました。
おわりに
1000 枚ほどの CT 画像(医療画像データ)を海外リージョンの S3 バケットに画像をそのまま形でアップロードする機会がありました。海外リージョンに 1000 枚の画像データ転送はいつ終わるのかと不安だったのですが、s5cmd のお陰ですぐ終わりました。これはすごいのでは?と気になったので検証してみました。ゲノム関係ファイルも細かいファイルに分かれることがあるので S3 バケットへアップロードへも使えそうです。