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간 접속이거나, 2거점간의 VPC 접속이면 그다지 Transit Gateway의 배치 장소는 괴롭지 않을 것이다. 는 생각하는 것이 좋을지도 모른다.