김종원의 '망치와 모루'

마지막 글을 올린 지 한 달이 넘었네요. 많은 일이 엉켜서 시간이 금방 지나갔습니다.

가장 최근에 끝난 일은 지난 4월 29일 회사 내의 개발자 컨퍼런스였습니다.

제목이 낚시성이 농후한 '차세대 MMORPG 서비스 아키텍처'이어서 준비하는데 부담이 많이 갔습니다.

여기저기 모아 놓았던 자료와 NoSQL 관련 자료들을 엮어서 발표를 하였는데 쉬운 주제가 아니어서 그런지 내용을 이끌어가기 어렵더라구요.

강연 내용 중에서 회사 기밀 내용 외에는 조금씩 여기에 풀어볼까 합니다.

와 주신 분들 모두 감사 드리고 또 다른 기회가 있으면 더 좋은 내용으로 찾아뵙도록 하지요.

@모루

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

GDC Austin: An Inside Look At The Universe Of Warcraft

요약 정리 글 : 박PD 게임 아키텍트 블로그

구체적인 설명은 위의 글을 보시면 될 것입니다.

글을 보고 든 생각을 간략히 적으면

1. 현재 Live 팀의 구성이지 처음부터 저런 구성은 아니다.

2. 생각보다 기획팀이 적어서 놀랬다.

3. 월드당 서버가 몇 대인지 궁금. 13250대의 서버라고 하는데 월드당 30대 이상 되는 것처럼 추측됨

4. Creative development team은 팀의 역사를 기록한다고 한다. 팀 내의 작업 history를 관리한다고 하는데 무척 참신함

5. 프로덕션 팀의 중요한 역할이 'succession planning'이란다. 다음 리더가 누가 될 것인지를 명확하게 해준다고 하는데 감동.

6. 한국에서는 저런 구조는 불가능 할 듯

저런 방식의 개발팀은 전세계적으로 WOW 한 개의 팀만 있는 것이 아닐까 생각해봅니다

@모루

아이폰/아이팟 터치 프로그래밍은 PC나 맥에 비하면 많은 제약이 있습니다만 휴대폰에서의 프로그래밍에 비

하면 개발 환경은 비교할 수 없을 만큼 편리합니다. 프로그래밍 환경이 맥 용 프로그래밍을 개발하는 것과 유사하고 실제 개발환경도 통합되어 있기 때문에 차이가 없는 것처럼 느껴집니다.

하지만 실제로 개발해보면 차이가 많아서 공부해야 할 것이 많다는 것을 금방 알게됩니다. 그리고 시뮬레이터에서 테스트하는 것과 실제 디바이스에서 동작하는 것이 다르다는 것도 알게되고 마우스로 터치를 시뮬레이션 하는 것도 차이가 있다는 것을 깨닫게 됩니다.

• 높이 : 110 mm
  
• 폭    : 61.8 mm
  
• 두께 : 8.5 mm
  
• 무게 : 115 g
  

위의 숫자는 10일 새벽에 발표한 iPod touch 3세대의 크기입니다.

어제 발표에서 아이팟 나노 신제품과 아이튠즈9이 발표가 되었습니다만 저의 가장 큰 관심은 아이팟 터치 3세대였습니다. 계속 카메라가 달린 아이팟 터치가 나올 것이라는 루머가 있었기 때문이죠. 하지만 하루 전날에는 카메라 문제로 나오지 못한다는 루머가 돌았습니다. 역시나 발표에서도 카메라가 빠진 채 공개가 되었습니다. 아파서 공개석상에 나오지 못했던 잡스도 카메라가 없는 제품 홍보에 열을 내셨지만 단팥 없는 찐빵 같은 느낌이 들었습니다.

어떤 카메라 스펙을 기대했던 것일까요? 사람들이 기대한 카메라 스펙은 iPhone 3Gs에 포함된 것이었습니다. 잠깐 살펴보죠.

• 3백만 화소
  
• 오토 포커스
  
• 동영상 녹화 (VGA 30 fps)
  
• 사진과 영상에 위치 정보 기록
  

저 정도의 스펙이라면 따로 사진기를 들고 다닐 필요도 없겠죠? 이미 아이폰의 카메라의 퀄리티는 충분히 만족스럽다고 알려졌으니까요.

잠깐, 그런데 중요한 차이점이 있는 것을 놓쳤습니다. 시작 부분에 나온 아이팟 터치의 크기를 보면 아이폰과 거의 차이가 없지만 두께에서는 많은 차이를 보입니다.

