【地域IX】GCP大阪リージョンはなぜ遅いのか レイテンシ編

最近、GCP大阪リージョン(asia-northeast2)が使えるようになりました。
私は大阪市北区に住んでいるのでとても嬉しいです。
GCP大阪リージョンで利用できるサービスは以下で確認できます。
https://cloud.google.com/about/locations/?region=asia-pacific#region
大阪リージョンでCloud Functionsが使えないのは残念ですね。(Cloud Runが来れば問題ない)

ネットワークについて素人ですのが間違えてる部分がたくさんあるかもしれません。

gcping.com というサイトでAzure西日本(大阪リージョン)からレイテンシを計測すると大阪が東京よりも遅いことがわかりました。大阪の方が速い結果になった方はぜひ教えてください。

Azure西日本からGCP大阪へのping(17ms)

azureuser@myVM:~$ ping -c 10 34.97.88.8
PING 34.97.88.8 (34.97.88.8) 56(84) bytes of data.
64 bytes from 34.97.88.8: icmp_seq=1 ttl=56 time=17.7 ms
64 bytes from 34.97.88.8: icmp_seq=2 ttl=56 time=17.1 ms
64 bytes from 34.97.88.8: icmp_seq=3 ttl=56 time=17.2 ms
64 bytes from 34.97.88.8: icmp_seq=4 ttl=56 time=17.3 ms
64 bytes from 34.97.88.8: icmp_seq=5 ttl=56 time=17.2 ms
64 bytes from 34.97.88.8: icmp_seq=6 ttl=56 time=17.3 ms
64 bytes from 34.97.88.8: icmp_seq=7 ttl=56 time=17.4 ms
64 bytes from 34.97.88.8: icmp_seq=8 ttl=56 time=17.3 ms
64 bytes from 34.97.88.8: icmp_seq=9 ttl=56 time=17.2 ms
64 bytes from 34.97.88.8: icmp_seq=10 ttl=56 time=17.2 ms

--- 34.97.88.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 17.198/17.345/17.747/0.206 ms

Azure西日本からGCP東京へのping(9ms)

azureuser@myVM:~$ ping -c 10 35.190.226.227
PING 35.190.226.227 (35.190.226.227) 56(84) bytes of data.
64 bytes from 35.190.226.227: icmp_seq=1 ttl=58 time=10.1 ms
64 bytes from 35.190.226.227: icmp_seq=2 ttl=58 time=9.81 ms
64 bytes from 35.190.226.227: icmp_seq=3 ttl=58 time=9.80 ms
64 bytes from 35.190.226.227: icmp_seq=4 ttl=58 time=9.78 ms
64 bytes from 35.190.226.227: icmp_seq=5 ttl=58 time=9.94 ms
64 bytes from 35.190.226.227: icmp_seq=6 ttl=58 time=9.90 ms
64 bytes from 35.190.226.227: icmp_seq=7 ttl=58 time=9.83 ms
64 bytes from 35.190.226.227: icmp_seq=8 ttl=58 time=9.76 ms
64 bytes from 35.190.226.227: icmp_seq=9 ttl=58 time=9.69 ms
64 bytes from 35.190.226.227: icmp_seq=10 ttl=58 time=9.70 ms

--- 35.190.226.227 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9015ms
rtt min/avg/max/mdev = 9.696/9.843/10.198/0.176 ms

GCP大阪からGCP東京へのping(8ms)

gcpuser@osaka:~$ ping -c 10 35.190.226.227
PING 35.190.226.227 (35.190.226.227) 56(84) bytes of data.
64 bytes from 35.190.226.227: icmp_seq=1 ttl=63 time=8.15 ms
64 bytes from 35.190.226.227: icmp_seq=2 ttl=63 time=8.19 ms
64 bytes from 35.190.226.227: icmp_seq=3 ttl=63 time=8.18 ms
64 bytes from 35.190.226.227: icmp_seq=4 ttl=63 time=8.19 ms
64 bytes from 35.190.226.227: icmp_seq=5 ttl=63 time=8.22 ms
64 bytes from 35.190.226.227: icmp_seq=6 ttl=63 time=8.17 ms
64 bytes from 35.190.226.227: icmp_seq=7 ttl=63 time=8.21 ms
64 bytes from 35.190.226.227: icmp_seq=8 ttl=63 time=8.32 ms
64 bytes from 35.190.226.227: icmp_seq=9 ttl=63 time=8.31 ms
64 bytes from 35.190.226.227: icmp_seq=10 ttl=63 time=8.36 ms

--- 35.190.226.227 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 8.151/8.233/8.364/0.127 ms

なぜ遅いのか？

GCP大阪とGCP東京のレイテンシが8msであり17msと9msの差(8ms)を考えると、
GCP大阪へのpingは東京を経由しているのではと考えました。

tracerouteを元に東京のホップを経由していないか確認してみます。

Azure西日本からGCP大阪へのtraceroute(23ホップ)

ルータがTime Exceeded Messageを返さない場合、*(アスタリスク)になります。

azureuser@myVM:~$ sudo traceroute -I 34.97.88.8
traceroute to 34.97.88.8 (34.97.88.8), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  8.88.97.34.bc.googleusercontent.com (34.97.88.8)  18.341 ms  18.339 ms  18.337 ms

Azure西日本からGCP東京へのtraceroute(20ホップ)

azureuser@myVM:~$ sudo traceroute -I 35.190.226.227
traceroute to 35.190.226.227 (35.190.226.227), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  227.226.190.35.bc.googleusercontent.com (35.190.226.227)  10.295 ms  10.305 ms  10.305 ms

GCP大阪からAzure西日本へのtraceroute(16ホップ)

