쿠키런 사례
댓글 남기기
KGC2013 을 참가 했었는데
이틀째 세션에는 아마존을 활용한 쿠키런 사례? 비슷한게 있었는데 개발쪽 세션입니다.
결론 부터 말하자면 대략적으로 AWS에서 자동화를 통해서 쿠키런을 운영할 수 있었다.
혼자서 서버 개발과 운영을 해야 했고 할 수 있었다.
발표 내용
서버 개발자 자기 포함2명인데 한명은 나가기로 예정되어있어서
결국적으로는 1명. 개발 / 운영을 해야되었다.
어디를 선택할지에 대해서 지인들에게 문의를 많이했었고 이런 결과를 얻게되었다.
- 서버 IDC 입주를 고려 했었는데 선은 어디 쓰지 IDC가서 설치는 누가 하지 영세한 게임 회사로써는 여러가지 문제들이 꽃피움 그래서 IDC제외
- 한국 클라우드 서비스를 하는 벤더들의 대한 신뢰 없음
- ELB가 뻗는 경우가 있었다라는 말을 함.
- 하청을 주는데 하청이 거지 같더라
- 그래서 한국 벤더 제외
여기서 부터 AWS에 극찬이 시작됨 못하는게 없다라는 식인데 오오 하며 흥미를 갖고 보게됨
AWS
- 다양한 서비스 제공
- 모든 서비스는 API로 제어가 가능 (API를 제공하는 언어도 많음)
- auto scaling, ELB, S3 등이 매력적이였다.
자동화 하기 위해서 사용한 방법
- CloudFormation : 예를 들면 디비를 만들고 웹서버 5대를 붙여 라는걸 자동으로 해주게 끔 만들고
- Chef : 아파치 한대를 열고 쿠키런 웹서버를 띄우고 방화벽 설정을 뭘로 잡고 이런걸 json 이나 소스코드로 인프라를 관리
- 위에 두개를 git 을 통해서 관리
- git 을 통해서 관리하니 서버의 변화라던지 설정의 형상 관리를 할 수있었다.
꼭 사용 하라고 하는것
- ELB, Auto Scaling 을 꼭 사용해라 그리고 CloudFormation 을 통해서 구현
- S3를 사용해서 게임 데이터를 제공하자 -> Ex: 신규 텍스쳐 사운드를 다운받도록 할 수 있다.
- 모니터링은 확실하게 하자 -> 모니터링 툴을 통해서 하도록 하자
쿠키런 출시 초기
- 첫날 9만 가입
- 6일 120만 가입
- 기하급수적으로 증가 auto scaling 100대가 넘는 상황
- 잘되던 환경에서 온갖 문제들이 터지기 시작함.
- 푸쉬를 보낼때마다 GCM push 서버가 5초간 응답이 없다고 했나 뭐 어쨋든
- 마스터 인스턴스가 죽기도하고 슬레이브가 깨지기도 하고 트렌젝션 관리라던지
- 기타 등등
장애의 회고
- AWS의 직접적인 문제는 없었다.
- AWS Bisiness Support 에 가입하라
- 돈은 비싸지만 장애시 유일한 동반자가 되었다.
- Engineer 에 따라서 AWS 외적인 문제도 도와주었다. (단 영어로)
- 장애를 신속하게 파악 판단 및 해결 하는데 필수적이다.
장애의 핵심적인 원인
- 순수한 데이터베이스 부하
- 게임 시작 및 게임 플레이 정산 부하로 데이터베이스 쓰기 폭주
- Checkpoint Age 문제로 throughput 급락 이후 장애
- 생명 보내기 기능 ( 기획의 일부)
- 매 시간 마다 N명의 사용자가 M 명의 사용자에게 생명을 “받고 보내기”
- 최대 3* 24*N* M 의 데이터로 DB 엔트리 급격하게 증가
- MySQL Delete 문의 테이블 락으로 성능저하
- 데이터를 삭제 하지 않으나 데이터가 무한정 쌓임
장애 해결을 위한 기초시도
- 이미 JOIN 이나 데이터 종속이 심하다
- 급하게 NoSQL 솔루션을 알아보기 시작
- Riak : 사용자 경험이 있지만 throughput이 낮음
- Couchbase : 성능은 좋아 보이나 왠지 사용버전을 써야 할것 같다.
- Redis : 사용하기 쉽고 관리하기 쉽고 throughput도 높다.
- 선물 포인트 생명 갯수 등은 redis 으로 마이그레이션
- 급하게 NoSQL 솔루션을 알아보기 시작
노하우의 느낌
- 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대로 이하로 유지할 것 (이 이상은 관리를 하는데 있어서 비효율적이였다)
- 실시간 로그 검색 / 분석 ElasticSearch
- 대용량 푸쉬 python, Celery
- CouchBase – 생명 우편함 등의 대용량 소셜 정보
- Redis 의 메모리 한계로 인해서 CouchBase 로 점차 변경중
- 유지 보수를 하지말아야하고 최대한 자동화를 통해서 아마존을 활용해야 한다.
- AMI, ELB, EBS 등의 조합으로 확장성 있는 고가용 서버 구축 가능
- S3, CloudFront -> 정적인 파일 저장 및 제공은 S3와 CloudFront (CDN)으로 모두 해결 가능
아마존 기능 설명
AWS RDS
- Replication,Backup 등을 알아서 관리해주는 편리한 서비스
- 데이터 베이스 Scale-up 가능
- 온라인 상태에서 IOPS증가 가능
- 사양 변경은 꼭 테스트 후에 , 가능하면 새벽 시간에 할 것
- 장애에 대비하여 Muiti-AZ 옵션 필수적
- MySql 5.5 의 경우 Master Failover 시 Slave Replica 가 깨지는 경우 발생
- RDS MySQL 5.6 에서 해결
Redis
- 설치하기 쉽고 쓰기 간편, 쓰기 성능도 매우훌륭
- 데이터 구조를 많이 지원 LeaderBoard 등 개발시 매우 편리
- 메모리를 넘어서는 데이터에 대해서는 답이 없음
- 최근 ElastiCache로 redis 를 지원하기 시작
AWS 와 IDC의 가격 비교
- 단순 서버 vs EC2 비교의 경우 Reserved Instance 를 꼭 고려해야 3년정도 예약하면 반값정도 할인해준다
- 로드벨런서 ,방화벽, 운영체제 설치 및 설정을 하려면 IDC에 가서 삽질 시작해야되지만 AWS은 필요없다. 마우스로 해결할 수 있다.
- 고가용성 정적 파일 호스팅을 구현하는 비용 CDN 은 누구랑 계약 해야 하나. 기타등등
- DB관리 Replication, Backup, Monitoring 는 누가? 누가하지?…를 고려해야 된다.
- 필요시 바로바로 서버를 이용 할 수 있다. vs IDC는 2주 이상 기다려서 서버를 넣어야된다.
- Capex Vs Opex : 운영비용과 자산비용의 차이
- 혼자 서버를 관리 한다면 어떤것을 선택할 것인가?
비용의 진실
- 전통적인 관점으로 바라보면 저렴하지 않은 AWS이다.
- 그러나 AWS에서제공하는 다양한 서비스를 활요한다면 훨씬 절약
- 트레픽 증감에 따라서 EC2가 Auto Scale ; 정확히 사용한 것만 지불하여 비용절감
- 1대에서 200대 까지 Scale out 을 해야 한다면 ? AWS를 사용해서는 200대 까지는 한번도 문제가 없었다.
- EC2 Reserved Instance 요금제로 비용을 최적화 -> 예약을 하면 비용을 줄일 수 있다.
- 급격하게 변하는 모바일 게임 시장, AWS는 필연적 선택
- 저렴하고 확장성있는 서버보다 성공하는 게임을 만드는게 훨씬 어렵다.
- 재미있는 게임을 만들 수 있도록 기능 개발 자체에 투자를 해야. -> 설정 복잡하게 하는 시간에 재미있는 게임 만들도록 하자
사용자가 늘어남에 따라서 지속적인 마이그레이션을 통하였고
mysql -> redis -> couchbase 로 변화중
이상이 발표를 적은 내용 … 입니다.