Tdc2013 선배들에게 배우는 server scalability
- 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명
- 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년)현재 '대 열광 프로야구 카드' 라는 게임이 큰 인기를 끌고 있음
- 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