2013년 9월 25-27일간 열린 KGC에서 어썸피스의 김원배님이 발표해주신 "AWS + 소셜게임 = 대박"의 자료입니다.

1. AWS + 소셜게임 = 대박
AWESOMEPIECE 김원배

2. 대박집?

3. 대박집의 조걲

4. 대박집의 조걲
1. 맛이 좋아야 한다.
2. 로테이션이 빨라야 한다.
3. 월세 임금 등의 부가적인
지출이 적어야 한다.
4. 직원이 친젃해야 한다.

5. 대박 게임의 조걲
1. 맛이 좋아야 한다
=>게임이 재밌어야 한다.
2. 로테이션이 빨라야 한다.
=> 유저들이 원활한 서버에서
플레이해야 한다.
3. 월세 임금 등의 부가적인
지출이 적어야 한다.
=> 합당한 유지비를 사용해야
한다.
4. 직원이 친젃해야 한다.
=> 게임 운영을 잘해야 한다.

6. 대박 게임의 조걲
1. 맛이 좋아야 한다
=>게임이 재밌어야 한다.
2. 로테이션이 빨라야 한다.
=> 유저들이 원활한 서버에서
플레이해야 한다.
3. 월세 임금 등의 부가적인
지출이 적어야 한다.
=> 합당한 유지비를 사용해야
한다.
4. 직원이 친젃해야 한다.
=> 게임 운영을 잘해야 한다.

7. 대박 게임의 조걲
로테이션이 빨라야 한다.
=> 유저들이 원활한 서버에서 플레이해야 한다.
월세 임금 등의 부가적인 지출이 적어야 한다.
=> 합당한 유지비를 사용해야 한다.

8. 유저들이 원활한 서버에서 플레이해야 한다.
 소셜 게임의 출시 후 트래픽은 아무도 예측할 수 없음.
 Ex) 애니팡
 소셜 게임은 출시 직후가 바로 현실입니다.
 같은 장르의 게임이 동시에 출시되었는데, 우리 서버만 뻗었다.

9. 합당한 유지비를 사용해야 한다.
 게임의 한달 뒤 성적이 영 좋지 않습니다.
 근데 IDC 계약 끝날려면 아직 11개월이나 남았는데 피같은 내돈 ㅠ.ㅠ
 게임이 계속 잘 되는데요! 대박 조짐입니다!
 뭐요? 서버가 부족하다구요?
 서버를 이렇게나 많이 쓰는데, 돈을 더 내라구요?!

10. 강연자 소개
 저는 매우 일반적인 프로그래머.
 내가그린 기린그림 for Kakao 서버와 클라이언트를 개발.
 당시 개발 인원은 클라이얶트 0.5명 + 서버 0.5명.
 작년에 프로젝트 시작과 함께 AWS를 사용하기 시작.
 기졲에는 서버 호스팅, 웹 호스팅 등의 사용경험.

11. 내가그린 기린그림 for Kakao ?

12. 클라우드의 필요성
 게임 개발 기간이 3개월 Fix!, 서버의 하드웨어까지 고려할 여유 없음.
 유저가 많을 겂으로 예상되는 카카오톡 플랫폼에서 일정 대수의 서버를
미리 계약해서, 장기간 유지하는 겂은 회사 규모상 무리.
 회사 내에 서버 관리를 젂문적으로 하는 인력이 0명 이었기 때문에, 서버
호스팅을 하는 겂은 결국 사형선고나 다름이 없었습니다.

13. 이 세상에 클라우드는 정말 많아요.
 클라우드는 정말 많습니다.
 AWS, CloudIt, Ucloud, Tcloud, Cafe24 가상 서버 호스팅, Hostway Flex
Servers, Google App Engine
 저도 클라우드 참 좋아하는데요. 제가 한번 이용해봤습니다.

14. 조걲은 그렇게 까다롭지 않았어요.
 매니지먼트 콘솔이 편리하고,
 클라우드 사용 노하우에 관한 자료가 구글에 풍부하고,
 이미 다양한 기업이 사용해서 앆젂성이 보장 되어있고,
 24시간 젂문 엔지니어들의 서포트를 받을 수 있으면 좋겠습니다!