gcpuser@osaka:~$ sudo traceroute -I 40.74.95.73
traceroute to 40.74.95.73 (40.74.95.73), 30 hops max, 60 byte packets
 1  be-122-0.ibr02.tyo30.ntwk.msn.net (104.44.20.41)  17.812 ms  17.807 ms  17.775 ms
 2  be-5-0.ibr02.osa31.ntwk.msn.net (104.44.16.235)  18.111 ms  18.159 ms  18.308 ms
 3  ae120-0.icr01.osa31.ntwk.msn.net (104.44.11.44)  17.745 ms  17.760 ms  17.759 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  40.74.95.73 (40.74.95.73)  17.890 ms  17.903 ms  17.901 ms

ほとんどアスタリスクですが、 tyo30.ntwk.msn.net は名前から東京にあると推測できます。また、msn.netであることからマイクロソフトのASであるとこともわかります。
GCP大阪からAzure西日本へ1ホップ目でマイクロソフトのエッジPOPに入ってることに注目してください。
マイクロソフトとGoogleのそれぞれのインターネットエクスチェンジ(L2IX)を確認すると、BBIXとEquinixとJPIXとJPNAPが共通していることが分かります。

マイクロソフトのインターネットエクスチェンジ

Googleのインターネットエクスチェンジ

推測ですが、以上のことからパケットが東京のインターネットエクスチェンジ(L2IX)でルーティングされて大阪に戻って来てる気がしませんか。
では、なぜtracerouteにインターネットエクスチェンジ(L2IX)が表示されてないのか疑問に思うかもしれません。
実は、インターネットエクスチェンジ(L2IX)はレイヤ2でルーティングするため表示されないのです。

一般的に用いられるtracerouteコマンドではレイヤ2IXは表示されない
https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%8D%E3%83%83%E3%83%88%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%81%E3%82%A7%E3%83%B3%E3%82%B8

Azure西日本からGCP大阪へのtracerouteは*(アスタリスク)ばかりでよくわかりませんが、このようなことからAzure西日本からGCP大阪へL2IXでルーティングしていてもおかしくないと思います。

地域IX問題

このようなことは、東京一極集中という問題にもなっています。

異なるプロバイダ同士でデータをやりとりする場合、物理的な距離が近くても、IPパケットははるばる東京まで往復して戻ってくることが多いといった無駄が発生している。
https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%8D%E3%83%83%E3%83%88%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%81%E3%82%A7%E3%83%B3%E3%82%B8

どうして40.74.95.73がマイクロソフトのIP、34.97.88.8がGoogleのIPだと分かるのか？

そもそも40.74.95.73がどこのASのIPか分からないとどこにルーティングしたらいいのか分かりません。
実は、GCEのIPアドレスやAzureのIPアドレスの範囲を予め公開しています。
そうすることで、1ホップ目からAzureやGCPのエッジPOPへルーティング可能なんだと思います。

Where can I find Compute Engine IP ranges?
https://cloud.google.com/compute/docs/faq#find_ip_range

Microsoft Azure Datacenter IP Ranges
https://www.microsoft.com/en-us/download/details.aspx?id=41653

レイテンシを小さくするには？

東京を経由せずに大阪府内でルーティングされればいいのですが、地域内折り返しのインターネットエクスチェンジが機能するのを待つしかないのでしょうか...

Googleは、Googleのデータセンターに接続しているインターネットエクスチェンジ(L2IX)や専用線(Private Peering)をPerringDBで公開しています。

専用線のEquinix Osaka(AWSのデータセンターとコロケーション、大阪市西区)とNTTテレパーク堂島ビル(大阪市北区)は、Dedicated Interconnectとして直接接続できます。

また、BBIX Osakaはキャリア ピアリングとして、間接的にGoogleのデータセンターに接続できるようです。

JPIX OSAKAはKDDIのIXPであり、JPNAP OsakaはNTTのIXPのようです。

まとめ

レイテンシを小さくするにはGoogleのデータセンターに接続するか、L2IXを通してTier1のプロバイダ(NTTコミュニケーションとか)を利用するとかになるのでしょうか。

List of Tier 1 networks
https://en.wikipedia.org/wiki/Tier_1_network#List_of_tier_1_networks#List_of_Tier_1_networks

番外編

大阪と東京のGoogle Cloud Storageのアップロード速度比較

Azure西日本から大阪リージョンへUbuntu 19.04のISOファイルをアップ

azureuser@myVM:~$ time gsutil cp ubuntu-19.04-desktop-amd64.iso gs://gcs-osaka/
Copying file://ubuntu-19.04-desktop-amd64.iso [Content-Type=application/x-iso9660-image]...
/ [1 files][  2.0 GiB/  2.0 GiB]   94.7 MiB/s                                   
Operation completed over 1 objects/2.0 GiB.                                      

real	0m20.423s
user	0m9.641s
sys	0m2.386s

Azure西日本から東京リージョンへUbuntu 19.04のISOファイルをアップ

azureuser@myVM:~$ time gsutil cp ubuntu-19.04-desktop-amd64.iso gs://gcs-tokyo/
Copying file://ubuntu-19.04-desktop-amd64.iso [Content-Type=application/x-iso9660-image]...
/ [1 files][  2.0 GiB/  2.0 GiB]   96.4 MiB/s                                   
Operation completed over 1 objects/2.0 GiB.                                      

real	0m19.987s
user	0m9.511s
sys	0m2.145s

やはり、大阪のほうが遅いみたいです。

最後に

もし、さくらのVPSの大阪やAWSの大阪リージョンが使える方でGCP大阪にpingを投げてくれるととても嬉しいです。 ping 34.97.88.8 ping 35.190.226.227