현재 서비스 중에 있는 시스템중 전부, 또는 일부를 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에 함께 구축해 두는 것이 서비스 품질에 좋을 것으로 보인다.



Posted by 얌노트

얼마전에 아마존에 테스트 서버팜을 구성해야 될 일이 있어 아마존 서비스를 훓어보다 생각보다 광범위하고 꼼꼼한 서비스 종류에 놀란적이 있다.

그래서 현재 아마존 웹서비스(AWS: Amazon WebServices)에서 제공하고 있는 서비스들에 대해서 간단하게 정리해 보았다.


1. Compute
 
- EC2 (Elastic Compute Cloud)
클라우드 환경에서 서버를 할당 받아 사용할 수 있는 서비스, 서버 호스팅과 비슷한 개념이지만, 실제 물리적인 서버를 할당 받는 것이 아니라 클라우드 환경에서 가상 서버를 할당 받는 것이 다른 점.
 
- Auto Scaling
수요에 따라 EC2의 규모를 자동으로 조절 할 수 있는 서비스. 
예를 들어 web server의 cpu load가 50%가 넘어가면 새로운 web server를 추가하도록 세팅이 가능하다.
 
 
2. Networking
 
- DirectConnect
AWS와 직접 연결된 전용 네트워크 서비스 (AWS 네트워크와 직접 연결을 해주는 네트워크 사업자가 따로 있는듯)
 
- Route 53
DNS 서비스
 
- VPC (Virtual Private Cloud)
사설 네트워크 서비스
 
- Elastic Load Balancing
Load Balancing 서비스
 
 
3. Storage & Content Delivery
 
- Glacier
저비용 데이터 보관 및 백업 서비스. 자주 사용되지 않는 데이터를 보관 및 백업하는데 유용한 서비스 
 
- S3 (Simple Storage Service)
인터넷 스토리지 서비스. 웹에서 바로 접근 할 수도 있고, EC2에서 mount해서 사용할 수도 있다.
 
- EBS (Elastic Block Storage)
EC2 인스턴스에서 사용할 수 있는 블럭 레벨 스토리지. 용량, IOPS 설정등이 가능하다. 
* S3는 네트워크 스토리지, EBS는 서버에 추가할 수 있는 하드웨어 스토리지(SATA 하드 같은)로 이해하면 될듯.  
 
- CloudFront
콘텐츠 전송용 웹서비스. CDN과 비슷한 서비스로, 
EC2나 S3같은 서비스에서 사용시 가장 가까운 엣지로 자동 라우팅되서 콘텐츠 전송 속도를 향상할 수 있다.   
 
- Storage Gateway
aws의 스토리지와 로컬 스토리지를 연동해주는 서비스. 로컬에 있는 DAS, NAS, SAN 과 같은 장비와 S3를 연동해서 메인 데이터는 S3에 두고 접근빈도가 높은 데이터는 로컬 스토리지에 케싱하거나, 모든 데이터는 로컬 스토리지에 두고 일정 시간에 따라 주시적으로 데이터의 스냅샷을 S3에 저장하는 등의 서비스를 구축할 수 있다.
 
- Import / Export
대용량 데이터를 이동식 디바이스에 직접 import / export 해 주는 서비스. 외장 하드같은 디바이스를 Amazon에 우편으로 보낸 다음, 데이터를 Import 또는 Export 후 다시 돌려받는 방식. 
 
 
3. Database (BigData)
 
- RDS (Relational Database Service)
RDBMS 클라우드 서비스. MySQL, PostgreSQL, Oracle, SQL Server 지원. 
* EC2에 새로 Instance를 생성하고 직접 설치해서 사용할 수도 있지만 RDS를 사용할 경우 유지 보수 이슈를 획기적으로 줄일수 있다.(Amazon이 관리해주니까....) 하지만 서버에 직접 접근 권한이 없기 때문에 사용에 제한이 많기 때문에 서비스 종류나 기타 기업의 특성등을 잘 고려해서 선택해야 될 듯 하다. 
 
