월간 액티브 유저 수 8375만명의 FarmVilleFacebook에서 가장 인기가 있는 게임인 것과 동시에 Web베이스의 인터넷 게임 중에서도 가장 인기가 있는 게임의 하나다. 스케일 아웃을 실현하기 위해 어플리케이션은 클라우드 내에 배치되고 캐쉬를 대대적으로 사용하고 있다. 또 피크 시에는 일부 기능을 정지할 수 있는 기능을 갖추어 성능 감시나 관리도 가능하다.

 

이 게임을 제작했던 Zynga사의 개발자 Luke Rajlich에 의하면 FarmVille20096월의 서비스 개시 이후, 4일에 100만 유저, 60일 후에는 1000만 유저에 이르렀다고 한다. 월간 액티브 player8000만을 넘는 중 FarmVille든 Facebook유저의 20%, 세계 인구의 1%를 넘는 유저에게 서비스를 제공 하기 위해 노력하고 있다. 규모와 이러한 단기간에 스케일 아웃을 실시하려면 하드웨어 및 소프트웨어에 대해 다소나마 솔루션이 필요하다.

 

InfoQLuke Rajlich씨에게 인터뷰를 실시하여 아키텍쳐의 상세를 해명했다. 첫 번째로 이 어플리케이션은 가상화 된 Linux 서버의 클라우드 환경에서 가동하고 있다. 그 때문에 처리 능력을 추가할 때에 리퀘스트와 수용이 지극히 용이하게 실시할 수 있다. 어플리케이션은 기본적인 LAMP(PPHP를 나타낸다) 스택으로 동작하며 캐쉬를 대대적으로 사용하고 있다.

 

기본적으로는 객체 지향에 준하고 있으며 커스터마이즈 된 DB/캐쉬 인터페이스의 MVC 어플리케이션이 되어 있습니다. 또 작업 부담량에 대응하기 위해 캐싱, 특히 memcache에 강하게 의존하고 있습니다. 게다가 분산 공유 데이타베이스도 사용하고 있습니다.”

 

통신량의 급증에 대처하는 것에 즈음하여 어플리케이션은 단시간으로의 용량 추가에 크게 의존하고 있다.

 

아키텍쳐적으로는 어플리케이션의 작업 부담량은 어느 레이어(로드 발란스, Web서버, memcache, 데이타베이스)에서도 분할할 수 있기 때문에 신속한 용량 추가가 가능합니다. 게다가 임의의 레이어에 용량을 추가하는데 있어서 매우 명확하고 정형화 된 순서도 가지고 있습니다. 그 때문에 용량 추가를 행하기 위한 관리가 용이하고, 즉시 실행할 수 있습니다. 게다가 가상 환경에서 가동하고 있기 때문에 하드웨어를 직접 프로비져닝 하지 않고 용량을 추가할 수 있습니다. 이것에 의해 용량 추가의 결정으로부터 필요한 하드웨어를 실제로 이용할 수 있도록 할 때까지의 시간을 큰 폭으로 단축할 수 있습니다. puppet등의 구성 관리 툴도 도입하고 있어 하드웨어의 추가에 걸리는 오버헤드를 줄이고 있습니다. 남아 있는 과제가 어려운 부분으로서 성능 관점으로부터 우선 어플리케이션의 어느 부분에 장해가 생기는지를 인식하고 검출하는 일이 있습니다. 이 과제를 해소하기 위해 전술의 서비스 열화에의 대응에 시간을 들여 왔습니다. 또 어플리케이션의 성능 감시에도 상당한 시간을 소비하고 있습니다.”

 

이 게임에는 많은 컴퍼넌트가 사용되고 있는 것부터 성능에 보틀 넥이 생겼을 경우 「플랫폼에서 사용하는 중요도 낮은 기능을 효율 좋게 정지」시키고 어플리케이션에의 요구를 경감하고 있다.

 

