우선은 1단계 목표로 삼았던 기초적인 멀티 스레드 에코 서버를 개발할 수 있었고, 이 과정에 대한 회고를 남깁니다. 내용은 다음의 단계로 구성됩니다.

1. 개발 진행 과정
2. 비동기화
3. 멀티 스레드화

개발 진행 과정

멀티 스레드 에코 서버 개발을 진행한 과정은 다음을 거쳤습니다.

우선 싱글스레드 동기적 에코 서버를 하나의 server.cpp 파일 하나에 구현했습니다. 이 때, 개발하는 서버가 점진적으로 발전할 것이기 때문에 여러 형태의 서버를 유연하게 대응할 수 있도록 별도의 IClientHandler라는 인터페이스를 생성해두고, 서버는 이를 이용하는 방식으로 구현합니다. 이 때의 에코 서버는 단순함을 확보하기 위해 단일 연결에 대한 요청을 수행한 경우 종료되도록 했습니다.

이후에 클라이언트 핸들러와 서버 클래스 자체를 구분하고, 헤더와 소스코드를 구분하는 과정을 위해 프로젝트에 기초적인 구조(src, include)와 CmakeLists.txt를 통해 빌드 시스템을 구축합니다.

그 다음으로는 에코 서버의 성능을 조금 더 구체화합니다. 서버는 이제 단일 요청을 수행하더라도 다음 요청을 수행하기 위해 열려있는 상태로 대기합니다. 대신 한 요청에서 유저가 악성으로, 혹은 부주의로 연결을 한 뒤 메시지를 보내는 등의 요청을 수행하지 않는 경우에 대해 처리하기 위해 타임아웃을 설정해두었습니다.

그 다음으로는 서버가 비동기적으로 동작하도록 변경하였습니다. 이 과정에서 제가 기존에 생각했던 public handle_client 함수보다는 run_server_loop을 두고, 이에 각각의 핸들러 별로 상세 구현에 필요한 private function들을 따로 두는 것이 낫다는 생각을 하게 돼 IclientHandler와 server 클래스의 구조를 변경하는 작업을 했습니다.

이전에는 server에서 Handler를 생성한 뒤 handle_client를 호출해 서버 내부적에서 클라이언트에 대한 핸들링 자체를 직접 했다면, 이제 server객체는 단순히 client에 대한 flag를 받으면 해당 객체를 initialize하고, run_server_loop, shutdown을 수행하는 형태로 기능이 단순화 및 추상화되었습니다.

마지막으로는 해당 구조를 기반으로 멀티 스레드 에코 서버를 태스크 큐 기반으로 작성했습니다. 이 때에는 더 이상 server나 IClientHandler의 구조적인 변경은 없었습니다.

비동기화

최초에는 boost의 asio 라이브러리를 사용하는 것을 생각했습니다만, 이를 이용하기에는 생각보다 제 c++ 언어 자체의 숙련도 자체도 모자라다는 점과 해당 라이브러리를 사용하는 것이 네트워크에 대한 기본적인 이해를 높이려는 프로젝트의 목적에 부합하지 못하다는 생각을 하게 됐습니다.

이 때문에 stl의 std::async를 사용하는 것과 epoll을 사용하는 것 중에 epoll을 사용하는 쪽을 선택했습니다. std::async를 사용하는 것이 더 비동기 자체에 대한 이해를 높이는 데에 도움이 됐겠지만, 그 정도의 저수준 구현을 하기 위해서는 2단계로 잡아둔 프로토콜에 대한 이해가 선행하는 것이 맞다는 판단을 했기 때문입니다. 이 때문에 epoll을 통해 비동기 프로그램이 동작하는 방식에 대해 이해하고, 추후에 필요하다면 std::async를 이용한 별도의 async echo client handler 등을 구현해 볼 생각입니다.

비동기 프로그래밍을 이해하기 위한 여정에서 epoll은 중요한 역할을 합니다. 전통적인 I/O 모델에서는 여러 클라이언트의 연결을 처리하기 위해 각 연결마다 스레드를 생성하거나, select나 poll과 같은 시스템 호출을 사용하여 이벤트 발생 여부를 확인해야 했습니다. poll은 파일 디스크립터 목록을 순회하며 이벤트가 발생했는지 확인하는 방식으로 동작합니다. 하지만 연결 수가 많아질수록 불필요한 순회 작업이 증가하여 성능 저하를 야기할 수 있습니다.