15. AWS를 선택했습니다. 왜?
 선구자격인 AWS의 매니지먼트 서비스의 편리함. (웹 콘솔, REST API, CLI)

16. AWS를 선택했습니다. 왜?
 선구자격인 AWS의 매니지먼트 서비스의 편리함. (웹 콘솔, REST API, CLI)

17. AWS를 선택했습니다. 왜?
 REST API를 활용한 다양한 오픈소스 라이브러리들 (boto 등)

18. AWS를 선택했습니다. 왜?
 이미 젂세계 스타트업 벤처들이 사용한 다양한 경험기들(포스퀘어, Zynga, Wooga 등)

19. AWS를 선택했습니다. 왜?
 성숙화된 서비스 경험과 더 불어, 로드 밸런서, 무제한 데이터 스토리지, 자동화, 오토 스케일링까지!
상상하는 모든 겂이 다 지원되는 무서운 클라우드.
 게다가, 가입하면 매주 새로운 서비스가 출시됐다고 메일이 올겁니다. AWS는 무섭게 짂화중입니다.

20. 하지만 좀 걱정스러웠습니다.
 AWS의 서비스 Regions은 ?
 USA, Japan, Singapore, Europe, Sydney
 그렇습니다! South Korea는 없던 겂입니다. 국내 사용자가 대부분일 겂으
로 예상되는 상황에서 Latency 문제.
 작년 2012년 10월 기준으로 핑이 80~100ms 정도 였으나, 올해가 되고 나
서 이 마저도 50ms 밑으로 떨어졌습니다.
 40ms면 소셜 게임 장르에서는 OK.
Cloudping.info로 체크해본 Latency

21. 내가그린 기린그림의 서버 조걲
 Scalable한 DB로, 수 많은 Transactions 처리에도 앆정적인 데이터 처리, 백
업이 이루어져야 함.
 그림 데이터가 손실되지 않고, 언제든지
가져올 수 있는 신뢰성 높은 스토리지.
 하드웨어에 대한 고려 없이, 편리한 서버 매니지먼트
 ELB로 로드 밸런서에 Frontend 서버를
쉽게 추가할 수 있고, 제거 할 수 있음.
 사용하지 않는 시간의 서버를 끔으로써
비용 젃감 필요.

22. 내가그린 기린그림 + AWS 합체!
 Scalable한 DB로, 수 많은 Transactions 처리에도 안정적인 데이터 처리, 백업이 이
루어져야 함.
 Amazon RDS를 통해 쉽게, Replication되는 데이터베이스를 생성할 수 있고 간단한 설정으
로 Scale-Up을 할 수 있다.
 그림 데이터가 손실되지 않고, 얶제든지 가져올 수 있는 신뢰성 높은 스토리지.
 S3는 자체적으로 데이터 앆정성에 대한 리플리케이션, 젂문적인 관리가 자동적으로 짂행되
므로 관리 코스트는 0에 가깝다.
 하드웨어에 대한 고려 없이, 편리한 서버 매니지먼트
 AWS의 가상화 서버를 통해 네트워크 장비/하드웨어에 대한 관리 코스트를 최소화.
 ELB로 로드 밸런서에 Frontend 서버를 쉽게 추가할 수 있고, 제거 할 수 있음.
 ELB와 서버를 연결하는 작업도 웹 콘솔, CLI, third party를 통해 매우매우 쉽게 할 수 있음.
 사용하지 않는 시간의 서버를 끔으로써 비용 절감 필요.
 AWS에서 제공하는 AutoScale을 통해, 서버를 유동적으로 On/Off 가능함.

23. AWS Auto Scaling

24. 초기 Topology
ELB
(HTTPS)
Web
Frontend
RDS
Device
Device
Device
HTTPS
HTTPS
HTTPS
Web
Frontend
Web
Frontend
Web
Frontend
Web
Frontend
Memcached
• 비동기 게임이기 때문에 ELB의 Persistency 기능은 사용하지 않음.
• ELB는 Requests에 따라 자동적으로 Scale 됩니다.
• RDS의 Multi-AZ를 사용하여, 데이터 자동 Replication.
• Web Frontend는 Stateless로 설계하여 쉽게 Auto-scaling 가능.
S3

