目次
はじめに
データイノベーション部浅田です。
アプリケーションにとって、どれだけサクサク動くかというのは重要な指標の一つです。Webアプリケーションやモバイルアプリケーションなどのネットワークの利用を前提としたアプリケーションにおいては、ネットワークのレスポンスの良さ、というのも重要なファクターになります。
せっかく情熱などをもって構築したサービスも、コンテンツの表示に時間がかかってしまうと「何よりも、速さが足りない!」と思われてしまいかねません。
そこで、今回ご紹介するサービスがこちら!
AWS Global Accelerator(以下Global Accelerator)
となります。
より詳しい特徴は上記をご確認頂ければと思いますが、色々あるメリットのうち、今回お伝えしたい内容としては、こちらのサービスを使うとネットワーク速度改善のメリットが得られるという点です。
「ネットワーク速度」はインターネットサービスとして限りなく速いことが望ましいです。そこで今回は、上記の二点について、Global Acceleratorを使わなかった場合と使った場合にどれだけかわるのかを検証して見たいと思います。なお、EC2にNginxをインストールし、そのレスポンスを確認する、という手順で見ていきます。
検証
前提
EC2インスタンスタイプ: m5.large
Nginx: 1.18.0
クライアント: curl 7.54.0
場所: アピリッツ社内(東京都渋谷区)
[EC2 IP]
東京: 54.250.246.155
バージニア: 34.229.65.223
[Global Accelerator IP]
75.2.96.126
99.83.178.155
なお、速度の比較として、10回読み込みを行い、その平均値を計測するものとします。
準備
東京リージョンとバージニア北部リージョンとにEC2を起動して、以下のコマンドでnginxのインストールおよびダミーファイルを準備します。
# EC2内で実行
sudo amazon-linux-extras install nginx1
cd /usr/share/nginx/html/
sudo dd if=/dev/zero of=1M.dummy bs=1M count=1
sudo dd if=/dev/zero of=20M.dummy bs=1M count=20
sudo service nginx start
計測用に以下のスクリプトをspeed-test.shの名前でローカルに用意します。
# 接続
echo "### サンプリング(秒)"
for i in {1..10}; do curl -XGET -w "%{time_total}\n" -o /dev/null -s ${1}; done | tee tmp.lst
# 平均値出力
echo "### 平均(秒)"
awk '{sum+=$1} END {print sum/NR}' tmp.lst
rm tmp.lst
最後に、Global Acceleratorを作成し、東京リージョンのEC2にエンドポイントの向き先を設定します。以上で、準備完了です。
第一弾 東京リージョン
第一弾として、東京リージョンへのアクセスでのGlobal Accelerator有無の速度についての比較をします。
1Mのファイル
まずは、直接EC2にアクセスします。
$ sh speed-test.sh http://54.250.246.155/1M.dummy
### サンプリング(秒)
0.109332
0.119329
0.131457
0.129000
0.115801
0.110114
0.132545
0.113515
0.112620
0.111140
### 平均(秒)
0.118485
次にGlobal Accelerator経由です。
$ sh speed-test.sh http://99.83.178.155//1M.dummy
### サンプリング(秒)
0.109456
0.105758
0.107199
0.107842
0.105607
0.108402
0.110008
0.104493
0.106547
0.109290
### 平均(秒)
0.10746
ん?少し早くなったかな、ぐらいでほぼ差はないですね。
20Mのファイル
直接EC2へのアクセスの場合を計測します。
$ sh speed-test.sh http://54.250.246.155/20M.dummy
### サンプリング(秒)
1.816273
1.810556
1.807303
1.802766
1.808038
1.808243
1.800309
1.804496
1.986049
1.805717
### 平均(秒)
1.82498
次にGlobal Accelerator経由です。
$ sh speed-test.sh http://99.83.178.155/20M.dummy
### サンプリング(秒)
1.802430
1.806430
1.804574
1.802140
1.800463
1.798066
1.802565
1.798186
1.846157
1.800256
### 平均(秒)
1.80613
ほぼ変わらないですね。
Global Acceleratorはアクセス元が対象リージョンに近いとそのメリットをあまり享受できないようです。
第二弾 バージニア北部リージョン
次に、国外のリージョンであるバージニア北部リージョンへのアクセスでのGlobal Accelerator有無の速度についての比較をしたいと思います。Global Acceleratorのエンドポイントをバージニア北部リージョンのEC2に切り替えます。
1Mのファイル
まずは直接EC2へのアクセスのケースです。
$ sh speed-test.sh http://34.229.65.223/1M.dummy
### サンプリング(秒)
3.134302
3.162077
3.117981
3.098290
3.150670
3.066146
3.134135
3.137177
3.134533
3.180120
### 平均(秒)
3.13154
次にGlobal Accelerator経由の場合です。
sh speed-test.sh http://99.83.178.155/1M.dummy
### サンプリング(秒)
1.040463
1.034937
1.036202
1.040337
1.032864
1.034404
1.035367
1.032810
1.041944
1.032675
### 平均(秒)
1.0362
お、およそ三倍の速度が出ているようです。
20Mのファイル
まずは直接EC2へのアクセスの場合です。
$ sh speed-test.sh http://34.229.65.223/20M.dummy
### サンプリング(秒)
7.312831
5.675996
6.660435
12.293564
7.569658
16.370434
13.757100
8.670905
16.401453
8.794712
### 平均(秒)
10.3507
時間もそこそこかかってますが、今までに比べてバラツキが大きくなっているのも気になります。(念のため、数回サンプリングしてみましたが、どのケースもバラツキは大きかったです。)
次にGlobal Accelerator経由です。
$ sh speed-test.sh http://99.83.178.155/20M.dummy
### サンプリング(秒)
2.739648
2.741390
2.741749
2.737428
2.763309
2.729312
2.731547
2.742664
2.736493
2.772755
### 平均(秒)
2.74363
かなり早くなりました。7秒も世界を縮めてしまいました。そして、ばらつきもほとんどなく、安定した速度が出ています。ついに見つけました、Global Acceleratorの真髄を!
第三弾 東京リージョン内のEC2からバージニア北部リージョンのEC2へのアクセス
第一弾と第二弾とでは、ユーザのアクセスを想定して筆者のローカルからアクセスして計測してみましたが、最後に東京リージョンのEC2からバージニア北部リージョンのEC2へアクセスした際の時間を計測してみます。
1Mのファイル
まず、直接EC2です。
$ sh speed-test.sh http://34.229.65.223/1M.dummy
### サンプリング(秒)
1.370514
1.372094
1.367089
1.380025
1.339979
1.375507
1.333260
1.373431
1.338106
1.367856
### 平均(秒)
1.36179
素でもかなり速くなっています。AWS内の回線品質の良さを伺わせます。
次にGlobal Accelerator経由です。
$ sh speed-test.sh http://99.83.178.155/1M.dummy
### サンプリング(秒)
0.870017
0.873519
0.872324
0.867491
0.870899
0.874320
0.875362
0.870478
0.873536
0.869653
### 平均(秒)
0.87176
倍とまではいきませんが、十分速くなっています。EC2内からアクセスした際にも、Global Acceleratorの恩恵は得られるということですね。
20Mのファイル
直接EC2の場合を計測します。
$ sh speed-test.sh http://34.229.65.223/20M.dummy
### サンプリング(秒)
3.528554
3.487068
3.753335
3.572857
3.675303
3.662903
3.599749
3.639234
3.552648
3.611756
### 平均(秒)
3.60834
ローカル環境からのアクセスに比べて十分に高速であるとともに、速度の安定度も感じられます。
次に、Global Accelerator経由です。
$ sh speed-test.sh http://99.83.178.155/20M.dummy
### サンプリング(秒)
2.467313
2.235525
2.159171
2.311107
2.023744
2.461509
2.320583
2.027042
2.169427
2.033224
### 平均(秒)
2.22086
さらに速くなっていますね。
検証結果
計測された、速度改善率をまとめると以下の通りです。
ロケーション | 1Mファイル | 20Mファイル |
---|---|---|
ローカル to 東京リージョン | 約9% | 約1% |
ローカル to バージニア北部リージョン | 約67% | 約73% |
東京リージョン to バージニア北部リージョン | 約36% | 約38% |
以上のことより、Global Acceleratorは特に離れたリージョンへのアクセス改善に効果を発揮するということが言えると思います。また、ファイルサイズが大きい方がメリットも大きくなった結果となりました。
まとめ
Global Acceleratorを使用することで、特に遠く離れたリージョンのサービスにアクセスする際に、かなり速度面でメリットを得られることがわかりました。特に大きなファイルをダウンロードする際には、単純な速度面もさることながら、安定した通信環境につなげるというのもメリットとなるかとおもいます。
今回は速度面に焦点を当てましたが、Global Acceleratorはその他にも利点があります。例えば、グローバルにサービスを展開している場合には、それぞれのリージョンのApplication Load Balancingの前段に配置することで、指定したWeightに応じてリクエストを各リージョンに割り振ることもできます。一つのリージョン内で運営する際にも、Blue Greenデプロイに活用することも可能でしょう。
また、Application Load BalancingではIPアドレスは可変のため、CNAMEで名前解決するように設定しますが、Apexドメインで名前解決する際にはCNAMEが設定できないことが問題になったりするケースも存在します。ですが、Global Acceleratorの場合は固定IPが振られるため、Aレコードで指定できるので、Apexドメインの問題が解消されます。
以上、Global Acceleratorの紹介&速度検証でした。