분산 서버 구축의 ABC
– 대규모 분산 시스템을 구축하기 위한 실용적 예와 그 원칙들
NEXON KOREA
이호규

Flying sole를 준비중인
최소 1년 이상의
서버프로그래머

 Dungeon Striker
 Smack Down VS Low (THQ)
 Riding Star
 그 외 퀴즈게임, 보드게임, 출시 못한
MMO들(…OTL..)
 2003년도부터 시작 대략 10년 넘은 개발자
안녕하세요?

Outline

1. 분산 서버는 왜 필요한가?
2. 어떻게 분산할 것인가?
3. 견고한 분산 서버 시스템이란?
4. 기타
1) 분산 서버 배포에 관하여…
2) 분산 서버와 개발관련…
목차

1.Why?
분산 서버는 왜 필요한가?

Dungeon Server
하나만 있으면 안되나요?

Answer??

Why?
필요하게 되었을까요?

Yes!!
게임이 바뀌었습니다.

More!!
유저들
세상과의 교류
심지어 하나의 공통 세상

단일서버

Yes!!

OK, Then?
무엇을 분산 해야 할까요?

분산이란?
Machine의 하드웨어 부하를 분산

Machine의 부하
Network Traffic
CPU
Memory

Good
기능의 분산을 통한 서비스 안정성
ex. 채팅서버 shutdown,
but Game play는 가능함

Bad
정보의 분산으로 디버깅의 어려움
e
에러처리 복잡
e
동시성 버그 파악의 어려움

1부 끝!

2.How?
어떻게 분산할 것인가?

분산서버의 기본
기능 or 로직이 독립적으로 작동
독립적 = 서로에게 영향을 주지 않음

Scale Out
A+B = C가 아니라 A A A

Origin…

Step 1

Step 2

Step 3

Step 4

Front / Back

주의할 점
통합 독립적 로직 vs 단순 기능 로직

기능로직 분리
ㅁ
예외처리의 복잡함
ㅁ
Transaction처리의 복잡함
ㅁ
로그 분석 복잡함
e

통합로직
ㅁ
동시성 제어 용이
ㅁ
버그 재현 및 수정에 용이
ㅁ
개발 유지보수 용이
e

결국 Role로 분산

Scale Up
성능과 비용의 타협

Step 3

Manager?
어떻게 scale out하죠?

비용을 생각해 봅시다.

애매…
그닥 아주 빈번한 처리가 아님
e
정보 분산 동기화 비용 너무 큼
e
성능보단 안정성

이런 경우 Scale
Up이 좋습니다. ( 장비빨!!)

Database?
음..이것은 어떻게 scale out?

Why?필요하게 되었을까요?
대규모 Social Game을 생각해봅시다

만, 십만 아닌
수백만명!

게임서버는 Scale out
But DB?
그래서…

Sharding!
Database의 Scale Out

Shard는
파편이라는 뜻입니다.

Social Game

Sharding방법
Mapping table
Dynamic share

Mapping
shard 정보를 테이블에 저장
Cache를 이용해 성능을 최적화

Watch!
Mapping Table size
( 20byte*1 million = 20M )
e
Global DB의 부하 (Scale Up)
e

Dynamic!
기준 값을 key로 하여 Data 분산
개발 구현이 쉬움

Watch!
Static Sharding으로 인한
Re-Sharding 문제 e

Sharding, Good!,
But?database
transaction?

DB SQL에서가 아닌
Code
에서 처리해야 합니다.

Social Game

Break!

이엉차!

Next?
더 무엇을 해야 하나요?

병목!
CPU? Memory? I/O?
Enterprise

CPU
Pipe Line이 아닙니다
a
병목 처리를 주의

Memory
64bit machine ( Win..2008 R2 En..)
최대물리 메모리 2TB
a
각 분산서버 메모리 사용

I/O
제일 느린 자원
DB I/O, Network I/O

DB I/O
Memory Update First
Data Validation From DB

