Zenn
🐟

私たちの通信はどのようにしてAWSに届いているのか？

2022/12/17に公開
AWS
network
tech

はじめに

皆さまは自分たちの通信がどのようにAWSに届いているか日々意識しているでしょうか？
ここ数年でAPI GW, Lambda, S3をはじめとするマネージドサービスの普及により、ネットワークを意識せずともなんとなくシステムを動かせるようになりました。
しかし、本記事を執筆している2022年12月現在ではネットワークを意識してアーキテクチャを設計する必要のある場面がまだまだあると思います。
（AWS re:Invent 2022で発表されたAmazon VPC LatticeやAmazon ECS Service Connectなどのサービスを見ていると、もしかしたら10年後にはネットワークを一切意識する必要がなくなってくるのでは・・・と妄想を膨らませております）

本記事の前提

  • Direct ConnectやSite-to-Site VPNなどを利用した閉域の通信ではなく、インターネット経由の通信を想定しています。
  • いわゆるOSI参照モデルやTCP/IPについて、ある程度の理解がある前提で記載します。
    余談ですが、OSI参照モデルは区切りが細かいので、大抵の場合はTCP/IPプロトコルで4層を意識すれば事足りると思います。
    OSI参照モデルやTCP/IPについてはネットワークエンジニアとしてが参考になるかと思います。
  • TCP/IPのトランスポート・インターネット層を主なターゲットとしています。
  • Amazon VPC(SG, NACL)などについての設定解説や説明はしません。

対象読者

  • 日頃行っている通信がどのようにAWSへ到達するのか知りたい方
  • エンドユーザとAWS間のレイテンシやジッターを減らす方法をインフラ観点で知りたい方

導入

漠然とネットワークを意識すると言ってもイメージが湧きにくいと思いますので以下図のような構成で通信を行った際の経路について見てみましょう。

Userが各リージョンのEC2と通信している図

次に、有線LANで接続されたPC(関東)から、東京リージョンおよび南米サンパウロリージョンのEC2へnetperfコマンドを用いてレイテンシなどを計測した結果を記載します(JST 土曜日18時台に実施)

実行コマンド

$ netperf -H ${DESTINATION_IP} -l 60 -t TCP_RR -w 1000ms -v 2 -- -O min_latency,mean_latency,max_latency,stddev_latency,transaction_rate

※${DESTINATION_IP}はEC2のGIP

結果

To min(ms) avg(ms) max(ms) 標準偏差(ms) Transaction/s
東京 11.633 12.372 25.133 0.371 80.803
南米サンパウロ 274.421 276.389 550.331 18.641 3.601

結果を見ると、「関東から東京リージョンへの通信」と「関東から南米サンパウロリージョン」に通信するのではかなりの差があることがわかります。
また、今回測定してわかったのですが「関東から東京リージョンへの通信」の標準偏差(p95)が0.371(ms)と、とても小さいことから、日本のネットワーク品質は非常に高いのだと再認識しました。

通信経路

次に、クライアント(関東)から、東京リージョンおよび南米サンパウロリージョンへどのような通信経路となっているかを確認してみましょう。
今回は tracerouteコマンドを用いて経由するASを基に通信経路を探って行きます。
ASについてはネットワークエンジニアとしてが参考になるかと思います。

実行コマンド

$ traceroute -a -P UDP -p 53 -q 1 -m 255 ${DESTINATION_IP}

※${DESTINATION_IP}はEC2のGIP

Tips:
  • tracerouteコマンドはMacbookにて実行しています。他OSだとオプションの指定方法が異なる場合があります。
  • ICMPやTCPだと応答を返さない機器が多かったため、今回はUDP(ポート53)を利用しています。
  • 対向に設置してあるEC2に紐づいているSGでUDP(ポート53)をGIPを絞って許可しています。
注意点:
  • tracerouteコマンドの応答を返さないAS(機器)もありますので、実際には実行結果よりも多くのASを経由してる可能性が高いです。

実行結果(関東-->東京リージョン)

traceroute to 35.77.3.218 (35.77.3.218), 255 hops max, 52 byte packets
 1  [AS0] 192.168.0.1 (192.168.0.1)  1.593 ms
 2  [AS2516] 27.85.197.217 (27.85.197.217)  11.091 ms
 3  [AS2516] 175.129.54.198 (175.129.54.198)  10.181 ms
 4  [AS16509] 150.222.77.163 (150.222.77.163)  12.576 ms
 5  [AS7545] 15.230.152.119 (15.230.152.119)  15.489 ms
 6  *
 7  [AS16509] 150.222.241.96 (150.222.241.96)  12.987 ms
 8  *
 9  [AS14618] 52.95.31.53 (52.95.31.53)  16.035 ms
10  [AS14618] 52.95.31.161 (52.95.31.161)  12.116 ms
11  [AS16509] 52.93.72.233 (52.93.72.233)  13.858 ms
12  [AS7545] 15.230.154.29 (15.230.154.29)  13.022 ms
13  [AS7545] 15.230.154.74 (15.230.154.74)  18.062 ms
14  *
15  *
16  *
17  *
18  *
19  *
20  [AS16509] ec2-35-77-3-218.ap-northeast-1.compute.amazonaws.com (35.77.3.218)  13.323 ms
ASの経由順番(関東-->東京リージョン)
  1. AS2516: KDDI管理
  2. AS16509: AWS管理
  3. AS7545: TPG Telecom Limited管理(おそらくAWS管理配下)
  4. AS16509: AWS管理
  5. AS14618: AWS管理
  6. AS16509: AWS管理
  7. AS7545: TPG Telecom Limited管理(おそらくAWS管理配下)
  8. AS16509: AWS管理

