ASP.NET과 C#으로 개발 하는 대규모 소셜 게임
ASP.NET과 C#으로 개발하는 대규모 소셜 게임
위 문서를 참고로한 번역&정리. 문서 url은 기억나지 않네요 ;;;
서비스 구성
2010년 2월부터 게임 제공 개시
제공 타이틀: 17개(2012년 4월 현재)
회원 수: 1500만명
월간 PV: 146억
막대한 트래픽 량
릴리스 후 5시간 동안 10만명 등록
릴리스 후 1개월 동안 100만명 등록
1 타이틀에서 65만 DAU (Daily Active User)
3.5억 PV/일 (단순 계산으로도 4000req/sec)
이벤트 개시 직후에 8만 명 동시 접근
클라스터에 걸리는 부하
동시 세션 수: 40만 이상
HTTP 리퀘스틔 15만 req/sec
전송량: 3Gbps (이미지 리소스는 제외)
DB 서버: 피크 시에는 20만 query/sec
시스템 구성
개발 언어: ASP.NET + C# (.NET Framework 4)
데이터베이스: SQL Server 2008 R2
Application 서버: IIS 7.5
load Balancer (Web 서버): nginx
KVS (Key Value Store): memcached, Redis
이미지 리소스 배신: CDN + Varnish + nginx
시스템 구성 배경
C#이 좋아서
그래도 MS가 좋다는 것은 아니다
처음에 3명 밖에 없었다
높은 트래픽 정보가 압도적으로 적다
결과 Windows + Linux 하이브리드 구성
IIS + ASP.NET은 빠르다 ! (Linux 서버 엔지니어의 말)
인프라 구성
심플한 구성 대수는 1년반만에 1000대 이상
게임 타이틀 하나 당 규모 예
로드 밸런스: 40대
AP 서버: 100대 FP용: 40대, SP용: 40대, Flash 합성: 20대
memcached: 4대, Redis: 4대
DB 서버: 3~5대
AP 서버
소셜 게임의 처리는 스테이트레스
스케일은 비교적 쉽다
대수가 많기 때문에 디플로이(배포)에 시간이 걸린다
구현상 주의할 점
장대한(복잡한) 처리를 하지 않는다.
데이터 접근 최적화
처리의 비동기화
페이지 사이즈 최적화(100KB 제한)
C#으로 할 수 있는 것은 C#으로(LINQ를 사용하면 좋다)
복잡한 처리 모니터링
1 리퀘스트 내에서 DB 접근 수
KVS 접근 수
외부 API 리퀘스트 수
DB 기본 동작 이해도 중요
Disk Read 발생을 시키지 않는다
시퀀셜/임의 접근
인덱스 동작
정렬 처리
체크 포인트 처리
DB 부하 경감을 위해서
KVS 이용
수직 분할과 수평 분할
고속 flash storage 도입
DB 분할에 대해서
수직 분할 테이블을 기능 단위로 분할 JOIN은 하지 않는다
수평 분할 같이 테이블을 Key에 의해서 분할 Range Partitioning / Hash Partitioning
계속적 개선
ideas -> build -> code -> measure -> data -> learn의 반복
Learn Faster를 중심으로
구현이 목적이 아니다
최단 명 애플리는 1주일 만에 클로즈
운용 스타일
데이터 분석을 중시한 개선 프로세스
각종 KPI 수치. DAU, ARPU, 계속률
동향 파악을 빠르게 (Monthly/Daily/Hourly)
종속적 디플로이
고속 PDCS를 실현하는 개발
문서를 적지 않는다
기본 사항만을 Wiki로
테이블 정의서도 없다
움직이는 것이 최신 사양