Ndc14 분산 서버 구축의 ABC

분산 서버 구축의 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

CPUMemory

Good 기능의 분산을 통한 서비스 안정성

ex. 채팅서버 shutdown, but Game play 는 가능함

Bad 정보의 분산으로 디버깅의 어려움

e

에러처리 복잡 e

동시성 버그 파악의 어려움

1 부 끝 !

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

분산서버의 기본기능 or 로직이 독립적으로 작동

독립적 = 서로에게 영향을 주지 않음

Scale OutA+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

Mappingshard 정보를 테이블에 저장

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

CPUPipe Line 이 아닙니다

a

병목 처리를 주의

Memory64bit machine ( Win..2008 R2 En..)

최대물리 메모리 2TBa

각 분산서버 메모리 사용

I/O제일 느린 자원

DB I/O, Network I/O

DB I/OMemory 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

ProcessI/O Multi thread

e

Single Logic Threade

관리 , 개발의 편리함

Thread 멀티코어를 활용한 처리량 증대

e

Singleton 제약 e

Concurrent 버그 발생 위험

2 부 끝 !

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

What?

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

SolidFault tolerance

e

User tracee

Server Dashboard

Fault!Exception Handling

Failover

Exceptione

Always Availablee

Graceful Exception Handlinge

Error Trace

SEH, TryCatch 예외처리를 통한 서비스 지속

Call Stack, dump 를 통한 에러 추적

Graceful! 단순 에러 처리 보단 친절 제공

ex. 에러 메시지 표시 + 10 초 후 로비

Error Trace Call Stack + Debug Log

ㄷ

Exception 발생시 기록한 일정수의 휘발성 로그를 저장 (BlackBox)

Failovere

Instant Loade

Local DB, Memory DBe

Replication

Instant! 필요할 때 정보를 복구

ㄷ

중요하지 않는 정보를 다를 때 유용ㄷ

ex. 메일서버

From DB! 시작될 때 필요정보 모두 Load

ㄷ

복구 안정성 좋음ㄷ

서비스 시작 Delay, 정보기록 부하ㄷ

ex. 매니저서버

Replication! Master / Slave (Write 동기화 )

ㄷ

안정적인 복구 모델ㄷ

다수의 Slave 를 통한 Read 부하분산ㄷ

ex. DB 서버 , 매니저서버

Failover

Dash Board!특정 유저의 추적

ㄷ

현재 분산서버 모니터ㄷ

지표 수집

Log파일 로그 < DB 로그

e

검색이 용이e

일일 로그 ( DB 일별 테이블 )

MonitorMemory 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 developmentTest Driven Development

Thank you!