쿠키런 사례

카테고리 없음 2014. 4. 21. 18:18 Posted by 초절정고수

쿠키런 사례

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 으로 마이그레이션

노하우의 느낌

  • 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 로 변화중

이상이 발표를 적은 내용 … 입니다.