Zynga의 Robert Zubek이 GDC2010에서 발표한 내용을 적어 둔(아래 링크)를 보다가 매우 좋은 내용같아서 번역을 했습니다. 발표를 받아 적은 것이라 일부 내용이 없고 약자로 된 것도 있어 풀어보았습니다. 틀린 것이 있을 수도 있으니 지적해주세요. 징가의 서비스에 대한 포괄적인 내용을 담고 있기 때문에 해당 문제를 고민한 사람들에게는 엄청난 정보가 됩니다. 규모에 있어 전혀 다른 문제로 보기 쉽지만 작은 규모에서도 발생하는 문제입니다. 많은 분들에게 도움이 되었으면 해서 가급적 모든 문장을 번역하였습니다.
@모루
-------------------------------------------------------------------------------------------------
GDC10: Scaling Social Games, Robert Zubek
March 12th, 2010
http://www.raphkoster.com/2010/03/12/gdc10-scaling-social-games-robert-zubek/
소셜 게임은 게임과 웹의 경계점에 놓여있기 때문에 엔지니어링 관점에서 재미있는 분야입니다.
우리는 게임을 재미있게 만드는 것을 생각하고 플레이어를 다시 돌아오게 하기 위해 많은 시간을 보냅니다.
이것들이 공학적 도전인 것을 알고 있습니다. 하지만 이 웹에는 자신만의 세트, 특히 예측할 수 없는 사용자들, 갑자기 많은 사람들이 몰려오는 경우에 발생하는 효과 같은 것이 있습니다. SNS는 이런 웹의 가장 좋은 예가 될 수 있습니다. 네트웍을 통해 효과가 전파되고 예상하지 못하는 트래픽 변동을 일으킵니다
Zynga 에서는 하루에 6천5백만 명이 플레이를 합니다. 한 달에는 2억2천5백만명이 플레이를 합니다. 하지만 사용 패턴은 매우 다릅니다.
롤러코스터 왕국은 1주일에 1백만 DAU(daily active user)를 달성하였습니다. 대략 70만에서 170만명 사이를 오갑니다.
다른 예로 FishVille 1주일에 0명에서 6백만 명의 DAU 달성 (daily active user)로 커졌습니다. 엄청난 확장성이 요구되었습니다. Farmville의 경우 5개월 만에 2천5백 만 DAU로 커졌습니다. 성장 곡선은 가파르지 않았지만 성장률의 정도가 자신의 도전과제가 되었습니다.
개요:
게임 개발자들에게 웹 개발 방식에 대한 가장 좋은 예를 설명하고자 합니다. 콘솔, 모바일 등에서 왔겠지만 웹 세상은 자신만의 도전할 것들이 있고 그런 것들을 통해서 배운 해결책들이 있습니다. 웹 개발자라면 이미 알고 있는 방법일 것입니다.
두 개의 서버 접근 방식과 두 개의 클라이언트 접근 방식이 있는데 그 중 많이 쓰이는 세 가지 방식에 대해서 이야기 하겠습니다.
1. Web server stack + HTML, Mafia Wars, Vampires, et
2. Web server stack + Flash, Farmville, Fishville, Cafe world
3. Web + MMO stack + Flash, yoVille, Zynga Poker, Roller Coaster Kingdom
Web stack은 LAMP, logic in PHP, HTTP Comms. 잘 알려진 프로토콜이고 한계도 명확합니다.
Mixed stack으로 게임 로직은 자바같은 것으로 만들어진 MMO 서버에 넣고 나머지는 Web 스택에. Web stack 제한이 게임 개발에 방해되는 경우에만 사용합니다. SNS 부분은 웹 스택에서 처리합니다.
FishVille의 경우
DB 서버 -> Web stack (캐시와 큐 서버)
yoVille:
DB > MMO
Cache > Web & CDN
왜 web stack을 사용하는가? HTTP는 확장성이 좋고, 리퀘스트의 수명이 짧습니다. 그리고 로드 밸런싱이 쉬움. 각각의 요청이 아토믹, 상태가 없음. 서버 추가가 쉬움. 게임에 대해서는 제한이 많음. 특히 서버쪽에서 시작하는 동작 (NPC가 돌아다니는 것이나, 게임에서 지는 경우, 몬스터가 반응하는 경우…)에는 HTTP에서는 구현하기 어려움. 리퀘스트/리스펀스 구조이기 때문. long polling 같은 몇가지 해결 방법이 있지만 확장을 어렵게 하는 속성이 있습니다. 로드 밸런서가 처리하기 어려우며 접속 수 제한에 도달하게 됩니다.
다른 방법으로는 리퀘스트 사이의 상태를 저장하는 것을 생각해볼 수 있습니다. 웹보다는 게임 개발에 더 많이 사용합니다. Farmville 을 플레이하고 있다고 해보죠. 사과를 수확하고 있는데 많은 액션을 하게 됩니다. 결과적으로 서버에 서로 다른 많은 요구를 하게 되죠. 하지만 우리는 나무에 대해 여러번 클릭을 하더라도 첫 번째 클릭에 대해서만 사과를 주려고 합니다. 이는 상태를 저장하고 유효성을 판단해야 한다는 것을 의미하죠. 많은 수의 웹 서버에 요청을 하는 클라이언트가 있다면 DB를 사용하면 안됩니다. DB는 결국 과부하가 걸릴 것입니다. 만약 클라이언트가 한 개의 웹 서버하고만 통신할 수 있도록 보장할 수 있다면 거기에 데이터를 저장하면 되고 DB에는 나중에 저장하면 됩니다. 하지만 이것은 꼼수일 뿐이죠. 사람들이 악의적인 클라이언트와 브라우저를 이용해서 세션 어피니티를 깨지 않도록 하는 것은 어려운 일입니다.
그래서 대신 캐시 계층에 DB 서버를 두어 매번 DB에 접근하지 않도록 할 수 있습니다. 그런 것을 Network Attached Caching이라 하죠. 이 방법은 아주 잘 먹힙니다.
MMO 서버는 최소한의 기능만 가진 MMO 서버입니다. 클라이언트 마다 소켓 연결을 유지하고 있고 채팅이나 서버 측 푸시와 같은 라이브 게임을 지원합니다. 또한 메모리에 게임 상태를 유지합니다. 우리는 플레이어가 로그인하여 DB에서 로드하여 세션 어피니티를 디폴트로 만든다는 것을 알고 있습니다. 웹과는 매우 다른 방식이죠! 웹처럼 로드 밸런싱을 쉽게 할 수 없습니다.
왜 그런 방식을 할까요? 로드 밸런싱 때문에 확장하기 무척 어렵습니다. 하지만 서버 사이드 푸시, 라이브 이벤트, 많은 게임 상태 등을 저장해야 하기 때문에 사용합니다.
그림:
DB 서버 - 아마도 캐싱은 덜 하고 있을겁니다 - 웹 서버와 MMO 서버와 연결되어 있습니다. 이 두 서버군은 클라이언트와 통신하고 있습니다.
클라이언트 사이드는 좀 더 간단합니다.
Flash는 높은 품질의 게임과 클라이언트 상에서의 게임 로직을 구현할 수 있게 하고 소켓을 계속해서 열어둘 수 있게 합니다. 어떤 프로토콜도 사용할 수 있습니다.
HTML + AJAX 게임은 단지 웹 페이지일뿐입니다. 최소한의 시스템 요구사항과 제한된 그래픽을 가지고 있습니다.
SNS와의 결합(페이스북과의 결합)은 '쉽지만' 스케일링과는 관련 없습니다. 친구 목록을 얻기 위해 호스트 네트웍을 호출하는 것 같은 일을 합니다. 여러분은 지연시간과 확장이란 문제를 고민하게 됩니다. 점점 커지면서 네트웍 이슈와 관련하여 단계적으로 생기는 성능 저하를 해결하기 위해서 여러분의 인프라스트럭처를 구축할 필요가 생깁니다. 네트웍은 REST API를 제공하고 때로는 클라이언트 라이브러리도 제공합니다.
아키텍처:
데이타는 이 세 개 모두에 걸쳐서 공유됩니다. : 데이터베이스, 캐시, 등등
제 2 부 : 솔루션의 스케일링
성장한다고 해서 날려버리지 마라.
두 가지 접근 방법 : 스케일 업과 스케일 아웃
스케일 업은 프로세서나 IO 한계에 다다르면 더 좋은 성능의 컴퓨터로 바꾸는 것을 말합니다.
스케일 아웃은 컴퓨터를 더 추가하는 것을 말합니다.
이런 차이는 대개는 구조적인 문제입니다. 스케일 업을 하면 코드를 바꾸거나 설계를 바꿀 필요가 없습니다. 하지만 스케일 아웃은 확장할 수 있는 아키텍처가 필요합니다. 징가는 스케일 아웃을 선택하였습니다. 이는 커다란 성공을 가져왔습니다. 어떤 상황에서는 필요한 만큼 빠른 컴퓨터를 얻지 못하는 경우도 있습니다. 낮은 성능의 제품을 구하기 더 쉬운 것은 분명합니다. 하지만 스케일 아웃을 지원하는 아키텍처를 가진 애플리케이션이 필요합니다.
롤러코스터 왕국은 엄청나게 많은 사용자를 빠르게 확보하였습니다. 우리는 데이터베이스 한 개에서 시작하였습니다. 일주일 만에 50만 DAU(daily active user)를 달성하였습니다. 병목이 발생했고 급한대로 스케일 업을 하였지만 결국 스케일 아웃으로 전환하였습니다.
데이터베이스는 매우 재미있는 분야입니다. 제일 중요한 것은 고장에 대비하는 것입니다. DB를 확장하는 것은 여러가지 방법이 있습니다. 여기서는 MySQL에 대한 용어를 쓰겠지만 다른 시스템에도 동일한 컨셉이 있습니다.
모두들 하나의 DB에서 시작합니다. 아주 좋습니다. 하지만 두 가지를 고려해야 합니다. 초 당 쿼리 수의 제한입니다. SuperSmack같은 표준 도구를 이용하여 벤치마크를 하십시요. 초 당 쿼리 한계를 알수 있을 겁니다. 그리고 그 한계를 넘어가면 어떻게 될지 궁금해질 것입니다. 이런 경우 최적화 할 수 있는 방법이 있습니다.
두 번째로 플레이어의 쿼리 프로파일을 알 필요가 있습니다. 이른바 인서트, 셀렉트, 업데이트, 평균 초 당 프로파일 말입니다. DAU 수치를 예상해 볼 수도 있습니다. 이 방법은 초 당 쿼리를 예측할 수 있고 언제 최대 한계에 도달할 수 있는지 알 수 있기 때문에 매우 유용합니다.
애플리케이션이 성장하고있다면 스케일 아웃을 할 필요가 있습니다.
첫 번째 접근 방법으로 읽기 전용의 데이터를 복제하는 것입니다. 블로그나 웹 속성에는 잘 동작합니다. 하지만 게임에는 적합하지 않습니다. 게임은 더 자주 DB에 수정을 하기 때문에 마스터 DB가 여전히 병목이 됩니다. 하지만 여분으로서는 유용합니다.
두 번째 접근 방법으로는 복수의 마스터를 두는 것입니다. 나누어 기록을 하기 때문에 유용합니다. 하지만 일관성을 해결해야하는 문제가 생겼습니다. 해결하려면 CPU 로드가 증가합니다.
세 번째 접근 방법이 있습니다. 가장 좋은 방법입니다. 애플리케이션 계층에 해결을 위한 로직을 넣는 것입니다. 일명 표준 샤딩 접근(standard sharding approach)이라 합니다. 애플리케이션은 데이터가 어느 DB로 갈지 알고 있습니다.
데이터는 두 가지 방법으로 나눌수 있습니다:
테이블 마다 수직적으로 나누는 것입니다. 간단하지만 DAU가 증가하는 것에 대해서 확장성이 없습니다. 플레이어가 아이템에 따라서 다른 컴퓨터(box)를 접근해야 합니다.
Row를 기준으로 수평적으로 나누는 방법이 있습니다. 어렵긴 하지만 가장 좋은 결과를 얻습니다. 각각의 row는 다른 DB에 들어갑니다. row에서 DB로 연결하기 위해 좋은 맵핑 방법이 필요합니다. 여러 장비들 사이에 row를 스트라이핑 합니다. 프라이머리 키를 DB의 수로 나머지 연산을 하는 방법입니다. row의 변하지 않는 프로퍼티에 이 같은 방법을 적용하는 것이죠. 마치 논리적인 RAID 0처럼 동작하는 것이죠. 좋은 점은 용량을 증가할 수 있다는 것이죠. 샤드(shard)를 추가하는 작업은 다음 순서로 합니다. 읽기 전용 슬레이브 서버를 추가합니다. 동기화를 하고 셧다운을 합니다. 복제를 끊고 백업을 멈춥니다. 순식간에 용량이 두 배가 되는 것입니다.
하지만 더 좋은 방법이 있습니다. 어디로 갈 지 체크하는 인터액션 레이어라는 것이죠. 하지만 이 방법이 좋은 점은 간단하기 때문입니다. 원자적 복제가 필요없고, 기술도 필요없습니다. 튼튼하고 관리하기 쉽습니다.
YoVille : 두 가지 방법으로 나누었습니다. 여러 Join이 나뉘어졌습니다. 데이타 패턴은 다시 설계되어야 했습니다. 샤딩을 했기 때문에 쿼리마다 샤드 id가 필요하게 되었습니다. 데이터 복제 방법은 높은 데이터 사용량을 따라 잡느라 어려움을 겪었습니다. 샤드로 나뉜 월드에서 샤드간의 join을 쉽게 할 수 없었습니다. 방법은 있었지만 비쌌죠. 대신에 여러 번 셀렉트를 하거나 데이터를 비정규화(정규화의 반대)를 하였습니다. 소위 아이템 카탈로그와 인벤토리 같은 식으로 말입니다. 카탈로그가 충분히 작으면 메모리에 그냥 둡니다.
트랜잭션과 포린 키 제한은 넘어가겠습니다. 애플리케이션 레이어에 이 문제를 넘기는 것이 더 쉽습니다. RAM에 많은 것을 넣어두면 이것에 대해 할 일이 줄어듭니다.
캐싱
DB에 대해 이야기 할 필요가 없다면 넘어가지요. 메모리를 써서 스피드를 얻는 것입니다. 요즘 가장 유행인 것은 memcache 입니다. 네트웍에 붙은 램 캐시죠. 캐싱 쿼리뿐만 아니라 공유 게임 상태를 저장하는데도 사용합니다. 앞서 예를 들었던 사과를 따는 일 같은 것 말이죠. 간단한 키/값 쌍을 저장합니다. 구조적 게임 데이터를 거기에 넣어 둡니다. 서버간의 동작 처리를 위한 뮤텍스도 넣어둡니다. 경고 : 이것은 LRU(least recently used) 캐시입니다. DB가 아닙니다. 파일 시스템이 없습니다! 너무 많은 데이터를 거기에 넣으면 오래된 데이터를 삭제합니다. 그래서 데이터를 DB에 썼는지 확인할 필요가 있습니다.
bc(binding component ?)는 매우 근본적인 것이어서 DB와 마찬가지로 샤드로 나눌 수 있습니다. 서버마다 다른 키를 사용하거나 수직 또는 수평적으로 샤드로 나눌 수 있습니다.
게임 서버
웹 서버 부분은 잘 알려져 있습니다. 로드 밸런스. 선호하는 방법은 프록시를 이용한 로드 밸런스입니다. 보안 관점에서는 아주 좋습니다. 하지만 이것은 단일 기점 결함(SPOF, single point of failure)입니다. 그리고 프락시는 최대 커넥션이 있기 때문에 용량의 한계도 있습니다.
이런 로드 밸런스의 한계에 도달하면 로드 밸런서는…. 그래서 그 앞에 DNS 로드 밸런싱을 합니다. DNS 전달에 시간이 걸리는 것은 중요하지 않습니다.
그밖의 유용한 것으로는 미디어 서버에서 미디어 트래픽을 떼어놓기 위해 리디렉팅을 하는 것입니다. swf 파일, 오디오 파일 등은 크기가 크기 때문에 게임 서버와 같은 서버에서 서비스 할 수 없습니다. 미디어 파일에 대해서 모든 네트웍 용량을 다 쓸 것입니다. 이것은 CDN에 넣어두세요. 이미 클라우드 시스템에 있다면 거기에 넣어 둘 수 있습니다. 리소스들이 사용자에게 가깝게 있기 때문에 CDN은 빠르게 처리합니다. 다른 방법으로는 미디어 파일만을 사용하는 가벼운 웹 서버를 사용하는 것입니다. 하지만 필연적으로 파일이 아니라 게임 데이터만을 위한 커다란 서버 은행을 원할 것입니다. 이를 위해서 많은 자릿수의 성능을 필요합니다.
MMO 서버
셋업에서 일반적이지 않은 부분입니다! 서버끼리 서로 통신하지 않기 때문에 확장은 쉽습니다. DB는 샤드로 나누면 되고 memcache도 샤드로 나누면 됩니다. 웹은 로드 밸런스 팜으로 해결합니다. 하지만 MMO는? 글세요, 우리는 다른 서버와 마찬가지로 샤드로 나누는 방식을 선택했습니다.
서로에 대해 가지고 있는 정보를 제거하고 복잡도를 높이거나 낮추시기 바랍니다.움직이는 것은 어느정도는 로드 밸런싱을 의미합니다. 내부 서버간의 통신을 줄이세요. 라이브 이벤트에 참여한 모든 참가자는 한 서버에 있어야 합니다. 스케일 아웃은 직접 샤딩을 의미하는 것은 아닙니다. 서드파티를 통한 샤딩도 좋습니다. 이벤트 트래픽을 위한 별도의 서비스도 가능합니다.
플레이어가 자신의 접속을 선택할 수 있도록 하지 마세요. '가난한 자의 로드밸런싱'(poor man's load balancing)은 로드밸런싱 pool에서 부하가 걸린 서버를 제거하는 방식입니다. 많은 서버들이 부하가 걸리면 더 많은 인스턴스를 추가하고 거기에 새 컨넥션을 보냅니다. 로드밸런싱이 확장성을 제한한다는 것은 그다지 사실이 아닙니다.
설치 시 다운타임은 금전적 손실과 같습니다. 웹에는 PHP 파일만 복사하면 됩니다. 소켓으로 연결되는 서버는 더 어렵습니다. 제로 다운타임으로 배치하는 방법은? 이상적으로는 새 그림자 서버를 셋업하고 천천히 사용자를 넘겨 받습니다. 이것은 버전 문제가 있기 때문에 어려울 수 있습니다. 이런 이유로 다른 웹 서버에 비교하면 가장 어려운 일입니다.
용량 계획
우리는 스케일 아웃이 유용하다고 믿습니다. 하지만 요구는 빠르게 변할 수 있습니다. 충분한 서버를 어떻게 준비할 것인가? 이것은 다른 세부 계획입니다. 물리적인 서버를 준비할 것인가요? 아니면 클라우드로 갈 것인가요? 여러분이 자신의 장비를 가지고 있다면 선택의 여지가 많고 컨트롤을 할 수 있으며 더 높은 고정 비용을 갖고 있습니다. 클라우드는 낮은 비용이 들지만 더 빨리 준비를 할 수 있습니다. CPU를 컨트롤 할 수도 없고 IO를 가상화 할 수 있습니다. 클라우드에 있으면 스케일 아웃이 스케일 업보다 쉽습니다.
서버군을 관리하기 위해 커스텀 대시보드가 필요합니다. Munin은 서버 모니터링 그래프이고 Nagios는 경고를 위한 것입니다. 분석하기 위한 일단계는 각 서버 패밀리에 대한 분리된 그래프를 제공하는 것입니다. 그렇게 해서 시스템 내의 해당 레이어에 대한 서버 패밀리를 격리할 수 있습니다. memcache 사용이 순간적으로 뛰어오르는 것을 발견하면 특정 장비들을 분석할 수 있습니다.
Nagios는 서버 로드, 4를 초과한 CPU로드, 테스트 계정이 접속하는데 세 번 이상 시도 실패 등에 대해서 SMS 경고를 합니다.
비즈니스 상태에 대해서도 경고를 하도록 하세요. DAU가 일일 평균 이하로 떨어지는 경우 말입니다. 때로는 서버 상태보다도 빠르게 반응하기도 합니다.
만약 클라우드에서 서비스를 하고 있다면 네트워크 문제는 더 자주 발생합니다. 네트워크에서 분리되거나 재시작은 흔합니다. 방어적이 되세요. 단일 지점 결함을 줄이도록 하세요. 방어적으로 프로그래밍을 하세요. 이것은 게임쪽 구현에서도 마찬가지입니다.
Q&A
q: 왜 MySQL인가요? 스케일링의 경우 다른 DB도 좋은데요?
a: 더 오래되고 더 좋은 커뮤니티를 가진 DB도 있습니다. 하지만 그런 큰 DB가 하는 기능을 사용하지 않습니다. 샤딩 측면에서 되돌아보자면 트랜잭션과 같은 것도 많이 하지 않습니다. 그런 복잡한 일은 애플리케이션 레이어로 옮기는 것이 더 쉽습니다. 그런 방법을 쓰기 시작하면 좋은 해결책이 됩니다.
q: 그런 종류의 것에 대한 벤치마크를 해보셨나요? 다른 DB에 대해서 말이죠.
a: 당연하죠.
q: 데이터 무결성에 대해서 이야기하죠. 포린 키 제한을 없앤다는 것이 엄청난 소리로 들리는데요 악몽같은 일이 아닌가요?
a: 아닙니다. 실은 전혀 나쁘지 않습니다. 특히 항상 DB를 접근하지 않도록 하면 그런 위험한 상황에 자주 빠지지 않는다는 것을 알게될 겁니다.
q: 테이블을 추가하는 경우 복잡해지지 않나요?
a: 그다지 나쁘지 않아요. 잘 해왔습니다
q: 브라우저를 고른다고 한다면 WebGL을 고려할 것인가요?
a: 재미있는 많은 기술들이 있습니다. 3D 브라우저, 실버라이트 등. 개인적으로는 그것들을 사용하는 것에 흥미가 있습니다. 그것들이 높은 시작 침투력을 갖기 시작한다면요.
q: 왜 플래시를 선택했나요?
a: 모든 사람들이 설치하고 있으니까요. 아주 실용주의적인 접근이죠
q: DB는 백업하나요?
a: 물론
q: 어떻게?
a: 클라우드나 아마존으로 한 번 가보세요. 그런 접근을 사용해야 합니다. 우리는 여러가지 백업 솔루션을 갖고 있습니다.
q: 나는 친구들간의 많은 join이 있을 것 같은데요 그들은 여러 샤드에서 이야기를 해야 합니다. 친구들을 같은 샤드로 넣으려고 노력하나요?
a: 아니요, 모든 사람은 서로 다른 친구를 갖고 있습니다.
q: SNS 결합을 할 때 비동기를 지원하지 않는 PHP 때문에 문제에 부딪힌 적이 있나요? SNS에서 응답이 지연되거나 쓰레드가 부족해진 경우는 없나요?
a: SNS 통신을 할 때 지연을 겪을 겁니다. 하지만 전체 인프라에서 일부분에 지나지 않습니다. 이것은 PHP 뿐만아니라 어디서든지 발생할 수 있습니다. 이것을 피해가도록 프로그래밍 해야 합니다. 이런 일이 바인딩 컴포넌트에 발생했을 때 이를 해결하기 위해 좋은 해결법을 찾도록 해야 합니다.
q: 그래서 PHP에서 다른 것으로 옮길 생각은 없으신가요? 프로세스를 지연 시키나요?
a: 우리는 그런 규모에서 잘 동작할 수 있도록 하기 위해 PHP 내부를 깊게 파야만 하는 일이 여러 차례 발생하였었습니다.
q: 그렇다면 PHP를 고치기도 했단 이야기인가요?
a: 우리는, 음… 예, 고쳤습니다.
q: NoSQL 과 같은 것에 대해서는 어떻게 생각하고 계신가요?
a: 적극적으로 알아보고 있습니다. 기술이 충분히 성숙하면 좋은 대안이 될 수 있습니다. 현재로서는 구현하고 있지 않습니다.
q: 파티션에 대해서 질문하죠. 두 개의 테이블로 나눈다고 합시다. 두 개의 DB 간의 거래에 대한 아이템을 가정하면 트랜잭션은 깨질 수 있나요? 두 개의 다른 DB에 대해 소유권 변경은 어떻게 하나요?
a: 복수개의 DB간의 보장하는 것이 필요합니다. 데이터를 memcache 계층에 넣어 둡니다. 락을 걸고 쓰기를 합니다. 아니면 애플리케이션 레이어에 두고 '간단한 트랜잭션'을 구현합니다.
q: 클라우드에 있다고 할 때 서비스 접근 방법을 사용하지 말아야 하나요? 각각의 PHP 계층이 서비스 계층을 이용하는 대신에 직접 쓰기를 하면요? MMO로 치자면 업적 또는 출석 서비스 같은 것 말이죠. 웹 서비스로서 서비스 계층을 유지할건가요? 아니면 DB에 직접 쓰기를 원하시나요? 서비스 호출 시간이 더 길어집니다. 클라우드라 할지라도요.
a: 예. 이것을 잘 모듈로 나누어야 합니다. 우리는 다른 기계에 넣지 않도록 결론내렸습니다. 게임 로직으로 같은 장비에 있으면 네트웍 트래픽이 발생하지 않습니다. 그래서 분리된 계층이 없습니다. 그래서 모듈로 나누어야 합니다. 하지만 이 모듈이란 말이 네트웍 구조의 용어는 아닙니다.
@모루
Zynga의 다른 발표자료
http://www.slideshare.net/amittmahajan/building-big-social-games
