https://coolspeed.wordpress.com/2016/02/11/century_design_philosophy/


Go언어 게임서버 검색하다 걸린 글인데 Go언어랑 상관없이 재미지다





통념 1: 게임 서버에게는 CPU 성능이 제일 중요하다


사실은 IO boundary (물리나 공간관계 연산이 많지 않은 한)


Redis 도 IO boundary. (이 문장은 필자가 내린 결론이 아니라 redis 개발자가 내린 결론.)


여기에서는 논거나 논증을 생략하겠다. 업계 구루가 쓴 책에서도 내린 결론이다. 다만 충분히 널리 알려지지 않았다고 생각해서 열거한거다.


통념 2: 멀티스레드는 싱글스레드보다 빠르다


통념 1 의 결과를 참조하면 알 수 있는데, 게임서버에 있어서 무거운 연산 타스크가 없는 한, 병목이 아닌 상태변경자(Business Logic Processor, BLP)를 병렬화하는 것은 성능향상을 가져올 수 없을뿐더러 동기화의 부담(성능부담 & 복잡성 부담)을 가져온다.


통념 2.1: 상태 변경자는 느리다.


진실: 상태 변경자는 매우 빠르다. 전체 게임서버에서 상태변경자만큼 빠른 부분도 없다. (LMAX를 봐라) (이 부분은 순수(pure)하다.)


통념 2.2: lock-free 를 사용하면 동기화문제에서 벗어날 수 있다.


진실: lock-free 도 동기화이다(CPU instruction 입도의 동기화일뿐). atomic 연산도 비교적 느리다.


추가로 lock-free 는 쉽지 않다. 특히 게임 서버에서 흔히 사용하는 객체들 예를 들어 player 등은, lock-free 자료형으로 표현하기 쉽지 않다. 다른 흑마법들이 필요하다.


redis vs memcached


LMAX 6M TPS


(LMAX architecture 소개글, not only how, but also why)


주의: 비즈니스 로직 프로세서, 즉 상태변경자에서 스크립트를 무절제하게 사용하기 시작하면 상태변경자가 병목이 될 수도 있고, 병렬화를 통한 이득을 볼 수도 있다.


통념 3: 일부 멀티스레드 프로그램은 버그가 가득하다.


진실: 스레드를 사용하는 대부분의 프로그램들은 버그로 가득 차 있다.


— Havoc Pennington @ Dreamforce 2011


RWlock 을 spinlock 으로 바꿨다고 자만하고 있을지도 모르지만, spinlock 도 블락킹이다. (일례로)


통념 4: 게임서버는 빠를수록 좋다


진실: 일정한 수준 (redis 정도) 이상 올라가면 추가의 성능향상은 의미가 없다


고성능 테크닉들 ( STL 사용 거부, try..catch.. 거부, 스마트 포인터 거부 등등.. 이 리스트는 아주 길 수 있지만 여기서는 생략한다) 을 사용하여 사실 redis 보다 한개 수량급(즉 10배) 빨라질 수 있다. 하지만 대부분의 콘텐츠개발자는 이런 테크닉들에 대한 요해가 부족하거나 이런것까지 신경쓸 시간적 여유가 안된다. 동적 메모리 할당을 무분별 도입하는 순간, 예외처리를 도입하는 순간, 코어 레이어에서 사용한 모든 고성능 테크닉들의 가치는 신속하게 소멸될 것이며 전체 시스템 스루풋은 redis 수량급으로 떨어진다(사실 redis와 비슷한 성능을 내주면 이미 굉장히 잘한 것이다).


결국 (절대적이진 않지만) 당신이 게임서버 엔진을 어떻게 짜든 당신의 실시간 게임 서버는 redis 보다 현저하게 (하지만 수량급은 같을 수 있고 또 같아야 한다) 느릴 수 밖에 없다.


통념 5: 벤치마크는 유용하다


진실: 벤치마크 결과비교는 늘 생산성의 적인데, 후자가 훨씬 중요하다.


LIES, DAMN LIES, AND BENCHMARKS


라는 업계 클리셰도 있다.


VM 개발자들이 늘 하는 말:


마이크로 벤치마크 결과를 믿지 마라.


프로그래밍은 결국은 복잡성에 대한 통제이다. 그렇지 않으면 모든 프로그램 개발에서 어샘블리 언어를 사용하지 않는 이유를 설명할 수가 없다. Node.js 작자가 libevent (실은 당시는 libev였고 현재는 libuv라지만)를 사용하여 node.js 를 만든 목표는 libevent의 성능을 향상시키기 위함이 아니라 복잡성을 다스리기 위함이였는데, 후자가 훨씬 “0에서 1을 창조”한 셈이다.


사내 정치, 커뮤니티 입소문으로는 생산성의 가치가 굉장히 저평가되고, 반면에 일견 증거가 든든해보이는 벤치마크 결과들이 과대평가 될 수 밖에 없는 구조다. 생산성은 양화하기 어렵기 때문이다.


통념 6: 서버 노드당 동접수는 중요하다


진실: (경제 계산상) 물리기계 대당 동접수가 중요하지 프로세스당 동접수는 중요하지 않다.


Seamless MMOG 를 제외한 대부분의 게임 서버 시스템은 분산 저항성 (Partition Tolerance) 이 그렇게 약하지 않다. Seamless MMOG 일지언정, 대부분의 경우는 멀티스레딩 ( or 멀티스레딩 + 멀티 프로세싱) 은 멀티프로세싱 only 보다 분산으로 인한 (트래픽) 부하 패널티가 그렇게 크지 않다.


일부 논점들에는 근거들을 대지 않았는데, 그런 부분들은 모두 업계에 이미 잘 알려져 있어서 논증할 필요가 없다고 판단한 부분들이다. 물론 매 한마디 말에도 반대하는 사람이 많을지도 모른다. 그런 말들에 일일이 반박할 수는 없을 것 같다.