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. 마무리
공부를 하다 보면 자주
• 두꺼운 사용 설명서를 읽는 기분
• 지도를 원하는 사람이 읽을 자료가 적었어요
저에게 필요해서 만든 지도가
여러분의 여정에도 보탬이 된다면 기쁘겠습니다.
감사합니다!
