페이스북 AKUG에서 다음과 같은 포스팅을 봤다.
처음엔 아무생각이 없었으나 급 아이디어가 떠올랐다.
EC2 엔드포인트를 지원하면 리전간의 레이턴시를 줄일수 있지 않을까? 그러니까..궁금증은 오픈카톡에서 시작된거였다.
한국과 도쿄리전 간의 레이턴시를 20ms 로 줄일수 있는지가 관건이었다.
AWS Global Accelerator는 TCP/UDP를 지원한다. 그렇다면 OPENVPN을 TCP로 셋팅해서 인스턴스의 앞단에 AWS Global Accelerator 둔다면 과연 빨라질까?
그런 궁금증이었다.
엣지로케이션을 이용하여 라우팅 최적화라고 생각하면 가장 간단하다.
테스트 방식은 총4가지였다
openvpn-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping
openvpn-가속기-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping
openvpn-한국리전(인스턴스)-vpc 피어링-도쿄리전- 프라이빗 IP 22 port tcping
openvpn-가속기- 한국리전(인스턴스)-vpc 피어링-도쿄리전- 프라이빗 IP 22 port tcping
AWS Global Accelerator 셋팅은 아주 간단하다.
Accelerator 를 생성하고 Listeners ID 를 생성할떄 region 을 지정하고 Endpoint groups 을 인스턴스 ID로 설정하면 status 를 업데이트 한다. ALL healthy 로 보이면 정상적으로 연결된것이다.
생성된 Accelerator 은 총3개의 endpoint 를 가진다. IP 두개와 DNS 하나이다.
그럼 테스트로 넘어간다.
가속기를 쓰지않고 도쿄리전의 인스턴스에 openvpn 으로 연결하여 프라이빗 IP로 22번 포트로 tcping 을 테스트 하였다. 총 100회의 tcping 의 time 을 확인할 계획이다.
172.31.26.253에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 34ms, 최대 = 35ms, 평균 = 34ms
C:>tcping.exe -n 100 172.31.26.253 22
Ping statistics for 172.31.26.253:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 43.180ms, Maximum = 81.995ms, Average = 64.100ms
가속기를 사용하지 않은 값으로 icmp 34ms / tcping 64ms 가 나온다.
172.31.26.253에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 34ms, 최대 = 35ms, 평균 = 34ms
Ping statistics for 172.31.26.253:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 43.065ms, Maximum = 78.722ms, Average = 61.323ms
평균 icmp 34ms / tcping 61ms 정도 확인할수 있었다.
tcping은 속도가 늘어지는 감이 있어서 ping 까지 체크해 보았다.
ping 로는 유효한 내용을 확인할수 없었다. openvpn 으로 접속하여 1194포트로 ping 를 확인하므로 실제 전송은 tcp로 이루어진다.
구성에 대해서 간략하게 설명하고 다음테스트를 진행하려고한다.
피어링은 신청하고 수락하는 단계를 거쳐서 허용된다.
피어링으로 끝이 아니라 두개의 VPC에서 라우팅을 설정해줘야 한다.
현재 서울 172.29.0.0/24 -> pcx 도쿄 172.31.0.0/20 -> pcx 로 라우팅 테이블을 설정 하였다. 테스트는 인스턴스 내부에서 ping 으로 확인하면된다.
사실 이때쯤 테스트가 잘못된것을 알았다.
--- 172.29.0.110 ping statistics ---
22 packets transmitted, 22 received, 0% packet loss, time 21036ms
rtt min/avg/max/mdev = 33.540/33.606/33.679/0.244 ms
vpc 피어링으로 묶은 속도의 평균이 33.5ms 였다.
망내 속도는 두 리전간의 피어링이 제일 빠를거라 생각했기 때문이다.
그래도 포기하지 않고 유효한 데이터를 쌓기위해 테스트를 진행했다.
이즈음 site to site vpn 셋팅이 가물가물 기억이 안나서 좀 이것저것 봤다.
다음 테스트구성은 서울리전 인스턴스에 openvpn으로 연결하고 vpc peering 으로 도쿄 리전과 연결한다. 그리고 ping / tcping 22 번 테스트를 한다.
172.29.0.110에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 39ms, 최대 = 40ms, 평균 = 39ms
Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 45.206ms, Maximum = 79.891ms, Average = 60.589ms
Accelerator 를 사용하지 않은 결과로 icmp 39 / tcping 22 60ms 이다.
ICMP는 늘어지는데 TCP는 빨라지는 결과가 나왔다. 뭐지..
그래서 한번더 했다.
Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 46.106ms, Maximum = 85.099ms, Average = 64.571ms
늘어지네... 39/ 60 / 64
172.29.0.110에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 40ms, 최대 = 41ms, 평균 = 40ms
Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 46.406ms, Maximum = 78.911ms, Average = 65.489ms
Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 45.652ms, Maximum = 81.980ms, Average = 66.764ms
40 / 65 /66 시간이 지날수록 속도가 느려졌다. 왜지? Accelerator 가 가까운 거리에선 라우팅을 한번 더 들어가게 되는건 아닐까 하는 생각이 들었다.
실제론 엣지를 타게되지만 전송거리가 더 먼건 아닐까...
그런 생각이 들어서 결국 오레곤 리전에 셋팅을 했다. 이젠 근성이다.
10.0.0.227에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 136ms, 최대 = 193ms, 평균 = 141ms
Ping statistics for 10.0.0.227:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 145.219ms, Maximum = 283.356ms, Average = 168.073ms
141 / 168 역시 오레곤은 멀다. 그럼 Accelerator 를 사용해 본다.
10.0.0.227에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 126ms, 최대 = 127ms, 평균 = 126ms
Ping statistics for 10.0.0.227:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 132.458ms, Maximum = 224.706ms, Average = 154.244ms
126 / 154 드디어 Accelerator 를 사용했을때 유효한 결과가 보인다.
한국에서 거리가 먼~오레곤 정도 되어야..속도가 오르는게 확인이 된다.
물론 라우팅이 꼬일대로 꼬인 지역에선 Accelerator가 매우큰 도움이 될것이다.
하지만..여기서 끝내기엔 너무 아쉬웠다. 하.
또 한국리전에 최근에 적용된 기능이 생각났다.
이 테스트는 다음을 기약해야 할것같다..
ㅜㅜ실패의 충격이 크다.
하지만 얻게된 aws의 내부 망에 대한 추측이다.
서울 리전과 도쿄리전은 라우팅이 복잡해서 지연이 있는게 아니라 실제 회선이 지연이 있어서 발생하는 레이턴시다. 그래서 이 레이턴시를 줄이기 위해선 라우팅 최적화나 다른 시도가 필요한게 아니라 회선의 질적인 상향이 필요하다는게 내 결론이다.
오늘의 우승 구성은 " openvpn-가속기-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping " 이다.
오늘은 도쿄에 테스트 했으니까 사요나라!
