[바미] MMORPG 서버 구조에 대해 알아보자.(2)(싱글프로세스 vs 멀티프로세스)

저번에 이어서 싱글프로세스 구조와 멀티 프로세스 구조의 차이에 대해 좀 더 알아보도록 하겠습니다.

싱글 프로세스 구조를 알아봅시다.

싱글프로세스 구조는 프로세스가 하나 즉 프로그램 하나가 돌아가는 걸 의미하는데 이게 개념적으로 이렇다는 얘기지 꼭 싱글 프로세스 구조라고 해서 프로그램이 무조건 하나다. 라고 볼 수는 없습니다. 단순히 봐서 싱글 프로세스 구조면 게임서버 하나다. 라고 보면 됩니다.

 

하나의 게임 서버로 어떤 서비스가 게임이 서비스 된다라고 봤을 때 이걸 싱글 프로세스라고 보면 됩니다.

예를 들어 봅시다. WOW라는 게임이 있는데 WOW의 월드가 여러가지가 있는데 각 월드가 하나의 프로세서로 돌아간다면 싱글 프로세스로 볼 수 있고, 여러 게임 프로세스들이 하나의 월드를 구성한다면 멀티 프로세스로 볼 수 있습니다.

 

싱글 프로세스다!라고 하는 것은 왜 게임 서버를 하나로 만드냐고 물어 볼 수 있는데 옛날 방식으로 보았을 때 Scale Up 방식이라 보면 되는데 게임 서버 성능을 올리기 위해서 장치를 더 좋은 장치로 교체하는 것을 Scale Up 방식이라고 하는데 싱글 프로세스는 Scale Up에 의존하는 방식입니다.

 

프로세스가 하나가 돌기 때문에 하나의 머신에 그 프로세스 하나만 돌리면 그 머신의 성능이 올라가면 그 프로세스도 성능이 올라가게 되는 과거에 많이 사용했었던 방식이죠. 하지만 이제 공짜점심이 끝이났습니다.

가만히 있는데 프로세스의 성능이 올라가지 않게 되는 시대가 되었죠. 이 말은 어떤 의미냐면 머신의 성능이 좋아졌다 해서 프로세스의 성능이 덩달아 늘지 않는다는 것을 의미합니다.

물론 머신의 성능이 좋아지면 처음에는 프로세스 성능도 좋아지겠지만 어느 정도의 수준이 되면 실제 프로세스 성능이 증가하는 양은 적어진다는 것입니다.

심지어 프로그램을 잘 못짜면 프로세스 성능의 증가 폭이 더 적어진다. 그래서 오히려 머신의 성능은 커졌는데 프로그램의 성능이 떨어지는 효과가 나타납니다.

공짜점심이 끝났기 때문이죠.

이런상황에서 나온것이 Scale Out 방식입니다. Scale을 퍼트렸다는 의미인데, 머신의 성능을 늘리는게 아니라 머신의 수를 늘리는 것입니다.

Scale Up방식은 싱글프로세스 구조방식, Scale Out방식은 멀티프로세스 구조방식입니다.

Scale Up은 더 좋은 머신에 프로세스를 돌리는 방법이고, Scale Out은 프로세스 하나가 머신에서 돌고 있는데 성능이 필요할 때 똑같은 머신을 하나 더 넣어서 그 안에 프로세스를 돌리는 방식입니다.

Scale Up은 하나의 프로세스가 더 좋은 머신에서 하나의 프로세스가 돌아가는 구조지만 Scale Out은 1개가 2개가 되고, 2개가 3개가 되어 수십~수백개 까지 늘려나가는 방식입니다.

그렇다면 두 방식에서는 어떤 차이가 있을까?

Scale Out과 Up을 할 경우 비용 측면을 먼저 보죠.

Scale Up을 해서 좋은 머신을 바꿀 경우 성능 좋아짐에 따라서 비용 상승 폭이 커집니다.
Scale Out방식은 같은 머신을 늘려가는 방식이기 때문에 비용이 직선으로 증가합니다.
그런데 변화가 생기는 지점이 생깁니다. 그 점에서 Scale Up 방식이 추월하게 되죠.

처음에는 Scale Up방식이 싸게 먹히기 때문입니다. (기기가 싸니까)

그런데 일정하게 증가하는 Scale Out방식과 만나는 교점이 생기게 되는데 그 부분을 넘어가면 그 때부터는 Scale Up방식보다 Out방식이 비용측면에서 더 효율적인 것으로 볼 수 있습니다.

 

기본적으로 소프트업계에서 나오는 말이 머신은 싸다는 것입니다. 그러니까 프로그래머에 비해 싸다는 것인데 좋은 프로그래머를 써서 효율적으로 코딩을 하는 것보다 값 싼 프로그래머를 쓰고 좋은 머신을 돌리는게 더 싸게 먹힌다는 속설이 있습니다.

