1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

S3の転送速度って、、、どんぐらい?こんぐらい

Last updated at Posted at 2024-10-30

はじめに

某ベンダで、クラウドの人材育成企画と研修トレーニングのデリバリを担当しています。
先日、講義の中に受講者の方から「パブリック回線を利用したS3への転送速度って、性能の目安はどのくらい?」と質問を頂きました。通常、10TBを超えると大量データの移行はAWS Snowball使いましょう、と講義では教えているのですが、実際にS3の性能を測ったことがなく解答にモゴモゴしちゃいました。世の中に色々と実測情報は出ていますが、折角なので、自分で計測してみるとにしました。

前提環境

仕事でお借りしている、某サテライト事務所のwifi環境を利用します。
USENの回線スピードテストで測定してみました。

[ネットワーク]
DOWN LOAD:25Mbps
UPLOAD: 21Mbps

[クライアント環境]
Ubuntu Server 24.10 (MacBook Air(M2)上の仮想VM)

[S3]
東京リージョン
シドニーリージョン

評価手順

1. aws-cliのインストールと設定

Ubuntu Serverを利用したので、aptコマンドを利用します。依存関係を解決してaws-cliをインストールします。便利ですねー、以前はパッケージを個別に入手してたハズが本当に楽になりました。インストール後にaws configureで、各種設定を行います。

# apt install awscli
# aws --version
aws-cli/2.17.3 Python/3.12.7 Linux/6.11.0-9-generic source/aarch64.ubuntu.24
# aws configure 
# aws configure list

2. アップロード転送用にデータの作成

乱数生成機能を利用して、アップロード転送用に500MB、100MBのデータをそれぞれ作成します。本当はGB単位で転送データを作りたいのですがディスク容量が少ないので、小さなデータで実験します。

# dd if=/dev/random of=500_data  bs=1M count=500
# dd if=/dev/random of=100_data_3  bs=1M count=100

3. S3の作成とファイルのアップロード評価

aws cliのコマンドラインで、500MBのデータと100MBのデータをそれぞれアップロードしてtimeコマンドで時間を計測します。

○ 500MBのデータをアップロードした場合

# time aws s3 cp 500_data s3://{東京リージョンのバケット名}
upload: ./500_data to s3://{東京リージョンのバケット名}/500_data

real	3m23.277s
user	0m6.374s
sys	0m4.306s

# time aws s3 cp 500_data s3://{シドニーリージョンのバケット名}
upload: ./500_data to s3://{シドニーリージョンのバケット名}/500_data

real	5m33.144s
user	0m7.945s
sys	0m5.217s

○ 100MBのデータを順次アップロードした場合

# time aws s3 cp 100_data_1  s3://{東京リージョンのバケット名}
upload: ./100_data_1 to s3://{東京リージョンのバケット名}/100_data_1

real	0m31.305s
user	0m1.425s
sys	0m1.243s

# time aws s3 cp 100_data_1  s3://{シドニーリージョンのバケット名}
upload: ./100_data_1 to s3://{シドニーリージョンのバケット名}/100_data_1

real	1m39.429s
user	0m1.753s
sys	0m0.934s

[トラブル発生] 時刻ズレのエラーが出てしまった

実測中に以下のトラブルが出てしまいました。

An error occurred (RequestTimeTooSkewed) when calling the CreateMultipartUpload operation: The difference between the request time and the current time is too large.

仮想VMの時間設定をサボっていたので、時間ズレが発生してしまったようです。
timedatectlコマンドでクライアント側の時刻を合わせて、無事に問題解決しました。

# timedatectl set-timezone Asia/Tokyo
# date
Thu Oct 31 07:22:36 JST 2024

おわりに

リージョンで比較すると、想定通り、近隣のリージョン>>遠方のリージョンで性能差が出ていました。ネットワーク環境がそんなに良いものではなかったのですが、もう少し速度の出る環境だと1GB/分くらいアップロードの性能が出てもおかしく無さそう、かなと思います。数テラ単位のデータ転送だと、十分S3へのネットワーク転送でも要件は満たせそう。実は朝と深夜で性能評価したのですが、時間帯でも性能に大分揺れがありました。パブリック回線を使う限り、混まない時間帯を利用することが鉄則ですね。

今回、実測は淡々と進んだのですが、MackBook Air(M2)に何の仮想化機構を使うか悩んでしまいました。Intel Mac時代にVirtual Boxが秀逸だったので長年利用していたのですが、今回を機会にVMware Fusionに仮想化機構を引っ越ししました。VMware Fusionって、今年の春先から無償で利用できるようになったんですね。まだまだ修行です。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?