[Book] 게임 서버 프로그래밍 교과서 - 1장 멀티 스레딩 (3)

1장 멀티 스레딩

 

10. 싱글 스레드 게임 서버

많은 상용 게임 서버는 CPU가 여러 코어로 구성되어 있다. 따라서 게임 서버를 싱글 스레드로 구동하는 경우 코어 하나만 사용하게 되는 비효율성 문제가 생긴다. 그래서 싱글 스레드 서버를 구동하는 경우 CPU 개수만큼 프로세스를 띄우는 것이 일반적이다.

 

싱글 스레드, 멀티 프로세스

 

• 각 서버 프로세스는 방을 여러 개 가지고 방에서는 플레이어 하나 이상이 싱글 플레이 혹은 멀티 플레이를 한다.
• 플레이어 정보를 로딩할 때 발생하는 디바이스 타임을 처리하는 과정에서 큰 시리얼 병목이 일어난다. 이를 해결하고자 비동기 함수나 코루틴 같은 것을 사용하기도 한다.
• 방 개수만큼 스레드나 프로세스가 있으면 스레드나 프로세스 간 컨텍스트 스위치의 횟수가 증가한다.
• 같은 동시접속자를 처리하는 서버라고 하더라도 실제로 처리할 수 있는 동시접속자 수를 크게 떨어뜨린다.

 

11. 멀티 스레드 게임 서버

멀티 스레드로 서버를 개발하는 경우는 주로 다음과 같다.

• 서버 프로세스를 많이 띄우기 곤란할 때: 프로세스당 로딩해야 하는 게임 정보의 용량이 매우 클 때
• 서버 한 대의 프로세스가 여러 CPU의 연산량을 동원해야 할 만큼 많은 연산을 할 때
• 코루틴이나 비동기 함수를 쓸 수 없고 디바이스 타임이 발생할 때
• 서버 인스턴스를 서버 기기당 하나만 두어야 할 때
• 서로 다른 방이 같은 메모리 공간을 액세스해야 할 때

 

멀티 스레드

 

한 프로세스에 멀티 스레드로 작동하는 게임 서버의 모델이다.

이를 코드로 구현하면 아래와 같다.

 

게임 서버 메인, 게임 방, 뮤텍스

 

• 게임 서버 메인은 방 목록을 가지며 방 목록에는 각 방이 들어간다.
• 각 방은 뮤텍스를 가지며 또 게임 서버 메인 자체도 뮤텍스를 가진다.
• 플레이어 행동에 대한 처리는 각 방을 잠근 후에 한다.
  • 공통 데이터(방 목록 등)를 잠근다.
  • 플레이어 A가 들어 있는 방을 방 목록에서 찾는다.
  • 공통 데이터를 잠금 해제한다.
  • 찾은 방을 잠근다.
  • 플레이어 A의 방 안에서 처리를 한다.
  • 방을 잠금 해제한다.

MyGameServer.DoSomething(playerID)
{
    lock(m_critSec);
    room = m_roomList.find(player);
    Unlock(m_critSec);
 
    lock(room.m_critSec);
    room.DoSomething(playerID);
    Unlock(room.m_critSec);
}

 

12. 스레드 풀링

멀티 스레드 모델의 게임 서버를 만들 때 스레드는 몇 개를 만들고 각 스레드는 어떤 일을 하면 좋을까?

 

가장 쉬운 방법은 클라이언트마다 스레드를 배정해 주는 것이다. 이러한 방법은 개발은 쉽지만 스레드 개수가 매우 많아지므로 여러 가지 문제가 발생할 수 있다.

• 각 스레드는 호출 스택을 가지는데 이를 저장할 메모리 공간이 매우 커진다.
• 컨텍스트 스위치 연산은 무거운 작업인데 이를 매우 자주해야 한다.

 

앞선 방법은 거의 활용하지 않고 자주 사용하는 방법은 스레드 풀링이다.

 

스레드 풀링

 

공중 화장실에는 문이 여러 개가 있고 기다리는 사람들은 일렬로 줄을 서서 기다린다. 사용 중이 아닌 문이 하나라도 있으면 들어가고 모든 문이 사용 중이면 기다려야 한다. 이때 각 문은 스레드이고 기다리는 사람들은 이벤트이다. 여러 문의 집합, 즉 화장실은 스레드 풀이다.

 

이렇게 하면 많은 수의 이벤트를 동시에 여러 스레드에서 처리할 수 있으면서 너무 많은 스레드를 두었을 때 발생하는 문제점을 방지할 수 있다.

• 어떤 서버의 주 역할이 디바이스 타임이 없고 CPU 연산만 하는 스레드라면, 스레드 풀의 스레드 개수는 CPU 개수와 동일하게 잡아도 충분하다.
• 서버에서 데이터베이스나 파일 등 다른 것에 액세스 하면서 디바이스 타임이 발생할 때 스레드 개수는 CPU 개수보다 많아야 한다.

 

13. 이벤트

멀티 스레드 프로그래밍을 위한 또 다른 도구이다.

 

이벤트는 잠자는 스레드를 깨우는 도구로 Reset(이벤트 없음, 0), Set(이벤트 있음, 1) 상태 값을 가진다.

 

Event event1;
 
void Thread1()
{
    // 이벤트가 신호를 일으킬 때까지 기다린다.
    event1.Wait();
}
 
void Thread2()
{
    // 이벤트에 신호를 준다.
    event1.SetEvent();
}

• CreateEvent: 이벤트를 생성한다.
• CloseHandle: 이벤트를 파괴한다.
• WaitForSingleObject: 이벤트를 기다린다.
• SetEvent: 이벤트에 신호를 준다.

 

