벤처 투자자가 원하는 사업계획서 란

벤처 투자자가 원하는 사업 계획서에 대해서 쓴 글이 있어 소개합니다.


예전에 투자를 받으려 사업 계획서를 쓴 적이 있었는데 주변에 레퍼런스도
없고 도움 줄 사람도 없어서 쉽지 않더라구요.


1. Executive Summary
2. Problem or Customer Needs
3. Product or Service
4. Market Size
5. Competition
6. Financial Projection
7. Why Funding or Use of Proceedings
8. Team
9. Appendix


이런 순서라는데요 순서 보다는 투자해야 할 아이템이나 내용이 우선이겠죠.
시장 초기에 없는 제품을 만드려고 하면 설명하기 참 어렵고,
기존에 있는 제품을 따라하려 하면 차별화 하기 힘들죠.


@모루

게시판 옮기는 중입니다.

기존에 사용하던 textcube가 폐쇄될 예정이라 구글에서 blogspot으로 자동 이전을 시켰습니다.

페이지 레이아웃이 기존 것과 맞지 않아 조정할 필요가 있고 글에 번호를 붙이는 방식도 달라서 기존의 링크가 깨지는 것도 있을 것 같습니다. 그렇게 되면 이글루에 올린 링크도 수정해야 할 것 같습니다.

수정이 완료되면 이 글은 지우도록 하지요. 
(수정 완료)


기존 텍스트큐브의 글은 남겨둘 줄 알았더니만 이전하면서 접근할 방법이 없어졌습니다.
예전 설정이나 레이아웃을 백업하지 않아서 예전과 비슷하게 하느라 고생을 했습니다.

'맑은 고딕'폰트를 지정하는 것이 어려웠습니다.
여러 위젯으로 필요한 기능을 추가하고 마지막으로 트위터에서 업데이트 위젯을 찾아서 추가하였습니다. 바로 blogger로 위젯을 추가할 수 있도록 기능이 있어서 표준 업데이터를 추가할 수 있었습니다.

정리하는데 3시간 정도 걸렸네요. 전반적으로 사이트가 느려졌고 사진이 들어 있으면 더 느려지는 것 같습니다. 서버가 한국에 없는 것 같습니다.

편집기 내에서 사진 크기를 변경하는 기능이 없어서 예전에 크게 올렸던 사진이 그대로 페이지에 보이고 있습니다.

몇 시간에 걸쳐서 한 것 치고는 비교적 양호하게 옮겨졌습니다. 도메인도 그대로 연결되어 있긴 합니다. 예전과 같이 forge.kr/35 와 같은 형식이 아니고 리다이렉셔만 해서 블로거 주소인 forgekr.blogspot.com/2010/12/blog-post.html 형태로 만들어지는 것이 차이가 있습니다. 다행히도 예전 형식 그대로 forge.kr/3 이라고 입력하면 그대로 연결되네요.
블로거는 좀 더 써보면서 알아보겠습니다.

@모루

KGC 2010에서 강연 스케줄이 확정되었습니다

지난 번 글에서 언급 했지만 이번 9월 13일부터 15일까지 열리는 KGC2010 http://www.kgconf.com/ 에 참가 합니다.

내용은 지난 번에 발표했던 '차세대 MMORPG 서비스 시스템'이란 주제로 발표합니다. 이미 들으신 분들에게는 중복되는 내용이 많을 것 같습니다. NoSQL에 관련해서 좀 더 내용을 추가하고자 합니다만 짧은 시간에 많은 내용을 다루기에는 어려울 것 같습니다.

발표는 9월 13일 첫 날 오후 3시 50분 부터 1시간입니다. 거기서 뵙도록 하지요.

@모루

NCDC 와 NDC에서 했던 강연 자료를 공개합니다

지난 번 NCDC 강연 이후에도 5월 24일부터 28일까지 열린 넥슨의 NDC에서도 같은 주제로 강연을 했었습니다.

내용은 NC측의 민감한 부분을 일부 제외한 거의 대부분을 다루었습니다.

NCDC 때보다 강연장은 작았지만 가득 메워주신 청중들 덕분에 1시간을 꽉 채워서 이야기를 했습니다.

회사 사람이 아닌 강연은 오랜만이더군요. 같이 웃어주시고 반응해주신 덕분에 즐겁게 보냈습니다.

