블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

구글의 파이버 백본과, 글로벌 프록시 노드를 이용한 네트워크 시간 단축하기 실제 테스트 결과


앞의 글 http://bcho.tistory.com/1109 에서 언급한 바와 같이, 직접 서버를 호출 하는 것보다 구글의 클라우드 로드밸런서를 사용하게 되면, 트래픽을 가장 가까운 target proxy 서버를 통해서 그 뒤의 구글 광케이블망을 통해서 전송 받기 때문에 속도가 빠르다고 했습니다. 실제로 빠른지 간단한 테스트를 해봤습니다.


서버를 미국 중부 지역에 배포한후, 첫번째는 그 서버 IP로 직접 부하를 줘보고, 두번째는 그 서버 앞에 구글 클라우드 로드밸런서를 넣은 후, 로드밸런서를 통해서 호출하게 하였습니다.

Node.js 서버로 간단하게 서버의 네트워크 정보를 출력하는 프로그램을 만들어서 호출하였습니다. 다음과 같은 응답값이 나오고 응답값의 총 크기는 514 byte 입니다.



첫번째 시나리오는 서버로 직접 호출한 경우입니다.

서버의 IP는 104.197.165.74를 사용했습니다.


Apache ab 벤치마크 툴을 사용해서 20개의 쓰레드로 3000번 호출을 하였습니다.

결과는 다음과 같습니다.

Server Software:        

Server Hostname:        104.197.164.74

Server Port:            80


Document Path:          /

Document Length:        514 bytes


Concurrency Level:      20

Time taken for tests:   58.945 seconds

Complete requests:      3000

Failed requests:        0

Total transferred:      2154000 bytes

HTML transferred:       1542000 bytes

