NDC14 분산 서버 구축의 ABC - 대규모 분산 시스템을 구축하기 위한 실용적 예와 그 원칙들 발표자료

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

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

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

4. Outline

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

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

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

8. Answer??

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

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

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

14. 단일서버

15. Yes!!

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

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

18. Machine의 부하
Network Traffic
CPU
Memory

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

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

21. 1부 끝!

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

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

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

25. Origin…

26. Step 1

27. Step 2

28. Step 3

29. Step 4

30. Front / Back

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

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

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

34. 결국 Role로 분산

35. Scale Up
성능과 비용의 타협

36. Step 3

37. Manager?
어떻게 scale out하죠?

38. 비용을 생각해 봅시다.

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

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

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

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

43. 만, 십만 아닌
수백만명!

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

45. Sharding!
Database의 Scale Out

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

47. Social Game

48. Sharding방법
Mapping table
Dynamic share

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

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

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

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

53. Sharding, Good!,
But?database
transaction?

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

55. Social Game

56. Break!

57. 이엉차!

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

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

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

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

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

63. DB I/O
Memory Update First
Data Validation From DB

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

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

66. Next?

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

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

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

70. Network 지표
Network Latency
Send Queue data 크기

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

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

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

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

75. Multi!
Process or Thread

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

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

78. 2부 끝!

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

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

81. Solid
Fault tolerance
e
User trace
e
Server Dashboard

82. Fault!
Exception Handling
Failover

83. Exceptione
Always Available
e
Graceful Exception Handling
e
Error Trace

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

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

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

87. Failovere
Instant Load
e
Local DB, Memory DB
e
Replication

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

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

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

91. Failover

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

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

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

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

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

97. Client Logging

98. Next?

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

100. Admin

101. 3부 끝!

102. Extra…

103. Deploy!
United Server
One Binary Server

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

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

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

107. Thank you!