epoll은 이러한 poll의 단점을 개선하기 위해 등장한 Linux 시스템의 I/O 이벤트 통지 메커니즘입니다. epoll은 관심 있는 파일 디스크립터를 등록해두고, 이벤트가 발생한 파일 디스크립터만을 반환하는 방식으로 동작합니다. 이를 통해 불필요한 순회를 줄이고, 많은 수의 연결을 효율적으로 처리할 수 있습니다. 특히 네트워크 프로그래밍에서 epoll은 서버가 동시에 여러 클라이언트의 요청을 비동기적으로 처리하는 데 필수적인 요소로 활용됩니다. 이벤트 기반의 비동기 프로그래밍 모델을 구현하는 데 핵심적인 역할을 수행하며, 높은 성능과 확장성을 갖춘 서버 애플리케이션을 구축하는 데 기여합니다.

제가 구현한 AsyncEchoClientHandler에서는 서버가 시작되면 epoll을 하나 생성합니다. 이 때 epoll은 서버 소켓을 감시대상으로 두고, 서버 소켓에서 읽을 준비가 됐을 때 이벤트가 발생한 파일 디스크럽터와 해당 이벤트 정보를 events 배열에 저장합니다.

이제 추가적인 연결이 발생하면 서버는 accept()를 통해 클라이언트 별로 새로운 소켓을 할당하고, 이 소켓을 비블로킹 모드로 설정한 후 이벤트 발생을 epoll을 통해 비동기적으로 감지할 수 있도록 등록합니다. epoll_wait()는 등록된 소켓에서 이벤트가 발생할 때까지 대기하며, 이벤트가 감지될 경우 해당 소켓의 읽기 가능(EPOLLIN) 또는 쓰기 가능(EPOLLOUT) 여부에 따라 handle_client_read() 또는 handle_client_write() 함수를 호출하여 네트워크 데이터를 읽어 내부 버퍼에 저장하거나, 버퍼의 데이터를 소켓을 통해 네트워크로 전송합니다. 이때 각 클라이언트의 상태(예: 송수신 버퍼)는 client_states_ 맵을 통해 관리됩니다.

이러한 이벤트들의 핸들링 자체는 메인 스레드의 while 루프에서 epoll_wait()를 통해 이벤트들을 계속해서 감시하고, 감지된 이벤트에 따라 적절한 동작(데이터 읽기, 쓰기, 연결 종료 등)을 수행하는 방식으로 이루어집니다. 오류 발생 시에는 perror()를 통해 오류를 보고하고, remove_client_from_epoll()을 호출하여 해당 클라이언트 연결을 종료합니다.

멀티 스레드화

사용한 구조

현재 멀티 스레드 클라이언트 핸들러와 같은 경우에는 다음과 같은 형태로 동작합니다. 전반적인 구조는 일종의 생산자-소비자 패턴을 통해 이벤트 감지 스레드가 작업을 생성하여 큐에 넣고, 워커 스레드가 큐에서 작업을 꺼내 병렬로 처리하는 방식입니다.

  1. 스레드 풀 생성: 서버 시작 시 미리 정의된 개수의 워커 스레드를 생성하여 스레드 풀을 초기화합니다.
  2. 태스크 큐: 이벤트 핸들링 작업을 담는 큐로 epoll_wait을 통해 이벤트가 감지되면, 해당 이벤트와 관련된 정보(클라이언트 상태, 소켓 파일 디스크립터, 발생한 이벤트 등)을 람다 형태로 캡쳐하여 큐에 추가합니다.
  3. 워커 스레드: 각 워커 스레드는 무한 루프를 돌면서 태스크 큐에서 작업을 꺼내와(이 때 notify_one을 통해 wait 상태인 컨디션을 깨우고 스레드를 동작시킵니다.) 실제 이벤트 핸들링을 수행합니다.
  4. epoll 기반 이벤트 감지: 메인 스레드의 run_server_loop 함수에서 epoll_wait을 통해 이벤트 발생을 감지하고, 새로운 연결 요청 또는 기존 클라이언트의 이벤트 발생 시 해당 작업을 태스크 큐에 넣습니다.
  5. 클라이언트 상태 관리: 각 클라이언트의 상태(읽기/쓰기 버퍼 등)를 공유 포인터를 사용하여 관리하고, 멀티 스레드 환경에서 안전한 접근을 위해 공유 뮤택스(client_states_mutex)를 사용합니다.

