[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버Heungsub Lee
NDC14에서 발표한 "[야생의 땅: 듀랑고] 서버 아키텍처" 세션의 슬라이드입니다.
슬라이드에 설명이 많지 않은데, 디스이즈게임에서 발표 내용을 잘 정리해주었습니다. 기사도 함께 보시면 좋을 것 같습니다.
http://www.thisisgame.com/webzine/news/nboard/4/?n=54955
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버Heungsub Lee
NDC14에서 발표한 "[야생의 땅: 듀랑고] 서버 아키텍처" 세션의 슬라이드입니다.
슬라이드에 설명이 많지 않은데, 디스이즈게임에서 발표 내용을 잘 정리해주었습니다. 기사도 함께 보시면 좋을 것 같습니다.
http://www.thisisgame.com/webzine/news/nboard/4/?n=54955
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...Amazon Web Services Korea
서비스 런칭을 위해 라이온하트와 카카오게임즈가 어떻게 최적 성능의 인스턴스를 선택하고, Windows 운영 체제를 최적화하며, 왜 Amazon Aurora를 기본 데이터베이스로 채택하였는지를 설명합니다. 또한, 출시부터 운영까지의 과정에서 MMORPG가 어떻게 AWS 상에서 설계되고, 게임 서버 성능을 극대할 수 있었는지에 대해 전달해드립니다.
오픈 소스 Actor Framework 인 Akka.NET 을 통해 온라인 게임 서버를 어떻게 구현할 수 있는지를 설명합니다. Actor Model 에 대한 기본 이해부터 Scale-out 가능한 게임 서버 구축까지 전반적인 내용에 대해 알 수 있습니다. 설명을 위해 클라이언트는 Unity3D 를 사용할 예정입니다.
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...Amazon Web Services Korea
서비스 런칭을 위해 라이온하트와 카카오게임즈가 어떻게 최적 성능의 인스턴스를 선택하고, Windows 운영 체제를 최적화하며, 왜 Amazon Aurora를 기본 데이터베이스로 채택하였는지를 설명합니다. 또한, 출시부터 운영까지의 과정에서 MMORPG가 어떻게 AWS 상에서 설계되고, 게임 서버 성능을 극대할 수 있었는지에 대해 전달해드립니다.
오픈 소스 Actor Framework 인 Akka.NET 을 통해 온라인 게임 서버를 어떻게 구현할 수 있는지를 설명합니다. Actor Model 에 대한 기본 이해부터 Scale-out 가능한 게임 서버 구축까지 전반적인 내용에 대해 알 수 있습니다. 설명을 위해 클라이언트는 Unity3D 를 사용할 예정입니다.
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
어느날 우연히 스위처 소방수로 참여해서 2달 동안 수행한 일들을 공유합니다. 그 첫번재 이야기 ‘기본을 지키자’ 입니다.
전체를 리드하면서 업무를 진행해본 첫 경험이기도 했고, 유저가 증가하며 서비스되고 있는 프로젝트를 A to Z로 혼자 감당해본 첫 경험이기도 했습니다.
새로운 서버를 설계하고 개발하면서, 레거시 안정화 및 이슈 응대를 모두 병행하는게 쉬운 일은 아니었지만, 핑계대지 않고 하나하나 기본을 다져 보았습니다!
아직 갈길이 멀었지만, 성장해가는 아이오(스위처)의 소프트웨어 이야기를 하나씩 하나씩 풀어보려 합니다 ;)
Unite'17 Seoul 아이펀팩토리 발표자료
1. 강연주제: 클라이언트 개발자, 서버 개발 시작하기
2. 강연자: 박근환 TD
3. 강연소개: 이 세션은 주로 게임 클라이언트 개발자로 경력을 쌓아오던 개발자가 게임 서버 솔루션 회사에서 일하면서 알게된 사실들을 바탕으로, 클라이언트 개발자가 서버 개발을 시작하려면 필요한 것들이 무엇인지, 어떻게 시작해야 하는지에 대하여 이야기합니다.
Auto Scalable 한 Deep Learning Production 을 위한 AI Serving Infra 구성 및 AI DevOps...hoondong kim
[Tensorflow-KR Offline 세미나 발표자료]
Auto Scalable 한 Deep Learning Production 을 위한 AI Serving Infra 구성 및 AI DevOps Cycle 구성 방법론. (Azure Docker PaaS 위에서 1만 TPS Tensorflow Inference Serving 방법론 공유)
(GameTech2015) Live Operation by Adbrix의 Node.js와 MongoDB를 이용한 멀티테넌트 인프라 구축사례Jeongsang Baek
대부분의 중소 모바일 게임 업체는 앱을 잘 만들기에도 시간이 모자라 출시일을 잘 맞추기 급급한 상황이다. 그러다 보니 운영을 위한 툴은 소홀히 개발하는 경우가 대부분이고 운영 캠페인은 날림으로 개발하거나 그때 그때 개발자가 필요한 부분만 개발하기 일쑤다. 그러다보니 마케터는 결국 늘 개발자 눈치만 살피게 된다. 필자는 블루윈드에서 이러한 문제를 절감했고 '모바일 게임 개발사가 앱 개발에만 집중할 수 있게 해주고 싶다'는 IGAworks의 철학에 공감하여 라이브 오퍼레이션 프로젝트를 시작하게 되었다.
라이브 오퍼레이션의 개발 중점과제는 5가지였다. 첫번째, 다수의 개발사가 하나의 큰 클라우드 시스템을 사용하도록 multi-tenant 인프라를 구축해야 한다. 두번째, TCO(Total cost of ownership)를 최소화해야 한다. 세번째, 앱의 핵심유저를 실시간으로 그룹화하여 타게팅 캠페인을 할 수 있어야 한다. 네번째, 캠페인의 성과를 마케터에게 실시간으로 피드백해야 한다. 다섯째, 3개월 안에 정식 서비스가 되어야 한다는 점이었다. (왜 우리에게 주어지는 시간은 늘 3개월인가) 그리고 당연하지만 이 서비스를 혼자 개발해야 했다.
이 다섯가지 이슈를 해결하기 위하여 AWS 클라우드 상에 생산성과 성능이 검증된 node.js 와 mongodb를 이용하여 서비스 백엔드를 구성하였고, multi-tenant를 구성하기 위한 여러가지 고민과 그 해결책을 직접 구현하였다. 필자는 node.js와 mongodb를 사용해 본 경험이 충분하다 생각했지만 대규모 정식 서비스를 진행하며 많은 함정에 빠졌고 결국 해결했다.
이 발표를 통해 청강자는 node.js와 mongodb를 이용하여 multi-tenant 인프라를 구축해야 할 때 고려해야 할 설계 방식과 기술적인 고민, 그것에 대한 현실적인 해법을 얻을 수 있다.
7. 발표의 초점
‘어떻게’가 아니라 ‘무엇’을 해야하는지
할 일의 목록을 알 수 있다면
• 계획을 세우기 쉽고, 일정 산출에 도움
• 후반 작업에서의 체크리스트
• 공부할 때 찾아볼 수 있는 키워드
• 서버 개발 업무 전반에 대한 이해
<ONE PUNCH-MAN>
8. 목차
1. 최초의 의사결정
2. 기반구조 보강
3. 게임 컨텐츠 구현
4. 스케일아웃
5. 출시 준비
6. 무점검 스케일아웃
7. 부하테스트
8. 장애 안정성
9. 예측 실패 대비
10. 출시 이후
더 안정된 라이브 서비스를 위해 필요한 것들
상용 서비스 혹은 대규모 서비스에 필수적
모든 프로젝트 공통
취미나 프로토타입이라면 보통 여기까지
10. 1. 최초의 의사결정
서버의 용도, 장르
사용자 규모
통신 환경
데이터 손실 허용성
데이터 저장소
언어
운영체제
11. 1. 최초의 의사결정
서버의 용도, 장르
사용자 규모
통신 환경
데이터 손실 허용성
데이터 저장소
언어
운영체제
서버의 요구 사항에 관한 질문들
• 가장 중요하며, 이후 의사 결정들의 근거가 됨
12. 1. 최초의 의사결정
서버의 용도, 장르
사용자 규모
통신 환경
데이터 손실 허용성
데이터 저장소
언어
운영체제
• 서버 한대로 커버할 수 있는지, 아닌지?
• DB 한대로 커버할 수 있는지, 아닌지?
(4장 미리 살짝)
• 봉투 뒷면 계산법을 통해 계산
• Scale-out 전략과 서버간 통신 여부에 영향
https://brunch.co.kr/@gimmesilver/5
13. 1. 최초의 의사결정
서버의 용도, 장르
사용자 규모
통신 환경
데이터 손실 허용성
데이터 저장소
언어
운영체제
서버에서 먼저 클라를 호출하는 경우가
• 빈번한지, 적은지, 없는지
어느 정도 지연 시간이 허용되는지
• 네트워크 프로토콜에 영향 (http, tcp, udp)
쉽게 하려면 http
• 모바일 환경에 강하고 다루기 쉽다.
• Long polling 으로 양방향 통신도 가능
• 지연시간 길어서 장르 제한
14. 1. 최초의 의사결정
서버의 용도, 장르
사용자 규모
통신 환경
데이터 손실 허용성
데이터 저장소
언어
운영체제
저장소의 강점들은 트레이드 오프 관계
• 구현하는 기능의 용도와 제약 조건에 맞는지 판단해서 결정
RDB ACID 보장으로 안정된 로직 구현
스키마 덕분에 잘못 사용할 때의 위험이 적음
Redis 높은 처리량 (~ 100K rps 스케일)
다양한 자료구조, pub-sub, expire 유용함
낮은 persistence. 데이터 오염에 취약
S3 비용 저렴, 용량 제한 X, 데이터 손실 X
높은 레이턴시 (수백 ms)
← 비교 기준
15. 1. 최초의 의사결정
서버의 용도, 장르
사용자 규모
통신 환경
데이터 손실 허용성
데이터 저장소
언어
운영체제
동적 타입 언어 vs. 정적 타입 언어
높은 생산성 낮은 오류, 유지 보수 안정성
작고 기민한 조직 대규모 협업에 유리
다른 선택 기준
• 빌드 시간은 이터레이션 주기와 업무 집중도에 영향
• 클라와 동일한 언어는 기능 이전과 업무 배분에 유리
C# 좋아요
• 구현 편리, 유지 보수 안정성 좋음
• 빌드 빠르고 Unity 엔진과 협업 편리
• 윈도우 서버라면 추천
<xkcd>
16. 1. 최초의 의사결정
서버의 용도, 장르
사용자 규모
통신 환경
데이터 손실 허용성
데이터 저장소
언어
운영체제
서버 개발자 하려면 리눅스 꼭 필요한가요?
• 리눅스 잘 다루면 좋지만 “기술적으로” 필수는 아님
윈도우 vs. 리눅스
Visual Studio 개발 환경 편리 라이브 할 때 서버 비용이 저렴
게임 클라이언트를 같이 실행하기 좋음 유틸리티 활용 이점, 터미널 작업 편리
윈도우 개발 환경 + 리눅스 빌드
• 양쪽의 장점을 살릴 수 있을 수 있지만 방식에 따라 추가 비용 발생
1. MSVC, GCC 빌드를 모두 지원 : 초기 셋팅이 어려움, 미묘한 동작 차이
2. 리눅스를 가상 머신으로 구동 : 개발 다소 불편, 이터레이션 타임 길어짐
3. WSL, clang 활용 : 저도 궁금한데 해보지 않아서..
18. 2. 기반구조 보강
프로토콜
DB 추상화
데이터 동시성
시간 처리
알아 두면 유용한
• 로직 구현을 쉽게 해주고
• 오류 방지에 도움 주는 구조들
19. 2. 기반구조 보강
프로토콜
DB 추상화
데이터 동시성
시간 처리
서버 ↔ 클라 프로토콜은 생각보다 자주 변경하게 됨
• 수정이 번거롭고, 찾기 힘든 오류의 원인이 되기도
• 수작업을 피하는게 생산성 향상에 도움
자동화 구현 방향
1. C++ 템플릿, 언어별 기능으로 구현
2. 코드 생성
3. 프로토콜 타입을 Json 인코딩
4. ProtoBuf
20. 2. 기반구조 보강
프로토콜
DB 추상화
데이터 동시성
시간 처리
코드 생성을 DB 접근 추상화에 활용해서
1. 잘못 사용할 수 있는 케이스를 최대한 차단하자
2. 기계적으로 생성 가능한 로직은 다 자동 생성하자
NDC2018 <실버바인 서버 엔진 2 설계 리뷰>
21. 2. 기반구조 보강
프로토콜
DB 추상화
데이터 동시성
시간 처리
낙관적 동시성 제어 vs 비관적 동시성 제어?
• 실버바인 서버엔진 2는 분할된 DB의 트랜잭션에
• App 레벨 분산 락을 이용한 비관적 동시성을 적용
Lock의 단위
• 크면 동시성이 나빠지고, 작으면 로직 구현 복잡
• 유저 단위로 잡으면 대체로 무난
데드락
• Lock 순서 규칙으로 피할 수 있음
• 순서 틀리게 잡으면 에러 발생하도록 자동화
<낙관적 동시성 제어를 적용한 사례>
NDC2016 <야생의 땅: 듀랑고> 서버 아키텍처 Vol. 2
22. 2. 기반구조 보강
프로토콜
DB 추상화
데이터 동시성
시간 처리
시간 불일치 가능성을 고려
• 시간 불일치는 어디서나 발생할 수 있다.
• 서버 ↔ 클라 사이, 클라 ↔ 클라 사이, 서버 ↔ 저장소 사이 , 서버 ↔ 서버 사이
• 자동 시간 동기화도 문제를 일으킴 (시간 역전 or 시간의 속도가 달라짐)
• 컨텐츠가 유저의 지역 시간에 연동되면 타임존 문제도 복잡
시간 변경이 필요한 테스트
• 이벤트, 거시 플레이 테스트를 위해 서버 시간 변경이 필요
• 시간을 되돌렸을 때 시간 역전으로 인한 데이터 오염 문제 주의 (시간여행 후유증)
기본 제공 시간 타입이 충분하지 않다면
• 단조 증가 시계, 시간 분해능 축소 고려
• 서버 프로세스 간의 시간 비교 가능 여부는 기술적 디테일이 복잡
24. 3. 게임 컨텐츠 구현
서버 로직의 분류
테스트 자동화
레이어링
동시성
실행 성능
도메인 언어
경제 버그 예방
변경 대상과 노티 여부에 따라 스케일아웃 구현이 다름 (4장)
1. 자기 정보만 변경, 노티 불필요 = DB 수평 분할 쉬움 (싱글 프로세스와 로직 동일)
2. 자기 정보만 변경, 노티 필요 = 서버 → 클라 전송 필요 (싱글 프로세스와 로직 동일)
3. 남의 정보도 변경, 노티 불필요 = 분산 트랜잭션 필요
4. 남의 정보도 변경, 노티 필요 = 서버간 통신 (+ 뒷단 서버) 필요
구현 방향
1. 최초 구현은 싱글 프로세스 서버로 먼저 개발하는게 유리
• 게임 플레이를 검증하고, 다듬을 시간을 확보해야 하므로
2. 스케일아웃을 위한 구조가 준비된 후 (4장)
• 멀티 프로세스 서버로 동작하도록 변경하는 것이 어렵지 않음
25. 3. 게임 컨텐츠 구현
서버 로직의 분류
테스트 자동화
레이어링
동시성
실행 성능
도메인 언어
경제 버그 예방
자동화 테스트 ⊃ { 유닛 테스트, 통합 테스트 }
꼭 해야 하나요? YES
• 서버 버그는 파급 효과가 큼
• 수동 테스트는 재현, 검증이 어려움. 신뢰성 증명 x
• 처음에 잘 구현해도 이후 수정으로 오류 생기기 쉬움 (리그레션 테스트)
• 테스트가 없으면 개선이 어려워 구현 품질 낮아짐
부가 효과
• 인터페이스 변경 여파 확인
• 통합 테스트 시나리오는 부하 테스트에서 재사용 (8장)
26. 3. 게임 컨텐츠 구현
서버 로직의 분류
테스트 자동화
레이어링
동시성
실행 성능
도메인 언어
경제 버그 예방
하위 레이어 - 로직 모듈
• 개별 단위 기능을 제공
• 예) 재화 변경, 아이템 변경을 분리된 각각의 모듈로 구현
• 유닛 테스트로 검증 (서버 내부에서 실행)
상위 레이어 – 리퀘스트 핸들러
• 클라 요청 대응을 위해 로직 모듈을 조합해서 구현
• 예) 재화 변경과 아이템 변경을 조합해 거래 구현
• 통합 테스트로 검증 (테스트 클라이언트로 실행)
27. 3. 게임 컨텐츠 구현
서버 로직의 분류
테스트 자동화
레이어링
동시성
실행 성능
도메인 언어
경제 버그 예방
게임 로직에서 멀티 쓰레드 사용?
“피할 수 있다면 피하자”
• 구현이 어렵고
• 버그 재현이 어렵고
• 고쳤다는 걸 확신하기도 어렵다
• 고부하에서만 나오는 버그는 잘 발견되지 않음
• 게임 로직은 복잡도와 변동성이 크다
동시성 처리의 대안들
• async/await, promise/future
• fiber, coroutine, Virtual Actor, …
(2013 DEVIEW) 멀티쓰레드 프로그래밍이 왜이리 힘드나요?
한빛미디어 <7가지 동시성 모델>
28. 3. 게임 컨텐츠 구현
서버 로직의 분류
테스트 자동화
레이어링
동시성
실행 성능
도메인 언어
경제 버그 예방
성능 좋은 코드가 항상 필요할까? NO
• 미리부터 모든 코드를 최적화 할 필요 X
• 개별 코드 성능보다 명료한 구현이 중요
• 설계시 알고리즘 시간 복잡도에 관한 이해는 필요
• N 이 작다면 다소 높은 시간 복잡도도 감수 가능
최적화를 한다면
• 네트워크, DB 성능 개선은 대체로 이득
• 사후에 프로파일링을 통해 필요한 곳 개선
• 암달의 법칙
“성급한 최적화는 만악의 근원이다”
- 도널드 커누스
29. 3. 게임 컨텐츠 구현
서버 로직의 분류
테스트 자동화
레이어링
동시성
실행 성능
도메인 언어
경제 버그 예방
도메인 특화 언어
Domain Specific Language
• 특정 용도에 특화해 설계된 언어
• 커뮤니케이션 비용 절감
• 팀 생산성 향상
도입 예시
• 시스템 기획 안정 후 컨텐츠 양산 단계에서 컨텐츠 조립 핑퐁 대체
• 코드 생성으로 기계적인 와이어링을 자동화 (패킷 송수신, DB 관련 자동화)
→ 주로 프로그래머 업무 간소화에 기여하는 경향
NDC2017 <내가 만든 언어로 게임 만들기>
30. 3. 게임 컨텐츠 구현
서버 로직의 분류
테스트 자동화
레이어링
동시성
실행 성능
도메인 언어
경제 버그 예방
경제 버그
• 돈 복사, 아이템 복사, 재화 증발 등
• 게임 서비스 운영에 치명적
• 절차, 시스템을 통한 예방 필요
31. 목차
1. 최초의 의사결정
2. 기반구조 보강
3. 게임 컨텐츠 구현
4. 스케일아웃
5. 출시 준비
6. 무점검 스케일아웃
7. 부하테스트
8. 장애 안정성
9. 예측 실패 대비
10. 출시 이후
상용 서비스 혹은 대규모 서비스에 필수적
33. 4. 스케일아웃
목표 동접 / 가입자 수
봉투 뒷면 계산법
간이 부하테스트
게임 서버 분할
유저간 상호작용
DB 분할
Redis 분할
서버 장비의 처리 규모 향상 방법
• 스케일아웃 : 장비의 수량 증가
• 스케일업 : 장비의 사양 증가
34. 4. 스케일아웃
목표 동접 / 가입자 수
봉투 뒷면 계산법
간이 부하테스트
게임 서버 분할
유저간 상호작용
DB 분할
Redis 분할
최대 동시 접속자 수 & 누적 가입자 수
• “모든 스케일 계산의 기준”
• 사업 부서에서 상한선을 추산
• 마케팅의 영향을 강하게 받기 때문
동접
가입자수 메모리
트래픽
DB
서버대수
Redis
고용안정
게임롱런
세계평화
매출
35. 4. 스케일아웃
목표 동접 / 가입자 수
봉투 뒷면 계산법
간이 부하테스트
게임 서버 분할
유저간 상호작용
DB 분할
Redis 분할
복잡한 문제를 풀기 전에 하는 간단한 추정이나 어림 계산 (페르미 추정)
서버 / DB 얼마나 필요할까?
• (목표 동접 * 초당 요청 횟수) 처리에 필요한
• 메모리, 네트워크 트래픽, DB 처리 횟수 등을 계산
가정이 많이 들어감
• CPU 사용량은 경험적인 숫자로 가늠
• 정확한 값이 아닌 스케일을 확인하기 위한 절차
• 좀 더 정확한 측정을 위해서는 부하테스트가 필요
인사이트 <생각하는 프로그래밍>
36. 4. 스케일아웃
목표 동접 / 가입자 수
봉투 뒷면 계산법
간이 부하테스트
게임 서버 분할
유저간 상호작용
DB 분할
Redis 분할
서버 한대가 커버하는 성능 지표를 측정
• 한대로 충분할지 여부 판단 외에도
• 주요 성능 지표들이 상식 범위를 벗어나는지
• 눈에 띄는 병목 지점이 있는지 확인
• 대략적인 측정이어도 이후 개선에 큰 도움이 된다
37. 4. 스케일아웃
목표 동접 / 가입자 수
봉투 뒷면 계산법
간이 부하테스트
게임 서버 분할
유저간 상호작용
DB 분할
Redis 분할
해결 과제
1. 로드 밸런싱 (+ 세션 Stickiness)
2. 무중단 업데이트
3. 유저간 상호작용
가장 쉬운 방법은 Stateless
• 데이터는 저장소에만, 게임 서버는 랜덤 접속 가능
• 로드 밸런싱과 무중단 업데이트가 쉽게 해결됨
• 지연시간 길어서 장르 제약 있음
Stateful 서버라면
• 로드 밸런싱 : 재접속시 동일한 서버 접속 보장 필요
• 무중단 업데이트 : 서버간 세션 이전 지원 필요
NDC2015 <모바일 게임 개발자로의 변신!>
38. 4. 스케일아웃
목표 동접 / 가입자 수
봉투 뒷면 계산법
간이 부하테스트
게임 서버 분할
유저간 상호작용
DB 분할
Redis 분할
Stateless 서버에서 유저간 상호작용
• Redis pub/sub 고려
Stateful 서버에서 유저간 상호작용
1. 서버간 통신
2. 채널 이동
3. 뒷단 서버 (= 서버들이 접속하는 서버)
• Case by case
Actor 모델
• 뒷단 서버가 필요할 때 권장
<마비노기 듀얼>
NDC2016 <가상 액터 모형과 MSR의 Orleans Project>
39. 4. 스케일아웃
목표 동접 / 가입자 수
봉투 뒷면 계산법
간이 부하테스트
게임 서버 분할
유저간 상호작용
DB 분할
Redis 분할
수직 분할
• 용도별로 DB 를 구분해서 구현이 쉬움
• 여러 변경을 같은 트랜잭션으로 묶기 불편해 적용 범위 제한적
수평 분할
• 유저, 길드 등의 식별자 기준으로 적절히 분산. 탐색 불편이 단점
1. (유저 식별자) % n
2. 유저마다 테이블 룩업으로 조회 (6장)
분산 트랜잭션
• 여러 DB 에 걸쳐 원자성을 보장하기
• 예) 자기 데이터와 남의 데이터를 함께 고치는 로직
• 분산 락을 이용하면 구현 편리
NDC2015 <마비노기 듀얼: 분산 데이터베이스 트랜잭션 설계와 구현>
40. 4. 스케일아웃
목표 동접 / 가입자 수
봉투 뒷면 계산법
간이 부하테스트
게임 서버 분할
유저간 상호작용
DB 분할
Redis 분할
DB 분할과 유사하지만
• Redis 는 어차피 트랜잭션으로 묶을 수 없기 때문에
• 수직 분할을 좀 더 적극적으로 시도 가능
• 수직 분할로 커버되지 않으면 마찬가지로 수평 분할
42. 5. 출시 준비
마켓, 결제 연동
인증 시스템
보안 검수
모니터링 툴, 분석 도구
넥슨 표준 로그
NXLog
운영툴, 대량 지급
자금 결제법 대응
점검 공지
실시간 공지
패치 시스템
에러 리포트
다국어 지원
커뮤니티 연동
이벤트 제어
백오피스
43. 5. 출시 준비
업무 성격이 크게 달라짐
상당수 요구 사항이 외부 조직에서 발생
• 부서간 커뮤니케이션 중요
런칭 시기 외에는 해볼 일이 없는 생소한 업무
• 일정 예측 어려움
개발 도메인이 바뀌고, 대외 업무 비중이 높음
• 구성원 멘탈 자원 관리 어려움
과소평가 하고 시작하기 쉬움
• 배정된 업무 일정이 부족
매니징
• 일의 종류가 많아 착오나 업무 누락이 발생하기 쉬움
• 관리자가 실무에 매몰되면 부작용이 심각하므로
부서 간의 소통과 일정 관리에 집중해야 한다.
• 모든 요청 사항을 수락하면 일정 위기가 찾아올 수 있다.
• 중요도와 작업 비용에 따른 우선 순위 판단이 필수
정말 힘든 시기입니다
• 다들 힘든데 자신들도 왜 힘든지 잘 모르는 고통
• 죽는줄 알았넹..
45. 6. 무점검 스케일아웃
출시 피크
게임 서버
저장소
유저가 많이 몰리면 장비 증설을 위해 점검 걸어도 될까?
• Probably not
출시 피크 (= 마케팅 집중 기간)
• 유저 유입이 가장 활발
• 좋은 초반 경험을 제공해야 함
• 출시 시점에 점검은 게임 지표에 크게 악영향
예상을 넘는 흥행 때문에 점검을 거는 것은
장사가 잘 되기 때문에 휴업하는 것과 마찬가지
초기 평점을 좌우!
46. 6. 무점검 스케일아웃
출시 피크
게임 서버
저장소
오토 스케일 적용은 기본
= 현재 서버 부하에 따라 Scale in/out 을 자동 실행
• Stateless 가 아니라면 세션 stickness 처리 방안 필요
• 뒷단 서버가 있다면 함께 스케일 변경 처리 필요
예상보다 부하가 빠르게 몰린다면
• 오토 스케일이 동작하기 전에
• 부팅, 웜업 시간을 고려해서
• 미리 수동으로 스케일아웃 필요
47. 6. 무점검 스케일아웃
출시 피크
게임 서버
저장소
수평 분할 적용된 저장소
1. %n 분할은 나중에 확장하기 어려움
2. 룩업 분할은 성능을 약간 희생하지만 쉽게 확장
• 게임 서버와 달리 수동으로 확장 적용
• 부하 감소시 통합이 어렵기 때문에 책임자 결정 필요
CenterDB
• 하드코딩 된 장비 정보를 모두 제거하고
• 성능 영향 없는 설정 값 전용 DB 에 저장
• CenterDB 연결 문자열은 서버 실행 인자로 넘김
• 라이브 서비스 중에 저장소 추가시 CenterDB 변경
• 게임 서버는 CenterDB 를 주기적으로 모니터링
<달리는 차에서 바퀴 갈기>
49. 7. 부하 테스트
개념
서버군
더미 클라이언트
부하 패턴
문제 확인
문제 해결
일정
서버 부하테스트
1. 라이브 환경과 비슷한 서버군에
2. 유저 행동과 비슷한 더미 클라이언트로
3. 목표 동접 이상의 부하를 줘서
4. 서버의 동작 성능과 오류 여부를 확인하고 개선하는 절차
50. 7. 부하 테스트
개념
서버군
더미 클라이언트
부하 패턴
문제 확인
문제 해결
일정
1. 라이브 환경과 비슷한 서버군에
왜 ‘동일한‘이 아니라 ‘비슷한’ 일까?
• 최적의 성능, 비용, 안정성을 갖는 구성을 아직 모름
• 부하 테스트를 진행하면서 찾는다.
• 장비 구성과 설정을 다양하게 바꿔보면서 테스트
<메타몽과 피카츄>
51. 7. 부하 테스트
개념
서버군
더미 클라이언트
부하 패턴
문제 확인
문제 해결
일정
2. 유저 행동과 비슷한 더미 클라이언트로
클라이언트 구성
1. 테스트 시나리오 : 통합 테스트용 시나리오를 수정해서 사용 (3장)
2. 요청 비율 산정 : 팀내, 본부, 사내 테스트, FGT 데이터 활용
3. 클라이언트 군 : 서버군과 분리된 환경에 구성. 대규모 동시 실행
셋 다 한번 만들고 끝이 아님
시나리오와 비율은 반복해서 조정
대규모 클라이언트 운용도 단위가 큰 업무
52. 7. 부하 테스트
개념
서버군
더미 클라이언트
부하 패턴
문제 확인
문제 해결
일정
3. 목표 동접 이상의 부하를 줘서
주요 대비 시나리오
• 신규 가입이 급격하게 발생 (출시 피크)
• 로그인이 급격하게 발생 (점검 종료, 이벤트)
• 높은 동접이 지속적으로 유지 (게임 대박)
• 예상되는 성능 취약점에 부하 집중
• 각종 장애 상황 (8장)
주의할 점
• 테스트에서 빠진 부분이 없는지 꼼꼼히 확인
• 대기열은 (목표 동접 x n) 의 부하로 테스트
“잘못될 가능성이 있다면 잘못 된다”
- 에드워드 머피
53. 7. 부하 테스트
개념
서버군
더미 클라이언트
부하 패턴
문제 확인
문제 해결
일정
4. 서버의 동작 성능과 오류 여부를 확인하고 개선하는 절차
사업팀
• 최대 동접, 가입 가능 유저수, 서버 비용
인프라팀 (= 시스템 엔지니어링)
• 서버 구성이 충분히 최적화 되었는지
• DB 쿼리와 인덱스가 최적화 되었는지
• 결제 및 각종 모니터링 로그가 잘 남는지
• 무점검 스케일 아웃 (6장) SPOF, 장애 안정성 대비 (8장)
개발팀
• 고부하 상황에서 로직 오류 발생 여부
• 목표 동접에서도 플레이 가능한 응답 속도, 유저 경험인지
• 배포, 모니터링 도구와 오류 리포트 등 운영 인프라의 사용성이 적절한지
54. 7. 부하 테스트
개념
서버군
더미 클라이언트
부하 패턴
문제 확인
문제 해결
일정
4. 서버의 동작 성능과 오류 여부를 확인하고 개선하는 절차
테스트만 하는게 아님
• 지금까지 발생하지 않던 수많은 문제들이 출현
• 사소한 버그 ~ 아키텍쳐 설계 오류까지 문제의 스케일과 범위가 다양
• 발견되는 문제를 고치면서 테스트를 계속 진행
• 새로운 문제가 계속 나오므로 종료 시기를 예상하기 어렵다
• 출시일은 정해진 경우가 많아 강행군이 된다
출시 전에 하는 업무 중 가장 힘들어요
55. 7. 부하 테스트
개념
서버군
더미 클라이언트
부하 패턴
문제 확인
문제 해결
일정
금방 끝나지 않는다.
• 충분한 일정이 필요하므로
• 준비되면 가급적 일찍 시작 권장
• 추가 구현된 부분 있으면 다시 해야 하지만
• 한 번 테스트를 잘 통과했다면 이후에는 비교적 쉽게 통과
<내일의 죠>
56. 목차
1. 최초의 의사결정
2. 기반구조 보강
3. 게임 컨텐츠 구현
4. 스케일아웃
5. 출시 준비
6. 무점검 스케일아웃
7. 부하테스트
8. 장애 안정성
9. 예측 실패 대비
10. 출시 이후
더 안정된 라이브 서비스를 위해 필요한 것들
58. 8. 장애 안정성
SPOF
목표
설계
동작 예시
테스트
Single Point Of Failure. 단일 장애 지점
• 한곳이 고장 나면 전체 시스템이 중단되는 지점
• 최대한 SPOF 가 없도록 설계
• 장비를 다중화 해서 우회 접속이 가능하도록 하거나
• 장애 발생시 곧바로 예비 장비로 대체함으로써 극복
예시) Redis replication
1. 데이터 쓰기가 일어나는 master 노드와
2. master를 실시간 복제하는 읽기 전용 slave들로 구성
• master 노드에 장애 발생한다면
• slave 중 하나가 master 로 승격해 역할을 수행
→ Redis 장비가 SPOF 가 되는 것을 방지
장애 극복 기능
(= 페일오버)
59. 8. 장애 안정성
SPOF
목표
설계
동작 예시
테스트
다운타임 최소화
• 인프라 장애에도 서버는 다운되지 않음
장애 여파 최소화
• 장애가 발생한 기능 이외에는 최대한 동작하도록
장애 복구 시간 최소화
• 인프라 복구 후에는 전체 기능이 자동 복구
데이터 정합성 보장
• 유저 데이터, 로그 유실 최소화
• 유저 계정이 잠기거나 유효하지 않은 데이터 기록이 없도록
60. 8. 장애 안정성
SPOF
목표
설계
동작 예시
테스트
장애 영향 축소
• 국소 장애가 서비스 전체 장애로 번지지 않도록 설계
• 의존하는 외부 서비스 장애에 대비 (연결 끊어짐, 접속 장애, 무응답 , 실패 응답)
자동 복구
• 인프라가 제공하는 페일오버 기능을 활용
• 읽기 쓰기 재시도, 연결 끊고 재연결을 자동화
• 연속해서 쓰기 실패한 로그 데이터는 2차, 3차 저장소로 (S3, 디스크 등)
• 쓰기 실패한 데이터는 서버 재기동시 처리
데이터 정합성
• Idempotent 설계
• 모든 데이터 기록은 원자성을 보장
• 데이터 기록과 로그 기록의 정합성은 eventual consistency 추구
61. 8. 장애 안정성
SPOF
목표
설계
동작 예시
테스트
예시) Redis 장애 복구 과정
1. Redis master 노드 장애 발생
2. 게임 서버로 장애 전파
3. 게임 서버 복구 시도 시작
4. Redis slave 노드 중 하나가 master로 전환
• 수십초 ~ 분 단위 소요
• 노드가 살아난게 아니라 다른 노드로 대체된 것
5. 게임 서버 → Redis 연결 복구
• 기존 Redis 연결을 끊고 새로 연결함
6. 확산된 다른 장애가 있다면 복원 절차 진행
• 데이터 소실 대응
7. 게임 서버 복원 완료
8. 서비스 이상 여부 확인 (에러 리포트)
62. 8. 장애 안정성
SPOF
목표
설계
동작 예시
테스트
로컬 테스트 불가
• 서비스 인프라들은 주로 클라우드에 있고
• 장애 상황 재현 노하우가 없으면 테스트 어려움
• 실제와 가까운 환경에서 테스트 해야 하므로
• 부하 테스트 후반부에 병행해서 진행
구현 시기
• 개발 기간 중 기본 구현 후
• 부하테스트 기간에 검증하면서 보완 작업
<하늘을 걷는 남자, 필리프 프티>
64. 9. 예측 실패 대비
준비가 충분할까?
서버군 분리
대기열 서버
차단 스위치
우려하는 점?
• 예상보다 크게 흥행 했음에도 기술 이슈로 지표 하락 가능
• 사후에 문제를 고쳤을 땐 타이밍을 놓칠 가능성이 큼
• 가장 임팩트 있는 이벤트 중 하나가 출시 & 마켓 피쳐드
프로젝트가 크게 흥행한다면?
• 커리어 전체에서 흔치 않은 기회!
• 서버가 동접을 못 받아서 기회를 못 잡는건 너무 아깝죠
• 놓치지 않기 위해 만약의 만약을 대비
65. 9. 예측 실패 대비
준비가 충분할까?
서버군 분리
대기열 서버
차단 스위치
서버군 분리
• 계정 생성시 서버군을 사용자가 선택
• 현재 모바일 게임의 단일 서버 경향과 다르지만
• 부하 분산을 위해 고려할 수 있는 방법
구현
• 클라이언트 - 서버군 선택 UI 준비
• 서버 - 서버 주소 목록 제공, 기능 활성화 여부 컨트롤
• 출시 전에 미리 준비 필요 (마켓 검수로 긴급 대응 어려움)
• 이후 서비스 기간 중 서버군 통합 고려
↖ 서버군 분리의 진정한 비용
<야생의땅:듀랑고>
66. 9. 예측 실패 대비
준비가 충분할까?
서버군 분리
대기열 서버
차단 스위치
유저의 진입 속도를 조절해 서버 과부하를 방지
까다로운 요구 사항들
• 견뎌야 하는 부하의 수준이 매우 높음
• 게임 서버의 성능을 저하시키면 안 됨
• 남은 인원 혹은 입장 예상 시간 표시
• 순번 가로채지 못하게 암호화
• DDOS 등에 대비
• 방송 시연시 VIP 패스 구현
잘 만들기 어렵다
<모범적인 대기열 서버 설계>
NDC2019 <실버바인 대기열 서버 설계 리뷰>
67. 9. 예측 실패 대비
준비가 충분할까?
서버군 분리
대기열 서버
차단 스위치
차단 스위치
• 패치 없이 서버에서 특정 기능을 끄거나
• 추가 입장을 제한하는 기능
다양한 활용 가능성
• 성능 부하가 급격히 몰릴 경우 일부 기능 제한
• 특정 기능 버그 발생시 긴급 조치
• 경제 버그 확산 차단
69. 10. 출시 이후
출시 초기 문제
패킷 로그 조회
데이터 분석
장애 대응
세대 교체 준비
초기 문제 유형
• 부하테스트에서 누락된 부분
• 계획에 없이 갑자기 들어간 기능
• 버그 고치려다 생긴 버그 (라이브 경험 부족)
• 해킹 시도
어려움
• 전반적으로 툴과 경험이 부족
• 문제 분석이나 데이터 복원이 무척 힘들다
• 소수의 구성원에 의지하는 경향
“출시하면 다 잘 될 줄 알았는데..”
<Community (TV series)>
70. 10. 출시 이후
출시 초기 문제
패킷 로그 조회
데이터 분석
장애 대응
세대 교체 준비
필요한 경우
• DB 변경 로그로 파악이 힘든 오류 보고
• 실패 로그를 남기지 않아 분석 어려운 경우
• 해킹 시도인지 로직 오류인지 구분하기 힘들 때
데이터의 방대함
• TB 스케일
• 패킷 로그는 용량이 크고 빠르게 쌓이기 때문에
• 장기간 보관과 검색이 모두 어려움 (트레이드 오프 관계)
• 용도에 특화된 설계 결정이 중요
<마거릿 해밀턴>
71. 10. 출시 이후
출시 초기 문제
패킷 로그 조회
데이터 분석
장애 대응
세대 교체 준비
외부 분석툴?
• 도움 되지만 결국엔 내부 데이터 접근 필요
주요 업무
• 데이터 분석 + 대량 수정 작업
• RDB 라면 SQL 쿼리가 기본
• RDB 아니라면 분석 도구 준비해야
필요한 경우
• 유저 현황 파악으로 마케팅, 업데이트 전략
• 의심되는 버그 확진. 오염된 데이터 복원
• 어뷰징 탐지, 여파 분석
• 데이터 마이그레이션
72. 10. 출시 이후
출시 초기 문제
패킷 로그 조회
데이터 분석
장애 대응
세대 교체 준비
서비스 초기
• 장애 대응 업무가 많음
• 업무 시간이나 근무일에만 발생하지 않음
• 원격 작업, 시간외 근무 가능성 높다
발생률 높은 시기
• 연말연시, 명절, 각종 기념일 : 이벤트 많음
• 자정 : 날짜가 바뀌면서 이벤트 활성화
• 연말은 검수 일정 문제로 급하게 작업되는 경향
비상 출근 대비
• 원격 작업 가능한 업무는 제한적, 크로스체크 필요
• 보안 문제로 원격에서 개발 환경 접근도 낮음
<사고 사례 기록의 중요성>
NDC2016 <마비노기 듀얼> 라이브 서비스 사건사고기록
73. 10. 출시 이후
출시 초기 문제
패킷 로그 조회
데이터 분석
장애 대응
세대 교체 준비
시니어, 베테랑에 의존하는 구조는 위험
• 업무 독점과 특정인 의존성을 경계
• 내부 교육을 통한 노하우 확산, 업무 조정 필요
• 구성원의 권한과 책임 범위 확대
인력 교체 가능성에 대비
• 이직 시점을 출시 이후로 계획하는 경향
• 인력 재배치 빈번해짐
• 조직 규모 확대, 축소 모두 관리자 육성 필요
• 관리 경험과 라이브 경험을 쌓을 좋은 기회
• 갑자기 이뤄지지 않음. 미리 준비 필요
NDC2018 <게임 프로그래머는 어떻게 가르치나요?>
74. 목차
1. 최초의 의사결정
2. 기반구조 보강
3. 게임 컨텐츠 구현
4. 스케일아웃
5. 출시 준비
6. 무점검 스케일아웃
7. 부하테스트
8. 장애 안정성
9. 예측 실패 대비
10. 출시 이후
더 안정된 라이브 서비스를 위해 필요한 것들
상용 서비스 혹은 대규모 서비스에 필수적
모든 프로젝트 공통
취미나 프로토타입이라면 보통 여기까지
75. 마무리
공부를 하다 보면 자주
• 두꺼운 사용 설명서를 읽는 기분
• 지도를 원하는 사람이 읽을 자료가 적었어요
저에게 필요해서 만든 지도가
여러분의 여정에도 보탬이 된다면 기쁘겠습니다.
감사합니다!