[2010 네이트 앱스토어 개발자 세미나] 세션3-2 앱스 제작 사례 (2) 소셜게임 서버 구성 전략 선데이토즈 임현수 CTO

1. 소셜게임 서버 구성 전략
CTO, 선데이토즈
임현수
fribirdz@sundaytoz.com
1

2. 2

3. Daily Active User
3

4. 와~ 서비스 잘 된다~
4

5. 현실은....
5

6. 6

7. 소셜게임서버와
웹서비스서버의 같은 점
같은 프로그래밍 언어와 라이브러리/기술을 사용
PHP, Java, Ruby On Rails, Memcached...
같은 서비스 플랫폼을 사용
LAMP(Linux, Apache, MySQL, PHP), Resin,
Tomcat, Nginx...
기본적인 최적화 전략은 비슷
HTTP Call 줄이기, Gzip, Expire 적용 등..
7

8. 소셜게임서버와
웹서비스서버의 다른 점
쓰기(Write, Delete, Update)가 읽기보다 훨씬 많다.
일반적인 웹서비스에 비해 계산 할 것들이 많다.
트랜잭션 단위의 요청이 많다.
리소스(swf, img)의 사이즈가 매우 크다.
리소스의 변경(Update)이 매우 잦다.
8

9. 해결 방안
벤치마킹, 프로파일링을 통한 병목 찾기
적절한 시스템 아키텍쳐 수립
적합한 서버 기술 사용
서비스 설정파일 최적화
장애 모니터링/감지/알림
자동화된 장애복구
9

10. 벤치마킹, 프로파일링
좋은 도구들이 많이 있다.
Web Server
ab, http_load, JMeter
Mysql
MySQL Benchmark Suite, mysqlslap, Database Test
Suite, mysqlreport, Tuning Primer..
OS
sar, iostat, vmstat..
실제 유저의 행동들을 따라하는 테스트 스크립트도 필요
10

11. 서버가 폭주해요~
코드 최적화
DB 쿼리 최적화
장비 최적화
설정 최적화
아키텍쳐 최적화
11

12. DB 쿼리 최적화
DB 쿼리 분석 - 최적화
DB Call 을 최대한 줄이기
웹서버나 클라이언트에서 처리할 수 있는 것들은 웹서
버/클라이언트에서 처리/계산해라
12

13. 장비 최적화 - Scale Up
13

14. 장비 최적화 - Scale Out
14

15. 장비 최적화 - Scale Up
Scale Up
서버 하드웨어 업그레이드 = 서버에 금칠하기
Scale Up의 한계
Scale Up을 할 대상은 대부분 DB 서버
DB 서버 갯수 < 웹서버 갯수
장비 업그레이드에는 한계가 있음
15

16. 장비 최적화 - Scale Up
부하 발생의 원인은 IO 병목의 경우가 많다
고성능 IO 스토리지로 변경
SAS, SSD, FusionIO ...
병렬 스토리지 구성으로 구성
Table Partioning, RAID
16

17. 장비 최적화 - Scale Out
서버 대수 늘리기
구조상 한계가 있다
왜?
Scale Out을 해야할 대상은 대부분 DB서버이기 때문
DB 서버는 늘리는 것이 어렵다
17

18. Database Scale Out
Replication
출처 : http://knowledgehub.zeus.com/media/mysql1.png
쓰기요청이 절대적으로 많기 때문에
Slave를 늘리는 것은 성능 향상의 한계가 있음
18

19. Database Scale Out
출처 : http://www.dbshards.com/wp-content/uploads/2010/06/dbsDiagram2.png
Sharding
19

20. DB 3 DB 4DB 2DB 1
Web Server(s)
users
1-100
user_farms
1-100
user_crops
1-100
user_items
1-100
users
101-200
user_farms
101-200
user_crops
101-200
user_items
101-200
users
201-300
user_farms
201-300
user_crops
201-300
user_items
201-300
users
301-400
user_farms
301-400
user_crops
301-400
user_items
301-400
Sharding
20

21. Database Scale Out
Sharding
DB를 여러대로 나눔
나눠진 DB 간의 Join, Transaction의 어려움
공평하게 분산하는 것도 쉽지 않음
최근 가입한 회원들이 더 요청을 많이 함
Hash를 통해 분산한다면, 서버를 추가했을 때 처리가
복잡해짐
서버 설계 단계부터 고려되어야 함
21

22. DB 3 DB 4DB 2DB 1
Web Server(s)
user_farms
1-100
user_crops
1-100
user_items
1-100
users
101-200
user_farms
101-200
user_crops
101-200
user_items
101-200
users
201-300
user_farms
201-300
user_crops
201-300
user_items
201-300
user_friends
log_payment
farm_schema
Sharding
users
1-100
22

23. 설정 최적화
MySQL - my.cnf
PHP : php.ini
Apache : httpd.conf
nginx : nginx.conf
Resin : resin.conf
23