Requests per second:    50.89 [#/sec] (mean)

Time per request:       392.968 [ms] (mean)

Time per request:       19.648 [ms] (mean, across all concurrent requests)

Transfer rate:          35.69 [Kbytes/sec] received


Connection Times (ms)

             min  mean[+/-sd] median   max

Connect:      191  195   4.0    193     219

Processing:   192  196   4.1    194     223

Waiting:      192  196   4.1    194     223

Total:        383  392   8.0    387     427


Percentage of the requests served within a certain time (ms)

 50%    387

 66%    393

 75%    402

 80%    402

 90%    403

 95%    404

 98%    405

 99%    407

100%    427 (longest request)


전체 수행 시간이 58.945초가 소요되었습니다. 평균 처리 시간이 392ms가 나오는데, 그중에서 connection을 하는 시간이 195 ms가 나옵니다.


이번에는 로드밸런서를 통해서 구글 백본망을 통해 트래픽을 들어오게 테스트 하였습니다.


Target proxy는 전세계에 걸쳐서 배포되어 있고 Any IP 라우팅 로직에 따라서 가장 가까운 곳을 찾아서 라우팅이 됩니다. 로드밸런서는 IP는 위의 그림과 같이 130.211.11.38 을 사용했습니다.


테스트 조건은 동일하고 결과는 다음과 같습니다.

Server Software:        

Server Hostname:        130.211.11.38

Server Port:            80


Document Path:          /

Document Length:        514 bytes


Concurrency Level:      20

Time taken for tests:   47.295 seconds

Complete requests:      3000

Failed requests:        0

Total transferred:      2148000 bytes

HTML transferred:       1542000 bytes

Requests per second:    63.43 [#/sec] (mean)

Time per request:       315.298 [ms] (mean)

Time per request:       15.765 [ms] (mean, across all concurrent requests)

Transfer rate:          44.35 [Kbytes/sec] received


Connection Times (ms)

             min  mean[+/-sd] median   max

Connect:       36   41   1.7     41      56

Processing:   192  273  78.3    211     587

Waiting:      192  273  78.3    210     586

Total:        229  314  78.3    252     623


Percentage of the requests served within a certain time (ms)

 50%    252

 66%    387

 75%    389

 80%    395

 90%    404

 95%    407

 98%    420

 99%    422

100%    623 (longest request)

terrycho-macbookpro:~ terrycho$


전체 소요 시간은 47.295초, 호출당 평균 소요 시간은 314ms, Connection 시간이 많이 짧습니다. 평균 41ms 입니다.



직접 호출한경우

로드밸런서(구글백본)통해 호출한 경우

총 소요시간

58.945초 (124%)

47.295초

호출당 평균 소요시간

392ms (124%)

314ms

Connection 시간

195ms  (470%)

41ms


서버에서 처리시간은 동일하기 때문에, 연결 시간이 중요한데, 위에서 볼 수 있듯이 연결 시간은 대략 4~5배 정도 차이가 나는 것을 볼 수 있습니다.


한국 → 미국 구간 시간이지만, 글로벌 서비스를 한다고 생각할때, 이정도 시간을 줄일 수 있는 것은 애플리케이션 응답시간에 꽤나 많은 영향을 주지 않을까 싶습니다. 대략 호출 평균 시간이 80ms 정도 차이가 나는데, 애플리케이션에서는 꽤나 긴 시간으로 생각할 수 있습니다.


패킷 사이즈가 작고, 시간대역에 따라서 네트워크 상황이 달라서 정확한 결과를 얻기는 어렵습니다만 확실히 광케이블 네트웍을 통해서 성능 향상은 있고, 트래픽이 커지면 더 성능차이가 날거라고 보입니다. 

기회가 되면 파일 전송과 같은 다른 시나리오로 한번 테스트 해보도록 하지요.

구글의 파이버 백본과, 글로벌 프록시 노드를 이용한 네트워크 시간 단축하기


조대협 (http://bcho.tistory.com)


구글의 클라우드 기능을 공부하던 중에 대단히 멋진 기능이 있어서 소개하고자 한다.

구글은 전세계적으로 많은 네트워크 망을 가진것으로 유명하고 특히나 구글의 데이타 센터들은 광케이블 기반의 백본 네트워크로 묶여 있다.


일반적인 글로벌 서비스에서 클라이언트가 서버를 호출하게 되면 다음 그림 처럼 일반 인터넷 망을 통해서 서버를 호출하게 되기 때문에, 글로벌로 배포되어 있는 서비스의 경우 거리에 따라 속도가 느리다.




구글은 데이타 센터이외에 여러개의 거점에 Target Proxy라는 서버 (일종의 중계 서버를) 배치 해놨고, 이 Target Proxy에서 각 데이타 센터까지는 광케이블로 연결이 되어 있다.

구글 클라우드의 글로벌 로드 밸런서를 사용하면 global IP  라는 것을 사용할 수 있는데, 이 global IP는 Anycast 기반의 IP로, 클라이언트가 이 IP로 접근을 하면, 이 IP와 가장 가까운 Target Proxy 서버로 프로토콜을 라우팅 해준다. 그후에, Target Proxy에서 부터 데이타 센터까지는 광케이블 네트웍을 타기 때문에, 일반 인터넷망으로 접근하는 것에 비해서 매우 빠른 응답 속도를 보장할 수 있다.

(참고 Anycast IP에 대한 설명 http://totaluptime.com/what-is-ip-anycast-and-how-does-it-work-in-the-cloud/)



CDN 처럼 정적 컨텐츠를 서비스 하는 것 뿐만 아니라 일반적인 웹 호출이나 REST API도 이 구조를 사용할 수 있기 때문에 글로벌 서비스를 할 경우 일반적인 인터넷 망을 사용하는 것에 비해서 빠른 속도를 보장 받을 수 있다.

애플리케이션의 로직을 변경하거나, DNS Round Robin 등을 사용할 필요 없이 로드밸런서만 설정하기 때문에 매우 쉽게 적용이 가능하다.


상세 내용과 사용 방법에 대해서는 https://cloud.google.com/compute/docs/load-balancing/http/#overview

를 참고하기 바란다.


실제 테스트 결과 http://bcho.tistory.com/1110