[발 번역] Amazon EC2 – 데이터 센터에서 클라우드로 이동한 실제 사례

해당 내용은 http://gregsramblings.com/2012/05/02/amazon-ec2-a-real-world-case-study-of-moving-from-data-center-to-the-cloud-chessjam/ 라는 글을 발 번역한 것입니다. 오역에 주의하시길 바랍니다.

역자 주: 해당 케이스는 엄청나게 많은 서버가 이전한 케이스는 아니고 간단하게 한두대 수준에서 왜 클라우드로 이동했는가에 대한 글입니다.  amazon ec2에 관심있는 분들이 보시면 좋을듯 합니다. 그리고 아마존에서 AWS에 대한 한국어 페이지가 생겼습니다. 이제 영어일 때 보다 훨씬 쉽게 접근할 수 있을듯 합니다.

2년전에, 저는 ChessJam 에 대해서 블로깅을 했습니다. ChessJam은  세계의 떨어져있는 사람들이 함께 체스를 라이브로 즐길 수 있는 체스 프로그램입니다. ChessJam을 출시한 이후로,  매일 24시간 동안 잘 운영되었고, 아주 적은 다운타임을 가지며, 잘 성장해왔습니다.

현재의 ChessJam의 수치에 대해서 언급을 하자면,

  • 낮밤, 언제라도, 평균적으로 100여명의 유저가 체스를 두고 있으며,  주말에는 180명 정도의 동시 접속자를 볼 수 있습니다.
  • 우리의 평균 로드는 초당 2~3번의 체스말의 이동이 있습니다.
  • 2012년 3월 동안에 4,500 명 이상의 유저가 128,920 게임을 즐겼습니다.( 한달에 580만 건의 체스 말의 이동이 있었습니다.)

마케팅 없이 한것 치고는 나쁘지 않다고 생각합니다. 다른 많은 어플리케이션과 비교하면 엄청 큰 부하를 요구 받지는 않지만, 성능 요구 사항은 꽤 높습니다. 몇몇 민감한 체스 플레이어들은 적절한 응답시간 이상은 기다리지 않습니다. 그래서 우리는 좋은 CPU와 대역폭을 여분으로 가지고 있어야 합니다.

호스팅 히스토리:

2009 말/2010 초 — 초기 개발 – 서버는 집에서 돌림

개발 초반 몇달 동안은 ChessJam은 집 컴퓨터에서 운영했습니다. 가격은 고정 IP와 FiOS를 쓰고 전기세를 포함해서 한달에 $70 이었고, 이것은 플로리다의 여름 폭풍으로 인해서 파워를 두배로 사용하기 전까지는 꽤 괜찮았습니다. 이 때, 나는 실제 데이터 센터와 개인 데이터 센터의 차이점에 대해서 깨닫게 되었습니다.  또 내가  없느 사이에 아내가 늦은 밤 서버의 복구 담당이어야 해서 꽤 신경쓰였습니다.

2010 말 — rack mounted servers 를 진짜 데이터 센터로 옮기다.

우리는 두대의 중고 rack-mounted IBM 서버를 구입했고,  데이터 센터에 랙용 공간을 임대했습니다. 신뢰할 만한 파워와 인터넷은 더 이상 문제가 없었습니다.  그러나 하드웨어는 종종 수리를 해야 했습니다. 전보다 좋아지긴 했지만, 그래도 좋은 상황은 아니었습니다. 데이터 센터로 옮긴 후 비용은 한달에 $190 불 근처였습니다.( 랙 공간을 임대하는 것과 밴드위스 비용)

왜 데이터 센터 대신에 아마존 EC2 로 옮기기 않았을까요? 처음에, 데이터 센터 대신에 아마존 EC2 를 고려했습니다. 그러나, 그때는 아마존은 우리가 고려할 만한 장비 사양이 없었습니다.  small instance 가 매력적이었지만, 겨우 1.7GB 의 메모리만 제공되어서 우리의 서버를 운영할 수 없었습니다.(시도는 해봤지만)  두번째는 메모리를 7.5GB를  large instance 였는데, 너무 비쌌습니다.

