1. ASP.NET과 C#으로 개발
하는 대규모 소셜 게임

2. 위 문서를 참고로한 번역&정리. 문서 url은 기억나지 않네요 ;;;

4. 서비스 구성
 2010년 2월부터 게임 제공 개시
 제공 타이틀: 17개(2012년 4월 현재)
 회원 수: 1500만명
 월간 PV: 146억

6. 막대한 트래픽 량
 릴리스 후 5시간 동안 10만명 등록
 릴리스 후 1개월 동안 100만명 등록
 1 타이틀에서 65만 DAU (Daily Active User)
 3.5억 PV/일 (단순 계산으로도 4000req/sec)
 이벤트 개시 직후에 8만 명 동시 접근

7. 클라스터에 걸리는 부하
 동시 세션 수: 40만 이상
 HTTP 리퀘스틔 15만 req/sec
 전송량: 3Gbps (이미지 리소스는 제외)
 DB 서버: 피크 시에는 20만 query/sec

8. 시스템 구성
 개발 언어: 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

9. 시스템 구성 배경
 C#이 좋아서
 그래도 MS가 좋다는 것은 아니다
 처음에 3명 밖에 없었다
 높은 트래픽 정보가 압도적으로 적다
 결과 Windows + Linux 하이브리드 구성

10. IIS + ASP.NET은 빠르다 !
(Linux 서버 엔지니어의 말)

11. 인프라 구성
 심플한 구성
 대수는 1년반만에 1000대 이상

12. 게임 타이틀 하나 당 규모 예
 로드 밸런스: 40대
 AP 서버: 100대
FP용: 40대, SP용: 40대, Flash 합성: 20대
 memcached: 4대, Redis: 4대
 DB 서버: 3~5대

13. AP 서버
 소셜 게임의 처리는 스테이트레스
 스케일은 비교적 쉽다
 대수가 많기 때문에 디플로이(배포)에 시간이 걸린다

14. 구현상 주의할 점
 장대한(복잡한) 처리를 하지 않는다.
 데이터 접근 최적화
 처리의 비동기화
 페이지 사이즈 최적화(100KB 제한)
 C#으로 할 수 있는 것은 C#으로(LINQ를 사용하면 좋다)

15. 복잡한 처리 모니터링
 1 리퀘스트 내에서 DB 접근 수
 KVS 접근 수
 외부 API 리퀘스트 수

16. DB 기본 동작 이해도 중요
 Disk Read 발생을 시키지 않는다
 시퀀셜/임의 접근
 인덱스 동작
 정렬 처리
 체크 포인트 처리

17. DB 부하 경감을 위해서
 KVS 이용
 수직 분할과 수평 분할
 고속 flash storage 도입

18. DB 분할에 대해서
 수직 분할
테이블을 기능 단위로 분할
JOIN은 하지 않는다
 수평 분할
같이 테이블을 Key에 의해서 분할
Range Partitioning / Hash Partitioning

19. 계속적 개선
 ideas -> build -> code -> measure -> data -> learn의 반복
 Learn Faster를 중심으로
 구현이 목적이 아니다
 최단 명 애플리는 1주일 만에 클로즈

20. 운용 스타일
 데이터 분석을 중시한 개선 프로세스
 각종 KPI 수치. DAU, ARPU, 계속률
 동향 파악을 빠르게 (Monthly/Daily/Hourly)
 종속적 디플로이

21. 고속 PDCS를 실현하는 개발
 문서를 적지 않는다
 기본 사항만을 Wiki로
 테이블 정의서도 없다
 움직이는 것이 최신 사양