実行結果(関東-->南米サンパウロリージョン)

 1  [AS0] 192.168.0.1 (192.168.0.1)  1.472 ms
 2  [AS2516] 27.85.197.217 (27.85.197.217)  10.602 ms
 3  [AS2516] 106.139.192.153 (106.139.192.153)  11.668 ms
 4  [AS2516] 106.139.193.30 (106.139.193.30)  11.620 ms
 5  [AS2516] 106.187.12.42 (106.187.12.42)  117.104 ms
 6  [AS2516] 203.181.106.230 (203.181.106.230)  110.231 ms
 7  [AS6517] ae28.cr3-lax2.ip4.gtt.net (208.116.133.197)  123.275 ms
 8  [AS3257] ae12.cr7-dal3.ip4.gtt.net (213.200.120.106)  140.203 ms
 9  [AS26015] ip4.gtt.net (209.120.154.162)  143.645 ms
10  [AS16509] 150.222.206.223 (150.222.206.223)  148.745 ms
11  [AS0] 176.32.125.243 (176.32.125.243)  144.750 ms
12  [AS16509] 52.93.34.129 (52.93.34.129)  145.090 ms
13  [AS16509] 150.222.99.158 (150.222.99.158)  141.703 ms
14  *
15  [AS16509] 54.240.244.196 (54.240.244.196)  272.696 ms
16  [AS16509] 150.222.69.113 (150.222.69.113)  286.235 ms
17  *
18  [AS16509] 54.240.244.171 (54.240.244.171)  280.876 ms
19  [AS16509] 177.72.240.127 (177.72.240.127)  277.826 ms
20  *
21  *
22  *
23  [AS16509] ec2-18-231-141-186.sa-east-1.compute.amazonaws.com (18.231.141.186)  276.871 ms
ASの経由順番
  1. AS2516: KDDI管理
  2. AS6517: GTTNQ管理
  3. AS3257: GTTNQ管理
  4. AS26015: GTTNQ管理
  5. AS16509: AWS管理

通信経路考察

上記の結果から今回検証した限りでは、関東-->東京リージョンは20ポップ, 関東-->南米サンパウロリージョンには23ポップで到達することができたようです。
関東-->東京リージョンへは、tracerouteを試行したPC端末のIX(KDDI)から直接AWSに入って行っており、
関東-->南米サンパウロリージョンへは、KDDIからGTTNQを経由してAWSに入っていることがわかりました。

※余談とはなりますが、関東-->南米サンパウロリージョンの11ポップ目でAS0となっている箇所がありますが、AS番号0はICANNによって予約されたAS番号なので利用してはいけません。tracerouteコマンドのソースコードを読んでみましたが、おそらくtraceroute.cとas.cの仕様(バグ?)だと思います。
（この記事を見た有識者の方はコメントいただけると嬉しいです。Twitterに私の見解を書いてありますので、レスいただけると嬉しいです）

エンドユーザとAWS間のレイテンシやジッターを減らすには？

どのようにクライアントからAWSへ通信が行われているか理解できたでしょうか？

関東から南米サンパウロに通信する人はあまりいないかもしれないですが、AWSのサービスを利用してパフォーマンスを改善してみましょう。
AWSにはAWS Global Acceleratorというサービスがあります。
AWS Global Acceleratorを設定している場合、利用した方が良いとAWS Global Acceleratorが判断した際には全世界にあるAWS Global Acceleratorのエッジロケーション経由で通信が行われ、レイテンシやジッターを低くすることでインターネットよりも高パフォーマンスで安定した通信が可能となります。

AWS re:Invent 2022 Improve performance and availability with AWS Global Acceleratorより抜粋

関東-->南米サンパウロリージョンの通信をAWS Global Accelerator経由にしてみた

AWS Global Acceleratorを作成して、再度netperfコマンドを用いて測定した結果が以下です。

結果

min(ms) avg(ms) max(ms) 標準偏差(ms) Transaction/s
AWS Global Accelerator無し 274.421 276.389 550.331 186.417 3.601
AWS Global Accelerator有り 262.792 264.763 517.518 168.564 3.766

AWS Global Accelerator無しの場合よりもレイテンシが低くなり、標準偏差も低くなっています。
もう少しパフォーマンス改善するかと思っていましたが、今回のケースでは思ったほどの改善はなかったです（通信元が海外のネットワーク環境があまり良くない地域だと改善幅が異なってくると思います）
また、AWS Global Acceleratorはキャッシュを行わないため、キャッシュできる静的コンテンツはAmazon CloudFrontを利用するのが良いと思います。

まとめ

今回は、普段あまり意識されることが少ないであろうクライアントからAWSへインターネット経由で通信する際の経路について探ってみました。
最初にも書いた通り、まだまだ通信の流れを意識してシステムを動かしていくこと(設計/運用)が重要だと思います。

この記事を読んでくださった皆様が、少しでもAWSのネットワークに興味をもっといただけたら幸いです。

Discussion