이벤트는 스레드 간 소통하며 일을 처리해야 할 때 유용하다.

예를 들어 스레드 1의 일을 마친 후 스레드 2에 알릴 때 활용한다.

 

14. 세마포어

멀티 스레드 프로그래밍을 위한 또 다른 도구이다.

 

뮤텍스나 임계 영역은 오로지 스레드 1개만 자원을 액세스 할 수 있게 한다.

하지만 세마포어는 원하는 개수의 스레드가 자원을 액세스 할 수 있게 한다.

 

Semaphore sema1;
 
void Main()
{
    // 스레드 2개만 자원을 액세스할 수 있게 제한한다.
    sema1 = new Semaphore(2);
}
 
void Thread1()
{
    // 리소스를 액세스할 수 있을 때까지 기다린다.
    sema1.Wait();
 
    // 리소스 액세스가 다 끝났음을 세마포어에 알린다.
    sema1.Release();
}
 
void Thread2()
{
    // 리소스를 액세스할 수 있을 때까지 기다린다.
    sema1.Wait();
 
    // 리소스 액세스가 다 끝났음을 세마포어에 알린다.
    sema1.Release();
}
 
void Thread3()
{
    // 리소스를 액세스할 수 있을 때까지 기다린다.
    sema1.Wait();
 
    // 리소스 액세스가 다 끝났음을 세마포어에 알린다.
    sema1.Release();
}

• CreateSemaphore: 세마포어를 생성하고 자원을 몇 개 허락하는지 설정한다.
• WaitForSingleObject: 세마포어가 자원 액세스를 요청하고, 허락할 때까지 기다린다.
• ReleaseSemaphore: 세마포어에 자원 액세스가 끝났음을 통보한다.
• CloseHandle: 세마포어를 파괴한다.

 

세마포어는 상태 값을 갖고 있으며 초기값은 설정했던 최대 액세스 가능한 스레드 개수이다. 스레드가 세마포어에 자원 액세스를 요청하면 상태 값을 1 감소하며 자원 액세스가 끝난 후엔 1 증가한다. 세마포어와 이벤트는 비슷하지만 이벤트는 상태 값이 0, 1로 제한되지만 세마포어는 0 이상의 값이란 차이가 있다.

 

15. 원자 조작

멀티 스레드 프로그래밍을 위한 또 다른 도구이다.

 

원자 조작은 뮤텍스나 임계 영역 잠금 없이도 여러 스레드가 안전하게 접근할 수 있는 것을 의미한다.

하드웨어 기능이며 대부분의 컴파일러는 원자 조작 기능을 쓸 수 있게 한다.

 

16. 멀티 스레드 프로그래밍의 흔한 실수들

1. 읽기와 쓰기 모두에 잠금 하지 않기

그냥 값을 읽고만 있으면 잠금을 하지 않더라도 안전하다는 막역한 생각 때문에 발생한다.

크래시를 일으키지는 않지만 a 값이 이상하게 출력될 수 있다.

int a;
mutex a_mutex;
 
void func1()
{
    // lock(a_mutex); 누락
    print(a);
}
 
void func2()
{
    lock(a_mutex);
    a = a + 10;
}

 

2. 잠금 순서 꼬임

프로그램 규모가 커지면 이 규칙을 준수하기가 생각보다 어렵다.

제일 좋은 것은 잠금 순서 규칙을 최대한 적게 유지하는 것이다.

 

3. 너무 좁은 잠금 범위

잠금 객체 범위가 너무 넓으면 컨텍스트 스위치가 발생할 때 운영체제가 해야 할 일이 많아지고 병렬성이 떨어진다.

잠금 범위를 좁히면 컨텍스트 스위치의 확률이 떨어지기는 하지만 임계 영역 잠금이 더 많은 처리 시간을 차지한다.

따라서 임계 영역을 적당한 수준에서 나누면 좋다.

 

4. 디바이스 타임이 섞인 잠금

디바이스 타임이 있을 때는 다른 스레드가 자주 접근하는 리소스에 대한 잠금을 하지 말아야 한다.

특히 자주 하는 실수는 로그 출력이나 콘솔 출력이다.

동시접속자는 많은데 게임 서버에서 CPU 사용량이 적게 나오는 경우, 이 때문인 경우가 있다.

 

5. 잠금의 전염성으로 발생한 실수

잠금으로 보호되는 리소스에서 얻어 온 값이나 포인터 주소 값 등이 로컬 변수로 있는 경우에도 잠금 상태를 계속 유지해야 할 때가 있다.

class A
{
    int x;
    int y;
};
 
mutex list_mutex;
List<A> list;
 
void func()
{
    lock(list_mutex);
    A* a = list.GetFirst(); 
    unlock(list_mutex);
 
    a->x++; // 문제가 되는 부분
}

 

6. 잠금된 뮤텍스나 임계 영역 삭제

class A
{
    mutex mutex;
    int a;
};
 
void func()
{
    A* a = new A();
    lock(a->mutex);
    delete a;
}

 

7. 일관성 규칙 깨기

아래 코드에서 list와 listCount는 일관성이 유지되어야 하는데, 잠금 객체가 2개이기 때문에 일관성이 유지되지 못한다.

class Node
{
    Node* next;
};
 
Node* list = null;
int listCount = 0;
 
mutex listMutex;
mutex listCountMutex;
 
void func()
{
    lock(listMutex);
    Node* newNode = new Node();
    newNode->next = list;
    list = newNode;
    unlock(listMutex);
 
    lock(listCountMutex);
    listCount++;
    unlock(listCountMutex);
}