Slack 社の Secured API Acceleration with Engineers from Amazon CloudFront and Slack という資料を読んでいたら、Slack社のようなグルーバル企業において「CloudFront をはさんだらキャッシュしないAPIアクセスでも速くなった :D」 と書いてあった。しかし、CloudFront (例えばjp)から ELB (例えばus) までは依然として大きな latency があるわけで、本当に速くなるのか懐疑的だったので自分でも試してみた。

このスライドの11ページに速くなった理由は5つ書いてあり、以下のとおり。

  • (1) CloudFront Latency Based Routing
  • (2) TCP/IP Optimizations for the Network Path
  • (3) Keep-Alive Connections to reduce RTT
  • (4) AWS Backbone Network
  • (5) SSL/TLS Optimizations

(1) CloudFront Latency Based Routing については、日本のエッジロケーションを自動選択してくれるんだから、まぁそうだよね、という感じで、 (5) SSL/TLS Optimizations についても、距離が近くなればSSL確立まで速くなるのは、まぁわかる、という感じ。

(4) AWS Backbone Network については、なにかあるんだろうが、実際速くなるんだろうか、という気持ちで、 (2) TCP/IP Optimizations for the Network Path と (3) Keep-Alive Connections to reduce RTT については、何を指しているのかがスライドには書いてなくて、わからん、という感じ。試してみたほうが早いな、と。

やったこと

  • us-east-1 に t2.nano で Amazon Linux なインスタンスを立て、nginx-1.8.1-3.27.amzn1.x86_64 を yum install して空の index.html を返すようにしておく(素の設定のまま)
  • us-east-1 に ELB を立てて作ったインスタンスを追加しておく (ELB を作るのは、CloudFront が ELB か S3 しかオリジンに設定できないため)
  • CloudFront を立てて、ELB をオリジンに設定。キャッシュを一切しないように設定しておく

この状況で日本のオフィスから以下の ruby スクリプトを実行して、ELBを指定した場合とCloudFrontを指定した場合の時間を計測した。

エッジロケーションまでの距離が近くなればSSL確立の時間が短くなるのはわかっているので、あえてhttpsではなくhttpで計測して、(4) AWS Backbone Network にどれぐらいの効果があるのかを検証した。

require 'net/http'
fqdn = 'xxxxxx'

started = Time.now.to_f
# no keeepalive
10.times do
  Net::HTTP.get fqdn, '/index.html'
end
puts "#{(Time.now.to_f - started) / 10.0} sec / req"

結果

  • ELB: 0.405 sec / req
  • CloudFront: 0.267 sec / req

確かに速くなった。

DSA (Dynamic Site Acceleration) と呼ばれる技術体系

rebuildfm fastly の miyagawa さんに twitter で教えて頂いたが、fastly など他のCDNでも、エッジロケーション <=> オリジン間のネットワーク最適化は行っているそうで業界的には DSA と呼ばれる技術体系とのこと。TCP multiplexing や HTTP keep-alive したりしているようだ。参考:速度比較

まとめ

確かにキャッシュなしでも 

  • (2) TCP/IP Optimizations for the Network Path
  • (3) Keep-Alive Connections to reduce RTT
  • (4) AWS Backbone Network
といった DSA の技術により、1 HTTP リクエストにおける RTT が事実上 2/3 程度に短縮された。さらにSSL確立もCDNでやれば距離が近い分もっと速くなるので実用としてはもっと差がでるだろう。


ちょうど us リージョンに立てているけれど、日本からもアクセスされる API サーバがあるので、使ってみようかな。

蛇足

ap-northeast-1 の EC2、ELB に対して日本のオフィスから CloudFront 経由でアクセスした場合はどう?と聞かれたので、念のため実際に計測した結果を書いておく。物理的な距離はどちらもたいして変わらないので、結果もたいして変わらないだろうと予想。むしろ、CloudFront の1段が増えるので遅くなる可能性もありそう。


結果 

  • EC2直接: 0.030 sec / req
  • ELB: 0.063 sec / req
  • CloudFront: 0.064 sec / req

予想通り、たいして変わらなかった。