iPhone 3 Gs HW spec

• 높이 : 115.5mm

• 폭    :   62.1mm

• 두께 :   12.3mm

• 무게 : 135 g

터치는 8.5mm 아이폰은 12.3mm 입니다. 생각보다 차이가 많이 납니다. 아이폰이 두꺼운 것이 아니라 아이팟 터치가 얇은 것이겠죠? 하지만 거의 45% 정도 더 두껍다는 것은 아이폰에 적용된 카메라가 터치에 사용될 수 없다는 것을 의미합니다.

애플은 디자인에 기능을 맞추는 것으로 유명한 회사입니다. 카메라 높이 때문에 디자인을 변형하지는 않습니다. 아이팟을 두껍게 만들거나 원래의 디자인을 포기하고 카메라 부분만 튀어나오게 하지는 않습니다.

그럼 애플은 어떻게 했을까요? 당연히 현재 아이팟의 크기에 맞는 카메라를 만들도록 했겠지요. 하지만 같은 스펙의 부품의 높이를 30%를 줄여야 합니다.  

오래된 이야기지만 제가 모 회사의 스마트 폰을 개발할 때 겪었던 일을 이야기를 해야겠습니다. 그 당시에 나온 대부분의 핸드폰들은 30만 화소의 카메라를 가지고 있었고 막 100만 화소를 가진 카메라가 언제 나오는지가 궁금하던 시절입니다. 그 당시 핸드폰은 20~25mm 정도로 모토롤라의 레이저가 유행하기 전이니 얇은 휴대폰이 유행하기 전이었습니다.

한창 개발하던 폰도 30만 화소였는데 갑자기 새로운 보드가 나왔으니 새로 드라이버를 올리라는 것입니다. 높이가 10mm도 안되는 100만 화소의 카메라를 달기로 했다는 군요. 처음부터 그럴 계획이 있었지만 외주 업체인 우리에게는 계약할 때 그런 이야기는 꺼내지도 않았었습니다. 문제는 새로 시작하는 것에 있지 않았습니다. 100만 화소 카메라 모듈이 막 공장에서 나온 시제품이었다는 것이죠. 더구나 붙여야 하는 컨트롤러도 아직 완성이 안되어서 현재 나온 컨트롤러에 붙였다가 나중에 제 성능을 가진 카메라 컨트롤러가 나오면 거기에 붙여야 하는 것이었습니다.

막 나온 시제품이 제대로 동작할리는 만무하죠. 화질은 나쁘죠. 스펙 대로 만들어지지도 않아서 보드가 새로 나올 때마다 새롭게 버전업 된 모듈이 붙었습니다만 마지막까지도 안정이 잘 안되었습니다. 화질은 여전히 좋지 않았고요. 품질이 나빴던 것은 카메라 모듈의 크기에 있었습니다.

카메라 모듈은 광학 제품입니다. 카메라 렌즈를 통과한 빛이 센서에 상을 맺기 위해서는 최소한의 높이가 필요합니다. 고해상도의 카메라는 센서가 더 커지게 되고 만족스러운 상을 맺기 위해서는 렌즈도 더 커집니다. 보통 작은 카메라 모듈의 렌즈는 플라스틱 재질로 만들게 되는데 굴절률을 높이기 어려워 모듈의 높이가 어느 정도 이상 작게 만들기는 어려웠습니다.

그때 디자인된 높이는 7mm 였는데 처음 시제품은 8mm 였습니다. 중간에 폰의 디자인도 변형하여서 현실 상황과 타협을 해보려고도 했었지만 결국 원래 디자인 컨셉을 유지 하기 위해 7mm에 맞추어서 나오게 되더군요. 하지만 그만큼의 시간과 노력 (돈을 더 주진 않았습니다)이 더 들어갔습니다. 카메라 뿐만 아니라 다른 핵심 부품들도 그런 상황이었기 때문에 그 때 고생은 말로 할 수 없었죠. 중요한 것은 출시 타이밍을 놓쳤다는 것인데 그 이야기는 나중으로 미루지요.

다시 아이팟 터치로 돌아가보죠. 제일 두꺼운 부분이 8.5mm입니다. 아이폰과 같은 위치에 설치하려면 저 두께보다 더 작아지겠지만 최대 높이인 8.5mm 인 부분에 설치한다고 하고 케이스의 두께를 고려하면 잘 해야 7mm 정도가 한계입니다. 그 높이에 맞춘다고 해보죠.

