LOGIN • JOININ

webmaster

1. asio에 비효율적인 예제로 테스트를 했다. strand는 왜 사용하지 않았나.

asio 지적에 대해서는 이 글 댓글의 앞에 분들께서 이미 많이 지적을 사셨으니 댓글을 한번 쭉 일어보시길 바랍니다.

strand에 대해서도 이미 앞에 여러분들께서 언급을 하셨습니다. (근데 이 테스트에서 strand를 사용한다고 성능이 향상되진 않습니다.)

아직까진 없었지만 만약 asio가 제대로 성능을 발휘하지 못하게 설계되었다면 제안해 주십시요.


2. asio가 표준안 채택 가능성 높다.

또 앞에서도 여러 차례 말씀드렸듯 asio가 훌륭한 library입니다. 그래서 많은 분들의 지지를 받고 있습니다.

하지만 그 만큼이나 한계를 지적하시는 분들도 많아서 표준안 채택에 논란도 많은 것으로 알고 있습니다.

C++ 네트워크 표준은 C++14에 결정되기로 되어 있었지만 여전히 여러 논란으로 아직 확정이 안된 걸로 알고 있습니다.

현실적으로 C++ 네트워크 표준안은 꼭 필요는 한데  asio 외에 다른 표준안의 대안이 딱히 없는 상황이라 asio이 표준안 가능성이 높긴하지만 또 한계도 많이 지적되다 보니 미뤄지고 있는 것으로 알고 있습니다.

개인적으로도 asio가 표준안이 되어서 공급이 된다면 반가울 것 같습니다. 

C++으로 작성만 하면 플랫폼 상관없이 네트워크 프로그래밍이 가능하니 매우 편리하리라고 생각합니다.  게임 클라이언트나 툴들 그리고 이런 테스트용 소프트웨어 제작에 더할나이 없이 훌륭한 도구가 될 것 같기 때문입니다.

무엇보다도 익숙하다는 점이 가장 큰 장점이 되겠죠.

근데 서버(특히 고부하 고성능을 요구하는 MMO 게임 서버)라면  좀 더 복잡한 고려가 필요하리라고 생각합니다.

asio는 표준을 기준으로 설계가 되어 진다면 분명 특정 플랫폼이나 용도에 특화되어 최고의 성능과 안정성을 발휘하게 하는 것에는 한계가 있을 수 있을 수 밖에 없고 또 이런 최고의 성능과 안정성이 필요한 곳에서는 범용적인 api는 최고의 선택이 아닐 수 있기 때문입니다.

Web서버나 간단한 모바일 게임류의 경우 Restful형 서비스로 제작가능해서 Scale-Out이 간단했고 또 서버나 프로세스가 죽더라도 다시 다른 서버에 접속하면  되기에 어느 정도의 불안정성도 크게 문제가 되지 않았습니다만 MMO서버는 훨씬 고부하 안정성과 고성능을 요구합니다.

왜냐면 MMO게임은 기본적으로 Restful 시스템이 아니기에 Scale Out이 쉽지 않기 때문이죠.

예를 들어 공성전을 진행한다면 한 서버에 얼마나 많은 사용자를 처리하냐가 한꺼번에 많은 사용자가 공성전에 참여할 수 있는가를 결정합니다.

또 서버가 죽어 버리거나 문제가 생기면 다시 다른 서버에 접속하면 되는 정도로 다시 복구가 되지 않습니다.
즉 고부하 상태에서도 절대 죽지 않는 것을 요구하는 것이죠. 

또 이런 고부하는 특정 시간이나 특정 서버로 몰리는 경향이 많아서 이런 부하에 대한 내성은 필수 입니다. 

예를 들어 MMORPG 게임 중 특정 지역에 어떤 이벤트가 있다면 해당 지역을 담당하는 서버에만 몰리는 현상이 발생합니다. 
이런 여러 특징으로 인해 MMO서버는 안정적 서비스를 위해서는 범용성 높은 API보다는 훨씬 더 고부하 내성을 가질 수 있는 각종 저수준 기술들도 요하게 되며 한 서버에 최대한 많은 유저를 받을 수 있는 고성능은 매우 중요합니다. 

 따라서 다양한 플랫폼을 모두 수용하는 범용적인 인터페이스와 범용적 목적으로 설계된 API보다는 플랫폼에 특화되어 최고의 성능과 안정성을 얻을 수 있도록 제작된 API나 서버 엔진들이 필요로 하게 되는 것이죠. 


2000년대 초 MMO서버가 거대한 붐을 이룰때 1년에 300~400개의 MMO게임 프로젝트가 제작되었었다고 합니다. 근데 그 중 오픈베타 정도 수준까지 도달하는 것은 10개가 될까말까하는 수준이었고 그마저도 태반이 서버 기술의 한계로 서버가 다운되거나 장애를 발생시켜 게임 서비스 실패의 주요 원인 중에 하나가 되었습니다.

(앞에서도 설명했듯이 MMO서버는 동기화문제 순간적 몰림 현상으로 인한 고부하 문제 등은 실제 서비스를 해보기 전에는 그 중요성이나 해결책을 인지하는 경우가 많았기 때문이고 인지했을 때는 이미 손을 쓸수 없이 늦은 상태였죠.  당시는 서버 기술의 척도가 하나의 물리 서버에 얼마나 많은 동시접속자를 처리할 수 있느냐가 되기도 했었고 투자자들도 항상 물어보는 질문중에 하나가 서버의 동접처리 능력이었을 정도였습니다.)

 근데 최근 모바일 게임의 시대가 되며 주로 단독(Stand-alone)형 게임이 주류를 이루다보니  Restful 형태의 웹서버에 준하는 구조가 많이 사용될수 있어 Scale-Out으로 대규모 사용자나 서버의 불안정을 커버할 수 있었습니다.

쉽게 말해서 Restful형 서버의 경우 서버가 좀 불안전해서 다운되더라도 큰 문제가 되지 않았습니다. 어느 서버에 접속해서 처리되더라도 문제가 없으니 그냥 다른 서버에 접속하면 되니 말이죠.

또 성능의 문제 역시 그냥 같은 서버를 하나 더 띄우기만 하면 되므로 Scale-Out이 매우 용이한 면이 있었습니다.
하지만  사용자간 상호작용이 많은 게임 특히 MMORPG 게임 서버는 그  컨셉과 요구 사항까지 좀 다른 개념이 적용된다는 것이죠. 
 이제 모바일 게임들도 점점 대형 MMORPG들이 등장하기 시작했고 앞으로 대세가 될 가능성이 높습니다.
 MMORPG가 아니더라도 최소한 유저간의 상호 통신이 중요해질 가능성이 높다는 것이죠.

이런 상호작용이 많은 게임 서버의 문제들은 그 서버가 실제 서비스 하기 전에는 그 심각서을 파악하지 못하는 경우개 매우 많습니다.

restful 시스템의 경우 사용자가 많아진다고 해서 복잡성의 문제가 그렇게 심각해지지 않습니다.

하지만 상호 작용이 많은 서버의 경우 소수 테스트할 때와 실제 환경에서 다수 테스트 할 때 발생하지 않았던 수많은 문제들이 발생하게 되고 이 문제는 보통 서비스를 오픈한 이후에야 자각하게 되는 경우가 많습니다만 그 때는 이미 돌이킬수 없는 상황이란 점을 고려한다면 저수준API나 서버 엔진의 선택에 좀 더 많은 고민이 필요하지 않을까 생각합니다.