싱글스레드 모델이 액터 모델(Actor-Model)보다 나은 X가지 이유

1. 액션(동작) 순서 컨트롤이 된다. 액션의 페이스를 컨트롤할 수 있다. 예를 들어 30fps 로 모든 몹의 x좌표 더하기 1. 액터 모델에서는 비동기라서 그 액션이 어느 프레임에 들어갈찌 모른다.

2. 디버깅이 쉽다.
2.1 액터 모델에서는 글로벌 상태에 브레이크 포인트를 찍은 후에 매개인의 메일박스를 검사해야 하는 번거로움이..
서버의 경우 클라와 달리 브포보다 로그가 더 유용할 경우가 많다. 예를 들어서 Joe Armstrong 과 Richard Stallman 등 분들이 모두 printf 디버깅 방식을 더 선호한다는 소문이… 하지만 서버가 클라만큼 상태가 복잡할 경우, 브포(==시간정지) 를 통한 글로벌 상태 파악이 극히 중요해질 때가 있다.
2.2 그리고 액터 모델은 비결정론적이라서 어떤 버그들이 어떤때는 재현되고 어떤 때는 재현되지 않을 수 있다. (그러고보니 2.2 항목은 LMAX 의 장점만 말하면 다 나오네.)

3. 반경 10메터안 모든 몹들에게 범위공격. 액터모델의 경우 남의 좌표를 알 수 없어서 일일이 물어야 한다. “님 좌표 얼마임?” (그렇지 않으면 좌표를 좌표테이블에 등록해야 하는데, 그러면 액터모델이 아니게 됨) (IO 오버헤드, 코딩 코스트)

4. 로드밸런싱따위 필요없다. 액터모델의 경우 (스케쥴러에 따라 다르지만) (어차피 스케쥴러 연구하는 사람은 없으니) 액터 로드밸런싱이 필요한 경우가 있다(Skynet 역사 참조). 반면 싱글스레드 모델에서 프로그래머는 신이고, 로드밸런싱따위 필요없다.

5. 트랜잭션?

6. 클라도 싱글스레드 모델이잖아.

7. CPU 성능에 좋다 (동일언어) (사실 이건 가장 중요하지 않은 원인이다) (늘여쓰면 글한편감이라 자세한 내용은 생략한다).

결론: 두 모델이 서로 다른 문제 도메인 (Problem Domain) 에 적합할 것 같다는거다:

  • 액터모델은 격리성, 분산성과 faul-tolerance 가 골(goal)에서 제일 중요한 경우 또는 message-passing 자체가 문제를 잘 모델링할 경우 (IM, Instant Messenger: e.g. Facebook Messenger, Whatsapp, etc.)
  • 싱글스레드 모델은 글로벌 상태 컨트롤이 중요한 경우. 예를 들어 게임. (시뮬레이팅 문제?)

적재적소(適材適所).

길게 쓰면 아무도 안읽으니 이번에도 후딱 끝내는 미덕을 발양하겠다.

(끝)

차세대 실시간 게임서버 엔진 Century 설계 설명

피터 틸의 <ZERO to ONE> 은 이런 물음으로 시작된다:

사람을 채용하려고 면접을 볼 때 내가 자주 하는 질문이 하나 있다.

“정말 중요한 진실인데 남들이 당신한테 동의해주지 않는 것은 무엇입니까?”

그리고 책 중간에도 이런 문장들이 있다:

“대부분의 사람들은 더 이상 찾아낼 숨겨진 비밀이 없는 것처럼 행동한다.” (P126)

“사람들이 숨겨진 비밀을 무서워하는 것은 틀릴까 봐 무서워하기 때문이다. 숨겨진 비밀이라면 당연히 주류 세력의 점검을 받은 적이 없다. 인생에서 실수하지 않는 것이 목표인 사람은 숨겨진 비밀을 찾아다니면 안 된다. 혼자서만 옳은 것도 쉬운 일이 아닌데, 혼자이면서 ‘틀리는 것’ 은 견딜 수 없을 테니 말이다.” (P130)

“세번째 추세는 ‘무사 안일주의’ 다. 사회의 엘리트들은 새로운 사고를 탐구할 수 있는 자유와 능력을 가장 많이 지녔다. 하지만 그들이야말로 숨겨진 비밀을 가장 믿지 않는 사람들인 것 같다. 이미 다 해놓은 것들을 토대로 편안하게 지대(地代)나 받고 있으면 되는데, 무엇하러 새로운 숨겨진 비밀을 찾아 해매겠는가?” (P130)

“숨겨진 비밀을 찾겠다는 포부를 가진 사람들은 먼저 이렇게 자문하게 될 것이다. ‘뭔가 새로운 것을 발견하는 게 가능하다면 똑똑하고 창의적인 글로벌 인재들 중 누군가가 벌써 발견하지 않았을까?’ ” (P131)

“숨겨진 비밀은 찾아다니지 않으면 발견할 수가 없다. 이 점을 잘 보여준 사람이 페르마의 마지막 정리를 증명한 앤드루 와일스였다.” (P135)

“진짜 진실은 아직 찾아내지 못한 숨겨진 비밀들이 많이 있다는 점이다. 하지만 그 비밀들은 오직 그칠 줄 모르고 찾아 헤매는 사람들에게만 그 모습을 드러낼 것이다.” (P136)

“숨겨진 비밀을 믿고 그것을 찾아다니는 것만으로도 우리는 보편화된 관습을 넘어 뻔히 보이는 곳에 숨어 있는 기회들을 볼 수 있다.” (P137)