대안적 구조

이와 다른 구현 방식으로는 스레드 당 연결 모델, 스레드 풀 기반의 직접 이벤트 처리 등이 있습니다.

스레드 당 연결 모델은 서버와 새로운 클라이언트 연결이 수락될 때마다 해당 클라이언트와 통신을 전담하는 새로운 스레드를 생성하는 방식입니다.

스레드 풀 기반의 직접 이벤트 처리는 메인 스레드에서 이벤트를 감지한 후, 각 이벤트에 해당하는 처리를 스레드 풀의 스레드에 직접 할당하는 방식입니다.

태스크 큐 방식의 게임 서버 관점에서의 실용성 및 선택 이유

일반적으로 게임 서버는 높은 동시성 처리 능력, 낮은 지연 시간, 복잡한 게임 로직 처리 용이성을 필요로 합니다. 태스크 큐 방식으로 멀티 스레드 서버를 구축하는 것은 다른 선택지와 비교해서 해당 부분에서 우수하다 판단했기 때문에 선택했고 구체적인 설명은 다음과 같습니다.

게임 서버에 필요한 기능적 요구:

이 프로젝트에서 태스크 큐 방식을 선택한 이유:

고려사항: client_state 동기화 shared_mutex 도입

개발을 진행하는 과정에서 여러 워커 스레드가 동시에 client_states에 접근해야하는 일이 발생하고, 원래 해당 객체를 unique_ptr로 구현해두었기 때문에 확장성 측면에서 용이하지 못하다는 판단을 하게 됐습니다. 동시에 client_states에 여러 객체들이 동시에 접근하는 것에 대한 동기화도 누락돼있었습니다.

이를 최초에는 단순하게 mutex를 사용하는 것을 고려했으나, 해당 client_states 객체는 서버에서 호출하게 될 일이 굉장히 빈번하게 발생하기 때문에 병목으로 작용할 가능성이 높다는 판단을 하게 됐습니다. 이에 따라 해당 객체를 shared_mutex로, clinet_states를 shared_ptr 객체로 변경하는 과정을 추가로 진행했습니다.

shared_ptr과 shared_mutex을 사용하면 읽기와 같은 작업을 할 때에는 해당 객체를 다른 스레드에서도 비슷한 안전한 작업을 하는 경우에는 활용할 수 있도록 열어두고, 쓰기와 같은 작업을 할 때에는 lock_guard를 통해 막는 식의 세밀한 조정이 가능합니다.

마치며

최근 제가 진행한 해당 코드를 보고 잡 큐는 왜 하나만 뒀어요?라는 질문을 받았는데 이에 대해 할 말이 없었던 경험이 있습니다. 잡 큐를 하나만 둔 데에는 딱히 아무런 이유가 없었습니다. 왜냐하면 제 머릿 속에서는 애초에 여럿을 둘 수 있다는 선택지 자체가 없었기 때문입니다.

개발을 하다보면 이처럼 가장 중요한 것은 단순히 코드가 돌아가도록 만드는 능력이 아니라, 내가 선택을 할 때 어떤 경우의 수들이 있고 그 장/단점과 우리의 현실적인 목표에 맞춰 검토를 할 수 있는 능력이라고 생각합니다. 다만 그 관점에서 놓고 보면 아직도 나아가야 할 길이 많이 멀었단 것을 다시 한 번 깨닫습니다.

그런 관점에서 원래 다음 작업으로 에코 서버 다음으로 진행하려했던 요청 처리를 잠시 접어두고, 해당 확장성에 대한 검토 및 수정을 먼저 진행해보겠습니다.

2025-05-19
카테고리로 돌아가기 ↩