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

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

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

[gcping.com](http://www.gcping.com/) というサイトでAzure西日本(大阪リージョン)からレイテンシを計測すると大阪が東京よりも遅いことがわかりました。大阪の方が速い結果になった方はぜひ教えてください。:bow:
![Screenshot from 2019-04-21 19-38-10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/208363/2c679940-9304-87a9-8e5e-91f653667288.png)

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

```bash
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)

```bash
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)

```bash
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を返さない場合、*(アスタリスク)になります。

```bash
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ホップ)

```bash
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ホップ)

```bash
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が共通していることが分かります。

#### [マイクロソフトのインターネットエクスチェンジ](https://www.peeringdb.com/net/694)
![Screenshot from 2019-04-23 04-00-47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/208363/6356a06e-3d98-da2d-e7ec-b2b0d10a6ee2.png)

#### [Googleのインターネットエクスチェンジ](https://www.peeringdb.com/net/433)
![Screenshot from 2019-04-23 04-02-40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/208363/7799ad58-615c-b332-80d3-e284f4f67c20.png)

推測ですが、以上のことからパケットが東京のインターネットエクスチェンジ(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](https://www.peeringdb.com/net/433)で公開しています。

![Screenshot from 2019-04-21 20-26-58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/208363/ee860cb1-3679-d68f-cad1-1838ded61bd3.png)

専用線のEquinix Osaka(AWSのデータセンターとコロケーション、大阪市西区)とNTTテレパーク堂島ビル(大阪市北区)は、[Dedicated Interconnect](https://cloud.google.com/interconnect/docs/concepts/dedicated-overview?hl=ja)として直接接続できます。

また、BBIX Osakaは[キャリア ピアリング](https://cloud.google.com/interconnect/docs/how-to/carrier-peering?authuser=0&hl=ja)として、間接的に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ファイルをアップ

```bash
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ファイルをアップ

```bash
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`