24. 설정 최적화
설정에 정답은 없음
벤치마킹 - 프로파일링 - 설정 변경 - 벤치마킹 - 프로파일링 - 설정 변경
- 벤치마킹 - 프로파일링 - 설정 변경 - 벤치마킹 - 프로파일링 - 설정 변
경 - 벤치마킹 - 프로파일링 - 설정 변경 - 벤치마킹 - 프로파일링 - 설정
변경 - 벤치마킹 - 프로파일링 - 설정 변경 - 벤치마킹 - 프로파일링 - 설
정 변경 - 벤치마킹 - 프로파일링 - 설정 변경 - 벤치마킹 - 프로파일링 -
설정 변경 - 벤치마킹 - 프로파일링 - 설정 변경 - 벤치마킹 - 프로파일링
- 설정 변경 - 벤치마킹 - 프로파일링 - 설정 변경 - 벤치마킹 - 프로파일
링 - 설정 변경 ....
24

25. 아키텍쳐 최적화
로드 밸런싱
리소스 서버의 분리
적절한 웹 서버 선택
PHP
op-code caches 적용 : APC, XCache, eAccelerator..
Memcached 사용
NoSQL 사용
25

26. 웹 서버
리소스 파일 서빙에 아파치는 너무 무겁다
Nginx, Lighttpd를 사용
26

27. Nginx vs Apache
27

28. Memcached
반드시 사용해야 함
DB로 가는 Call을 1번이라도 줄이자
소셜게임에도 “잘 변하지 않는 데이터”도 있다.
예: 친구 목록 정보
28

29. NoSQL
29

30. 30

31. NoSQL
redis, cassandra, mongoDB, tokyo-cabinet/tyrant,
cauchDB ....
성격이 각기 다르기 때문에, 서비스 특성과 운용 비용, 성
능을 종합적으로 판단해서 사용해야 함
정답은 없음
무턱대고 사용하는 것은 곤란
MySQL과 적절히 혼합해서 사용하는 것도 방법
31

32. apache / nginx
mod_php / php-fpm /
resin / tomcat
memcached
NoSQL (redis, mongodb)
32

33. apache / nginx
mod_php / php-fpm /
resin / tomcat
memcached
NoSQL (redis, mongodb)
MySQL
33

34. apache / nginx
mod_php / php-fpm /
resin / tomcat
memcached
NoSQL (redis,
mongodb)
MySQL
34

35. 서비스/장애 모니터링
요구조건
하드웨어 상태를 모니터링 하고 있다가,
임계치를 넘어가는 문제가 발생할 경우,
관리자에게 리포팅 해야 한다.
리포팅
이메일, 메신저, SMS
35

36. 서비스/장애 모니터링
도구
nagios, catci, collectd
awstat
mrtg
M/Monit, god
36

37. 37

38. 장애 극복(Fail Over)
장애를 자동으로 감지하고,
자동으로 복구가능할 시에,
이를 자동으로 복구하거나,
장애가 있는 서버로의 접근을 차단해야 한다.
스크립트를 작성하거나, Monit과 같은 툴을 사용한다.
38

39. 장애 극복(Fail Over)
다중화의 필요성
DNS서버의 다중화
스토리지 서버의 다중화
네트워크의 다중화
로드밸런서의 다중화
...
39

40. 40

41. Monit Example
check system localhost
if loadavg (1min) > 4 then alert
if loadavg (5min) > 2 then alert
if memory usage > 75% then alert
if cpu usage (user) > 70% then alert
if cpu usage (system) > 30% then alert
if cpu usage (wait) > 20% then alert
check process apache with pidfile /usr/local/apache/logs/httpd.pid
start program = "/etc/init.d/httpd start" with timeout 60 seconds
stop program = "/etc/init.d/httpd stop"
if cpu > 60% for 2 cycles then alert
if cpu > 80% for 5 cycles then restart
if totalmem > 200.0 MB for 5 cycles then restart
if children > 250 then restart
if loadavg(5min) greater than 10 for 8 cycles then stop
if failed host www.tildeslash.com port 80 protocol http
and request "/somefile.html"
then restart
if failed port 443 type tcpssl protocol http
with timeout 15 seconds
then restart
if 3 restarts within 5 cycles then timeout
depends on apache_bin
group server
41

42. 배포 전략
빠른 배포 / 빠른 롤백
여러대의 웹서버에 한번에/쉽게 배포가 가능해야 함
어떤 revision으로 export 또는 rollback 가능해야 함
방법
직접 배포 스크립트를 작성
Capistrano과 같은 배포 도구를 사용
42

43. 결론
기본적인 서비스 최적화 및 운용 전략은 웹서비스와 유
사함
그 중, 소셜게임 서버의 특성을 파악하고 그에 맞는 전략
을 수립해야 함
병목의 원인은 대부분 DB & DB I/O
최대한 DB Call을 줄이기
DB 쿼리 최적화
성능 최적화
하드웨어의 I/O 성능을 높임
Memcached, NoSQL 적용
43

44. 결론
장애 모니터링
좋은 도구들을 잘 사용하기
여러가지 채널로 리포팅 받기
설정 파일 최적화
적절한 기술, 아키텍쳐 도입
44

45. 결론
장애 극복
다중화가 필요함
자동화되어 있어야 함
배포
빠른 배포와 빠른 롤백이 가능해야 함
45

46. 감사합니다
46