모바일 RPG 웹 서버 제작

1. 천기환/gujjy97@gmail.com

2.  Java 웹 개발자
 Spring framework를 주무기로
 SI로 시작, 업무 도메인을 자주 바꾸는게 싫어서
어쩌다 게임 개발로 전향
 도메인만 게임으로 바뀌었고 기술 스택은 그대로

3.  사용했던 기술요소를 나열
 기술요소 선정했던 이유를 나열
 답이 아니에요
 아쉬움을 덜어내려고…
 기억이 정확하지는 않아요...

5.  웹서버 35대
•4Core / 8G Ram
 DB 6대
•16Core / 32G Ram
 redis 20대
•4Core / 16G Ram
 memcached 4대
•4Core / 16G Ram

6.  Game Server : AJP/1.3 Tomcat
•Tomcat 안정적인 소켓 연결
•Service Port fix
•80 -> 8009 or 8010
•mpm : process + worker
•간단한 접근 제어
•필요한 기능만 compile 설치
•mod_dumpio : network packet 분석
 Monitor 서버 : php 연동

7.  memcached session manager(MSM)
•session clustering
•remote cache
 Non sticky Session
•비동기 요청없도록 협의
•HttpSession is not thread-safe
•MSM lock (max 5 seconds)
 최대 5초 안으로 처리하고 memcached에 저장해야함
 JmxRemoteLifecycleListener
•방화벽, port 고정 필요

8.  access log : apache vs tomcat
•apache
 대부분 2초 아래
 간헐적으로 응답시간 이상
 응답 packet size 에 따라 응답시간이 증가하는 폭이 큼
•tomcat : 최대 0.4 초
 apache-ajp 외부 네트워크와 tomcat사이에서
버퍼 역할을 담당

9.  좋은 건 써봐야
 G1GC
•CPU는 조금 더 먹고
•조금 더 안정적
 Lambda
 Stream
 가독성 논란 : 쓰고 싶은 사람만 쓰기로

10.  profile
•서버군별 다른 설정 적용
 module
•로직과 실행환경에 따른 모듈을 분리
•core / web / simulator / admin
 plugin
•resources, tomcat, git, ant, svn, groovy

11.  최대한 최근 버전: 기능 향상 기대
 JSON RestFul API 통신
•MessageConverter
•Gson vs Jackson
 성능 : jackson사용시 CPU가 미세하게 튀는 듯
 JSON 변환이 앱 전체에 큰 비중이 없는지 성능차 없음
 앱 특성에 따라 library 검토는 해봐야...
 Java Configuration
•profile에 따른 설정파일을 줄임

12.  기본적인 spring 설정
 Core 모듈로 시뮬레이션 CLI 앱 제작
•미리 모듈화 해야
 Schedule 앱 제작
•환경제약으로 DB에 스케쥴 적용

13.  단계축소
•DB -> SP -> XML -> Java Instance
•관리 소스 감소
 성능 향상
 Simple Immutable instance
•no getter, all argument constructor
 MyBatis cache -> Spring cache

14.  성능 (log4j2 는 아직..)
 Sl4j를 통해 모든 로그 모아
 AsyncAppender
 logback.groovy
•xml에 비해 custom한 설정
•변수 사용, 문자열 조작

15.  Test를 사랑해야..
 Junit, Mockito
 단위 테스트보다 시나리오 테스트 위주로
 변경에 확신
•library 바꿀 때
•filter등 공통모듈 적용할 때

16.  L4: Non Sticky Load Balancing
•remote session store
 개인 컨텐츠 관련 데이터 모두 Session에 캐싱
•select 부하 감소
•CAS(Check And Save)

17.  chunk : key – value 저장 단위
 slab
•일정 크기 범위에 chuck를 담는 단위(1KB,
1.25KB, 1.56KB...)
•1 chunk -> 1 slab
 page : slab을 모아두는 단위 (1MB)
•1KB slab * 1024 = 1 page
•2KB slab * 512 = 1 page
•page 단위로 미리 slab을 생성
 주기적인 모니터링이 필요

18.  랭킹 서버 (zhash)
 simple shared cache
•캐릭터 이름/레벨/소속 길드 등
 구성
•sentinel 3
•master 1 / fail over slave 1
•read only replica slave 2~
 Client library
•Jedis
•read/write 분리한 RedisConnectionPool 사용

19.  DB 분할
• Device DB(Single) : 샤딩 기준
• User DB(Shared)
 개인 컨텐츠 저장
• Social DB(Single)
 길드 / 친구 / 랭킹 원본 정보
 실시간 랭킹을 redis로
 Stored Procedure(T-sql)
• DBA 협업
 JTA
• atomikos -> ChainedTransactionManager
 Profile로 개별 session 상태 분석 후 connection 설정 확인 필요

20.  단순한 반복작업, 명령어 모음
 groovy
•API 시나리오 테스트
•nGrinder용 스크립트 호환
•gmaven vs groovy-maven : stub 생성 차이
 bash
•ssh로 동시 여러서버 일괄제어
 batch
•SQLCMD, BCP를 사용한 DB작업 자동화

21.  Gradle 지원때문에 STS에서...
 code cache / 중복코드 알림
 단축키 적응
•테스트 생성, 인터페이스 구현!!!
 Maven 해석 방식이 다른 듯
 CRLF, charset 변경이 간편

22.  강력한 브렌치
•배포 서버군이름을 브렌치로(dev, qa, live...)
•기능을 브렌치로
 gerrit 리뷰
•리뷰하며 공유
 학습비용 높아
•rebase 꼬이면 지옥
•windows 환경에서 git-bash 사용 어색

23.  무료 부하 테스트 툴
 groovy로 작성
•java로 구현한 Core로직이나 상수를 재정의하기
귀찮...
 관련 서버 모니터링 가능
 시나리오 변경 후 배포 및 테스트까지 시간이 많
이 걸림

24.  HP-JMeter : GC 로그 분석
 MAT : heap dump 분석
 Thread-logic : Thread dump분석
 JMC(java mission control)
• 위에 것들 실시간으로
• jconsole 보다 보기 좋음
• JMX 클라이언트
 Dtrace
• java vm으로 접속, method/line 호출 확인
• 자주 호출되는 부분에 걸면 부하 급상승! 조심!

25.  관련성 있는 것끼리 모듈화
 클래스에 메서드 과다하지 않게
 복붙은 프로그래밍이 아냐
 자기테스트는 필수
 코드리뷰는 과외가 아니야
 IDE와 단축키는 개발 리듬을 살려
 모니터링 할 이유가 그다지
 성능테스트보다 실 동시접속이 나오지 않음
 앱 성능은 머신을 추가해서 극복!

26.  API로그를 남겼으면...
 차트 자료를 남겼으면...
 API 문서 자동생성
•서버/클라이언트 통신소스 자동생성