곧 자료를 올리겠다고 생각했는데 자꾸 늦어져서 한 달이 지난 지금에야 올리게 되었습니다.

일부 강연 분위기를 위한 이미지 몇 장을 제외하고 그대로 올렸습니다.

강의 내용은 WeRule이 보여준 여러 의미를 생각해보고 미래의 MMORPG는 어떤 방향으로 발전해야 하는 가 하는것에 대한 고민을 담아봤습니다. 하지만 내용은 NoSQL인 카산드라를 적용해보자는 것으로 끝나는 것 같습니다. 아직 논의의 시작이고 실제 실험과 결과를 준비해보고자 합니다. 가을에 KGC2010이 열리는데 강연 신청을 해두었습니다. 아마도 그 때 더 많은 이야기를 할 수 있었으면 합니다.

@모루

회사 개발자 컨퍼런스 강연

 

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

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

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

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

 

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

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

 

@모루

GDC2010:소셜 게임 서비스의 확장, Zynga

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

 

구글의 첫 스마트폰, 넥서스 원

어제 구글에서 직접 만든 첫 번째 스마트 폰인 넥서스 원을 만져볼 기회가 있었다.

자세한 하드웨어의 스펙은 여기를 참고하기 바라고 간단한 느낌만 적어볼까 한다.

만져본 제품은 SIM 카드가 없어서 단순히 PDA로만 동작하여 실제 폰 화면은 써보지 못했다.

사진처럼 - 아이폰으로 찍은 것이라 화질은 양해바란다 - 넥서스 원은 안드로이드 마크가 찍힌

파우치 안에 들어있었으며 꺼내보니 아이폰보다 약간 더 좁고 위아래로 긴 단단한 느낌이 들었다.

잡는 부분의 재질은 알루미늄 다이캐스팅으로 찍은 듯한 금속성 느낌이었다.

하단 끝부분에는 블랙베리처럼 작은 스크롤 용 트랙볼이 있어 한 손으로 다루거나 장갑을 끼었을

경우에는 무척 편리할 것 같은 생각이 들었다. 지인 중에 블랙베리 사용자는 이 트랙볼 때문에

아이폰의 멀티터치가 안부럽다는 사람도... (결국 아이폰과 같이 들고 다니는 듯)

하단은 Palm 처럼 화면 밖에 터치로 동작하는 네 개의 버튼이 있고 모든 것은 WVGA(800 x 480)화면

에 들어 있었다. 아이폰의 480 x 320 에 비해 두 배 이상 높은 해상도라 화면이 훨씬 더 정교하였지만

일관된 폰트 크기나 디자인적인 측면은 기존의 PDA를 보는 것과 차이를 느끼지 못했다.

위 사진의 메인 화면의 성운은 서서히 돌아가는데 화면을 스크롤하다보면 내 손가락에 따라 성운의

방향이 조금씩 바뀐다.

자세히 써보진 못했지만 멀티 데스크 탑처럼 앱의 아이콘을 5개의 영역에 배열할 수 있고 가운데

바둑판 아이콘을 누르면 여러 개의 아이콘을 모아서 원하는 기능을 찾을 수도 있었다.

화면 스크롤은 아이폰 만큼 부드럽지 못하다. 여타 제품에 비해서 매끄럽긴 하지만 스크롤 중간에

다른 태스크로 전환되는 듯한 화면이 튀는 느낌이 있다. 아이폰과 달리 UI 처리에 최우선 순위를

주고 있지 못한 것 같다. (안드로이드의 UI 처리 구조의 문제일 수도 있으나 공부를 하지 않았으니

속단은 금물이다) CPU가 아이폰보다 빠르니 더 부드러워져야 하는 것 아니냐는 사람도 있겠지만

하드웨어 가속이 되는 스마트폰의 경우 CPU 속도와는 큰 차이가 없다. 최적화 보다는 무엇이 더

중요한가 라는 질문에 따른 설계 철학의 문제라 본다.

멀티터치가 가능함에도 미국에서 판매하는 제품에는 멀티 터치를 지원하지 않는다고 한다. 아마도

애플의 특허 때문이라 생각하는데 두 손가락으로 사진을 줌 인/아웃을 하는 동작을 꼬집다는 뜻의

