2016년 1월 7일, Amazon에서 AWS Seoul Region(서울 리젼) 설립을 발표하였습니다.




위의 발표공지를 보고나서, AWS Seoul Region의 Latency와 AWS Tokyo Region의 Latency를 측정해보았습니다.

측정은 Apache ab와 nginx를 이용하여 다음의 링크를 사용하여 측정했습니다.



AWS Tokyo Region 

 # ab -n 10 -c 1 http://**.**.**.**/index.html

This is ApacheBench, Version 2.3 <$Revision: 1706008 $>

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/


Benchmarking **.**.**.** (be patient).....done



Server Software:        nginx/1.9.9

Server Hostname:        **.**.**.**

Server Port:            80


Document Path:          /index.html

Document Length:        612 bytes


Concurrency Level:      1

Time taken for tests:   0.848 seconds

Complete requests:      10

Failed requests:        0

Total transferred:      8440 bytes

HTML transferred:       6120 bytes

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

Time per request:       84.805 [ms] (mean)

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

Transfer rate:          9.72 [Kbytes/sec] received


Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:       40   42   1.3     42      45

Processing:    41   43   1.2     43      45

Waiting:       41   42   1.2     42      45

Total:         82   85   1.8     84      88


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

  50%     84

  66%     85

  75%     85

  80%     87

  90%     88

  95%     88

  98%     88

  99%     88

 100%     88 (longest request)

AWS Seoul Region

 # ab -n 10 -c 1 http://**.**.**.**/index.html

This is ApacheBench, Version 2.3 <$Revision: 1706008 $>

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/


Benchmarking **.**.**.** (be patient).....done



Server Software:        nginx/1.9.9

Server Hostname:        **.**.**.**

Server Port:            80


Document Path:          /index.html

Document Length:        612 bytes


Concurrency Level:      1

Time taken for tests:   0.172 seconds

Complete requests:      10

Failed requests:        0

Total transferred:      8440 bytes

HTML transferred:       6120 bytes

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

Time per request:       17.201 [ms] (mean)

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

Transfer rate:          47.92 [Kbytes/sec] received


Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:        7    9   1.3      9      11

Processing:     6    8   2.2      8      14

Waiting:        6    8   2.2      8      14

Total:         14   17   2.4     17      22


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

  50%     17

  66%     18

  75%     18

  80%     19

  90%     22

  95%     22

  98%     22

  99%     22

 100%     22 (longest request)



AWS Tokyo Region Avg. Latency

 87.11111111(ms)

AWS Seoul Region Avg. Latency

 20.22222222(ms)


AWS Seoul Region 의 Latency와 AWS Tokyo Region의 Latency를 비교하니 AWS Seoul Region이 훨씬 빠르다는걸 체감하였습니다.

이후 다운로드 전송량 측정을 해보아도 AWs Seoul Region이 빠르다는 것도 확인하였습니다.


AWS Tokyo Transfer Rate

 9.72 [Kbytes/sec] 

AWS Seoul Transfer Rate

 47.92 [Kbytes/sec]


측정결과 AWS Tokyo와 AWS Seoul간의 엄청난 속도차이를 경험하였고, AWS Tokyo Region의 사용료보다 AWS Seoul Region의 사용료가 조금 더 저렴하다는 걸 보고 깜짝 놀랐습니다.


Tokyo 보다 접근 속도가 빠르면서, Tokyo보다 저렴한 Seoul을 사용해야겠다는 결론을 내렸습니다.


기존에 AWS Tokyo Region에서 생성한 인스턴스(Instance)를 AWS Seoul Region으로 옮기는 작업을 진행하였습니다.


AWS Tokyo Region(도쿄/東京 리젼)의 인스턴스를 AWS Seoul Region(서울 리젼)으로 옮기는 방법

이 방법은 

위의 링크를 참조하였습니다. 위의 링크에 있는대로 따라하니 문제 없이 Tokyo Region의 Instance가 그대로 Seoul Region의 Instance로 옮겨지고, 정상작동함을 확인함.


1. AWS Tokyo Region EC2 Instances 메뉴 

옮길려는 인스턴스의 속성 메뉴에서 Create image(EBS AMI)함.

2. AMIs 메뉴 - 새로 만든 AMI 이미지로 Launch Instance 하고 기존에 생성한 Instance와 같은 사양의 Instance를 만든다.

