2. Awesomepiece by Awesomepeople
간단한 소개
• 저는 매우 일반적인 프로그래머.
• 내가그린 기린그림 for Kakao 서버와 클라이언트를 개발.
• 당시 개발 인원은 클라이언트 0.5명 + 서버 0.5명.
• 작년에 프로젝트 시작과 함께 AWS를 사용하기 시작.
• 기존에는 서버 호스팅, 웹 호스팅 등의 사용 경험만 갖고 있었
습니다.
3. Awesomepiece by Awesomepeople
클라우드의 필요성
• 게임 개발 기간이 3개월 정도로 정해진 상황에서, 서버의 하
드웨어까지 고려할 여유 없음.
• 유저가 많을 것으로 예상되는 카카오톡 플랫폼에서 일정 대수
의 서버를 미리 계약해서, 장기간 유지하는 것은 회사 규모상
리스크가 컸습니다.
• 회사 내에 서버 관리를 전문적으로 하는 인력이 0명 이었기
때문에, 서버호스팅을 하는 것은 결국 사형선고나 다름이 없
었습니다.
4. Awesomepiece by Awesomepeople
이 세상에 클라우드는 정말 많아요.
• 클라우드는 정말 많습니다.
• AWS, CloudIt, Ucloud, Tcloud, Cafe24 가상 서버 호스팅,
Hostway Flex Servers, Google App Engine
• 저도 클라우드 참 좋아하는데요. 제가 한번 이용해봤습니다.
5. Awesomepiece by Awesomepeople
조건은 그렇게 까다롭지 않았어요.
• 매니지먼트 콘솔이 편리하고,
• 클라우드 사용 노하우에 관한 자료가 구글에 풍부하고,
• 이미 다양한 기업이 사용해서 안전성이 보장 되어있고,
• 24시간 전문 엔지니어들의 서포트를 받을 수 있으면 좋겠습
니다!
10. Awesomepiece by Awesomepeople
AWS를 선택했습니다. 왜?
성숙화된 서비스 경험과 더 불어, 로드 밸런서, 무제한 데이터 스토리지, 자동화, 오토 스케일링까지! 상상
하는 모든 것이 다 지원되는 무서운 클라우드.
게다가, 가입하면 매주 새로운 서비스가 출시됐다고 메일이 올겁니다. AWS는 무섭게 진화중입니다.
11. Awesomepiece by Awesomepeople
하지만 좀 걱정스러웠습니다.
• AWS의 서비스 Regions은 ?
• USA, Japan, Singapore, Europe, Sydney
• 그렇습니다! South Korea는 없던 것입니다. 국내 사용자가 대부
분일 것으로 예상되는 상황에서 Latency 문제가 걸렸던 것이죠.
• 작년 2012년 10월 기준으로 핑이 80~100ms 정도 였으나, 올해
가 되고 나서 이 마저도 50ms 밑으로 떨어졌습니다.
• 40ms면 저희 게임과 같은 소셜 게임 장르에서는 허용해줄 만한
범위 입니다. Cloudping.info로 체크해본 Latency
12. Awesomepiece by Awesomepeople
내가그린 기린그림의 서버 조건
• Scalable한 DB로, 수 많은 Transactions 처리에도 안정적인 데이터 처리, 백업
이 이루어져야 함.
• 그림 데이터가 손실되지 않고, 언제든지 가져올 수 있는 신뢰성 높은 스토리
지.
• 하드웨어에 대한 고려 없이, 편리한 서버 매니지먼트
• ELB로 로드 밸런서에 Frontend 서버를 쉽게 추가할 수 있고, 제거 할 수 있음.
• 사용하지 않는 시간의 서버를 끔으로써 비용 절감 필요.
13. Awesomepiece by Awesomepeople
내가그린 기린그림 + AWS 합체!
• Scalable한 DB로, 수 많은 Transactions 처리에도 안정적인 데이터 처리, 백업이
이루어져야 함.
– Amazon RDS를 통해 쉽게, Replication되는 데이터베이스를 생성할 수 있고 간단한 설정으
로 Scale-Up을 할 수 있다.
• 그림 데이터가 손실되지 않고, 언제든지 가져올 수 있는 신뢰성 높은 스토리지.
– S3는 자체적으로 데이터 안정성에 대한 리플리케이션, 전문적인 관리가 자동적으로 진행되
므로 관리 코스트는 0에 가깝다.
• 하드웨어에 대한 고려 없이, 편리한 서버 매니지먼트
– AWS의 가상화 서버를 통해 네트워크 장비/하드웨어에 대한 관리 코스트를 최소화.
• ELB로 로드 밸런서에 Frontend 서버를 쉽게 추가할 수 있고, 제거 할 수 있음.
– ELB와 서버를 연결하는 작업도 웹 콘솔, CLI, third party를 통해 매우매우 쉽게 할 수 있음.
• 사용하지 않는 시간의 서버를 끔으로써 비용 절감 필요.
– AWS에서 제공하는 AutoScale을 통해, 서버를 유동적으로 On/Off 가능함.
15. Awesomepiece by Awesomepeople
초기 Topology
ELB
(HTTPS)
Web
Frontend
RDS
Device
Device
Device
HTTP
S
HTTP
S
HTTP
S
Web
Frontend
Web
Frontend
Web
Frontend
Web
Frontend
Memcached
• 비동기 게임이기 때문에 ELB의 Consistency 기능은 사용하지 않음.
• ELB는 Requests에 따라 자동적으로 Scale-up 됩니다.
• RDS의 Multi-AZ를 사용하여, 데이터 자동 Replication.
• Web Frontend는 Stateless 이기 때문에 쉽게 Auto-scaling 가능.
S3
16. Awesomepiece by Awesomepeople
그런데!
• 프론트엔드 서버, 로드 밸런서에는 그렇게 큰 이슈가 없었습니다!
• 하지만, DB가 뻗어버렸네요. 당시 도쿄 Region에서 쓸 수 있는
아마존 RDS 최고 사양을 사용하고 있었습니다.
• 예상을 뛰어넘는 동접으로, DB 서버에 부하가 많이 간게 원인.
17. Awesomepiece by Awesomepeople
결국에!
• DB를 옮겨야할 것 상황이 왔습니다. Tokyo의 RDS가 현재와 달리
Scale-up에 한계가 있어서, 옮길수가 없었습니다.
• 어떤한계 ? (당시 용량이 1TB 까지만 지원, 너무나 비싼 Dynamo
NoSQL 가격)
– RDS 현재는 3TB/ 30,000 Provisioned IOPS 를 지원함.
– 현재 Dynamo NoSQL 은 당시가격보다 90% 저렴해짐
• 개별 Instance 에 RDB와 Cassandra 를 설치하여 운영하게 됨.
– 향후에는 관리 COST 를 고려해 RDS 도입을 재검토중.
18. Awesomepiece by Awesomepeople
현재 Topology
ELB
(HTTPS)
Web
Frontend
Small
RDS
Device
Device
Device
HTTP
S
HTTP
S
HTTP
S
Web
Frontend
Web
Frontend
Web
Frontend
Web
Frontend
Memcached
Cassandra
• RDS를 최소한의 정보를 저장하는 DB 로 사용.
• EC2로 직접 DB를 구축하여, 튜닝
• 수많은 오답 데이터를 저장하기 위해, RDS대신 Cassandra를 도입하여, 해결
EC2 DB
대부분의 데이터
마이그레이션
S3
19. Awesomepiece by Awesomepeople
운영해보니…
• 3억개의 그림 데이터를 S3에 보관중. 손실률 0%
• 50억개의 오답 데이터를, Cassandra Backend(EBS RAID 1)*2
로 서비스중
• CloudWatch가 개별 인스턴스의 상태를 파악하고, 자동적으로
Scale Up/Down
• 다수의 서버에 배포, 배치 명령 실행은 Fabric과 boto같은 third-
party로 쉽게 해결.
• 하드웨어에 대한 커다란 이해가 없이도, 클라우드 서비스를 이용.
22. Awesomepiece by Awesomepeople
그래도, 비싸지 않나요 ?
• Autoscale을 통한 서버의 사용량에 따라 On/Off로 새벽 시간대
의 서버 비용을 30% 절감할 수 있었습니다.
• 그것도 부족하면, Reserved Instance 계약을 통해 1년~3년 단위
로 계약함으로써, 비용을 최대 71%까지 낮출 수 있음.
• 심지어 더 절약하고 싶다면, AWS에 연락해서 컨설팅을 받아보자!
성심성의껏 도와줄 것입니다!
• 무료 컨설팅 문의는 이정인 영업대표님에게
jungin@amazon.com