pinch 기능을 쓰지 못하는 것은 무척 아쉬운 것 중의 하나다.

(얼마전 옴니아2에서 박진영 씨가 두 손가락으로 웹 브라우저를 확대하려고 무척 애쓰는 것을 보면서

웃었는데 옴니아2에서도 pinch 기능을 지원하지 않는다)

다른 브라우져를 올려서 멀티 터치 브라우징이 가능하게 한 사람도 나왔으니 조만간 해결책이 나오

지 않을 까 생각한다.

뒷 면은 500백만 화소의 플래시를 장착한 카메라가 달려있다. 사진의 오른쪽에 보이는 슬릿 구멍은

스피커 구멍이다. 아이폰처럼 하단에 스테레오로 달려있지 않고 뒷 면에 하나만 달려있는 것이 특이했다.

뒷면 케이스에 그려진 그림은 구글 직원들에게만 제공된 것에만 그려져있다고 하는데 안드로이드가

흔드는 깃발안의 2차원 바코드가 무척 궁금했다. 내 아이폰의 앱에는 2차원 바코드 리더가 없어서

결국 넥서스 원의 카메라로 인식해서 무슨 의미인지 알아냈다. 마지막 사진이 그 내용이다.

배터리 교환을 위해 뒷 면 커버가 분리되는데 금속 재질은 아니었다. 안테나가 있을 것으로 추정되는

하단 부분도 부드러운 코팅이 된 플라스틱으로 보인다.

가운데 얇은 배터리에는 HTC innovation 이라는 글자가 선명하게 보인다. 기계식 줌이 달린 카메라와

LED 플래시, 스피커를 볼 수 있다. 앞의 사진에서는 명확하게 보이지 않는데 왼쪽에 아주 작은 구멍이

케이스에 나 있는데 노이즈 캔슬링을 위한 마이크라고 한다. 그래서 통화 중에 환경음을 제거하여

통화 품질이 좋다고 한다.

아랫쪽에는 4GB 마이크로 SD 카드와 SIM 카드를 꼽을 수 있는 곳이 보인다.

배터리 탈착이 가능하므로 사용이 많은 사람들에게는 안심일 것이다.

하지만 배터리 탈부착이 가능하면 충격에 의해 배터리가 갑자기 튕겨져 나가는 위험이 있어서

동작 중인 스마트폰에게는 치명적인 문제 - 갑자기 전원이 나가면서 생기는 플래시 파일 시스템

크래시나 미처 플래시에 저장하지 못한 정보의 손실 - 로 인해 AS를 받아야 할 수도 있다.

애플이 아이폰이나 아이팟에서 배터리 교체를 전혀하지 않는 이유 중에 의도치 않은 전원 차단으로

인한 시스템 크래시 방지가 가장 크다고 생각한다. 아예 하드 리셋 버튼 구멍 - Palm을 쓴 사람들은

시스템이 먹통이 되면 이 리셋 버튼을 눌러댔다 - 을 없애 버린 것도 갑작스런 리셋이나 전원 차단을

막겠다는 것이다. 모든 것을 통제하겠다는 애플의 철학과도 일치한다. 하지만 안드로이드는 그런

철학을 가지지 않았으므로 일반 PDA와 같다. 휴대폰 처럼 함부로 배터리를 빼지 않기 바랄 뿐이다.

앞서 말한 것처럼 뒷 면에 있던 2차원 바코드를 넥서스 원에서 인식 시킨 화면이다.

http://www.android.com/holidays 라는 링크가 인식되는데 실제 가보면 www.android.com 으로

바뀐다. 아마도 기획되었다가 취소된 사이트로 보인다.

인식한 URL을 세 가지 방법으로 전송하는 화면이 떠 있는데 브라우저를 선택하였으면 WebKit 기반의

웹 브라우저가 뜬다. 아직 크롬이 아닌 것이 의아한데 아마도 크롬이 나오기 전부터 최적화

된 것이라 계속 쓰이고 있는 것이 아닌가 싶다.

아주 잠깐 만져본 것이라 사용기까진 아니고 만져본 소감기 정도라 보면 될 것이다.

지난 주에 국내 첫 개통자도 나왔으니 조만간 많은 사용기를 웹에서 볼 수 있을 것이라 생각한다.

@모루