Net I/O
네트워크 라인 분리
ㄷ
채팅 때문에 게임이 느려져서는
안됩니다.

Broadcast
지불할 수 밖에 없는 비용
Grouping을 통한 최적화
네트워크 라인 분리
완벽한 최적화 < 90% + 장비

Next?

Test!
어떤 것을 테스트 해야 할까요?
Enterprise

Machine 지표
CPU, Memory, Network bound
In/Out

Logic 지표
e
Packet Queue 길이
-> Packet Handler
e
Logic Frame 처리 속도

Network 지표
Network Latency
Send Queue data 크기

병목!
전체적으로 게임이 느려짐?
Scale out을 해도 개선이 안됨?

성능!
단일서버의 성능 ( 동접등 )

How?
장비 Spec 중요!
Broadcast + 중요 Logic
ㄷ
ex) 대량사냥 + 대량로그인 / 로그아웃

서버성능!
비동기 I/O
Polling vs Event
계산, 값 Cache

Multi!
Process or Thread

Process
I/O Multi thread
e
Single Logic Thread
e
관리, 개발의 편리함

Thread
멀티코어를 활용한 처리량 증대
e
Singleton 제약
e
Concurrent 버그 발생 위험

2부 끝!

3.What?
견고한 분산 서버 시스템이란?

What?
견고한 분산 시스템이란 무엇일까요?

Solid
Fault tolerance
e
User trace
e
Server Dashboard

Fault!
Exception Handling
Failover

Exceptione
Always Available
e
Graceful Exception Handling
e
Error Trace

SEH, TryCatch
예외처리를 통한 서비스 지속
Call Stack, dump를 통한 에러 추적

Graceful!
단순 에러 처리 보단 친절 제공
ex. 에러 메시지 표시 + 10초 후 로비

Error Trace
Call Stack + Debug Log
ㄷ
Exception 발생시 기록한 일정수의
휘발성 로그를 저장 (BlackBox)

Failovere
Instant Load
e
Local DB, Memory DB
e
Replication

Instant!
필요할 때 정보를 복구
ㄷ
중요하지 않는 정보를 다를 때 유용
ㄷ
ex. 메일서버

From DB!
시작될 때 필요정보 모두 Load
ㄷ
복구 안정성 좋음
ㄷ
서비스 시작 Delay, 정보기록 부하
ㄷ
ex. 매니저서버

Replication!
Master / Slave (Write 동기화)
ㄷ
안정적인 복구 모델
ㄷ
다수의 Slave를 통한 Read 부하분산
ㄷ
ex. DB서버, 매니저서버

Failover

Dash Board!
특정 유저의 추적
ㄷ
현재 분산서버 모니터
ㄷ
지표 수집

Log
파일 로그 < DB 로그
e
검색이 용이
e
일일 로그 ( DB 일별 테이블)

Monitor
Memory DB( redis )를 이용하자
e
성능지표( latency )
e
Warning ( exception, critical value)

Indicator
중요 지표( cs )는 서버에서
E
게임 분석 지표는 client base log를 고려
e

Client Base
필요한 정보을 Client가 가지고 있음
ㄷ
서버 로깅 부하와 분리 가능 ( Rabbit MQ )
ㄷ
로그 작업의 편리( client 패치, 시점 )
ㄷ
Ex. 특정 레벨업 때의 장비 정보,
던전 입장시 파티원의 직업

Client Logging

Next?

Redis?!
pub /sub을 통한 다양한 Admin
ㄷ
공지사항, 특정 유저 알림
ㄷ
실시간 event ( QA Live test )
ㄷ
상점 on/off등 feature 관리 기능(제재기능)

Admin

3부 끝!

Extra…

Deploy!
United Server
One Binary Server

United!
각 서버를 객체로..
ㄱ
정말 쉬운 배포
ㄱ
정말 쉬운 디버깅

One!
서버간 버전 불일치 X
ㄱ
쉬운 배포
ㄱ
약간 복잡한 종합 설정

Schedule!
Say No!
6:4 development
Test Driven Development

Thank you!