“[게임 그 자체 이외에]친구의 소개나 기프트의 리퀘스트 등 많은 컴퍼넌트가 있습니다. 그러한 요소를 게임으로부터 떼어낼 수 있기 때문에 게임의 기본 부분은 이러한 컴퍼넌트의 성능에 의한 영향을 받지 않습니다. 우리의 게임은 본질적으로 유저가 특정의 액션을 실시하기 위해서 특정 시간에 게임으로 돌아오는 타이밍 베이스의 게임이기 때문에 이 점은 아주 중요합니다. 이러한 특정의 액션은 다운 타임이 생겼을 경우 유저 익스피리언스(experience)에 크게 영향을 주기 때문에 유저에게 그러한 사태가 일어나지 않게 할 필요가 있습니다.”

 

어플리케이션에 있어서 읽기와 쓰기의 비율은 3:1로 쓰기의 비율이 높은 것으로부터 싱을 대대적으로 사용한다는 것으로 대처하고 있다. Rajlich씨는 Todd Hoff과의 인터뷰에서 분명히 했다.

 

유저 상태의 상당수는 치밀하고 복잡한 릴레이션 쉽을 포함한 데이터로 구성되어 있습니다. 예를 들어 농장의 오브젝트는 다른 오브젝트와 겹칠 수 없습니다. 이 때문에 어느 유저가 자신의 농장에 집을 배치하면 그 유저의 농장의 해당 스페이스에 다른 오브젝트가 놓여지지 않은지 연구 최종 단계에 체크할 필요가 있습니다. Google이나 Facebook등 대개의 메이저 사이트에서는 읽기가 현저해지는 것과는 달리 FarmVille에서는 쓰기에 의한 작업의 부담량이 매우 많아서 데이터의 읽기와 쓰기의 비율은3:1입니다. 이것은 쓰기의 비율이 현저하게 높은 것을 나타내 보이고 있습니다. FarmVille의 연구 최종 단계에 행해지는 리퀘스트의 대부분은 플레이 중의 유저 상태를 어떠한 형태로 갱신하는 것입니다. 이 처리를 확장성 있게 하기 위해서 어플리케이션의 교환이 주로 캐쉬 컴퍼넌트와 행해지도록 임해 왔습니다.”

 

FarmVilleFacebook플랫폼간의 통신량은 피크 시에 대략 3기가 비트/초가 된다. 따라서 클라이언트 어플리케이션은 플랫폼에 대한 콜을 어느 정도 정지하고 통신 링크의 방해가 되지 않게 할 필요가 있다.

 

“FarmVilleFacebook플랫폼 간의 통신량은 방대합니다. FarmVilleFacebook사이에 왕래하는 통신량은 피크 시에는 대략 3기가 비트/, 한층 더 캐싱 클러스터와의 통신량으로서 1.5기가 비트/초가 더해집니다. 또 성능의 변동에 대비하여 어플리케이션에는 플랫폼으로의 콜백을 동적으로 정지하는 기능이 준비되어 있습니다. 플랫폼으로의 콜백을 보다 단계적으로 정지하도록 조정 가능한 다이얼을 마련하고 있습니다. 또 플랫폼으로의 모든 콜백에 대해서 어플리케이션 그 자체의 로드를 방해하는 것이 없게 하기 위해서 임해 왔습니다. 여기서의 생각은 「로드 이외의 처리에 실패했을 경우에서도 player는 적어도 게임 플레이를 유지할 수 있다」라고 하는 것입니다.”

 

성능 감시 및 관리에 대해서는 「경계 체제에는 nagios, 감시에는 munin, 구성 관리에는 puppet를 사용하고 있습니다. 주로 내부의 통계 시스템을 이용하고 어플리케이션이 사용하는 서비스(Facebook,DB,Memcache)의 성능을 추적하고 있습니다. 게다가 성능 열화가 확인되었을 경우는 리퀘스트의 IO 이벤트를 샘플 베이스로 프로파일 합니다.」라는 것이다.

 

보충 사항으로서 Inside Social Games 어널리스트 Justin Smith에 의하면 FarmVille을 제공한 Zynga사는 작년 49000만 달러의 수익을 올렸으며 금년은 83500만 달러를 전망하고 있다고 한다.

 

 

출처 : http://www.infoq.com/jp/news/2010/03/FarmVille

 

 

저작자 표시
신고
by 흥배 2010.05.18 08:30
| 1 |

티스토리 툴바