3. Instances 메뉴 - 새로운 Instance가 Running 되면 Instance의 속성 메뉴에서 Stop 한다.

4. Volumes 메뉴 - Instance에 연결된 볼륨의 속성 메뉴에서 Create Snapshot 한다.

5. Snapshots 메뉴 - 새로 만든 스냅샵의 속성 메뉴에서 Copy Snapshot 한다. 

6. 팝업창에서 Destination region 항목에 Seoul Region을 선택한다.


7. AWS Seoul Region EC2Snapshots 메뉴 - Tokyo Region 에서 복사 된 스냅샷의 속성 메뉴에서 Create Volume from Snapshot 한다.

8. Volumes 메뉴 - 스냅샷으로 만든 볼륨의 Volume ID를 확인 한다.

9. Instances 메뉴 - Tokyo Region Instance 와 같은 사양의 Instance를 Launch Instance로 생성하고 Instance가 Running 되면 속성 메뉴에서 Stop 한다.

10. Volumes 메뉴 - Instance에 연결(sda1)된 볼륨의 속성 메뉴에서 Detach Volume 하고 Instance에서 볼륨을 때어낸다. Tokyo Region의 스냅샷으로 만든 볼륨을 속성 메뉴에서 Attach Volume 한다. 

팝업창에서 Instance 항목에 해당 Instance를 선택하고, Device 항목에  "/dev/sda1"으로 수정한 다음 Yes, Attach 해서 볼륨을 붙인다.

12. Instance 메뉴 - Stop 되어 있는 Instance를 Start 한다. Instance가 Running 되면 접속해서 확인한다.


이제 AWS Seoul Region이 생겼으니 Seoul Region을 애용해야겠습니다 ~_~

Buy me a coffeeBuy me a coffee
이번에 이글루스 블로그(http://sungdh86.egloos.com)에서 티스토리로 넘어왔습니다.

tistory계정이 있었음에도 또 만들게 되었네요. 뭔가 새로 시작하고 싶은 욕망으로 닉네임도 Ego君에서 StudioEgo로 바꾸었습니다.
이글루스가 SK란 회사로 넘어간것에 실망하고, 이오공감서비스에 실망을 하고 등등의 일을 겪고, 거의 3년동안 이글루스 서비스를 써왔다만 이글루스 UI보다 티스토리의 UI와 서비스에 마음에 들어서 옮겼습니다.

블로그를 네이버→이글루스→티스토리로 옮기게 되군요.
제가 처음 블로그(Blog)란 말을 알게 되었던 때가 고등학교 3학년때 8월경(2004년 8월)이었습니다. 홍익대학교 수시 1학기 정보컴퓨터공학부에 붙어서 컴퓨터가 운명인가를 고민하다가 서점에서 김중태님의 저서인 "나는 블로그가 좋다"(revu에서의 소개, 강컴링크, Me2Day에서의 소개)란 책을 보고 나서 블로그라는 것을 만들고, 직접 웹호스팅회사에서 계정생성해서 직접 블로그 운영해보고(도메인은 제가 용돈 받은 시절이라 살려는 생각하지 않았음), 만 18세가 넘은 2004년 12월 15일날 이글루스 블로그를 써본 기억이 나네요.

티스토리블로그를 새로 만들면서 예전 생각이 새록새록났습니다. 고등학교 3학년때 쓰던 네이버, 고3말에 가입을 하고 싶어도 만 18세가 넘지 않아서 12월 15일날에서야 가입했던 이글루스나, 지금은 사라진 계정에서 쓰던 글들이 생각 나네요. 고3말에 할짓이 없어 블로그 만들면서 Linux를 처음 접하고 삽질했던 기억등등^^

이제 블로그를 만들면서 새로 시작을 해볼렵니다. 이글루스는 Me2day글들만 올릴 계획입니다.

ps. StudioEgo라는 닉네임이 파랜드택틱스를 만든 분이 세운 게임회사이름인 Studio e·go과 동일하네요. 예전에도 이 회사를 알긴 했어도 의도되지 않게 닉이 게임회사랑 중복이 되군요.
Buy me a coffeeBuy me a coffee
  1. Favicon of http://studioego.info/ BlogIcon StudioEgo 2009.01.03 16:38

    Test

+ Recent posts