머신(하드웨어)가 그 만큼 싸기 때문에 나온 속설이죠.

그럼에도 불구하고 예전에 비해 하드웨어의 가격이 떨어졌지만 어느정도 고 성능의 머신은 비싸다는 것을 알아두어야 합니다.

예를 들면 Scale Out방식에서는 고성능의 머신이 필요가 없습니다.

• 2Ghz 2 Core
• 8GB RAM
  

의 스펙의 하드웨어 10대를 사용한다 했을 때 1대당 20~30만원이 정도 밖에 안하기 때문에 200만원 정도가 든다고 가정하고 (이하 일 수도 있습니다.)

• 3.5 Ghz 32 Core
• 128GB RAM

의 스펙을 가진 컴퓨터는 천 만원 가까이 갈 수 있기 때문에 훨씬 더 비쌉니다.

그래서 Scale Out방식은 경제적인 측면에서 봤을 때도 더 좋다고 볼 수 있습니다.

특히 요즘에는 클라우드 컴퓨팅이 발전이 되면서 가상머신을 많이 사용하죠.

실제 머신이 있는게 아니라 그 머신의 성능을 가상화해서 머신자원을 공유하기도 하고, 일부의 자원만 가져다 쓰기도 하는 식으로 가상화를 시켰기 때문에 실제 머신이 어떻게 되어 있는지 알 수가 없습니다.

아마존의 AWS 같은 경우에 머신을 대여를 해주는데 그 가상 머신의 실제 모습을 알 수도 없고, 알 필요도 없죠.

저 성능 머신을 빌려쓰는 것은 아마존 입장에서도 크게 부담이 안되고, 가격적인 측면에서도 큰 부담이 되지 않습니다.

그래서 저 성능 머신이 10대든 100대든 간에 고성능 머신 1대보다 더 싸게 먹힐 수 있다는 것입니다.

 

그 다음에 Availability라는 것이 있는데요. 해석하면 가용성을 의미합니다. 그러니가 사용할 수 있는 정도를 말하는 것이죠.

예를 들어보면 싱글 프로세스 서버가 한 대에서 A라는 게임 서버(월드) 하나를 운영한다고 가정해보죠.

근데 A서버가 죽어서 플레이어들은 A서버가 다시 서버를 띄우기 전까지는 더 이상 A서버를 접근할 수 없게 되어 서비스가 종료가 되어버리는데 이것을 single point of failure 줄여서 SPOF 라고 합니다.
실패 할 수 있는 하나의 점 이라는 의미인데 하나의 프로세스가 죽으면 전체 서비스가 마비되는 상황이 생깁니다.

싱글 프로세스에서는 이런 문제가 생길 수 있고, 멀티 프로세스에서는 프로세스 4개가 A서버(월드)를 구성하고 있다고 가정해보죠

(채널로 나누든, Zone으로 나누든해서 구성하고 있다고 가정하죠.)

이 때 하나가 죽었을 때 나머지 프로세스들이 살아있기 때문에 서비스가 가능한 상황이라 SPOF가 작동하지 않습니다.
이 경우를 Availability, 가용성이 높다. 고 말을 합니다. 그러니까 서비스가 어떤 상황에서도 지속될 수 있다라는 의미입니다.

그래서 이게 가장 중요한 장점인데 싱글프로세스는 가용성이 낮고, 비용이 높고, 멀티프로세스는 가용성이 높고, 비용이 낮죠.

이렇게 보면 멀티프로세스 상황이 더 좋다고 볼 수 있습니다. 그래서 Scale Up 방식에서 Scale Out방식으로 자연스럽게 변화하고 있습니다.

문제는 그렇다고 해서 싱글프로세스가 안 좋냐? 그건 아니에요. 뭐든지 장 단점(Trade off)가 있지요.

 

싱글 프로세스의 장점은 하나기 때문에 구조가 단순하다는 점에 있습니다.
하나의 프로세스가 모든 걸 다 처리하기 때문에 Seamless하죠. 이는 끊어짐이 없는 상태를 말하는데 아무리 프로세스 간에 관계를 잘 처리한다 하더라도 여러개의 프로세스가 떠 있으며 각각의 프로세스들을 관리를 해주어야 합니다. 그래서 A지역에 있는 유저가 B지역으로 넘어가게 되면 어떤 단절이 반드시 있을 수 있습니다.

물론 이 단절을 눈속임해서 마치 없는 것처럼 만들 수 있지만 그러면 복잡도가 올라가게 됩니다. 여러가지 해줘야 할 것들이 많아지게 되죠.

그런데 싱글 프로세스는 A지역에서 B지역으로 넘어가도 단절이 없습니다.