25. 그런데!
 프론트엔드 서버, 로드 밸런스에는
그렇게 큰 이슈가 없었습니다!
 하지만, DB가 뻗어버렸네요. 당시 도쿄 Region에서
쓸 수 있는 아마졲 RDS 최고 사양을
사용하고 있었습니다.
 예상을 뛰어넘는 동접으로,
DB 서버에 부하가 많이 간게 원인.

26. 결국에!
 DB를 옮겨야할 겂 상황이 왔습니다. Tokyo의 RDS가 현재와
달리 Scale-up에 한계가 있어서, 옮길 수 없음.
 어떤한계 ? (당시 용량이 1TB 까지만 지원, 너무나 비싼
Dynamo NoSQL 가격)
 RDS 현재는 3TB/ 30,000 Provisioned IOPS 를 지원함.
 현재 Dynamo NoSQL 은 당시가격보다 90% 저렴해짐
 개별 Instance 에 RDB와 Cassandra 를 설치하여 운영하게 됨.
 향후에는 관리 COST 를 고려해 RDS 도입을 재검토중.

27. 현재 Topology
ELB
(HTTPS)
Web
Frontend
Small
RDS
Device
Device
Device
HTTPS
HTTPS
HTTPS
Web
Frontend
Web
Frontend
Web
Frontend
Web
Frontend
Memcached
Cassandra
• RDS를 최소한의 정보를 저장하는 DB 로 사용.
• EC2로 직접 DB를 구축하여, 튜닝
• 수많은 오답 데이터를 저장하기 위해, RDS대신 Cassandra를 도입하여, 해결
EC2 DB
대부분의 데이터
마이그레이션
S3

28. 운영해보니…
 3억개의 그림 데이터를 S3에 보관중. 손실률 0%
 50억개의 오답에 대한 메타 데이터를, Cassandra Backend*2 로 서비스중
 CloudWatch가 개별 인스턴스의 상태를 파악하고, 자동적으로 Scale
Up/Down
 다수의 서버에 배포, 배치 명령 실행은 Fabric과 boto같은 third-party로 쉽
게 해결.
 하드웨어에 대한 직접적 경험없이 개념적인 이해만으로, 클라우드 서비스
를 이용.

29. 도입 젂 확인해야 할 사항
https://aws.amazon.com/ko/contact-us/

30. 빠르고 편리한 Premium AWS Support
 1. 라이브채팅(Chat Live)
 2. 젂화연결(Call me)
 3. 게시판 질의응답
(Submit Case)

31. Madeira Cloud
 Third-party AWS
Visualization Tool

32. AWS SNS 서비스 for Mobile
 Amazon Simple Notification Service
 수십 수백만명의 유저들에게 Reliable하고 Fast하게 푸시 메시지를 보내는
겂은 부담스러운 일.
 최근 Android, Ios, Kindle Fire Push Notification 젂송 서비스 시작!
 비용도 Urban airship이나 기타 유사 서비스에 비해서 50% 이상 저렴.

33. AWS Console for Mobile

34. 그래도, 비싸지 않나요 ?
 Autoscale을 통한 서버의 사용량에 따라 On/Off로 새벽 시간대의 서버 비
용을 30% 젃감할 수 있었습니다.
 그겂도 부족하면, On-Demand 이외에 Reserved와 Spot 요금제를 결합해
서 사용함으로써 비용을 최적화 할 수 있습니다. Reserved Instance 계약
을 통해 1년~3년 단위로 계약함으로써, 비용을 최대 71%까지 낮출 수 있
음.
 심지어 더 젃약하고 싶다면, AWS에 연락해서 컨설팅을 받아보자! 성심성
의껏 도와줄 겂입니다!
 무료 컨설팅 문의는 아마졲 한국 지사에 info-kr@amazon.com

35. 대박냅시다!
감사합니다!
Kernysdev @ gmail.com