Your SlideShare is downloading. ×
Tdc2013 선배들에게 배우는 server scalability
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Tdc2013 선배들에게 배우는 server scalability

5,509

Published on

Published in: Technology
0 Comments
40 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,509
On Slideshare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
94
Comments
0
Likes
40
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 선배들에게 배우는 Server Scalability 티쓰리 엔터테인먼트 mobile 1팀 공통 기술 개발팀 최흥배 과장
  • 2. 시스템 구축에 사용한 기술  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을 채용
  • 3. 시스템 구축에 사용한 기술 (Cont'd)  데이터는 대부분 PostgreSQL  12대의 Quadruple Extra-Large memory 인스턴스로 클 라스터를 구성  다른 Availability Zone에서 레플리케이션  메인 피드에는 Redis. Quadruple Extra-Large Memory 인스턴스로 가동  100대 이상의 인스턴스의 감시에 Munin  서비스 모니터링에 Pingdom  incident와 통지에 PagerDuty
  • 4.  공동 창업자 Mike Krieger씨는 이전에는 Meebo에서 프런트엔드 엔지니어로 근무. 또 한명의 창업자인 Kevin Systrom씨도 본격적인 백엔드 경험이 없었다.  서비스 후 만 2년도 되기 전에 3000만 이상의 유저를 획득  당시에는 LA의 모처에서 호스팅 된 서버는 1대. MacBook Pro 보다 성능이 떨어짐
  • 5. "Scaling이라는 것은 시속 100마 일로 달리는 자동차에서 모든 부 품을 교환하는 것"
  • 6. "최대한 간단" "운용 준비를 최소화" "모든 것을 자동화"
  • 7.  사진은 계속해서 증가...  Amazon EC2의 최대 메모리는 68GB  해결책으로... 먼저 수직 분산 DB 스케일링
  • 8.  Key와 사진 데이터를 분산 수개월 후에는 더 이상 메모리에 담을 수 없게 되었다.  이번에는 수평 분산, 이른바 Sharding 1. 데이터 획득: 대 부분의 경우 유저 ID로 분산 시킴 2. 특정 Shard가 너무 커지면 어떻게 할까? : 다 수의 작은 논리 Shard를 만들고 그것을 몇 개의 물리 Shard로 모았음 DB 스케일링 (Cont'd)
  • 9.  우리는 Redis를 사랑한다  Redis는 비교적 한정된 구조화 데이터를 다룰 때 좋다  팔로워 그래프. 최초의 버전에서는 Redis 위에 구축 일관성에 문제 발생. 추가 로직이 점점 증가. Twitter의 책을 보고 디자인을 변경. 재 빠르게 대응하는 것이 좋다. DB 스케일링 (Cont'd)
  • 10. 2010년: 엔지니어 2명 2011년: 엔지니어 3명 2012년: 엔지니어 5명
  • 11. 시스템은 괜찮은가? 과거의 이력과 비교해서 어떤가? 재 빠르게 대응하는 것 == 무엇이 중요한지 이미 의식하는 것. 간단함이 중요. 가능한 가동 부품을 작게 하고, 깨끗한 솔루션으로 한다. 예상보다 사건은 빨리 일어난다. 주변에 좋은 조언이 있을 것이다.
  • 12. 개발에 사용한 기술  애플리케이션 레이어에는 Python과 큰 변경이 들어간 Dj ango  Web 서버는 Tornado와 Node.js  오브젝트 캐시, 로지컬 캐시에는 Memcached와 Membas e/Redis 오브젝트 시리얼라이즈에는 MessagePack 사용  메시징 큐는 RabbitMQ
  • 13. 개발에 사용한 기술 (cont'd)  로드 발런싱과 정적 배포에는 Nginx, HAproxy, Varnish  데이터 저장소는 MySQL  맵리듀스는 Amazon EMR 위의 MrJob  코드 관리는 git
  • 14. Amazon 사용  Web층에서는 150개의 Amazon EC2인스턴스 활용 데이터베이스 로드를 줄이기 위해 90개의 인스턴스를 메모 리 캐시로 이용. 내부 처리용으로 35개의 인스턴스.  8000만개의 오브젝트를 Amazon S3에 보존, 총 용량은 41 0 테라 바이트.  70개의 마스터 데이터베이스와 병렬로 백업용 데이터 베이 스가 있고, 가용성을 위해 세계 곳곳에 분산하고 있다.  가장 트랙픽이 증가하는 것은 오후에서 저녁 사이로, 비용 절감을 위해 밤에는 EC2 인스턴스를 40%까지 줄이고 있다. 피크 시에는 시간 당 52달러의 EC2 비용이 오프 피크 시에 는 15달라까지 감소한다.
  • 15. 시작  2010년 3월에 발촉  창업자 2인에 이중 엔지니어는 1명  Rackspace 호스트 상에 Web 엔진 1, MySQL 엔진 1  1년은 동안은 스텔스 모드
  • 16. 그리고.....  2011년 1월에 서비스 오픈  Amazon EC2를 사용하여 Web 엔진 4개, MySQL은 Read&Slave  MongoDB 처음 사용  엔지니어는 2명
  • 17. 사투...  서비스 시작 후 9개월은 악몽 같은 상태  한달 반마다 스케일이 2배가 되고, 이럴 때는 꼭 시스템의 어딘가가 고장, 엔지니어는 수면 시간이 없을 정도로 압박 을 받음  게다가 벤더들이 와서 '이 제품이 모든 것을 해결' 해 준다 고 상품을 팔려고 함 -_-
  • 18.  MySQL、Cassandra、Membase、Redis、MongoDB를 사용 하고 있고, 엔지니어는 3명이 모든 것을 쏟아 붓고 있음
  • 19. 교훈 1 모든 것은 실패한다. 최대한 간단하게 하라
  • 20. 재구성  2012년 1월에 시스템을 재구성  90개의 Web 엔진, 66개의 MySQL 데이터베이스와 Memcache  엔지니어도 증가, 풀 타임 운용 담당도 생김
  • 21. 2012년 5월 엔지니어는 25명, 아키텍처는 이전과 그대로이며 다만 각 항목의 숫자만 증가.
  • 22. 클라우드  Amazon EC2/S3를 사용  선택한 이유는 특별한 건 없지만 다시 선택하더라도 Amazon을 선택할 것임  Amazon은 신뢰성이 높고, 지원도 좋고, 주변 툴도 잘 되어 있음. 지금도 DNS나 MapReduce 운용은 맡겨두고, 새로운 인스 턴스를 몇 초 만에 시작할 수 있어서 준비 시간이 거의 없다  다만 예를 들면 SSD가 사용하고 싶어도 해당 서비스에서 제공하지 못하면 사용할 수 없는 등 임의의 구성을 사용할 수 없다는 것 뿐이다  선택기가 작은만큼 고민 할 게 없다는 것도 장점이다
  • 23. 왜 MySQL을 사용하나?  성숙된 소프트웨어로 유저도 많다  데이터 파괴에 따른 손실은 거의 없다  응답 시간도 부하에 따라서 리니어하게 늦어지기 때문에 다 루기 쉽다  의문이 있다면 구글링 하면 찾기 쉽고, 공짜라서 스타트 업 에게 큰 도움이다
  • 24. 교훈 2 클러스터링은 무섭다
  • 25. Clustering은 무섭다  확장성 있는 시스템에서 문제점은 데이터 베이스가 하나의 서버로만 사용할 수 없을 때이다  Cassandra는 자동적으로 스케일링 해주고 설정도 간단하다. 가용성도 높고 단일 장해점도 없다. 그러나 장해는 일어나고 클러스터링 기술은 아직 익숙하지 않고 기본적으로 복잡하다. 커뮤니티도 아직 충분하지 않다  Cassandra에서 4회 정도 파괴적 현상을 겪었다. 데이터 리 발런싱에 실패하거나 모든 노드에서 데이터가 파괴된 적도 있다. 10개의 노드가 있는데 왜인지 부하가 하나의 노드에 집중 되어서 수동으로 다시 고쳤지만 자동 리발런스 기능으로 원 래대로 돌아가버렸다
  • 26. 샤딩  클러스터링을 대체하기 위해 샤딩 사용 샤딩은 방법은 여러개 있지만 알고리즘은 아주 간단하다  어느 시점에서 샤딩을 시작해야 할까? 샤딩을 시작하려면 새로운 서비스 개발을 멈추고 수개월은 샤딩에 집중해야 하고, 늦을 수록 샤딩은 복잡해진다  가능한 복잡한 샤딩은 제외하고 캐시 등을 추가. 그래도 부 족하다면 샤딩을 한다
  • 27. 샤딩  1대의 DB에 외부 키와 조인을 이용하고, 다음으로 비정규화 와 캐시. 또 슬레이브를 추가. 이 단계에서 샤딩을 생각하기 시작  그 후 몇 개의 기능을 샤드한 데이터 베이스와 리드/슬레이 브 등을 사용하기 시작. 샤딩 시작을 너무 늦게한 것을 반성 하고 있다  이 후 아키텍처를 재고하여, ID에 의한 샤딩을 하였다. 샤딩 을 하고 조인 등이 없어져서 스키마를 계획적으로 변경해야 한다.
  • 28. 샤딩 - 64비트 ID로 샤드 설정  Facebook나 Friendfeed 등에서 한 방법을 연구하여 그것을 우리에게 맞는 방법으로 채용  먼저 8개의 서버 각각에 512개의 데이터베이스가 있고, 각각에 유니크한 이름(db00001, db0002, db0003~db04096)을 부여한다. 이름으로 어느 데이터 베이스인지 어느 물리적인 서버인지 알 수 있다. 또 물리적 서버에는 각각 슬레이브 서버가 준비되어 레플리 케이션 되고 있다.
  • 29. 샤딩 - 64비트 ID로 샤드 설정
  • 30.  임시 수용 능력이 더 필요하면 데이터 베이스를 나누어서 새로운 서버에 레플리커를 만들고 다시 설정한다. 예를 들면 512개의 데이터 베이스를 256까지와 512까지로 나누어서 그것에 맞추어서 코드를 고친다. 이런 분해는 쉽게 할 수 있다. 샤딩 - 64비트 ID로 샤드 설정
  • 31. 샤딩 - 64비트 ID로 샤드 설정
  • 32.  데이터 ID는 64비트로 Shard ID가 어느 샤드에 데이터가 있 는지 표시하고, Type은 어느 타입의 데이터인지, 그리고 Local ID에서 그 테 이블 내의 위치를 가리킨다.  애플리케이션은 어느 샤드가 어느 서버에 있는지 알고 있기 때문에 다른 중간 서버의 도움 없이 직접 데이터에 접근한 다 샤딩 - 64비트 ID로 샤드 설정
  • 33. 샤딩 - 64비트 ID로 샤드 설정
  • 34.  신규 유저는 0에서 4096까지의 랜덤한 샤드에 할당된다  보드나 핀 등의 타입은 유저에 맞추어서 붙어진다  Local ID는 시퀸스 증가로 붙는다  오브젝트 테이블에는 유저의 보드나 핀 등의 정보가 있다  맵핑 테이블에는 유저가 보드를 가지고 있는지, 핀이 '좋아 요'로 되어 있는지를 맵한다. 명시적으로 오브젝트가 어떤 오브젝트와 연결된 단순한 구조이다. 모든 룩업이 샤드에 올라가면 데이터 이동이 없으므로 시스 템은 간단하다.  검색 시 99.9%로 캐시 히트한다. 샤딩 - 64비트 ID로 샤드 설정
  • 35. 과소 평가....  이전 시스템에서 새로운 시스템으로 이행하는데 4개월이나 걸림  5억이 핀, 16억의 팔로워 데이터 이행 때문에 스크립팅 팜 을 만들었다  코드 작성에 1개월, 데이터 이행에 3개월 걸렸다
  • 36. 장래에는....  MySQL에는 여러 가지로 사용하고 있지만 아직 클러스터링 준비는 부족하다  5년에서 10년까지는 이 시스템으로 갈려고 한다  자동 샤딩은 사용할만한 것이 될 것으로 예상한다
  • 37. 교훈 3 즐거움을 유지해라 팀이 200명이 넘어서 커지면 소통이 힘들어지고 재미가 없어지므로 회사 문화로서 즐거운 분위기가 아주 중요 하다.
  • 38. 2011년 12월 시점에서 직원 수는 12명, 현재(2012.05)는 31명
  • 39. http://www.konami.jp/products/sns_gre_dragoncollection/
  • 40. 개발 환경  개발 환경은 일반적인 LAMP. Linux, Apache HTTP Server, MySQL, Perl,PHP,Python  OS는 CentOS 5, Web 서버는 Apache2, 언어는 PHP를 메인 으로  KVS는 memcashed 베이스로 일부는 membased를 사용.
  • 41. 개발 환경
  • 42. 시스템 확장 - 릴리즈 직후
  • 43. 시스템 확장 - 릴리즈 2주 후
  • 44. 시스템 확장 - 릴리즈 1개월 후
  • 45. 시스템 확장 - 릴리즈 3개월 후
  • 46.  시스템은 인프라+앱 이 결합된 개념  PDCA(계획,실행,평가,개선) 사이클로 돌면서 운용실적을 쌓아가는 것이 중요  구체적인 장해가 발생하기 전에 수치 감시 등을 통해 장 해를 사전에 막는 체제를 만드는 것이 중요하다 장해는 어느 점을 넘으면 한번에 확대한다. 그러므로 징 후를 놓치지 않는 것이 중요  처음에는 서버 측 프로그래머는 2명으로 시작했지만 바 로 인원 부족이 되어 급하게 충원했다
  • 47. DB 문제  시스템이 대규모라서 Inno DB의 백업 사이즈도 큰 문제 가 되었다  회원의 증가에 따라서 회원 데이터 베이스 사이즈가 확대 화 되어 데이터 베이스 버퍼(임시 저장 영역)에 넣을 수 없어서 버퍼에 들어가지 않으면 디스크 읽기가 증가하여 장해 발생  문제 해결을 위해 데이터 대피 및 분할하여 데이터 사이즈를 작게 하였다 주 단위로 데이터 베이스 사이즈를 비교하여 급히 늘어난 부분을 선출하여 팀에서 공유, 사전에 대처하도록 했음
  • 48. 유저의 순차적 컨텐츠 접근  새로운 기능을 추가할 때 부하 테스트가 어려움. 일단 적은 수로 테스트 하여 비율에 따른 부하를 계산할 수 있지만 이것은 어디까지 이론 일뿐....  유저를 복수의 그룹으로 나눈다. 정기적으로 이용할 수 있는 범위를 바뀌도록 한다. 서비스 전체 이외에 특정 기 능에 대해서도 이 방식을 사용하여 개방 률을 컨트롤 한 다.  이것에 의해 특정 기능 장해로 서비스 전체가 멈추는 것 을 방지한다.
  • 49. 클라우드에서 자체 서비스로  처음에는 클라우드 서비스에서 시작  서비스 이후 데이터 센터 등으로 이전  소셜 게임은 서비스 전에 히트 예측이 어렵기 때문에 초 기에는 확장성을 위해 클라우드가 좋지만, 안정기 이후에는 더 세밀하게 다루고, 자사 서버나 데이 터 센터 활용이 더 좋을 것 같다고 생각한다.
  • 50.  대부분의 소셜 게임 개발사는 리눅스 플랫폼을 이용한다.  그러나 gloops 라는 회사는 Windows 플랫폼을 이용.  gloops는 일본의 소셜 게임 회사. http://gloops.com  지인의 말로는 일본에서도 꽤 높은 연봉을 주는 곳이라고 한다. (2012년)현재 '대 열광 프로야구 카드' 라는 게임이 큰 인기를 끌고 있음
  • 51. http://shg1996.blog.me/140171387622
  • 52. 애플리케이션 서버, 데이터베이스 서버는 Windows Server를 이용하고, 그 이외의 영역은 Linux를 사용하는 하이브리드 환경에서 개 발/서비스. 즉 게임 로직과 관련된 부분은 Windows, 인프라 부분은 Linux를 사용한다고 볼 수 있다. 일본의 소셜 게임 개발자들에게는 Windows Server는 느리다, 귀찮다, 불안정 하다라는 이미지가 있음.
  • 53. 장점  Windows 플랫폼의 장점 중 하나로 IIS와 ASP.NET 그리고 C#으로 만든 애플리케이션이 생각 이상으로 고성능 이라는 것. 또 당근 안정적임. Java를 중심으로 한 플랫폼과 비교하면 비교할 수 없을 정 도로 안정적임.  또 서비스 운용을 지원하는 툴이 잘 갖추어진 것도 큰 장점. 예를 들면 SQL Server에는 'SQL Server Management Studio'라는 GUI의 운용 관리 툴이 있음. 대부분의 관리 작 업이 이 툴로 가능하고 이용 현황 모니터링이나 필요한 쿼 리 작성도 가능하고, 잘 모르는 사람도 쉽게 운용이나 개발 을 할 수 있음.
  • 54. 장점  하드웨어 성능을 쉽게 활용할 수 있다. Linux에서는 하드웨어 성능을 올리기 위해서는 OS 설정을 만져야 하고 때에 따라서는 커널까지 손을 봐야 충분한 성 능을 얻을 수 있음. 그에 비해 Windows는 하드웨어에 맞추어서 확장되어 성 능이 향상. 높은 성능을 요구하는 소셜 애플리케이션에서는 이것은 아주 큰 장점.  개발이나 운용에 필요한 문서화가 Linux에 비해서 비교할 수 없을 정도로 좋음
  • 55. 단점  Windows 플랫폼의 가장 큰 단점은 라이선스 비용. 소셜 애플리케이션은 이벤트 등에 의해서 평상시에 비해 이용자 수가 10배 이상 증가되는 경우가 있는데 Linux에서 는 가볍게 서버를 증설할 수 있지만, Windows에서는 비용 때문에 서버 증설이 쉽지 않음.  gloops에서는 단점은 이 라이선스 비용 밖에 없다고 생각 함.
  • 56. Linux의 활용  gloops에서는 Linux도 같이 사용하고 있음.  먼저 프론트엔드에서 L7 로드 밸런스로서 병렬로 nginx를 돌리고 있음. 소셜 애플리케이션에서는 응답이 5초를 넘으면 에러로 취 급하는 '5초 룰'이 있음. 이것에 대응하기 위해서 IIS에서 응 답하지 않는 경우 nginx를 사용하여 Sorry 페이지를 직접 출력. (참고로 일본에서는 잘 나가는 게임은 클라우드를 잘 사용하지 않는데 이유는 위에 언급한 5초 룰 때문이기도 함. DeNA 등 의 소셜 플랫폼에서는 5초룰을 지정한 횟수 이상 어기면 게임에 문제가 있다고 판단하여 자동으로 내려버림)
  • 57. Linux의 활용  또 프론트엔드에서 varnish를 사용. 이것은 정적 컨텐츠의 HTTP 엑설레이터로서 이용. nginx에 대해서 리퀘스트한 내 용을 캐쉬하여 같은 리퀘스트가 오는 경우 ngnix를 걸치지 않고 직접 응답한다. 그래서 이 varnish를 활용하고 있는 서 버는 클라우드 환경에 배치.  백엔드에서는 memcached와 Redis를 사용. 또 파일서버로 Samba도 이용하여 Windows 환경에서 쉽게 depoly 할 수 있는 환경을 갖추고 있다.  Windows와 Linux의 이용률은 6:4 정도.
  • 58.  앞에서 열거한 환경을 운용하는 데이터 센터도 신경을 많 이 쓰고 있음.  (회사와)거리가 가까운 데이터 센터를 이용. 인터넷과는 10Gbps의 환경에서 접속하고, 서버 랙 간 통신 도 10Gbps로 통일.  운용하고 있는 서버 수는 실제 액티브한 것은 1000대를 넘 는다. 또한 150대 정도의 서버를 다음 프로젝트를 위해서 전원을 넣은 상태로 웜 스탠바이 상태로 하고 있다.  또 아직 포장된 상태의 서버도 수백 대 정도 있다. 데이터 센터
  • 59.  gloops에 입사한 개발자는 대부분 Windows 경험이 없는 편이라 이때까지 쌓은 경험과 지식을 활용하지 못할까 걱 정을 하는 편.  그러나 실제 개발을 해보니 별 문제가 없었음. 어차피 컴퓨 터의 기본 지식은 플랫폼과 상관 없이 같으므로 Linux에서 쌓은 경험을 Windows에서도 살릴 수 있었음.  현재는 운용 팀 인원은 9명. 이전에는 1명이 했음. 1명이 70억 PV까지 관리 했음. 처음에는 이걸 1명이 할 수 있을까에 대해서 의문스러워했 지만 해보니 할 수 있었음. 이유는 Windows 전문가가 아 니라도 쉽게 서비스 운용을 할 수 있었기 때문. Linux에서 쌓은 경험도 사용
  • 60. 현재의 개발 인프라 현재 월간 PV가 156억을 넘음. 그래서 성능 향상을 위해 다양 한 시도를 하고 있음. gloops의 인프라 환경 전체 그림. IIS나 SQL Server 등 MS 제품을 중심으로 구성
  • 61.  엔지니어가 보면 클라우드는 편리한 서비스이지만 IaaS에 는 아주 큰 문제가 있음. 그것은 바로 성능. IaaS에서는 스팩 대로 성능이 나오는 경우는 별로 없다. 이 줄어든 성능을 위해서 서버를 추가하여 스케일아웃 하 면 비용이 아주 커져서 운용에 큰 부담이 된다. 이것을 생 각하면 클라우드가 최적이라고 할 수 없다.  이런 이유 때문에 gloops는 온프리미스 환경을 중심으로 인프라를 구축. 그러나 클라우드도 활용 가치가 있다고 생 각하여 현재 MS의 Azure를 검증하고 있다. 서비스 중인 게임의 데이터 일부를 사용하여 Azure에서 테 스트 해보니 예상 이상으로 좋은 결과가 나와서 일부 콘텐 츠는 Azure에서 제공하려고 생각 중. 클라우드 서비스
  • 62. ioDrive 활용  소셜 게임 인프라 환경에서 성능에 큰 영향을 주는 것 중의 하나가 바로 스토리지(저장 장치)이다.  특히 데이터 베이스 환경의 스토리지 성능은 시스템 전체 의 성능을 크게 좌우한다.  gloops에서는 MS SQL Server를 돌리는 서버에 15,000 회 전의 SAS 디스크를 8개 장착하고 있다. 이중 6개는 RAID 10으로 조합하고, 나머지 2개는 글로벌 핫 스왑으로 사용하 고 있다.
  • 63. ioDrive 활용  여기에 플래쉬 메모리 스토리지인 Fusion-io의 'ioDrive'로 활용하고 있다. 구입할 때 마다 다르지만 현재 사용하고 있 는 것은 MLC 타입의 640GB 제품. 이것을 2개 사용하여 스트랩핑 하고 있다. 처음 사용 시에는 조금 불안한 마음도 있었지만 사용해 보 니 1년 이상 문제 없음.  벤치마크를 해보면 8대의 SAS 디스크 환경에서는 5,500 IOPS정도지만, 스트랩핑한 ioDrive에서는 20만 IOPS 정도 의 수치가 나온다. ioDrive를 사용하기 전에 다른 플래쉬 메 모리를 사용해 보았지만 이 정도의 성능과 안정성이 나오 지 않았다.
  • 64.  데이터 베이스의 성능을 올리기 위한 방법으로 스키마를 점점 분산해 가는 것도 있다. gloops에서 사용한 SQL Server는 CPU 1 코어당 비용을 지불해야 하기 때문에 분산 하면 비용이 크게 증가한다. 그러나 ioDrive를 사용하면 몇 분일 정도의 비용으로 높은 성능을 얻을 수 있다.  gloops에서는 ioDrive는 필수 아이템이다.  현재 Windows Server 2012를 크게 기대하고 있다. 실제 성능 테스트를 해보니 2008 R2에 비해서 성능 향상이라는 결과를 얻었기 때문. ioDrive 활용
  • 65. 심플한 시스템이 중요  시스템은 심플하게 구성하는 것이 중요 이유는 미래에 성능 튜닝을 할 때 대응하기 쉽기 때문. 반 대로 복잡한 시스템은 어떤 문제가 발생할 때 적절한 대응 을 하기가 어려움.  인프라 엔지니어는 다양한 미들웨어 만져보는 좋음. 'Web 서버라면 Apache가 최고'라고 무조건 적으로 사용하 는 것보다 lighttpd, nginx 등 다양한 미들웨어를 사용해 보 고 가장 적합한 것을 골라야 한다.
  • 66. 심플한 시스템이 중요  미리 테스트 해보기. 다양한 미들웨어를 알고 있어도 직접 사용해보지 않으면 알 수 없으므로 시스템의 일부로 테스트 해보면서 문제점 을 발견하면 개선책을 생각해본다.  보수적인 마인드보다 적극적인 마인드로 보통 인프라 엔지니어라면 보수적인 이미지가 많지만 사실 인프라 엔지니어는 공격적으로 다양한 애플리케이션을 사 용해 볼 수 있도록 해야 한다.
  • 67. 원활한 서비스를 위한 준비  게임 서비스 시작 전에 몇 대의 서버를 미리 준비하여. 예 상 이상으로 유저가 많으면 즉시 서버를 추가할 수 있도록 한다. 또 서버는 처음부터 스탠바이 상태로 준비한다.  최적화 된 서버 설정을 위해 Linux라면 쉘 스크립트를 사용 하고, Windows는 VHD 파일을 사용. 예) 사용하지 않는 Port 번호 비 활성화. Windows의 경우 CLOSE WAIT 타임이 길게 되어 있으므로 짧게 설정한다.
  • 68. 원활한 서비스를 위한 준비  gloops는 서버 구성 설계가 정해져 있으므로 보통 새로운 게임을 하나 서비스 하는데 1개월 정도 걸린다. 그리고 서 비스 2주 전쯤에 서버를 셋업한다. 하나의 신작 게임용의 서버 구성을 2명의 엔지니어가 3일 정도 작업. 대부분의 작업이 자동화 되어 있음.  오픈 소스 모니터링 툴인 'Icinga'를 사용. https://www.icinga.org/  Linux 엔지니어들은 Windows에서 GUI 서버를 관리하는 것 이 귀찮다고 생각하겠지만 막상 해보면 별로 문제 되지 않 음.
  • 69. 참고  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

×