- DynamoDB
아마존에서 서비스하는 NoSQL 데이터 베이스 
 
-SDB (Simple Database )
비정규방식의 DB 서비스(??)
 
- Elastic Cache
Caching 서비스. Memcached, Redis 지원. 
 
- Redshift *Beta
빅데이터 분석 서비스 인듯. 
 
- EMR (Elastic MapReduce)
AWS상에서 서비스되고 있는 Hadoop 프레임워크 위에서 사용할 수 있는 MapReduce 서비스. 데이터의 종류나 양에 따라 Mapreduce에 필요한 리소스의 가변폭이 큰 경우 아주 유용할 듯.
하지만 사용하기 위해서는 반드시 Hadoop도 AWS상에 구축되어야 한다.
 
- Data Pipeline
서버 또는 스토리지간 주기적인 데이터 이동을 지원하는 서비스.
 
** MySQL, PostgreSQL, Oracle, SQL Server, Redis, Memcached를 제외한 다른 어플리케이션들은 직접 설치하거나 EC2에 새로운 인스턴스를 생성할때 Amazon Marketplace에서 패키징된 OS를 선택해야 함.
 
  
4. Deploy & Management
 
- CloudFormation:
클라우드 서비스를 생성 관리 할 수 있는 서비스. 
예를 들어 LAMP Formation 을 선택하고 생성하면 Linux + Apache + MySQL + PHP 환경에 맞는 클라우드 컴퓨팅 환경을 한번에 생성 할 수 있다.
 
- CloudWatch
클라우드 리소스 및 어플리케이션 모니터링 서비스 
 
- Elastic Beanstalk *Beta
웹 어플리케이션(php, Node.js, Python, Ruby, .Net등등)을 aws에 쉽게 배포할 수 있도록 도와주는 웹서비스
 
- OpsWorks
웹 어플리케이션을 Stack 구조 베이스로 생성 관리 할 수 있고, 어플리케이션을 배포할 수 있는 배포툴 서비스.
예를 들어, 웹서비스 Layer(PHP), HA Proxy Layer, DB Layer(MySQL) 등으로 Layer를 정의한 다음. 각 Layer에 서버를 몇대씩 할당할지 정할 수 있다.
OpsWorks를 사용하면 하나의 인스턴스를 셋팅하는데 들이는 노력으로 1,000대의 EC2 인스턴스에 한번에 어플리케이션 배포가 가능하다. 
 
- SWF (Simple Workflow Service) *Beta
서버단위의 Workflow를 설정 관리 할 수 있는 서비스(??)  
 
 
5. App Services
 
- CloudSearch *Beta
아마존의 서치엔진 서비스.
 
- Elastic Transcoder *Beta
동영상 트랜스코딩 서비스
 
- SES (Simple Email Server)
Email 서비스
 
- SNS (Simple Notification Service)
푸시 메세징 서비스
 
- SQS (Simple Queue Service)
메세지 큐 서비스 
 
 
6. 기타
 
- Mechanical Turk *Beta
무서운 서비스. 인간 지능(물리적인 지적 노동력) 사고 팔기 위한 마켓플레이스. 
쉽게 말해서 인력이 필요한 작업이 있을 경우(예를 들어 비디오 판독, 자막 제작 등등) 그에 대한 결과물의 형태, 보수, 자격 조건 등을 입력 후 마켓플레이스에 등록.
등록자가 제시한 자격 요건 테스트를 통과한 지원자들이 그 일을 해주고 보수를 받는 서비스 ..... 아마존이 노가다 인력 시장까지 진출하려고 한다. (투잡족에게는 좋은 알바소개소?)
 
- CloudHSM (Cloud Hardware Security Module)
보안키 보관 서비스 (??)
 
- Support
아마존의 기술 지원 서비스. 지원 범위가 커질 수록 가격도 올라간다.
 
- Product Advertising API
아마존 배너광고 관련 API


Posted by 얌노트