IBM Cloud: Transit Gatewayの作成場所によってVPC間通信のlatencyが変わるか確認してみた

1. はじめに

IBM CloudのTransit GatewayはVPC間やClassic Infrastructureとの間の通信を可能としてくれる。しかし、このTransit Gatewayは、以下のように実際にはロケーションを意識して作成する必要があるようだ。

• VPC-A(Tokyo1)-VPC-B(Tokyo1)間を東京(Japan)に配置するTransit Gateway経由で通信するケース
• VPC-A(Tokyo1)-VPC-B(Tokyo1)間をダラス(U.S.)に配置するTransit Gateway経由で通信するケース

でlatencyの差が出るのかを確認してみた。

2. 検証結果

2-1. 東京(Japan)のTransit Gatewayを利用する場合

[root@syasuda5-vpc1 ~]# ping 172.16.0.4
PING 172.16.0.4 (172.16.0.4) 56(84) bytes of data.
64 bytes from 172.16.0.4: icmp_seq=1 ttl=59 time=0.711 ms
64 bytes from 172.16.0.4: icmp_seq=2 ttl=59 time=0.728 ms
64 bytes from 172.16.0.4: icmp_seq=3 ttl=59 time=0.689 ms
64 bytes from 172.16.0.4: icmp_seq=4 ttl=59 time=0.739 ms
64 bytes from 172.16.0.4: icmp_seq=5 ttl=59 time=0.614 ms
64 bytes from 172.16.0.4: icmp_seq=6 ttl=59 time=0.552 ms
64 bytes from 172.16.0.4: icmp_seq=7 ttl=59 time=0.674 ms
64 bytes from 172.16.0.4: icmp_seq=8 ttl=59 time=0.640 ms

2-2. ダラス(U.S)のTransit Gatewayを利用する場合

[root@syasuda5-vpc1 ~]# ping 172.16.0.4
PING 172.16.0.4 (172.16.0.4) 56(84) bytes of data.
64 bytes from 172.16.0.4: icmp_seq=1 ttl=43 time=275 ms
64 bytes from 172.16.0.4: icmp_seq=2 ttl=43 time=275 ms
64 bytes from 172.16.0.4: icmp_seq=3 ttl=43 time=275 ms
64 bytes from 172.16.0.4: icmp_seq=4 ttl=43 time=275 ms
64 bytes from 172.16.0.4: icmp_seq=5 ttl=43 time=275 ms
64 bytes from 172.16.0.4: icmp_seq=6 ttl=43 time=275 ms

まとめ

ダラスのTransit Gatewayを使った場合は、同じDC間の通信なのにRTTが275msecもかかっているため、やはりダラスまでの往復が発生していると思われる。
2020/08現在では、1つのVPCは1つのTransit Gatewayにしか接続できない。もちろん東京Region内のVPC間接続だったり、２拠点間のVPC接続であればそれほどTransit Gatewayの配置場所は悩まないだろうが、複数拠点間でのVPC接続の場合はどこにTransit Gatewayを作成するかは考えた方がいいかもしれない。