0
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?

【AWS】なんとなく東京リージョンを選んでいたのでちゃんと検証してみた

0
Posted at

はじめに

AWSを使う際、おそらく 東京リージョン(ap-northeast-1) を選択することが多いと思います。
これは以下のような前提に基づいています。

  • 日本国内のユーザが大半であること
  • 日本国内にデータを保管しておきたい
  • レイテンシーが最小になるはず

私自身、上記理由は把握していながらも、なんとなく東京リージョンを選びがちになっておりました。
今回はレイテンシーに注目して、本当に東京は最速なのかを検証しようと思います。

検証すること

以下のリージョンに対してALBを作成し、HTTPリクエストを送ることでレイテンシーを測定します。

  • 東京
  • 大阪
  • シンガポール
  • バージニア北部
  • サンパウロ

なお、測定元は東京近郊(私の家)とします。

検証結果

以下の通りとなりました。

リージョン レイテンシー
東京 33.1292 ms
大阪 139.517 ms
シンガポール 225.019 ms
バージニア北部 508.59 ms
サンパウロ 619.534 ms

予想通りではありますが、東京リージョンのレイテンシーが最小という結果になりました。
物理距離に比例するということが結果からも確認できます。

CloudFrontではどうなるか

次にCloudFrontの場合を検証してみます。
CloudFornt配下のオリジンにALBを指定しました。
果たして結果は・・・

リージョン レイテンシー
東京 31.8299 ms
大阪 31.7758 ms
シンガポール 33.6764 ms
バージニア北部 31.4756 ms
サンパウロ 33.1176 ms

どのリージョンもあまり変わらないという結果になりました。
CloudFrontを経由した場合、リクエストはエッジロケーションで処理されるため
オリジンのリージョン差はほぼ吸収されます。

そのためどのリージョンを使っても同じような結果になるようです。

CloudFrontのキャッシュヒット状態で測定しています。
キャッシュされなかった場合はALB直アクセスと同様、
レイテンシーは物理距離に比例しました。

まとめ

今回の検証結果から以下がわかりました。

  • 日本からのアクセスにおいては東京リージョンが最速であること
  • ALB直アクセスの場合は物理距離に比例すること
  • CloudFrontを使えばリージョン差は吸収できること

そのため「東京リージョン」が本当に最適なのかはユースケース次第であるともいえます。
リージョン選定は 「なんとなく」 ではなく、
レイテンシーやアーキテクチャ特性 に基づいて判断する必要があります。

今回の結果は、大方想定通りとなりましたが
「当たり前とされている常識」 が本当に正しいのかを疑いながら考えていきたいと思います。

検証に使った時のコードはこちらに公開しております。

0
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
0
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?