“숨겨진 비밀을 발견한 사람은 선택의 기로에 놓인다. 누군가에게 얘기를 할 것인가? 아니면 혼자서 간직할 것인가? 이는 숨겨진 비밀의 종류에 달려 있다. 파우스트가 바그너에게 들려준 것처럼 위험한 진실들도 있으니까 말이다.” (P141)


Continue reading

[퍼옴] Ndc2014 시즌 2 : 멀티쓰레드 프로그래밍이 왜 이리 힘드나요? (Lock-free에서 Transactional Memory까지)

웬만해서는 블로그에 퍼온 내용은 올리지 않을려고 했는데…

이건 올려야 해 ( __ __)\

NDC 2014 세션 키노트:

SlideShare 사이트 링크:

Continue reading

LMAX 거래소가 게임서버 아키텍쳐에 주는 계시 #2

부제: <거래엔진의 참조가치가 어느 정도인가?>

1편에서는 LMAX 아키텍쳐를 소개하고 (소개했다기에는 부끄러울 정도로 간략하게 소개하고) 그것을 성공 사례의 거울로 한번쯤 비추어보자고 말했습니다.

그럼 제기할 수 있는 한가지 자연스러운 질문은: 거래엔진이 뭐 게임 서버도 아닌데, 뭐 어뜨케 참조하잔 말야? 참조할 가치가 있냐? 가 되겠습니다.

제2편에서는 이 문제들을 대답하기 위해 노력을 해보겠습니다.

간단한 대답은 이렇게 되겠습니다: 그렇습니다, 다릅니다. 거래 엔진은 거래 엔진이고 게임 서버는 게임 서버겠죠?

하지만 게임 서버도 게임 서버와 다릅니다. 실시성에 대한 요구가 높은 게임 서버도 있고 실시성에 별로 요구가 없는 게임 서버도 있습니다. 오케이, 알겠습니다. 보다 의미있는 비교를 위하여 이 글에서는 “게임 서버” == “실시간 게임 서버” 로 한정하겠습니다. 그렇다고 하더라도 실시간 게임 서버가 다 같은 건 아니겠죠? 거래 엔진도 거래 엔진이라고 해서 다 같은게 아닙니다.

무엇보다 유사성을 논할 때 우리는 특성들의 집합을 두고 논해야 하는거지 그것이 뭐라고 “불리는가”에만 의뢰하여 유사성을 판단할 수는 없습니다.

그러면 문제는 아래와 같은 형태로 전환됩니다:

거래 엔진과 실시간 게임 서버는 어떤 면에서 유사하고 어떤 면에서 다를까요?

사실상 거래 엔진과 실시간 게임 서버는 많은 특성들을 공유하고 있습니다:

  • 1. 높은 스루풋을 희망한다. (그 단위는 업계에서 공인 되는 건 여러가지가 있지만 여기서는 “TPS”로 하겠습니다.)
  • 2. 레이턴시를 최소화 하고 싶어한다.

— 1 과 2 의 원인으로 양자는 모두 아래와 같은 특점들을 지니게 됩니다.

  • 3. socket 서버이다.
  • 4. 유상태(stateful) 아키텍쳐를 취한다. (모두 “DATABASE IS DEAD”란 화제에 휩쓸리기 좋은 예제이다. 취소선.)
  • 5. 서버가 request / response 모델로도 구현이 가능하지만 성능과 실시성을 높이기 위해서는 보통 서버에서 클라에 푸시하는 방식도 있기를 원한다.
  • 6. IO boundary. (게임 서버의 경우 CPU boundary 일 수 있는데 이는 뒤에서 논하겠다)

— 그리고 semantic 각도에서

  • 7. 리퀫에는 “술어”(predicate) 가 포함되는 경우가 허다하다.

이는 아래의 공통된 특성을 초래합니다:

  • 8. C / S 통신의 내용에는 RPC 가 많다.

— 그리고  Continue reading

LMAX 거래소가 게임서버 아키텍쳐에 주는 계시 #1

LMAX Exchange 란 무엇인가?

2010 년에 영국 런던에서 창립되였는데 첫 온라인 외환거래소라고 합니다. 영국에서 성장이 가장 빠른 핀테크 업체이기도 하답니다. [1] [2]

LMAX 거래소가 최근 기술영역에서 주목받게 된 이유는 LMAX 가 업계 최고 성능을 자랑하는 마켓 엔진 아키텍쳐를 발표했기 때문인데요, 도대체 얼마만큼의 성능이 되냐구요?

비교대상으로 우리가 익숙한 고성능 시스템을 살펴봅시다.

  1. VISA 는 평균 2,000 TPS 성능으로 돌고있다고 합니다. [3]
  2. NASDAQ 의 자료에 의하면 NASDAQ 의 전대 엔진의 성능은 10,000 TPS 였고 그때는 그걸로 자랑을 했었습니다. [4]
    지금의 NASDAQ 는 35,000 TPS 부하로 돌고있다는 것을 들은 적 있는데 출처는 찾지 못하겠습니다. 이건 그냥 그럴 수도 있겠거니 정도로 들어주시면 됩니다.
    현재 최신의 NASDAQ 마켓 엔진도 고성능 솔루션을 연구하여 백만 TPS 의 성능을 낼 수 있다고 합니다. [5]
  3. redis 의 set 성능은 100,000 TPS 입니다. pipeline 모드를 켜면 400,000 TPS 입니다. [9]

그건 그렇고 오늘 말하려고 하는 LMAX 의 스루풋 절대수치는 얼마인가요?
무려 600 만 TPS 에 이른다고 합니다. [8]

LMAX 를 알게 된 것은 Bitshares 를 통한 것인데요. [6] [7]  Continue reading