300만 화소에 오토포커싱 (광학인지는 확인하지 못하였습니다만 광학 오토포커싱이면 더 두꺼울겁니다) 카메라 모듈의 높이로는 구현하기에 무척 힘든 높이 입니다. iPhone 3Gs 카메라의 렌즈의 직경이 무척 작은 것을 보니 실은 더 낮은 높이인지도 모르겠습니다만 아이폰에 비해 30% 작아진 높이에 맞추기 위해 작게 만드는 것은 - 단 1mm 라도 -  쉬운 일이 아닙니다.  

iPhone 3Gs에 달린 카메라 모듈 대신 새롭게 만든 카메라 모듈을 달기 위해 고생했을 개발자들이 눈에 선합니다. 분명 카메라가 포함된 것이 처음 스펙이었겠지요. 하지만 정해진 시간까지 카메라 모듈의 개발이 완료되지 못하였던 것입니다. 날을 새고 주말에 나와도 하드웨어가 원하는 퀄리티가 나오지 못하는데 무슨 소용이겠습니까.

애플 입장에선 불확실한 모듈을 위해 기다릴 수 없으니 Plan B를 선택을 했겠지요. 카메라 모듈이 빠진다고 가격 낮출 것도 아니었을 것이고 - 단가는 몇 달러 합니다만 - 기본 시스템을 iPhone 3Gs와 같은 기능으로 업그레이드를 했으니 다음 제품 발표 때 - 타블렛 제품 발표 때 일까요 - 같이 터뜨리기로 했는지도 모릅니다. 다행이라고 스스로 위안을 했을지도 모릅니다.

하지만 애플 입장에선 - 실은 개발자 입장에서나 소비자 입장에서 - 아이폰과 차이가 전화기 뿐인 iPod touch 제품을 제공하지 못한 것은 무척 안타까운 일입니다. 애플의 동영상 컨텐츠 정책이 차질을 빚게 되었으니까요. 그나마 게임 쪽 전략은 그대로 유지하게 되어서 다행인 것 같습니다. 난데 없이 게임이라고요?

별로 크게 선전이 되지 않아서 그 중요함이 강조되지 않지만 50% 나아진 성능, OpenGL ES 2.0을 제대로 지원하는 프로세서는 게임 개발 입장에서는 무척 중요한 기능 개선 사항입니다. 앱스토어의 주요 매출원인 게임을 한 단계 업그레이드 될 수 있는 발판을 마련했으니까요. 이제  OpenGL ES 2.0을 제대로 지원하게 되는 게임들이 나오면 기존의 모바일 게임과는 비교가 안될 정도의 퀄리티 향상을 가져올 것입니다.

그렇습니다. 애플의 경영진들은 게임에 집중하기로 한 것입니다. iTunes 정말 훌륭합니다. 하지만 게임 앱의 성장은 더 눈부십니다. 닌텐도 DS의 부진이 아이폰이나 아이팟 터치 때문이라는 이야기가 나올 정도니까요. 카메라를 넣기 위해 제품 시기를 늦추는 것보다 게임기 성능을 높여서 게임 시장을 더 앞당기는 것이 더 급했던 것이죠. 3천만 대의 아이폰과 2천만 대의 아이팟 터치는 엄청난 플랫폼이 되어버렸습니다.

제품 마다의 성능이 다르다면 제일 낮은 성능의 제품에 맞추어 게임이 개발됩니다. 아이팟 터치 1세대에서는 실행 안됨이라고 붙일 수는 없으니까요.  3세대가 장착한 새로운 프로세서인 ARM A8 RISC 프로세서는 실수 벡터 연산이 가능한 모듈도 가지고 있습니다. 월등한 성능을 가지고 있으면서도 기능을 반 밖에 못 쓰고 있으니 얼마나 안타깝습니까.

멋진 아이팟 터치는 카메라 모듈이 빠짐으로써 한국에서 새롭게 인기 몰이를 할 기회를 놓치긴 했습니다만 아이폰 출시가 물 건너간 것 같은 상황이 되다 보니 아이폰을 사려고 기다려온 사람들에게는 여전히 매력적인 대안이 될 수 있을 것 같습니다.

 

이러나 저러나 소비자 입장에서는 안타까운 상황입니다.

@모루