Amazon CloudFront スループットを測ってみた


Amazon EC2系の記事を書く際にちゃんと動く内容を示さないといけないと思い、実際動作させながら確認していった。その中でも Amazon CloudFront のスループット測定はデータとしてちゃんと取れたので、導入効果が分かりやすかった。

実際どれくらいパフォーマンスに差が出るのか、ファイルのダウンロードのスループット結果は以下。

  • ダウンロードに使ったファイルは “Office2004-1154UpdateJA.dmg” で 9.8MB ほどのファイル
  • Amazon S3 上の “test” bucket 上にファイルを保存
  • “test” bucket を CloudFront に適用させる
  • 割り当てられたダウンロード可能なサーバのそれぞれの FQDN は以下
    • オリジンサーバ : hironobu-bucket.s3.amazonaws.com</p>
      • Region: Us-East なので、日本からだと太平洋を渡って、アメリカをwestからeastまで横断する経路になるはず
    • キャッシュサーバ : dql6mokzq0d1p.cloudfront.net
    • オリジンは ****.s3.amazonaws.com, キャッシュサーバは ****.cloudfront.net という名前になるのが特徴
  • Mac からそれぞれのサーバの URL に対して curl コマンドでダウンロードする
  • 3回ほど測定

オリジンサーバからのダウンロード

```bash dsea-MacBook:~ hironobu$ curl -o /dev/null -w time_total http://hironobu-bucket.s3.amazonaws.com/test/Office2004-1154UpdateJA.dmg % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 9.8M 100 9.8M 0 0 355k 0 0:00:28 0:00:28 --:--:-- 736k time_totaldsea-MacBook:~ hironobu$ curl -o /dev/null -w time_total http://hironobu-bucket.s3.amazonawsOffice2004-1154UpdateJA.dmg % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 9.8M 100 9.8M 0 0 370k 0 0:00:27 0:00:27 --:--:-- 401k time_totaldsea-MacBook:~ hironobu$ curl -o /dev/null -w time_total http://hironobu-bucket.s3.amazonawsOffice2004-1154UpdateJA.dmg % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 9.8M 100 9.8M 0 0 404k 0 0:00:24 0:00:24 --:--:-- 377k

ばらつきがあるが、400kB = 3.2Mbps くらい。太平洋とアメリカを横断するからこんなもんでしょう。

キャッシュサーバからのダウンロード

```bash dsea-MacBook:~ hironobu$ curl -o /dev/null -w time_total http://dql6mokzq0d1p.cloudfront.net/test/Office2004-1154UpdateJA.dmg % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 9.8M 100 9.8M 0 0 2364k 0 0:00:04 0:00:04 --:--:-- 2374k time_totaldsea-MacBook:~ hironobu$ curl -o /dev/null -w time_total http://dql6mokzq0d1p.cloudfront.netce2004-1154UpdateJA.dmg % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 9.8M 100 9.8M 0 0 2370k 0 0:00:04 0:00:04 --:--:-- 2380k time_totaldsea-MacBook:~ hironobu$ curl -o /dev/null -w time_total http://dql6mokzq0d1p.cloudfront.netce2004-1154UpdateJA.dmg % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 9.8M 100 9.8M 0 0 2344k 0 0:00:04 0:00:04 --:--:-- 2355k ```

大体、2300kB/s = 18.4Mbps くらい

国内ならばもうちょっとでても良いかもだがこんなもんか。オリジンと比べて約6倍速い。

AWS を利用するにはインスタンスの物理位置は US or EU になってしまうので、どうしても日本からアクセスする際のネットワーク遅延の問題は付いて回る。これが日本においたキャッシュサーバを利用すれば解消できてしまうのは、あまり解決策として注目されていないかもしれない。

ただ、静的ファイルだけがキャッシュに置けるので、動的なページ生成には適用できない。

確か、学びing さんが一緒にやった Amazon EC2/S3 実践セミナーの時に動的に生成する部分の容量はすごく小さいから、重たい画像などをどんどん CloudFront においてパフォーマンスを上げるノウハウを紹介していたな。

AWS は単に Amazon EC2/S3 だけを利用するだけではそのメリットはあまり生かせていなくて、その周辺のサービスも含めて利用することで日本からでも十分パフォーマンスの良いサイトが提供できると思っている。

ただ、これを利用するには AWS に対する独自なノウハウが必要で、よく分からないながらも手探りで経験しながら体得していった貴重な価値になるだろう。やってみてしまえばそれほど難しい世界ではないことが分かる。

幸い日本にはこれを活かしきれるノウハウを持った人たちがまだ少ないと思うので、価値を高めてくれていると感じる。

Related Posts

長沼公園 - お気に入りの場所

Flutter in_app_purchase で定期購入を実現する方法 2023年版

ペップのビルドアップ UEFA Champions League Final

テクニカルアドバイザー仕事が終わったのでまとめ

Amazon で Kindle とペーパーバックを作るやり方

[思考]老いへの許容

「ひとりスタートアップ」が本の形になりました

2022年を振り返る

ハードウエアのWeb化

本を書きました「ひとりスタートアップ」