2달전에, 아마존은 small instance 와 large instance type 사이의 큰 갭을 채웠습니다. “medium” instance type을 제공하기 시작한 것이죠. 그것은 3.75GB 메모리를 제공하고 적당한 가격에 적당한 CPU를 제공했습니다. 그래서 우리는 그것으로 옮길 시점이라고 결정했습니다.

우리의 EC2 설정:

  • Ubuntu Linux에서 동작하는 중간 크기의 EBS 사용.  EBS는 “Elastic Block Store”의 약어로 persistent한 저장소입니다. EC2를 한번도 본적이 없다면, EBS 저장소가 서버에서 사용하는 Persistent 저장소라는 것을 모를겁니다. 서버를 shutdown 할 때, 서버의 모든 데이터를 저장할 수 있습니다.( 실제 물리 서버 처럼 말입니다.
  • 200GB EBS 디스크 사이즈 – Mysql 데이터 베이스와 증가하는 로그 저장을 위해서 사용.

AWS 와 돈에 대한 걱정

대부분의 사람들이 아마존 EC2를 사요할 때 같은 질문을 하는데, 나도 마찬가지였다. “이게 실제로 비용이 얼마나 드나요?” EC2가 가격을 어떻게 결정하는지 깊게 들여다보면, 불확실성을 만들어내는 다양한 변수들을 보게 될것입니다. 기본적으로 instance type에 따른 비용, EBS 사용에 대한 비용, instance 에서 데이터가 외부로 나갈때 드는 비용. 또 추가로 I/O와 사용하지 않는 IP addresses 도 조금 돈이 들어가지만, 이 비용은 매우 작아서 계산서에 큰 영향을 주지않습니다.( 내 경혐에 기초한 것입니다.)

  • The server instance — 이것은 예측하기 쉽고 간단합니다. 아마존은 시간당 과금을 합니다. 예를 들면, 우리가 사용하는 medium instance는 한시간에 $0.16불입니다. 만약 medium instance를 한대 빌려서 8시간 동안 사용한다면 $1.30 만 내면 됩니다. 나쁘지 않습니다. 우리의 앱은 매일 24시간 동작하는데, 이러면 24 시간 * 30 일 해서 한달에 720시간 동안 동작합니다.  이것을 계산하면 $0.16 * 720 = 한달에 $115가 나옵니다.( 이 글의 말미에, reserved instance 가 어떻게 동작하고 , 거의 절반정도 할인이 된다는 것을 설명할 것입니다.)( 역자 주: 아마존 EC2의 Reserved Instance는 말 그대로 장기 임대입니다. 즉, 이렇게 장기 임대해두면, 매달 이용하는 것보다 싸게 파는 것이죠. CPU 사용률에 따라서, Lite, Medium, Heavy 의 세 가지 타입이 있고, Heavy 가 Lite 에 비해서 4배 정도 비쌉니다.)
  • Disk volume – 이것 역시 예측하기 쉽습니다. 한달에 1GB당 $0.10 씩 지불합니다. 200GB 를 사용하므로 200*$0.10 해서 한달에 $20씩 지불합니다.(역자 주:  중요한 시스템의 경우 madam 을 이용해서 Software 적으로 RAID10을 구성하는데 이러면 디스크가 4개가 필요하니 1TB로 * 4를 하면 한달에 장비 하나당 $400 달러가 더 나가게 됩니다.)
  • Disk I/Os — EC2 가격 페이지를 보면 백만 I/O 당 $0.10 로 책정되어 있습니다. 우리는 하루에 300,000 I/Os 가 있고(마지막 청구서를 기준으로) 한달에 9백만 I/Os 가 발생합니다. 그 결과로 한달에 $1 보다 적게 청구되고 있습니다. 아무래도 반올림 오류에 대해서 전화해야 할 듯 합니다.( 역자 주: 아무래도 관련 요금이 1$가 나왔나보네요. ㅎㅎㅎ).
  • Data transfer charges — 우리가 걱정하는 부분이 이부분입니다. 아마존에서는 EC2 instance 외부로 나가는 데이터 1GB당 $0.12 를 과금합니다. 들어오는 트래픽에 대해서는 과금하지 않습니다.  데이터에 대한 과금 방식이 데이터 센터에서 과금하는 방법과 많이 틀렸습니다. 데이터 센터에서는 “피크치의 95%를 기준으로 과금” 하는 방식을 취했고, 이는 전체 사용한 트래픽에 대한 과금이 아니라,  평균에 기초해서 과금을 했습니다. 세부 사항에 대해서는 좀 더 자세히 알아두시길 바랍니다. 아마존 모델은 이런 방식이 아닙니다. 데이터 센터에서는 매 달의 트래픽에 대한 보고서를 제공해주었고 우리는 그것으로 평가를 했습니다. 지금, 몇일 정도 서버를 돌리고 있는데, 매 시간당 250MB, 하루에 6GB 정도의 트래픽이 발생하고 있습니다. 그래서 6GB * 30 * $0.12 해서 한달에 $21 정도 과금이 되고 있습니다.

요약:  우리의 서버 장비에 한달에 $115.20, 디스크 볼륨에 한달에 $20, 네트웍 비용에  $21/month, 다 합쳐서 한달에 $156.20 과금되고 있습니다. 이것은 데이터 센터에서 우리가 지불하던 비용보다 $30 달러 정도 싼 비용입니다. 이것은 이미 이전보다 싸지만, 우리가 Reserved Instance를 사용하면 우리는 좀 더 비용을 줄일 수 있습니다.

Reserved instances를 사용해서 비용 줄이기

아마존 EC2를 사용하는 많은 업체들이 ChessJam 보다 훨씬 “유연함”을 이용하고 있습니다. 부하에 따라서 동적으로 서버가 늘어나고 줄어들도록 load balancer와 auto-scaling 을 셋업해 서 사용하고 있습니다.  그러나 아직 우리의 App은 그 정도로 복잡하지는 않습니다.( 종종 우리의 사용량에 따라서 백엔엔드를 뜯어고쳐야 하지만…) 우리의 App은 계속 서버를 사용하고 있습니다. 고맙게도 아마존에서는 이런 유형을 커버하기 위한 Reserved Instance 라는 것을 제공하고 있습니다. Reserved Instance는 각 instance 에 대해서 한번 지불하면 일정 기간 동안 계속 사용할 수 있고, 시간당 과금에 대해서 큰 할인을 받을 수 있습니다. 기본적으로 아마존은 장기 사용에 따라서 보상하는 것입니다.( 역자 주: 예를 들어 매달 과금보다는 1년 정기나 3년 정기로 하면 가격이 할인되는 것과 마찬가지입니다. 기업 입장에서는 할인을 해주더라도 운영이 안정적이 됩니다. 아마존의 경우 1년, 3년으로 계약을 할 수 있는데, 3년의 경우, 그 할인폭이 매우 큽니다. ) 3가지 타입이 있는데, light utilization, medium utilization, heavy utilization 입니다. 우리의 서버는 24/7로 운영되어야 하므로 우리에게 가장 적합한 선택은 heavy utilization 모델입니다.(역자 주: heavy가 가장 비쌉니다.)

1년 계약으로 medium instance에 $390 을 지불했습니다. 이제 한시간에 $0.16 불씩 과금되던 것에서 우리는 한시간에 $0.032 씩 밖에 지불하지 않습니다.( 겨우 3센트를 조금 넘습니다.) 우리가 아낀 것에 대해서 간단하게 계산해보면,

  • “Demand instance” 에서는 한시간에 $0.16 * 하루에 24시간 * 1년에 365 일을 해보면, 1년에 $1,401.60 이 듭니다.( 여기에 disk, I/O, transfer를 더해야합니다.)
  • “Reserved instance”에서는 먼저 $390 를 선불금으로 내고, 시간당 $0.032 * 24 시간 * 365 일 해서 일년에 $670.32 이 듭니다.( 여기에 disk, I/O, transfer를 더해야 합니다. ) ( 역자 주: 아, 여기에 제가 잘못 알고 있던 부분이 있었네요. 저는 선불금이 전부 인줄 알았는데, 선불금을 내면, 그 옆에 할인된 가격으로 이용할 수 있다는 뜻입니다. 자세한 건 http://aws.amazon.com/ko/ec2/reserved-instances/ 이걸 보시면 될듯 합니다. 이미 다 한글이예요!!!)

disk, data, 그 외 것들에 대한 최소 사용 비용

  • 한달에 $2,280 정도를 데이터 센터에 지불했습니다.
  • 현재는 아마존에 $1,160 정도를 지불합니다. 1년에 $1,000 정도를 절약하고 있씁니다.( 다른 하드웨어 비용은 포함하지도 않았습니다. )

micro 와 small 두 개의 작은 장비 타입이 있습니다. app과 site 에 따라서 훨씬 싼 것을 구입할 수 있습니다. Reserved Instance 가격 정책에 따르면, 1년에 $100 정도로 micro 장비를 구입할 수 있습니다. 저는 현재 6개의 작은 사이트를 한대의 micro 장비에 호스팅하고 있습니다. ( 지역의 베이글 가게 정보나, 개인적인 제 사진을 올리는 사이트 등이 있습니다.)

TIP: 만약 아마존 micro 장비를 사용할 계획이 있다면, 어떻게 그들이 CPU 파워를 올리는지에 대해서 알아야 합니다. 그것은 micro 장비의 독특한 특성입니다. 나는 이것에 대해서 지난달에 블로깅을 했습니다.(역자 주: micro 장비는 CPU Bursting 이 가능합니다. 박재호님이 쓰신 이 글을 보시길 추천합니다.)

TIP: 아마존의 과금 정보는 하루에 여러번 업데이트 됩니다. 그래서 빨리 모든 것의 과금 정보를 알 수 있습니다. 우리는 동작한지 24시간 후에 한달치 비용을 알 수 있었습니다.

우리는 돈을 아끼기 위해서 EC2로 이전한게 아니다!

물론, 우리는 돈을 좀 아꼈습니다. 이건 대단한 거죠. 하지만 정직하게 말하자면, 돈 때문에 옮긴건 아니었습니다. 진짜 이유는 하드웨어 장애로 인해서 발생하는 어려움을 EC2 같은 클라우드 인프라로 옮겨서 마음의 평화를 가지고 싶었기 때문입니다. 데이터 센터에 백업 서버가 있었지만, Primary 서버가 장애가 나면, 30분간 데이터 센터로 운전해 간 다음, 차가운  데이터 센터안에서, 몇 시간 동안, 하드 디스크를 옮겨 달아야 했고, 또, 그것이 잘 동작하기만을 빌어야 했습니다. 정말 끔찍한 상황이었죠. 지금은, 하드웨어 장애가 발생해도( 적기는 하지만, EC2에서도 발생합니다.),  간단히, 몇번의 마우스질로,  새로운 서버를 시작하고, 디스크를 마운트하고, 몇가지 설정만 해주면, 다시 정상으로 돌아가게 됩니다. 이것들이 전부 내가 잠옷있고, 빅뱅 이론을 보는 동안에 할 수 있습니다.

물론 몇몇의 IT 사고 방식을 가진 사람들이 나의 최종 아키텍처에서 뭔가 몇가지 문제점을 보고 있다는 것을 알고 있고, 당신이 옳습니다. 위의 사례에서, 디스크가 고장나는 경우에 대해서는 언급하지 않았습니다. 디스크 장애는 EC2에서는 정말 잘 안일어나긴 하지만, 해당 구조를 보완하는 몇가지 계획을 가지고 있습니다. 한 대의 서버를 더 추가해서 Mysql 메인 디비를 복제하고, 해 당 서버를 다른 zone에 다가 추가할려고 합니다. 이러면 기본적으로 다른 물리 장비에 할당된다는 것을 의미합니다. 이러면 1년 전처럼 몇몇 유명한 사이트가 몇시간 동안 장애가 발생했던 대규모 장애가 일어나더라도 재빨리 복구가 가능할 것 같습니다. 그러나, 현재는 가장 값싼 방법을 사용하기로 했습니다. 디스크만 하나 더 추가해서 메인 디스크의 mirror로 사용하는 것입니다.  누가 우리를 10억달러(역자주: 1조) 에 사가기 전까지는 충분할 것 같습니다.

 

다른 옵션은 Amazon RDS를 이용하는 것입니다. 우리가 DB로 RDS를 사용한다면,  좀 더 안정적이고 확장성이 좋아질 것 같습니다만, 지금은, 우리가 좀 더 성장할 때 까지는 장비 한대로 버티고 싶고, 비용을 줄이고 싶습니다.

모든 어플리케이션을 위한 것은 아니다.

특별히 우리의 경우에는 EC2는 아주 괜찮습니다. 그러나, 모든 종류의 어플리케이션에 좋은 것은 아닙니다. 서버는 여전히 “가상장비” 이고 성능은 완벽하지 않습니다.

Disk I/O 속도나, 네트웍 밴드위스 등에서, 아마존에 스왑 드라이브를 위해서 SSD를 설치해 달라거나, DBMS 디스크를 RPM 10,000 짜리로 바꿔달라는 말을 할 수 없습니다. 바꿔 말하면, 실제 장비에서는 할 수 있었던 튜닝을, 아마존 EC2에서는 할 수 없다는 얘기입니다. 그러나 EC2에서 당신의 app이 잘 돌아간다면, 이게 무슨 문제겠습니까?, 개인적으로는 내 경력의 대부분을 컴퓨터 실에 받쳤다고 생각합니다.(역자 주:  페이스북 CTO가 말했듯이, 하드웨어 장애에서 오는 문제에 대해서 처리해야 하는 시간을 줄여준다는 말입니다. 그리고 간단한 팁은 DBMS에서 어느 정도 성능 부하가 있을 경우, Memory를 많이 추가해서 DBMS 메모리 사용량을 높여주는 게, 가성비로서는 상당히 효과적입니다.)

아마존 웹 서비스 세계의 나머지…

본문에서 얘기한 것들이 전부 아마존 EC2의 소형 장비들에 대한 것들입니다. 그 외에도 AWS에는 다양한 장비 타입과, Load balances, auto-scailing, monitoring, automatic alerts 등 ㅁㄶ은 기능이 있습니다.  EC2는 아마존 AWS의 한 부분일 뿐입니다. 자세한 것은 다음 사이트에서 확인할 수 있습니다. http://aws.amazon.com/.

공짜로 사용해보기.

최근에 아마존은 EC2 신규 사용자를 위한  “free tier” 를 제공하기 시작했습니다. 기본적으로 1년동안 micro 장비를 적당한 disk와 네트웍 밴드위스를 공짜로 제공합니다. http://aws.amazon.com/free 를 보면 더욱 자세한 설명이 있습니다. 언제든지 장비의 타입을 바꿀 수 있습니다. 개발중에는 micro 를 사용하다가,  실제 서비스로 갈 때 필요하면 업그레이드 할 수 있습니다.