그리고 버전업을 했을 때 배포를 다 해야하는데 멀티프로세스는 싱글프로세스에 비해 배포할 양이 훨씬 늘어나게 되죠.

멀티프로세스 서버가 10개이고, 싱글프로세스는 1개이기 때문에 배포하고 서비스하는 과정이 멀티 프로세스가 굉장히 복잡한 과정이 생기게 되는데요.

그러다 보니 아까 말했듯이 Scale Up에서 Scale Out 방식으로 바꾸어 갔다고 말했는데 싱글 프로세스에서 멀티 프로세스 상황으로 바뀌다 보니까 프로세스의 갯수가 10개는 기본이고, 몇백개씩 증가가 되는데 이것을 사람의 손으로 관리 할 수 없게 됩니다.
싱글 프로세스에서는 서버가 몇개 안되기 때문에 사람이 일일이 관리가 가능했지만 멀티 프로세스로 넘어오면서 불가능하게 되었습니다. 그래서 멀티 프로세스로 넘어오면서 자동관리,형상관리, 자동배포가 중요하게 되었기 때문에 자동관리 프로그램들이 생겨났습니다. 빌드를 자동화 해주는 젠킨스, Ansible, Chef, 등등 이 생겨난 것이죠.
그 외에도 Docker, AWS 등 너무 많아지다보니 이것을 할 줄 아는 사람들이 새로운 직업군이 생겨났습니다.
이런 것들을 DevOps라고 하는데 이런 것들을 전문적으로 하는 사람들이 생겨날만큼 복잡해졌습니다.
그럼에도 Scale Out으로 가는 이유는 Scale Up으로 하기엔 비용이 높고, 가용성이 낮기 때문이다.

	Scale UP	Scale Out
구조	싱글 프로세스 방식	멀티 프로세스 방식
장점	구조가 간단하다. 지역 이동 시 단절 효과를 줄 필요가 없다.	가격이 싸다. 가용성이 높다.
단점	가격이 비싸다. 가용성이 낮다. SPOF가 발생 할 수 있다.	관리가 복잡하다. 지역 이동 시 단절 효과를 주어야 한다. (로딩 등)

그러면 멀티프로세스는 MMORPG에서 어떻게 구성할까요?

예를 들면 2가지 방식으로 나눌 수 있는데 수평으로 나누는 방식과 수직으로 나누는 방식으로 나뉩니다.

수평으로 나눈다는 것은 A,B,C,D월드가 있다 가정했을 때 각 프로세스들 P1 ~ P4가 각각 맡게 되는 것인데요.

지형지물(Zone)로 나누는 것인데 이 때 중요한 것은 A에 있던 유저가 B로 이동할 때 어떻게 처리할 것인가인데 가장 간단한 방법은 로딩화면을 넣어주는 것이고, 걸어서 A에서 B로 Seamless하게 넘어가고 싶다면 별도의 처리가 필요합니다.

수직으로 나눈다는 것은 같은 Zone이라도 중첩해서 나눌 수 있는 것인데요.

 

예를 들면 어떤 지형이 있는데 유저가 5000명이 모여 있다 가정할 때 하나의 프로세서들이 50000명을 감당하지 못하니까 하나의 채널로 나누어서 500명씩 프로세스 10개를 돌려서 나눌 수 있는데

 

이 방식을 채널로 나눈다 해서 Channel방식 이라고 합니다. 그래서 Zone방식이 있고, Channel방식이 있는데 같이 써도 상관이 없어요.

각 지역을 수평적으로 나누고, 여러개의 멀티프로세스로 채널로 나눠도 됩니다.

나누는 것보다 그것들을 관리하는게 제일 중요해서 그것들을 관리해주는 서버가 필요한데, 버전업이 되었을 때 배포하고, 빌드하고, 사고 발생 시 문제를 판단하고, 모니터링해서 고치는 상황들이 복잡해집니다.

이것들을 어떻게 잘 하느냐가 멀티프로세스 서버를 잘 만드는 방법중에 하나이고, 그것을 전문적으로 하는 직업군을 DevOps라고 합니다. 

 

그래서 다음 시간에는 굳이 싱글 프로세스를 하고 싶거나 멀티 프로세스라고 하더라도 각 프로세스가 싱글 쓰레드로 구성될 것이냐? 멀티 쓰레도 구성될 것이냐?는 또 다른 얘기인데 싱글 프로세스에서는 클럭 수가 높지 않기 때문에 멀티 쓰레드를 써야 하는 상황이고, 멀티 프로세스 상황이라 하더라도 싱글 쓰레드를 쓰느냐 멀티 쓰레드를 쓰느냐는 또 다릅니다.

그랬을 때 MMORPG에서 멀티쓰레드의 구조를 어떻게 만들것인지에 대해 알아보도록 하겠습니다!

 

ckdqja135/Typescript-restful-starter