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로

테이블 정의서도 없다

움직이는 것이 최신 사양