현재 서비스 중에 있는 시스템중 전부, 또는 일부를 Amazon AWS(Amazon WebService) 환경으로 이전 할 수 있는지 가능성을 타진하기 위한 프로젝트의 일환으로, 표면적으로 가장 문제가 될것으로 보이는 네트워크 속도에 대한 테스트를 진행했다.
현재 Amazon AWS의 실제 서버가 위치한 곳은 북중미 3곳(Virginia, Oregon, California) 유럽 1곳(Ireland), 남미 1곳(Sao Paulo), 아시아 3곳(Singapore, Japan, Sydney), 총 8곳의 region이 있다.
사용자는 이 8곳 중에서 원하는 곳 어디서든 인스턴스(서버VM)를 생성할 수 있지만, 각 지역마다 네트워크 속도의 편차가 심하기 때문에 주력으로 서비스하고자 하는 곳에서 네트워크 속도가 가장 잘 나오는 곳을 선택해서 사용하는 것이 효율적이다.(region 마다 사용비용은 조금씩 차이가 있다.)
이번 테스트에서는 일본지역을 사용하였는데, 각 지역별로 ping test를 따로 진행한 결과, 일본 지역이 사용하기에 가장 무난한 곳으로 판단되었다.
1. Ping(Network Latency) test
Ping test를 통해 각 지역별 latency를 측정해 보았다.
테스트는 http://cloudping.info(Amazon region별 ping test site) 사이트를 이용해 진행했으며, Client의 회선 제공 업체에 따라 결과가 다를 수 있기 때문에 주위에 테스트 가능한 회선을 최대한 모아서 각각 테스트 해보았다.
KT (전용회선) | KT (LTE) | KT (3G) | SK(LTE) | SK(3G) | LG(전용회선) | |
US-East (Virginia) | 214 ms | 450 ms | 359 ms | 448 ms | 471 ms | 235 ms |
US-West (California) | 138 ms | 206 ms | 246 ms | 184 ms | 545 ms | 141 ms |
US-West (Oregon) | 154 ms | 189 ms | 244 ms | 211 ms | 369 ms | 172 ms |
Europe (Ireland) | 287 ms | 448 ms | 435 ms | 451 ms | 490 ms | 313 ms |
Asia Pacific (Singapore) | 214 ms | 449 ms | 305 ms | 449 ms | 472 ms | 235 ms |
Asia Pacific (Sydney) | 179 ms | 451 ms | 267 ms | 647 ms | 329 ms | 156 ms |
Asia Pacific (Japan) | 150 ms | 187 ms | 238 ms | 89 ms | 174 ms | 63 ms |
South America (Brazil) | 334 ms | 446 ms | 452 ms | 543 ms | 652 ms | 313 ms |
[표 1.1] Amazon region 별 latency test 결과 (주황색 셀은 1위 region)
위의 표를 보면 KT(전용회선)을 제외한 모든 곳에서 Japan지역이 가장 빠른 Latency를 보여주는 것으로 나타난다.
그리고 KT(전용회선)도 Japan 지역이 1위는 아니지만 1위 지역과 차이가 거의 나지 않으며, KT를 제외한 다른 지역은 1위와 2위의 차이가 제법 나는 것을 확인할 수 있다.
한국에서는 테스트를 한 시점(2013년 12월)에서 광범위한 인터넷 서비스를 위해서 Amazon을 사용해야 한다면, 전 세계 8곳의 region 중 Japan을 사용하는 것이 가장 안정적인 Network Latency를 보장 받을 수 있을 것으로 판단된다.
2. HTML page(정적 콘텐츠) loading test
HTML로만 이루어진 정적 페이지의 로딩 속도를 측정해 보았다.
Amazon region은 latency test 결과에 의해 Japan지역을 선택했으며, 비교를 위해 국내 Cloud 서비스중 KT uCloud와 IDC에 있는 실제 서버를 함께 테스트 해보았다.
테스트에 사용한 HTML page의 size는 약 142K 정도이며, KT 전용회선을 사용하고 있는 PC에서 각각 20번씩 페이지를 호출해서 나온 load time과 latency의 평균을 서로 비교하는 방식으로 진행했다.
[그림 2.1] HTML page loading test 결과 그래프
테스트 결과 KT 에서 운영중인 uCloud에 있는 html page를 로딩할 때 속도가 가장 빠른 것으로 나왔다.
실제 IDC(KT영동) 보다 속도가 더 빠른것으로 나온것이 의아하긴 했지만, uCloud 테스트가 목적이 아니기 때문에 일단 패스하고, Amazon과 IDC(실 서비스 환경)의 load time을 비교해 보았다.
두 환경의 load time이 약 120ms 정도 차이가 나는데, 인터넷 전용선을 사용하는 PC에서는 채감상으로는 그렇게 크게 느껴지지 않았으나, 3G 환경에서는 속도의 저하를 확실히 채감할 수 있었다.
속도라는 것이 개인마다 느끼는 편차가 다르기 때문에 단정적으로 결론을 내리기는 애매하지만, 개인적으로는 쓸만한 정도, 다시 말해 빠르지는 않지만 스트래스를 받을 만큼 느리지도 않는 수준인 것 같다.
3. 외부(국내 IDC) 리소스를 경유할 경우에 대한 test
일부 리소스(예를 들어 DB 서버)를 국내 IDC에 두고 메인 시스템을 Amazon에 구축했을 경우, 페이지 로딩 속도가 얼마나 떨어지는지 확인을 위해 관련 테스트를 진행했다.
테스트는 국내IDC의 웹페이지를 읽어들인 다음, 그 내용을 그대로 재출력하는 페이지를 만들고, 정적 페이지 테스트처럼 각각 20번씩 페이지를 호출해서 나온 load time과 latency의 평균값을 비교하는 방식으로 진행했다.
[그림 3.1] 외부(국내 IDC) 리소스를 경유할 경우에 대한 test 결과
그래프를 보면 속도 차이가 확연한 것을 확인할 수 있다.
Amazon을 제외한 uCloud나 IDC의 경우는 직접 호출하는 것과 차이가 거의 나지 않는 것을 볼 수 있다. 즉 다시 말하자면, 외부 리소스에 접근해서 정보를 가져오는데 소모되는 latency가 아주 미미한 수준으로 볼 수 있는데, Amazon의 경우에는 약 2이상 속도 차이가 나는 것을 볼 수 있다.
결국, 국내 IDC에 DB서버를 두고 웹서버는 Amazon에 구축하는 방식의 시스템 구성은 현재로써는 힘들것으로 보인다.
다만 Amazon과 특정 지역의 네트워크를 직접 연결해서 네트워크 속도 및 latency를 줄일 수 있는 서비스 (AWS Direct Connect)가 있는 것 같은데, 이 서비스를 이용하면 되지 않을까 생각되지만, 서비스 이용료로 싸지 않은 듯 하고, 활용 가능성에 대해서는 좀 더 구체적인 리서치가 필요 할 듯 하다.
4. 결론
현재까지 총 3가지의 테스트에 대한 결과를 정리하고 결론으로 마무리 하고자 한다.
첫번째, Ping test에서는 북미나 동남아 서비스를 염두해 둔다면, 테스트를 다시 진행해 봐야 하겠지만, 현재 한국에서는 Japan 지역이 Amazon region중에는 가장 안정적인 네트워크 성능을 보장해주는 것으로 나타났다.
두번째, 정적 페이지 로딩 테스트는 일반적인 서비스 네트워크 품질을 가늠해보기 위한 테스트로 Amazon에서 시스템을 구축했을 때 네트워크 속도 측면에서 국내보다는 확실히 느려지는 것을 확인했지만, 서비스가 불가능한 수준은 아닌것으로 보였다.
세번째, 일부 리소스를 국내에 두었을때 속도 저하 추이를 보기 위한 테스트에서는 Amazon에서 추가적인 서비스(유료)를 받지 않는 이상, 서비스가 불가능한 수준으로 속도가 저하되는 것을 확인 할 수 있었다.
국내에서 Amazon을 사용할 경우에는 region은 Japan으로 하는 것이 좋고, 모든 데이터 리소스를 Amazon에 함께 구축해 두는 것이 서비스 품질에 좋을 것으로 보인다.
'Misc.' 카테고리의 다른 글
| D3js로 구현할 수 있는 다양한 차트와 예제 (0) | 2015.03.30 |
|---|---|
| [Tip] 우분투(Ubuntu) 12.04에서 구글 크롬(Google Chrome) 35 nabi 한글 입력 문제 해결 (0) | 2014.06.10 |
| OOD에서 SOLID Principle... (0) | 2014.03.24 |
| 아마존 웹서비스(AWS)에서 제공하고 있는 서비스 종류 (0) | 2013.11.27 |
| Easiest Remote Monitoring with Java-VisualVM (using JMX) (0) | 2013.10.02 |
