데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...Amazon Web Services Korea
<쿠키런:킹덤> 게임 유저 수가 급증하면서 지금까지 겪어보지 못했던 대규모 인프라 환경을 운영하게 되었고, 그 과정에서 다양한 문제점들에 부딪히게 되었습니다. 이 세션에서는 AWS에서 Stateful 한 게임 서버를 어떻게 운영해야 하는지 아키텍처 관점에서 먼저 설명한 후, 수 백만 명의 사용자를 감당하기 위해 해결해야 했던 어려움에 대해 Scalability 관점에서 설명해드립니다.
데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...Amazon Web Services Korea
<쿠키런:킹덤> 게임 유저 수가 급증하면서 지금까지 겪어보지 못했던 대규모 인프라 환경을 운영하게 되었고, 그 과정에서 다양한 문제점들에 부딪히게 되었습니다. 이 세션에서는 AWS에서 Stateful 한 게임 서버를 어떻게 운영해야 하는지 아키텍처 관점에서 먼저 설명한 후, 수 백만 명의 사용자를 감당하기 위해 해결해야 했던 어려움에 대해 Scalability 관점에서 설명해드립니다.
[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장Dylan Ko
Gonnector(고넥터) 고영혁 대표가 주최한 스타트업 데이터 활용 세미나 '우리가 데이터를 쓰는 법' 의 세 번째 발표 자료
세미나 : 우리가 데이터를 쓰는 법 (How We Use Data)
일시 : 2016년 4월 12일 화요일 10:00 ~ 18:00
장소 : 마루180 (Maru180) B1 Think 홀
제목 : 모바일 게임 로그 데이터 분석 이야기
연사 : 엔터메이트 공신배 팀장
AWS 클라우드를 활용하면 사용자의 트래픽에 따라 IT 인프라 아키텍처를 확장할 수 있습니다. 이번 강연에서는 서비스 초기의 작은 트래픽에 대응할 수 있는 단순한 아키텍처로 시작해 사업 성장 후의 수백만 사용자에 달하는 대규모 트래픽을 지탱할 수 있는 고확장성 아키텍처에 이르기까지의 단계별 아키텍처 구성 방법에 대해 소개해 드리고 컴퓨팅 및 데이터베이스 선택 및 사용자 증가에 따른 트래픽 경감 방법, 오토스케일링 및 모니터링과 자동화, DB 부하 분산, 고가용성 확보 등에 대한 다양한 모범사례를 알려드릴 예정입니다.
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유Hyojun Jeon
NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 1부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
PUBG: Battlegrounds 라이브 서비스 EKS 전환 사례 공유 [크래프톤 - 레벨 300] - 발표자: 김정헌, PUBG Dev...Amazon Web Services Korea
PUBG: Battlegrounds를 위한 게임 관련 인프라를 EKS 기반 환경으로 모두 전환한 경험에 대해 공유해 드릴 예정입니다. PUBG의 글로벌 서비스를 위한 인프라 구성에 대해 간단히 소개하고, 라이브 서비스 중인 인프라를 EC2 기반에서 EKS 기반으로 점진적으로 전환하면서 겪었던 문제들과 소중한 경험들을 사례를 통해 전달해드립니다.
source : http://www.opennaru.com/cloud/msa/
마이크로서비스는 애플리케이션 구축을 위한 아키텍처 기반의 접근 방식입니다. 마이크로서비스를 전통적인 모놀리식(monolithic) 접근 방식과 구별 짓는 기준은 애플리케이션을 핵심 기능으로 세분화하는 방식입니다. 각 기능을 서비스라고 부르며, 독립적으로 구축하고 배포할 수 있습니다. 이는 개별 서비스가 다른 서비스에 부정적 영향을 주지 않으면서 작동(또는 장애가 발생)할 수 있음을 의미합니다.
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...Amazon Web Services Korea
서비스 런칭을 위해 라이온하트와 카카오게임즈가 어떻게 최적 성능의 인스턴스를 선택하고, Windows 운영 체제를 최적화하며, 왜 Amazon Aurora를 기본 데이터베이스로 채택하였는지를 설명합니다. 또한, 출시부터 운영까지의 과정에서 MMORPG가 어떻게 AWS 상에서 설계되고, 게임 서버 성능을 극대할 수 있었는지에 대해 전달해드립니다.
OpenSearch는 배포형 오픈 소스 검색과 분석 제품군으로 실시간 애플리케이션 모니터링, 로그 분석 및 웹 사이트 검색과 같이 다양한 사용 사례에 사용됩니다. OpenSearch는 데이터 탐색을 쉽게 도와주는 통합 시각화 도구 OpenSearch와 함께 뛰어난 확장성을 지닌 시스템을 제공하여 대량 데이터 볼륨에 빠르게 액세스 및 응답합니다. 이 세션에서는 실제 동작 구조에 대한 설명을 바탕으로 최적화를 하기 위한 방법과 운영상에 발생할 수 있는 이슈에 대해서 알아봅니다.
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버Heungsub Lee
NDC14에서 발표한 "[야생의 땅: 듀랑고] 서버 아키텍처" 세션의 슬라이드입니다.
슬라이드에 설명이 많지 않은데, 디스이즈게임에서 발표 내용을 잘 정리해주었습니다. 기사도 함께 보시면 좋을 것 같습니다.
http://www.thisisgame.com/webzine/news/nboard/4/?n=54955
[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장Dylan Ko
Gonnector(고넥터) 고영혁 대표가 주최한 스타트업 데이터 활용 세미나 '우리가 데이터를 쓰는 법' 의 세 번째 발표 자료
세미나 : 우리가 데이터를 쓰는 법 (How We Use Data)
일시 : 2016년 4월 12일 화요일 10:00 ~ 18:00
장소 : 마루180 (Maru180) B1 Think 홀
제목 : 모바일 게임 로그 데이터 분석 이야기
연사 : 엔터메이트 공신배 팀장
AWS 클라우드를 활용하면 사용자의 트래픽에 따라 IT 인프라 아키텍처를 확장할 수 있습니다. 이번 강연에서는 서비스 초기의 작은 트래픽에 대응할 수 있는 단순한 아키텍처로 시작해 사업 성장 후의 수백만 사용자에 달하는 대규모 트래픽을 지탱할 수 있는 고확장성 아키텍처에 이르기까지의 단계별 아키텍처 구성 방법에 대해 소개해 드리고 컴퓨팅 및 데이터베이스 선택 및 사용자 증가에 따른 트래픽 경감 방법, 오토스케일링 및 모니터링과 자동화, DB 부하 분산, 고가용성 확보 등에 대한 다양한 모범사례를 알려드릴 예정입니다.
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유Hyojun Jeon
NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 1부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
PUBG: Battlegrounds 라이브 서비스 EKS 전환 사례 공유 [크래프톤 - 레벨 300] - 발표자: 김정헌, PUBG Dev...Amazon Web Services Korea
PUBG: Battlegrounds를 위한 게임 관련 인프라를 EKS 기반 환경으로 모두 전환한 경험에 대해 공유해 드릴 예정입니다. PUBG의 글로벌 서비스를 위한 인프라 구성에 대해 간단히 소개하고, 라이브 서비스 중인 인프라를 EC2 기반에서 EKS 기반으로 점진적으로 전환하면서 겪었던 문제들과 소중한 경험들을 사례를 통해 전달해드립니다.
source : http://www.opennaru.com/cloud/msa/
마이크로서비스는 애플리케이션 구축을 위한 아키텍처 기반의 접근 방식입니다. 마이크로서비스를 전통적인 모놀리식(monolithic) 접근 방식과 구별 짓는 기준은 애플리케이션을 핵심 기능으로 세분화하는 방식입니다. 각 기능을 서비스라고 부르며, 독립적으로 구축하고 배포할 수 있습니다. 이는 개별 서비스가 다른 서비스에 부정적 영향을 주지 않으면서 작동(또는 장애가 발생)할 수 있음을 의미합니다.
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...Amazon Web Services Korea
서비스 런칭을 위해 라이온하트와 카카오게임즈가 어떻게 최적 성능의 인스턴스를 선택하고, Windows 운영 체제를 최적화하며, 왜 Amazon Aurora를 기본 데이터베이스로 채택하였는지를 설명합니다. 또한, 출시부터 운영까지의 과정에서 MMORPG가 어떻게 AWS 상에서 설계되고, 게임 서버 성능을 극대할 수 있었는지에 대해 전달해드립니다.
OpenSearch는 배포형 오픈 소스 검색과 분석 제품군으로 실시간 애플리케이션 모니터링, 로그 분석 및 웹 사이트 검색과 같이 다양한 사용 사례에 사용됩니다. OpenSearch는 데이터 탐색을 쉽게 도와주는 통합 시각화 도구 OpenSearch와 함께 뛰어난 확장성을 지닌 시스템을 제공하여 대량 데이터 볼륨에 빠르게 액세스 및 응답합니다. 이 세션에서는 실제 동작 구조에 대한 설명을 바탕으로 최적화를 하기 위한 방법과 운영상에 발생할 수 있는 이슈에 대해서 알아봅니다.
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버Heungsub Lee
NDC14에서 발표한 "[야생의 땅: 듀랑고] 서버 아키텍처" 세션의 슬라이드입니다.
슬라이드에 설명이 많지 않은데, 디스이즈게임에서 발표 내용을 잘 정리해주었습니다. 기사도 함께 보시면 좋을 것 같습니다.
http://www.thisisgame.com/webzine/news/nboard/4/?n=54955
KGC 2014 가볍고 유연하게 데이터 분석하기 : 쿠키런 사례 중심 , 데브시스터즈Minwoo Kim
1년 7개월 장수 모바일 게임 쿠키런. 많은 유저, 하루에도 쏟아지는 많은 로그. Time To Market 단축이 핵심 역량 중 하나가 되는 모바일 게임 시장. 자주 빠르게 변경되는 스팩, 로그도 마찬가지로 자주 빠르게 변경되는 스키마. 이런 현실속에서 게임 개발과 운영, 데이터 분석까지 병행 하기 위해서 가볍고 유연한 아키텍처로 적당히 빠르게 데이터 분석을 하는 쿠키런 서버팀 사례를 소개합니다.
딥러닝과 강화 학습으로 나보다 잘하는 쿠키런 AI 구현하기 DEVIEW 2016Taehoon Kim
발표 영상 : https://goo.gl/jrKrvf
데모 영상 : https://youtu.be/exXD6wJLJ6s
Deep Q-Network, Double Q-learning, Dueling Network 등의 기술을 소개하며, hyperparameter, debugging, ensemble 등의 엔지니어링으로 성능을 끌어 올린 과정을 공유합니다.
NDC 2015 조길현 - 모바일게임 생명연장의 꿈 : 쿠키런 2년 게임 운영 분투기KilHyeon Cho
오랫동안 많은 사람들에게 즐거움을 주고 큰 사랑을 받아온 쿠키런. '모바일 게임의 수명은 길어야 3개월' 이라는 공식을 깨고 긴 시간 사랑을 받아온 비결에는 혼신의 힘을 다한 모바일 게임 운영이 있었다! 올해로 2주년을 맞이하는 쿠키런을 운영하면서 겪은 실제 사례들을 통해 오랫동안 끊임없는 재미를 제공하는 좋은 운영을 만드는 요소들에는 어떤 것들이 있는지 이야기해본다.
배상욱 hzael@naver.com
1. 위 내용은 애니팡 역기획입니다. 애니팡의 실제 시스템 및 기획과 전혀 상관이 없는 개인이 만든 포트폴리오입니다.
2. 역기획 내용 중 틀린 내용 및 오류가 있습니다. 너그러이 보아 주시면 감사하겠습니다.
3. 이 슬라이드의 구성 및 배경을 제외한 내용은 저의 지적재산이므로 무단 도용을 금지합니다.
4. 슬라이드의 구성은 이상균님의 게임 기획 튜토리얼의 배경을 많은 부분 참고하였습니다.
5. 슬라이드 컨버팅 중 변형된 곳이 있습니다.
6. 전리품 분배 시스템 기획 http://www.slideshare.net/SwooBae/ss-28736021
7. 전리품 분배 시스템 기획 - 아이템의 획득 DOCX 버젼 http://www.slideshare.net/SwooBae/ss-28736246
넥슨 글로벌 플랫폼 구축 이야기 : DB Migration case study (임현수 플랫폼인프라실 Technical Manager, 넥...Amazon Web Services Korea
넥슨 글로벌 플랫폼 구축 이야기 : DB Migration case study
이 세션에서는 넥슨의 Case study를 통하여 글로벌플랫폼 구축을 위해 기존 플랫폼을 AWS로 Migration하는 과정 및 발생가능한 이슈를 공유합니다. 넥슨이 DB서버를 이전하는 과정 속에서 마주한 기술적 고민과 이슈를 통하여 AWS 활용 시 고려해야 할 부분들에 대해 소개하고 함께 이야기 나누고자 합니다.
(GameTech2015) Live Operation by Adbrix의 Node.js와 MongoDB를 이용한 멀티테넌트 인프라 구축사례Jeongsang Baek
대부분의 중소 모바일 게임 업체는 앱을 잘 만들기에도 시간이 모자라 출시일을 잘 맞추기 급급한 상황이다. 그러다 보니 운영을 위한 툴은 소홀히 개발하는 경우가 대부분이고 운영 캠페인은 날림으로 개발하거나 그때 그때 개발자가 필요한 부분만 개발하기 일쑤다. 그러다보니 마케터는 결국 늘 개발자 눈치만 살피게 된다. 필자는 블루윈드에서 이러한 문제를 절감했고 '모바일 게임 개발사가 앱 개발에만 집중할 수 있게 해주고 싶다'는 IGAworks의 철학에 공감하여 라이브 오퍼레이션 프로젝트를 시작하게 되었다.
라이브 오퍼레이션의 개발 중점과제는 5가지였다. 첫번째, 다수의 개발사가 하나의 큰 클라우드 시스템을 사용하도록 multi-tenant 인프라를 구축해야 한다. 두번째, TCO(Total cost of ownership)를 최소화해야 한다. 세번째, 앱의 핵심유저를 실시간으로 그룹화하여 타게팅 캠페인을 할 수 있어야 한다. 네번째, 캠페인의 성과를 마케터에게 실시간으로 피드백해야 한다. 다섯째, 3개월 안에 정식 서비스가 되어야 한다는 점이었다. (왜 우리에게 주어지는 시간은 늘 3개월인가) 그리고 당연하지만 이 서비스를 혼자 개발해야 했다.
이 다섯가지 이슈를 해결하기 위하여 AWS 클라우드 상에 생산성과 성능이 검증된 node.js 와 mongodb를 이용하여 서비스 백엔드를 구성하였고, multi-tenant를 구성하기 위한 여러가지 고민과 그 해결책을 직접 구현하였다. 필자는 node.js와 mongodb를 사용해 본 경험이 충분하다 생각했지만 대규모 정식 서비스를 진행하며 많은 함정에 빠졌고 결국 해결했다.
이 발표를 통해 청강자는 node.js와 mongodb를 이용하여 multi-tenant 인프라를 구축해야 할 때 고려해야 할 설계 방식과 기술적인 고민, 그것에 대한 현실적인 해법을 얻을 수 있다.
천만사용자를 위한 AWS 클라우드 아키텍처 진화하기 – 문종민, AWS솔루션즈 아키텍트:: AWS Summit Online Korea 2020Amazon Web Services Korea
발표영상 다시보기: https://youtu.be/z68l2X5KoC4
AWS 클라우드는 초기에 적은 비용으로 웹 서비스를 시작하고, 향후 사업이 발전했을 때 천만 이상의 유저가 사용할 수 있는 고가용성, 확장성, 민첩성이 뛰어난 웹 서비스를 만들 수 있습니다. 본 세션에서는 작은 서비스로 시작하여 AWS의 다양한 서비스를 사용하여 천만 이상의 대규모 유저 트래픽을 수용할 수 있는 웹 서비스로 발전시키는 것을 단계별로 오토스케일링, 트래픽 경감, 모니터링과 자동화, 고가용성 확보를 위한 아키텍처 구성 방법을 소개합니다.
사례들로 알아보는 컨테이너, 언제 어떻게 쓰면 좋을까? – 김성수 AWS 솔루션즈 아키텍트, 허준 AWS 어카운트 매니저, 이창명 선데이토...Amazon Web Services Korea
컨테이너를 활용할 수 있는 Workload는 정해져 있는 걸까? 이제는 주변에서 쉽게 보고 들을 수 있는 컨테이너, 하지만 정작 내가 쓰려면 어떻게 써야 할지 감을 잡기 어려운 것도 사실이죠. 유명 게임, 웹 서비스에서 컨테이너를 어떻게, 왜 쓰게 되었는지를 알아봅니다. 그리고 컨테이너에 올리는 작업의 특성을 파악하면 활용할수 있는 팁들까지, 실사례를 통해서 알아봅니다!
2. 강연자 소개
홍성진 (sungjinhong@devsisters.com)
• KAIST 전산과 학사
• 소프트웨어 엔지니어링 인턴, 구글 코리아
• 통계기계번역팀, 한-영 번역 품질 향상: http://translate.google.com
• 시니어 소프트웨어 엔지니어, 위클레이
• 영상/음성 통화 앱 시드 클라이언트/서버 개발: http://seed.weclay.com
• 테크니컬 리드, 데브시스터즈
• 쿠키런 for Kakao, Ovenbreak 2 서버 개발
2
4. 2013년 초 데브시스터즈
• 서버 개발자 2명, 시스템 엔지니어 0명
• 한 분은 쿠키런 출시 전 전직 예정! 혼자 개발/관리해야함
• 2013년 초 Ovenbreak 2 출시로 일정 성과를 냄
• 한 명이 한 달만에 구현한 서버
• 북미 AWS 를 사용, 현지 서버가 필요했으니 당연한 선택
• 쿠키런은 서버는 어떻게 할 것인가?
• 서버는 어떻게 구현? Ovenbreak 2 서버를 재활용!
• 한국에 서비스하려면 서버는 어디에 둘까?
4
5. AWS 선택의 이유
• 애로사항이 꽃피는 IDC 입주 및 서버구입
• IDC는 어디로? 서버는 어느 밴더?
• BMT, 서버 설치, 네트워크 구축할 시간과 인력 부족
• 서버 확충에 대한 늦은 리드 타임 (최소 2주)
• 그렇다고 많이 구입을 하자니 높은 초기 투자비용 필요
• 한국 클라우드 밴더들에대한 신뢰성 문제
• 높은 트래픽 환경에서 제대로된 성능을 내지 못하는 사례 (LB 장애?!)
• 상대적으로 기능이 부족하고 운영 경험 및 노하우 부족
5
6. AWS 선택의 이유 (2)
• 회사가 이미 AWS를 사용
• 서버 개발자 한명이 관리할 수 있는 서버 환경
• API 및 원격으로 모든 시스템 관리 가능
• 단순 IaaS 라고 볼 수 없는 다양한 서비스 제공
• EBS, AMI, Auto Scaling, ELB, S3, Route53, CloudFront, RDS, ...
• 모든 서비스는 API로 제어가 가능
• AWS의 다양한 서비스와 조합하면 훨씬 더 큰 부가가치를 얻을 수 있을것
• 특히 Auto Scaling, ELB, S3 등이 매력적
6
8. AWS의 간단 소개
• 웹 서비스 (Web Service) - 인프라(컴퓨터, 스토리지 등)을 객체처럼 다룬다
• AMI (Amazon Machine Image) - 디스크 스냅샷; Class
• 인스턴스 (Instance) - AMI를 부팅한 가상머신; Object(Instance) of AMI
• ELB (Elastic Load Balancer) - 로드밸런서 as Object
• EBS (Elastic Block Store) - 추상화된 NAS 디스크; Disk as Object
• S3 (Simple Storage Service) - 추상화된 파일 스토리지; File as Object
• 모든 서비스는 API를 통해서 다룰 수 있다
• 요즘 대부분이 사용하는 Web Console은 원래 없었음
8
9. AWS S3 예제
>>> import boto
>>> import time
>>> s3 = boto.connect_s3()
# Create a new bucket. Buckets must have a globally unique name
>>> bucket = s3.create_bucket('kgc-demo')
# Create a new key/value pair.
>>> key = bucket.new_key('mykey')
>>> key.set_contents_from_string("Hello World!")
# Sleep to ensure the data is eventually there.
>>> time.sleep(2)
# Retrieve the contents of ``mykey``.
>>> print key.get_contents_as_string()
'Hello World!'
# $ curl http://kgc-demo.s3.amazonaws.com/mykey
# Hello World!
9
11. 출시 전 준비사항
• 핵심 주안점: 최대한 자동화된 서버 인프라
• CloudFormation, Chef, Git을 통하여 서버의 설정을 소스코드처럼 관리하자
• 서버 구조 문서화 및 배포를 따로 x
• ELB, Auto Scaling을 꼭 써보자: 손으로 일일이 서버를 증가시키기 x
• S3를 사용하여 게임 데이터를 제공하자: 웹서버 구축 및 파일 호스팅 관리 x
• 모니터링은 확실하게 하자: 직접 서비스 모니터링 x
11
12. 초기 소프트웨어 스택
• 메인 API 서버
• Java, Spring MVC, Mybatis, MySQL 5.5
• Tomcat 6.0, Apache 2.2 (mod_jk), Ubuntu Linux 13.04
• GMS, 게임 데이터 관리 서비스
• Python, Django, Boto
• 서비스 모니터링
• CloudWatch, SNS, Zabbix, Statsd, Graphite
12
13. 출시 직후
13
Availability Zone-1 Availability Zone-2
Front-end game service
S3 Buckets
EC2 EC2
ELB
RDS (MySQL)
Database group
Mobile Game user
EC2
Game & Server
Monitoring
Auto-scaling
group
EC2
Chef & Git Conf.
Management
Log archives Patches & Game Data
CloudFormation
CloudWatch
Internet
15. 출시 직후의 서버 상황
•미미했던 시작, 얼마나 성장할까?
•별다른 마케팅 없이 시작
•카카오톡 테마가 유일
•첫날(4/2) 가입자 9만명!
•서버 부하는 버틸만
•내일도 오늘만큼만 가입해다오!
15
0
22,500
45,000
67,500
90,000
9:00 24:00
누적 가입자
16. 출시 후 일주일
•산술증가가 아닌 기하급수적 증가
•DAU도 마찬가지로 증가
•4일째부터 주기적 서버 장애
•정말 다양한 원인
•6일만에 120만명 돌파
•Auto Scaling 최대 100대 까지
16
0
375,000
750,000
1,125,000
1,500,000
4/1 4/2 4/3 4/4 4/5 4/6 4/7
누적 가입자
17. 초기 장애 원인
17
Availability Zone-1 Availability Zone-2
Front-end game service
S3 Buckets
EC2 EC2
ELB
RDS (MySQL)
Database group
Mobile Game user
Apple / Google Push
Service
EC2
Game & Server
Monitoring
Auto-scaling
group
EC2
Chef & Git Conf.
Management
Log archives Patches & Game Data
CloudFormation
CloudWatch
Internet
EC2
1.mod_jk pooling failure
2.mod_proxy failure
3.Tomcat JVM OOM
4.Spring MySQL connection pooling
5.GCM push server timeout
6.etc...
1.Master instance failure
2.Slave instance failure
3.Parameter problems (trx, ...)
4.Performance problems
18. 초기 장애 회고
18
• 장애는 위(서버)에서부터 발생하고 문제를 해결해나가면 아래(데이터베이스)쪽으
로 문제가 점점 이동한다
• 초기 장애는 비교적 진단 및 고치기가 쉽지만 후반 장애는 그렇지 못함
• AWS가 직접적인 문제인적은 없었다
• AWS Business Support에 가입하라
• Engineer에 따라서는 AWS외적인 문제 디버깅도 도와준다 (단, 영어)
• 생소한 클라우드 환경에서 문제 발생시 훌륭한 동반자가 되어줌
• 장애를 신속하게 판단 및 해결하는데 필수적
19. 장애의 핵심적인 원인
• 순수한 데이터베이스 부하
• 게임 시작 및 게임 플레이 정산 부하로 데이터베이스 쓰기 폭주
• Checkpoint Age 문제로 쓰루풋 급락이후 장애
• 생명 보내기 기능
• 매 시간마다 N명의 사용자가 M명의 사용자에게 생명을 “받고 보내기”
• 최대 3*24*N*M의 데이터로 데이터베이스 엔트리 급격하게 증가
• MySQL DELETE문의 테이블 락으로 성능 저하
• 데이터 삭제를 하지 않으니 데이터가 무한정 쌓임
19
20. 장애 해결을 위한 초기 시도
• 데이터베이스 샤딩을 알아보았으나 이미 JOIN이나 데이터 종속이 심함
• 급하게 NoSQL 솔루션을 알아보기 시작
• Riak: 사용 경험이 있으나 쓰루풋이 낮음 (AP)
• Couchbase: 성능은 좋아보이나 왠지 상용 버전을 써야할 것 같다 (CP)
• Redis: 사용하기 쉽고 관리하기 쉽고 쓰루풋도 높다 (250Kops/s)
• 선물포인트, 생명 갯수 등의 주요 핫한 기능을 Redis로 마이그레이션
• 급한불은 끄고 데이터베이스 부하 저하
20
21. 초기 서버구조 회고(1)
• CloudWatch, SNS, Zabbix, Statsd + Graphite 의 모니터링 조합
• 초기 서버구조 선택 중에 가장 탁월한 선택: 장애/성능문제 판단에 큰 도움
• 메소드 호출빈도, MySQL, 게임 내 경제 (코인 생성/소멸), 결제 모니터링 등
@Timed(timingNotes = "")
public void earnCoin(int memberSeq, int amount, String fromWhere)
statsdClient.increment("stat.after_play_earned_coin", earnedCoin);
21
22. 초기 서버구조 회고(2)
• EC2 Auto Scaling 으로 API서버의 확장 문제 해결
• 출시 전 AWS의 Instance Limit을 미리 올려놓을것 (기본 20대)
• 개별 인스턴스의 CPU 사용률은 60% 이하로 유지가 안정적
• 평균 CPU 사용량 2분동안 60% 이상 → 인스턴스 2대 증가
• 최대 CPU 사용량 2분동안 80% 이상 → 인스턴스 2대 증가
• 미리 AMI를 빌드하여 인스턴스 부팅부터 서비스 시간을 1분 이하로 줄여놓을 것
• m1.medium, m1.large, m1.xlarge, c1.xlarge 순으로 인스턴스 변경
• 인스턴스는 최대 200대 이하로 유지할 것 (그 이상은 유지관리 비효율적)
22
24. 변경된 사항
• 실시간 로그 검색/분석 - Logstash, Elasticsearch, Kibana
• Logstash로 로그를 집계하여 S3에 저장 (200GB/day)
• Redis - 생명 개수관리, 점수, 선물포인트, 이벤트정보등의 소셜 정보
• 대용량 푸시 서비스 - Python, Celery
• Couchbase - 생명 우편함 등의 대용량 소셜 정보
• 가장 골치거리였던 생명 우편함을 MySQL에서 Couchbase로 마이그레이션
• Redis의 메모리 한계로 점차 Couchbase로 마이그레이션 중
24
25. 현 서버 구조
25
Availability Zone-1 Availability Zone-2
Front-end game service
CloudFront
Edge
S3 Buckets CloudFront Download
Distribution
EC2 EC2
ELB
M S
RDS
EC2 redis instance
Database group
Mobile Game user
Apple / Google
Push Service
EC2
Log Search (real-
time)
EC2
Game & Server
Monitoring
Auto-scaling
group
EC2
Chef & Git Conf.
Management
Log archives Patches & Game Data
CloudFormation
CloudWatch
Internet
Couchbase Cluster
EC2
26. # instances vs. CPU utilization
AWS EC2
• 물리서버와 비교하면 유지관리 시간이 거의 소모되지 않음
• AMI, ELB, EBS 등의 조합으로 확장성있는 고가용 서버 구축 가능
• ELB는 정말 무한한 확장 가능, 안정성 문제 단 한번도 없어
• Auto Scaling
• Scale out 임계치를 잘 설정하는것이 중요 (3개월 정도 튜닝 소요)
• 장애가 일어난 노드를 알아서 대체함
• 설정만 잘 해놓으면 더이상 신경쓸일 없음
• 이와같은 환경 설정에는 CloudFormation이 가장 편함
26
27. AWS S3, CloudFront
• S3, AWS 서비스 중에서 단연 최고의 서비스
• 응용 범위가 매우 다양함
• 정적인 파일 저장 및 제공은 S3와 CloudFront CDN으로 모두 해결 가능
• S3의 데이터 내구성 99.999999999%, 가용성 SLA 99.9%
• 하지만 응답속도와 변수를 줄이기 위해 가능한 CDN을 쓰는게 필수적
27
28. AWS RDS
• Replication, Backup 등을 알아서 관리해주는 매우 편리한 서비스
• 온라인 상태에서 데이터베이스 사양 Scale-up 가능
• 온라인 상태에서 IOPS 증가 가능 (Max 30,000 IOPS)
• 하지만 사양 변경은 꼭 테스트 후에, 가능하면 새벽 시간에 할 것
• 하드웨어/소프트웨어 장애를 대비하여 Multi-AZ 옵션 필수적
• MySQL 5.5 의 경우 Master Failover시 Slave Replica가 깨지는 경우가 발생
• RDS MySQL 5.6에서 해결
28
29. Redis
• 설치하기 쉽고 쓰기 간편. 쓰기성능도 매우 훌륭
• 데이터구조를 많이 지원하기 때문에 Leaderboard 등 개발 시 매우 편리
• 하지만 MySQL과 마찬가지로 부하 증가시 수동 샤딩등의 방법을 고안해야
• 메모리를 넘어서는 데이터에 대해서는 답이 없음
• 성능 유지를 위해서는 많은 신경을 써야함
• Fork Latency가 메모리를 많이쓸수록 증가하므로 마스터에서는 하면 안됨
• 읽기분산을 위해서 디스크 저장용 별도 인스턴스를 유지해야
• 최근 ElastiCache가 지원하기 시작
29
31. 비용 측면에서의 AWS
• 단순 서버 vs EC2 비교의 경우 Reserved Instance 를 꼭 고려해야
• 로드밸런서, 방화벽, 운영체제 설치 및 설정은?
• 고가용성 정적 파일 호스팅을 구현하는 비용 (CDN 계약?)
• 데이터베이스 관리는 누가? (Replication, Backup, Monitoring)
• 필요시 바로 서버를 이용할 수 있다는 것 vs 2주 이상 기다려야한다는 것
• Capex vs Opex: 운영비용과 자산비용의 차이
• 혼자 서버를 관리한다면 어떤것을 선택할 것인가?
31
32. 비용의 진실
• 전통적인 인프라의 관점으로 바라보면 결코 저렴하지 않은 AWS
• 그러나 AWS에서 제공하는 다양한 서비스를 활용한다면 훨씬 비용/시간 효율적
• Pay-as-you-go & Pay-per-only-what-you-use 의 Smart Metering
• 트래픽 증감에 따라 EC2가 Auto Scale; 정확히 사용한 것만 지불하여 비용 절감
• 한 대에서 200대까지 Scale out을 해야한다면 AWS를 사용해야
• EC2 Reserved Instance 요금제로 비용 최적화
• 급격하게 변하는 모바일 게임 시장, AWS는 필연적인 선택
•
32
33. 비용의 진실
• 전통적인 인프라의 관점으로 바라보면 결코 저렴하지 않은 AWS
• 그러나 AWS에서 제공하는 다양한 서비스를 활용한다면 훨씬 비용/시간 효율적
• Pay-as-you-go & Pay-per-only-what-you-use 의 Smart Metering
• 트래픽 증감에 따라 EC2가 Auto Scale; 정확히 사용한 것만 지불하여 비용 절감
• 한 대에서 200대까지 Scale out을 해야한다면 AWS를 사용해야
• EC2 Reserved Instance 요금제로 비용 최적화
• 급격하게 변하는 모바일 게임 시장, AWS는 필연적인 선택
• 저렴하고 확장성있는 서버보다 성공하는 게임을 만드는게 훨씬 어렵다.
재미있는 게임을 만들 수 있도록 기능개발 자체에 투자를 해야.
33