1. 선배들에게 배우는
Server Scalability
티쓰리 엔터테인먼트
mobile 1팀
공통 기술 개발팀
최흥배 과장

6. 시스템 구축에 사용한 기술
 Ubuntu Linux 11.04 on Amazon EC2
 3대의 Nginx를 Amazon Elastic Load Balancer로 로드
발런스
 Python의 Django를 Amazon High-CPU Extra-Large
인스턴스에서 가동 25대 이상
 WSGI（Web Server Gateway Interface）서버로서 Gunic
orn을 채용

7. 시스템 구축에 사용한 기술 (Cont'd)
 데이터는 대부분 PostgreSQL
 12대의 Quadruple Extra-Large memory 인스턴스로 클
라스터를 구성
 다른 Availability Zone에서 레플리케이션
 메인 피드에는 Redis.
Quadruple Extra-Large Memory 인스턴스로 가동
 100대 이상의 인스턴스의 감시에 Munin
 서비스 모니터링에 Pingdom
 incident와 통지에 PagerDuty

9.  공동 창업자 Mike Krieger씨는 이전에는 Meebo에서 프런트엔드 엔지니어로
근무. 또 한명의 창업자인 Kevin Systrom씨도 본격적인 백엔드 경험이 없었다.
 서비스 후 만 2년도 되기 전에 3000만 이상의 유저를 획득
 당시에는 LA의 모처에서 호스팅 된 서버는 1대.
MacBook Pro 보다 성능이 떨어짐

10. "Scaling이라는 것은 시속 100마
일로 달리는 자동차에서 모든 부
품을 교환하는 것"

11. "최대한 간단"
"운용 준비를 최소화"
"모든 것을 자동화"

12.  사진은 계속해서 증가...
 Amazon EC2의 최대 메모리는 68GB
 해결책으로... 먼저 수직 분산
DB 스케일링

13.  Key와 사진 데이터를 분산
수개월 후에는 더 이상 메모리에 담을 수 없게 되었다.
 이번에는 수평 분산, 이른바 Sharding
1. 데이터 획득: 대 부분의 경우 유저 ID로 분산 시킴
2. 특정 Shard가 너무 커지면 어떻게 할까?
: 다 수의 작은 논리 Shard를 만들고 그것을 몇 개의 물리
Shard로 모았음
DB 스케일링 (Cont'd)

14.  우리는 Redis를 사랑한다
 Redis는 비교적 한정된 구조화 데이터를 다룰 때 좋다
 팔로워 그래프. 최초의 버전에서는 Redis 위에 구축
일관성에 문제 발생.
추가 로직이 점점 증가.
Twitter의 책을 보고 디자인을 변경.
재 빠르게 대응하는 것이 좋다.
DB 스케일링 (Cont'd)

15. 2010년: 엔지니어 2명
2011년: 엔지니어 3명
2012년: 엔지니어 5명

16. 시스템은 괜찮은가? 과거의 이력과 비교해서
어떤가?
재 빠르게 대응하는 것 == 무엇이 중요한지
이미 의식하는 것.
간단함이 중요.
가능한 가동 부품을 작게 하고, 깨끗한 솔루션으로
한다.
예상보다 사건은 빨리 일어난다. 주변에 좋은 조언이
있을 것이다.

18. 개발에 사용한 기술
 애플리케이션 레이어에는 Python과 큰 변경이 들어간 Dj
ango
 Web 서버는 Tornado와 Node.js
 오브젝트 캐시, 로지컬 캐시에는 Memcached와 Membas
e/Redis
오브젝트 시리얼라이즈에는 MessagePack 사용
 메시징 큐는 RabbitMQ

19. 개발에 사용한 기술 (cont'd)
 로드 발런싱과 정적 배포에는 Nginx, HAproxy, Varnish
 데이터 저장소는 MySQL
 맵리듀스는 Amazon EMR 위의 MrJob
 코드 관리는 git

20. Amazon 사용
 Web층에서는 150개의 Amazon EC2인스턴스 활용
데이터베이스 로드를 줄이기 위해 90개의 인스턴스를 메모
리 캐시로 이용. 내부 처리용으로 35개의 인스턴스.
 8000만개의 오브젝트를 Amazon S3에 보존, 총 용량은 41
0 테라 바이트.
 70개의 마스터 데이터베이스와 병렬로 백업용 데이터 베이
스가 있고, 가용성을 위해 세계 곳곳에 분산하고 있다.
 가장 트랙픽이 증가하는 것은 오후에서 저녁 사이로, 비용
절감을 위해 밤에는 EC2 인스턴스를 40%까지 줄이고 있다.
피크 시에는 시간 당 52달러의 EC2 비용이 오프 피크 시에
는 15달라까지 감소한다.

21. 시작
 2010년 3월에 발촉
 창업자 2인에 이중 엔지니어는 1명
 Rackspace 호스트 상에 Web 엔진 1, MySQL 엔진 1
 1년은 동안은 스텔스 모드

22. 그리고.....
 2011년 1월에 서비스 오픈
 Amazon EC2를 사용하여 Web 엔진 4개, MySQL은
Read&Slave
 MongoDB 처음 사용
 엔지니어는 2명

23. 사투...
 서비스 시작 후 9개월은 악몽 같은 상태
 한달 반마다 스케일이 2배가 되고, 이럴 때는 꼭 시스템의
어딘가가 고장, 엔지니어는 수면 시간이 없을 정도로 압박
을 받음
 게다가 벤더들이 와서 '이 제품이 모든 것을 해결' 해 준다
고 상품을 팔려고 함 -_-

24.  MySQL、Cassandra、Membase、Redis、MongoDB를 사용
하고 있고, 엔지니어는 3명이 모든 것을 쏟아 붓고 있음

25. 교훈 1
모든 것은 실패한다. 최대한 간단하게 하라

26. 재구성
 2012년 1월에 시스템을 재구성
 90개의 Web 엔진, 66개의 MySQL 데이터베이스와
Memcache
 엔지니어도 증가, 풀 타임 운용 담당도 생김

27. 2012년 5월 엔지니어는 25명,
아키텍처는 이전과 그대로이며 다만 각 항목의 숫자만
증가.

28. 클라우드
 Amazon EC2/S3를 사용
 선택한 이유는 특별한 건 없지만 다시 선택하더라도
Amazon을 선택할 것임
 Amazon은 신뢰성이 높고, 지원도 좋고, 주변 툴도 잘 되어
있음.
지금도 DNS나 MapReduce 운용은 맡겨두고, 새로운 인스
턴스를 몇 초 만에 시작할 수 있어서 준비 시간이 거의 없다
 다만 예를 들면 SSD가 사용하고 싶어도 해당 서비스에서
제공하지 못하면 사용할 수 없는 등 임의의 구성을 사용할
수 없다는 것 뿐이다
 선택기가 작은만큼 고민 할 게 없다는 것도 장점이다

29. 왜 MySQL을 사용하나?
 성숙된 소프트웨어로 유저도 많다
 데이터 파괴에 따른 손실은 거의 없다
 응답 시간도 부하에 따라서 리니어하게 늦어지기 때문에 다
루기 쉽다
 의문이 있다면 구글링 하면 찾기 쉽고, 공짜라서 스타트 업
에게 큰 도움이다

30. 교훈 2
클러스터링은 무섭다

31. Clustering은 무섭다
 확장성 있는 시스템에서 문제점은 데이터 베이스가 하나의
서버로만 사용할 수 없을 때이다
 Cassandra는 자동적으로 스케일링 해주고 설정도 간단하다.
가용성도 높고 단일 장해점도 없다.
그러나 장해는 일어나고 클러스터링 기술은 아직 익숙하지
않고 기본적으로 복잡하다. 커뮤니티도 아직 충분하지 않다
 Cassandra에서 4회 정도 파괴적 현상을 겪었다. 데이터 리
발런싱에 실패하거나 모든 노드에서 데이터가 파괴된 적도
있다.
10개의 노드가 있는데 왜인지 부하가 하나의 노드에 집중
되어서 수동으로 다시 고쳤지만 자동 리발런스 기능으로 원
래대로 돌아가버렸다

32. 샤딩
 클러스터링을 대체하기 위해 샤딩 사용
샤딩은 방법은 여러개 있지만 알고리즘은 아주 간단하다
 어느 시점에서 샤딩을 시작해야 할까?
샤딩을 시작하려면 새로운 서비스 개발을 멈추고 수개월은
샤딩에 집중해야 하고, 늦을 수록 샤딩은 복잡해진다
 가능한 복잡한 샤딩은 제외하고 캐시 등을 추가. 그래도 부
족하다면 샤딩을 한다

33. 샤딩
 1대의 DB에 외부 키와 조인을 이용하고, 다음으로 비정규화
와 캐시. 또 슬레이브를 추가.
이 단계에서 샤딩을 생각하기 시작
 그 후 몇 개의 기능을 샤드한 데이터 베이스와 리드/슬레이
브 등을 사용하기 시작. 샤딩 시작을 너무 늦게한 것을 반성
하고 있다
 이 후 아키텍처를 재고하여, ID에 의한 샤딩을 하였다. 샤딩
을 하고 조인 등이 없어져서 스키마를 계획적으로 변경해야
한다.

35. 샤딩 - 64비트 ID로 샤드 설정
 Facebook나 Friendfeed 등에서 한 방법을 연구하여 그것을
우리에게 맞는 방법으로 채용
 먼저 8개의 서버 각각에 512개의 데이터베이스가 있고,
각각에 유니크한 이름(db00001, db0002,
db0003~db04096)을 부여한다.
이름으로 어느 데이터 베이스인지 어느 물리적인 서버인지
알 수 있다.
또 물리적 서버에는 각각 슬레이브 서버가 준비되어 레플리
케이션 되고 있다.

36. 샤딩 - 64비트 ID로 샤드 설정

37.  임시 수용 능력이 더 필요하면 데이터 베이스를 나누어서
새로운 서버에 레플리커를 만들고 다시 설정한다.
예를 들면 512개의 데이터 베이스를 256까지와 512까지로
나누어서 그것에 맞추어서 코드를 고친다.
이런 분해는 쉽게 할 수 있다.
샤딩 - 64비트 ID로 샤드 설정

38. 샤딩 - 64비트 ID로 샤드 설정

39.  데이터 ID는 64비트로 Shard ID가 어느 샤드에 데이터가 있
는지 표시하고,
Type은 어느 타입의 데이터인지, 그리고 Local ID에서 그 테
이블 내의 위치를 가리킨다.
 애플리케이션은 어느 샤드가 어느 서버에 있는지 알고 있기
때문에 다른 중간 서버의 도움 없이 직접 데이터에 접근한
다
샤딩 - 64비트 ID로 샤드 설정

40. 샤딩 - 64비트 ID로 샤드 설정

41.  신규 유저는 0에서 4096까지의 랜덤한 샤드에 할당된다
 보드나 핀 등의 타입은 유저에 맞추어서 붙어진다
 Local ID는 시퀸스 증가로 붙는다
 오브젝트 테이블에는 유저의 보드나 핀 등의 정보가 있다
 맵핑 테이블에는 유저가 보드를 가지고 있는지, 핀이 '좋아
요'로 되어 있는지를 맵한다. 명시적으로 오브젝트가 어떤
오브젝트와 연결된 단순한 구조이다.
모든 룩업이 샤드에 올라가면 데이터 이동이 없으므로 시스
템은 간단하다.
 검색 시 99.9%로 캐시 히트한다.
샤딩 - 64비트 ID로 샤드 설정

43. 과소 평가....
 이전 시스템에서 새로운 시스템으로 이행하는데 4개월이나
걸림
 5억이 핀, 16억의 팔로워 데이터 이행 때문에 스크립팅 팜
을 만들었다
 코드 작성에 1개월, 데이터 이행에 3개월 걸렸다

44. 장래에는....
 MySQL에는 여러 가지로 사용하고 있지만 아직 클러스터링
준비는 부족하다
 5년에서 10년까지는 이 시스템으로 갈려고 한다
 자동 샤딩은 사용할만한 것이 될 것으로 예상한다

45. 교훈 3
즐거움을 유지해라
팀이 200명이 넘어서 커지면 소통이 힘들어지고 재미가
없어지므로 회사 문화로서 즐거운 분위기가 아주 중요
하다.

46. 2011년 12월 시점에서
직원 수는 12명,
현재(2012.05)는 31명

47. http://www.konami.jp/products/sns_gre_dragoncollection/

49. 개발 환경
 개발 환경은 일반적인 LAMP. Linux, Apache HTTP Server,
MySQL, Perl,PHP,Python
 OS는 CentOS 5, Web 서버는 Apache2, 언어는 PHP를 메인
으로
 KVS는 memcashed 베이스로 일부는 membased를 사용.

50. 개발 환경

51. 시스템 확장 - 릴리즈 직후

52. 시스템 확장 - 릴리즈 2주 후

53. 시스템 확장 - 릴리즈 1개월 후

54. 시스템 확장 - 릴리즈 3개월 후

55.  시스템은 인프라+앱 이 결합된 개념
 PDCA(계획,실행,평가,개선) 사이클로 돌면서 운용실적을
쌓아가는 것이 중요
 구체적인 장해가 발생하기 전에 수치 감시 등을 통해 장
해를 사전에 막는 체제를 만드는 것이 중요하다
장해는 어느 점을 넘으면 한번에 확대한다. 그러므로 징
후를 놓치지 않는 것이 중요
 처음에는 서버 측 프로그래머는 2명으로 시작했지만 바
로 인원 부족이 되어 급하게 충원했다

56. DB 문제
 시스템이 대규모라서 Inno DB의 백업 사이즈도 큰 문제
가 되었다
 회원의 증가에 따라서 회원 데이터 베이스 사이즈가 확대
화 되어 데이터 베이스 버퍼(임시 저장 영역)에 넣을 수
없어서 버퍼에 들어가지 않으면 디스크 읽기가 증가하여
장해 발생
 문제 해결을 위해
데이터 대피 및 분할하여 데이터 사이즈를 작게 하였다
주 단위로 데이터 베이스 사이즈를 비교하여 급히 늘어난
부분을 선출하여 팀에서 공유, 사전에 대처하도록 했음

57. 유저의 순차적 컨텐츠 접근
 새로운 기능을 추가할 때 부하 테스트가 어려움.
일단 적은 수로 테스트 하여 비율에 따른 부하를 계산할
수 있지만 이것은 어디까지 이론 일뿐....
 유저를 복수의 그룹으로 나눈다. 정기적으로 이용할 수
있는 범위를 바뀌도록 한다. 서비스 전체 이외에 특정 기
능에 대해서도 이 방식을 사용하여 개방 률을 컨트롤 한
다.
 이것에 의해 특정 기능 장해로 서비스 전체가 멈추는 것
을 방지한다.

58. 클라우드에서 자체 서비스로
 처음에는 클라우드 서비스에서 시작
 서비스 이후 데이터 센터 등으로 이전
 소셜 게임은 서비스 전에 히트 예측이 어렵기 때문에 초
기에는 확장성을 위해 클라우드가 좋지만,
안정기 이후에는 더 세밀하게 다루고, 자사 서버나 데이
터 센터 활용이 더 좋을 것 같다고 생각한다.

60.  대부분의 소셜 게임 개발사는 리눅스 플랫폼을 이용한다.
 그러나 gloops 라는 회사는 Windows 플랫폼을 이용.
 gloops는 일본의 소셜 게임 회사. http://gloops.com
 지인의 말로는 일본에서도 꽤 높은 연봉을 주는 곳이라고
한다. (2012년)현재 '대 열광 프로야구 카드' 라는 게임이
큰 인기를 끌고 있음

62. http://shg1996.blog.me/140171387622

63. 애플리케이션 서버, 데이터베이스 서버는 Windows Server를
이용하고,
그 이외의 영역은 Linux를 사용하는 하이브리드 환경에서 개
발/서비스.
즉 게임 로직과 관련된 부분은 Windows,
인프라 부분은 Linux를 사용한다고 볼 수 있다.
일본의 소셜 게임 개발자들에게는 Windows Server는
느리다, 귀찮다, 불안정
하다라는 이미지가 있음.

64. 장점
 Windows 플랫폼의 장점 중 하나로 IIS와 ASP.NET 그리고
C#으로 만든 애플리케이션이 생각 이상으로 고성능 이라는
것. 또 당근 안정적임.
Java를 중심으로 한 플랫폼과 비교하면 비교할 수 없을 정
도로 안정적임.
 또 서비스 운용을 지원하는 툴이 잘 갖추어진 것도 큰 장점.
예를 들면 SQL Server에는 'SQL Server Management
Studio'라는 GUI의 운용 관리 툴이 있음. 대부분의 관리 작
업이 이 툴로 가능하고 이용 현황 모니터링이나 필요한 쿼
리 작성도 가능하고, 잘 모르는 사람도 쉽게 운용이나 개발
을 할 수 있음.

65. 장점
 하드웨어 성능을 쉽게 활용할 수 있다.
Linux에서는 하드웨어 성능을 올리기 위해서는 OS 설정을
만져야 하고 때에 따라서는 커널까지 손을 봐야 충분한 성
능을 얻을 수 있음.
그에 비해 Windows는 하드웨어에 맞추어서 확장되어 성
능이 향상. 높은 성능을 요구하는 소셜 애플리케이션에서는
이것은 아주 큰 장점.
 개발이나 운용에 필요한 문서화가 Linux에 비해서 비교할
수 없을 정도로 좋음

66. 단점
 Windows 플랫폼의 가장 큰 단점은 라이선스 비용.
소셜 애플리케이션은 이벤트 등에 의해서 평상시에 비해
이용자 수가 10배 이상 증가되는 경우가 있는데 Linux에서
는 가볍게 서버를 증설할 수 있지만, Windows에서는 비용
때문에 서버 증설이 쉽지 않음.
 gloops에서는 단점은 이 라이선스 비용 밖에 없다고 생각
함.

67. Linux의 활용
 gloops에서는 Linux도 같이 사용하고 있음.
 먼저 프론트엔드에서 L7 로드 밸런스로서 병렬로 nginx를
돌리고 있음.
소셜 애플리케이션에서는 응답이 5초를 넘으면 에러로 취
급하는 '5초 룰'이 있음. 이것에 대응하기 위해서 IIS에서 응
답하지 않는 경우 nginx를 사용하여 Sorry 페이지를 직접
출력.
(참고로 일본에서는 잘 나가는 게임은 클라우드를 잘 사용하지 않는데 이유는 위에 언급한 5초 룰 때문이기도 함. DeNA 등
의 소셜 플랫폼에서는 5초룰을 지정한 횟수 이상 어기면 게임에 문제가 있다고 판단하여 자동으로 내려버림)

68. Linux의 활용
 또 프론트엔드에서 varnish를 사용. 이것은 정적 컨텐츠의
HTTP 엑설레이터로서 이용. nginx에 대해서 리퀘스트한 내
용을 캐쉬하여 같은 리퀘스트가 오는 경우 ngnix를 걸치지
않고 직접 응답한다. 그래서 이 varnish를 활용하고 있는 서
버는 클라우드 환경에 배치.
 백엔드에서는 memcached와 Redis를 사용. 또 파일서버로
Samba도 이용하여 Windows 환경에서 쉽게 depoly 할 수
있는 환경을 갖추고 있다.
 Windows와 Linux의 이용률은 6:4 정도.

69.  앞에서 열거한 환경을 운용하는 데이터 센터도 신경을 많
이 쓰고 있음.
 (회사와)거리가 가까운 데이터 센터를 이용.
인터넷과는 10Gbps의 환경에서 접속하고, 서버 랙 간 통신
도 10Gbps로 통일.
 운용하고 있는 서버 수는 실제 액티브한 것은 1000대를 넘
는다. 또한 150대 정도의 서버를 다음 프로젝트를 위해서
전원을 넣은 상태로 웜 스탠바이 상태로 하고 있다.
 또 아직 포장된 상태의 서버도 수백 대 정도 있다.
데이터 센터

70.  gloops에 입사한 개발자는 대부분 Windows 경험이 없는
편이라 이때까지 쌓은 경험과 지식을 활용하지 못할까 걱
정을 하는 편.
 그러나 실제 개발을 해보니 별 문제가 없었음. 어차피 컴퓨
터의 기본 지식은 플랫폼과 상관 없이 같으므로 Linux에서
쌓은 경험을 Windows에서도 살릴 수 있었음.
 현재는 운용 팀 인원은 9명. 이전에는 1명이 했음. 1명이
70억 PV까지 관리 했음.
처음에는 이걸 1명이 할 수 있을까에 대해서 의문스러워했
지만 해보니 할 수 있었음. 이유는 Windows 전문가가 아
니라도 쉽게 서비스 운용을 할 수 있었기 때문.
Linux에서 쌓은 경험도 사용

71. 현재의 개발 인프라
현재 월간 PV가 156억을 넘음. 그래서 성능 향상을 위해 다양
한 시도를 하고 있음.
gloops의 인프라 환경 전체 그림. IIS나 SQL Server 등 MS 제품을 중심으로 구성

72.  엔지니어가 보면 클라우드는 편리한 서비스이지만 IaaS에
는 아주 큰 문제가 있음. 그것은 바로 성능.
IaaS에서는 스팩 대로 성능이 나오는 경우는 별로 없다.
이 줄어든 성능을 위해서 서버를 추가하여 스케일아웃 하
면 비용이 아주 커져서 운용에 큰 부담이 된다. 이것을 생
각하면 클라우드가 최적이라고 할 수 없다.
 이런 이유 때문에 gloops는 온프리미스 환경을 중심으로
인프라를 구축. 그러나 클라우드도 활용 가치가 있다고 생
각하여 현재 MS의 Azure를 검증하고 있다.
서비스 중인 게임의 데이터 일부를 사용하여 Azure에서 테
스트 해보니 예상 이상으로 좋은 결과가 나와서 일부 콘텐
츠는 Azure에서 제공하려고 생각 중.
클라우드 서비스

73. ioDrive 활용
 소셜 게임 인프라 환경에서 성능에 큰 영향을 주는 것 중의
하나가 바로 스토리지(저장 장치)이다.
 특히 데이터 베이스 환경의 스토리지 성능은 시스템 전체
의 성능을 크게 좌우한다.
 gloops에서는 MS SQL Server를 돌리는 서버에 15,000 회
전의 SAS 디스크를 8개 장착하고 있다. 이중 6개는 RAID
10으로 조합하고, 나머지 2개는 글로벌 핫 스왑으로 사용하
고 있다.

74. ioDrive 활용
 여기에 플래쉬 메모리 스토리지인 Fusion-io의 'ioDrive'로
활용하고 있다. 구입할 때 마다 다르지만 현재 사용하고 있
는 것은 MLC 타입의 640GB 제품.
이것을 2개 사용하여 스트랩핑 하고 있다.
처음 사용 시에는 조금 불안한 마음도 있었지만 사용해 보
니 1년 이상 문제 없음.
 벤치마크를 해보면 8대의 SAS 디스크 환경에서는 5,500
IOPS정도지만, 스트랩핑한 ioDrive에서는 20만 IOPS 정도
의 수치가 나온다. ioDrive를 사용하기 전에 다른 플래쉬 메
모리를 사용해 보았지만 이 정도의 성능과 안정성이 나오
지 않았다.

75.  데이터 베이스의 성능을 올리기 위한 방법으로 스키마를
점점 분산해 가는 것도 있다. gloops에서 사용한 SQL
Server는 CPU 1 코어당 비용을 지불해야 하기 때문에 분산
하면 비용이 크게 증가한다.
그러나 ioDrive를 사용하면 몇 분일 정도의 비용으로 높은
성능을 얻을 수 있다.
 gloops에서는 ioDrive는 필수 아이템이다.
 현재 Windows Server 2012를 크게 기대하고 있다. 실제
성능 테스트를 해보니 2008 R2에 비해서 성능 향상이라는
결과를 얻었기 때문.
ioDrive 활용

76. 심플한 시스템이 중요
 시스템은 심플하게 구성하는 것이 중요
이유는 미래에 성능 튜닝을 할 때 대응하기 쉽기 때문. 반
대로 복잡한 시스템은 어떤 문제가 발생할 때 적절한 대응
을 하기가 어려움.
 인프라 엔지니어는 다양한 미들웨어 만져보는 좋음.
'Web 서버라면 Apache가 최고'라고 무조건 적으로 사용하
는 것보다 lighttpd, nginx 등 다양한 미들웨어를 사용해 보
고 가장 적합한 것을 골라야 한다.

77. 심플한 시스템이 중요
 미리 테스트 해보기.
다양한 미들웨어를 알고 있어도 직접 사용해보지 않으면
알 수 없으므로 시스템의 일부로 테스트 해보면서 문제점
을 발견하면 개선책을 생각해본다.
 보수적인 마인드보다 적극적인 마인드로
보통 인프라 엔지니어라면 보수적인 이미지가 많지만 사실
인프라 엔지니어는 공격적으로 다양한 애플리케이션을 사
용해 볼 수 있도록 해야 한다.

78. 원활한 서비스를 위한 준비
 게임 서비스 시작 전에 몇 대의 서버를 미리 준비하여. 예
상 이상으로 유저가 많으면 즉시 서버를 추가할 수 있도록
한다. 또 서버는 처음부터 스탠바이 상태로 준비한다.
 최적화 된 서버 설정을 위해 Linux라면 쉘 스크립트를 사용
하고, Windows는 VHD 파일을 사용.
예) 사용하지 않는 Port 번호 비 활성화.
Windows의 경우 CLOSE WAIT 타임이 길게 되어 있으므로
짧게 설정한다.

79. 원활한 서비스를 위한 준비
 gloops는 서버 구성 설계가 정해져 있으므로 보통 새로운
게임을 하나 서비스 하는데 1개월 정도 걸린다. 그리고 서
비스 2주 전쯤에 서버를 셋업한다.
하나의 신작 게임용의 서버 구성을 2명의 엔지니어가 3일
정도 작업. 대부분의 작업이 자동화 되어 있음.
 오픈 소스 모니터링 툴인 'Icinga'를 사용.
https://www.icinga.org/
 Linux 엔지니어들은 Windows에서 GUI 서버를 관리하는 것
이 귀찮다고 생각하겠지만 막상 해보면 별로 문제 되지 않
음.

80. 참고
 Scaling Instagram
http://www.scribd.com/doc/89025069/Mike-Krieger-Instagram-at-the-Airbnb-
tech-talk-on-Scaling-Instagram
 What Powers Instagram: Hundreds of Instances, Dozens of Technologies
http://instagram-engineering.tumblr.com/post/13649370142/what-powers-
instagram-hundreds-of-instances-dozens-of
 Pinterest: What technologies were used to make Pinterest?
http://www.quora.com/Pinterest/What-technologies-were-used-to-make-
Pinterest
 Scaling Pinterest
http://www.qcontokyo.com/speaker_MartyWeiner_2013.html
 대 인기 소셜 게임 드래곤 컬렉션을 지지하는 기술 - 확대해 나가는 시스템의
발자국
http://www.gamebusiness.jp/article.php?id=5710