[2026] C++ 백엔드·게임 서버 시스템 디자인 | 대규모 동시 접속과 메모리 풀 [#46-1]
![[2026] C++ 백엔드·게임 서버 시스템 디자인 | 대규모 동시 접속과 메모리 풀 [#46-1]](/og/s/cpp-series-46-1-system-design.webp)
이 글의 핵심
C++ 면접 단골 주제인 대규모 동시 접속자 처리 구조, 메모리 풀 기반 객체 관리 설계 등 실전 아키텍처를 다룹니다. 문제 시나리오, 완전한 설계 예제, 흔한 실수, 프로덕션 패턴까지 C++ 실전 가이드 시리즈에서 예제와 함께 다룹니다.
들어가며: “10만 CCU 서버를 어떻게 설계하시겠어요?”
왜 시스템 디자인을 묻는가
C++ 백엔드·게임 서버 면접에서는 이론만이 아니라 “대규모 동시 접속자(CCU)(Concurrent Users—동시에 접속해 있는 사용자 수)를 어떻게 처리할지”, “세션·패킷·메모리를 어떻게 관리할지”를 설계 수준으로 묻습니다. 이 글은 그런 질문에 대비해 실전에 가까운 아키텍처 키워드를 정리합니다. 구현 세부보다는 구성 요소, 트레이드오프, 면접에서 말할 수 있는 답변 뼈대를 제공합니다. 이 글에서 다루는 것:
- 대규모 동시 접속 처리: 스레드 모델(이벤트 루프·스레드 풀), Acceptor·Worker 분리, 수평 확장
- 메모리 풀 기반 객체 관리: new/delete 대신 풀·오브젝트 풀, 단편화 방지, 라이프사이클
- 세션·패킷 설계: 연결당 세션 객체, 패킷 큐·버퍼 풀
- 문제 시나리오·완전한 설계 예제·흔한 실수·프로덕션 패턴 관련 글: C++ 실전 가이드 #29: Asio, 고성능 네트워크 가이드 #1~#3에서 이벤트 루프·Strand를 다룹니다.
실무 적용 경험: 이 글은 대규모 C++ 프로젝트에서 실제로 겪은 문제와 해결 과정을 바탕으로 작성되었습니다. 책이나 문서에서 다루지 않는 실전 함정과 디버깅 팁을 포함합니다.
실제 문제 시나리오
시나리오 1: 피크 타임에 서버가 멈춘다
상황: MMORPG 서버가 점검 후 오픈 시점에 5만 명이 동시 접속 시도
문제: 단일 스레드 accept + 동기 I/O → 연결 수락이 병목, 나머지 클라이언트 타임아웃
결과: "접속이 안 돼요" 문의 폭주, 이벤트 루프 블로킹으로 기존 유저도 끊김
→ Acceptor·Worker 분리, 비동기 I/O, 스레드 풀 도입 필요시나리오 2: 3일째 메모리 사용량이 계속 상승
상황: C++ 게임 서버가 72시간 운영 후 메모리 8GB → 14GB로 증가
문제: 세션·패킷 버퍼를 new/delete로 할당 → 힙 단편화 + 할당/해제 오버헤드
결과: 단편화로 인한 "가상 메모리 부족" 에러, 재시작 없이는 회복 불가
→ 메모리 풀·오브젝트 풀 도입, 스레드 로컬 풀로 경합 감소시나리오 3: 같은 유저의 패킷이 뒤섞여 처리된다
상황: 한 클라이언트에서 로그인 → 캐릭터 선택 → 게임 입장 요청이 연속 전송
문제: 여러 스레드가 같은 세션의 읽기/쓰기 핸들러를 동시 실행 → 레이스 컨디션
결과: 캐릭터 선택 전에 게임 입장 처리, 상태 꼬임, 크래시
→ 연결당 Strand로 해당 연결의 I/O 직렬화 필요시나리오 4: 10만 CCU 목표인데 3만에서 한계
상황: 단일 서버로 10만 CCU 목표, 3만 접속 시 CPU 100%, 지연 급증
문제: 스레드 수 = 연결 수 설계, 컨텍스트 스위칭·락 경합 과다
결과: 이벤트 기반 I/O 미적용, 블로킹 소켓 사용
→ io_context + run() 스레드 풀, 논블로킹 소켓, 수평 확장 검토시나리오 5: 패킷 송신 시 크래시
상황: 여러 스레드에서 같은 세션의 send()를 동시 호출
문제: 소켓은 스레드 안전하지 않음, 버퍼 덮어쓰기·use-after-free
결과: 랜덤 크래시, 패킷 손상
→ 패킷 큐 + 단일 Strand에서 순차 송신이 글에서는 위와 같은 문제를 예방하는 시스템 설계와 완전한 예제를 다룹니다.
개념을 잡는 비유
이 글의 주제는 여러 부품이 맞물리는 시스템으로 보시면 이해가 빠릅니다. 한 레이어(저장·네트워크·관측)의 선택이 옆 레이어에도 영향을 주므로, 본문에서는 트레이드오프를 숫자와 패턴으로 정리합니다.
목차
- 대규모 동시 접속자 처리 구조
- 메모리 풀·오브젝트 풀 설계
- 세션·패킷·버퍼 설계
- 완전한 시스템 설계 예제
- 자주 발생하는 실수와 해결법
- 모범 사례
- 프로덕션 패턴
- 면접에서 답변할 때 포인트
- 구현 체크리스트
1. 대규모 동시 접속자 처리 구조
아키텍처 개요
다음은 mermaid를 활용한 상세한 구현 코드입니다. 비동기 처리를 통해 효율적으로 작업을 수행합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.
flowchart TB
subgraph Client[클라이언트]
C1[Client 1]
C2[Client 2]
Cn[Client N]
end
subgraph LB[로드 밸런서]
LB1[L4/L7 LB]
end
subgraph Server[서버 인스턴스]
subgraph Acceptor[Acceptor 스레드]
A[async_accept]
end
subgraph Workers[Worker 스레드 풀]
W1["io_context run"]
W2["io_context run"]
W3["io_context run"]
end
end
Client --> LB
LB --> Acceptor
A -->|round-robin| Workers
이벤트 루프 + 스레드 풀
- 한 스레드 한 이벤트 루프: Asio의 io_context::run()을 여러 스레드가 돌리면, 완료 핸들러가 스레드 풀에 분산됩니다. 블로킹 없이 수만 개의 소켓을 소수의 스레드로 처리할 수 있습니다.
- Strand: 같은 연결(세션)에 대한 읽기/쓰기 핸들러를 한 Strand에 묶으면 락 없이 순차 실행이 보장되어, 공유 상태를 안전하게 다룰 수 있습니다.
- Acceptor와 Worker 분리: 연결 수락(accept)은 전용 스레드/루프에서 하고, 수락된 소켓을 round-robin 또는 부하에 따라 Worker 풀에 넘기는 패턴. Worker는 자신만의 io_context 또는 공유 io_context에서 run()을 돌립니다.
Strand로 연결 단위 직렬화
아래 코드는 mermaid를 사용한 구현 예제입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.
sequenceDiagram
participant C as Client
participant S1 as Worker 스레드 1
participant S2 as Worker 스레드 2
participant Strand as Session Strand
C->>S1: read 완료 (핸들러 1)
S1->>Strand: post(핸들러 1)
Strand->>S1: 순차 실행
C->>S2: read 완료 (핸들러 2)
S2->>Strand: post(핸들러 2)
Strand->>S2: 핸들러 1 완료 후 실행
수평 확장
- 단일 프로세스 한계: 한 머신의 CPU·메모리·네트워크에 한계가 있으면 여러 프로세스·여러 서버로 나눕니다. 로드 밸런서 앞에 서버 인스턴스를 두고, 세션 어피니티(같은 클라이언트는 같은 서버로) 또는 스테이트리스 + 공유 저장소로 설계합니다.
- 면접에서는 “단일 노드에서는 이벤트 루프·Strand·스레드 풀로 CCU를 늘리고, 그 다음에는 수평 확장·로드밸런싱·세션 분산”이라고 요약할 수 있습니다. 예시 시나리오: “10만 CCU를 한 서버로 받는다”면, 프로세스 하나에 io_context 하나를 두고, CPU 코어 수만큼(예: 8개) 스레드가 run()을 호출합니다. 연결마다 세션 객체와 Strand를 두면, 같은 연결의 읽기/쓰기 핸들러는 한 스레드에서만 순차 실행되고, 서로 다른 연결의 핸들러는 스레드 풀에 분산됩니다. 이렇게 하면 락 없이 수만 개 소켓을 소수의 스레드로 처리할 수 있습니다.
실행 가능 예제 (이벤트 루프·스레드 풀 개념)
다음은 cpp를 활용한 상세한 구현 코드입니다. 필요한 모듈을 import하고, 반복문으로 데이터를 처리합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.
// 복사해 붙여넣은 뒤: g++ -std=c++17 -pthread -o sys_demo sys_demo.cpp && ./sys_demo
#include <iostream>
#include <thread>
#include <vector>
int main() {
const int num_workers = 4;
std::vector<std::thread> workers;
for (int i = 0; i < num_workers; ++i) {
workers.emplace_back([i]() {
std::cout << "Worker thread " << i << "\n";
});
}
for (auto& w : workers) w.join();
std::cout << "Main thread\n";
return 0;
}2. 메모리 풀·오브젝트 풀 설계
왜 풀을 쓰는가
- 힙 단편화: 수만 개의 세션·패킷 버퍼를 new/delete하면 단편화와 할당/해제 비용이 커집니다.
- 메모리 풀: 미리 큰 블록을 할당해 두고, 같은 크기(또는 크기 클래스) 단위로 나눠 주고 반환받아 재사용합니다. 스레드 로컬 풀을 쓰면 락 없이 할당 속도를 높일 수 있습니다.
- 오브젝트 풀: 세션·패킷 객체 자체를 풀에서 꺼내 쓰고, 연결 종료 시 재설정 후 풀에 반환합니다. 생성/파괴 비용과 단편화를 줄입니다.
풀 vs new/delete 비교
아래 코드는 mermaid를 사용한 구현 예제입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.
flowchart LR
subgraph Heap["힙 (new/delete)"]
H1[블록1]
H2[빈공간]
H3[블록2]
H4[빈공간]
H5[블록3]
end
subgraph Pool[메모리 풀]
P1[연속 블록]
P2[연속 블록]
P3[연속 블록]
end
설계 포인트
- 크기 클래스: 작은 버퍼(64B), 중간(256B), 큰(4KB) 등으로 나누면 내부 단편화를 줄일 수 있습니다.
- 라이프사이클: 풀에서 꺼낸 객체는 “사용 중” 상태를 명확히 하고, 반환 시 모든 참조가 사라졌는지(스마트 포인터·참조 카운트) 보장해야 합니다. use-after-free를 막기 위해 반환 후 재사용 전까지 덮어쓰기하는 패턴도 있습니다. 면접에서는 “대량의 단명 객체가 있으면 new/delete 대신 메모리 풀·오브젝트 풀로 할당 비용과 단편화를 줄인다. 스레드 로컬 풀로 경합을 줄일 수 있다”라고 말할 수 있습니다.
메모리 풀 구현 예제
다음은 cpp를 활용한 상세한 구현 코드입니다. 필요한 모듈을 import하고, 클래스를 정의하여 데이터와 기능을 캡슐화하며, 반복문으로 데이터를 처리합니다, 조건문으로 분기 처리를 수행합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.
#include <vector>
#include <stack>
#include <mutex>
#include <cstddef>
// 단일 크기 메모리 풀: 같은 크기 블록만 관리
class FixedSizePool {
public:
explicit FixedSizePool(size_t block_size, size_t initial_count = 64)
: block_size_(block_size) {
for (size_t i = 0; i < initial_count; ++i) {
void* p = ::operator new(block_size_);
free_list_.push(p);
}
}
~FixedSizePool() {
while (!free_list_.empty()) {
void* p = free_list_.top();
free_list_.pop();
::operator delete(p);
}
}
void* allocate() {
std::lock_guard<std::mutex> lock(mtx_);
if (free_list_.empty()) {
return ::operator new(block_size_);
}
void* p = free_list_.top();
free_list_.pop();
return p;
}
void deallocate(void* p) {
std::lock_guard<std::mutex> lock(mtx_);
free_list_.push(p);
}
private:
size_t block_size_;
std::stack<void*> free_list_;
std::mutex mtx_;
};일상 비유로 이해하기: 메모리를 아파트 건물로 생각해보세요. 스택은 엘리베이터 같아서 빠르지만 공간이 제한적입니다. 힙은 창고처럼 넓지만 물건을 찾는 데 시간이 걸립니다. 포인터는 “3층 302호”처럼 주소를 가리키는 메모지라고 보면 됩니다.
3. 세션·패킷·버퍼 설계
연결당 세션
- 한 TCP 연결 = 한 세션 객체. 세션은 소켓, 수신/송신 버퍼, 프로토콜 상태(헤더 파싱 등)를 가집니다. 고성능 네트워크 가이드 #3처럼 연결당 Strand를 두면 해당 연결의 모든 핸들러가 순차 실행됩니다.
- 세션 풀: 연결이 끊기면 세션 객체를 풀에 반환하고, 새 연결 시 풀에서 꺼내 재사용합니다.
패킷·버퍼
- 고정 버퍼 vs 동적 버퍼: 지연이 중요하면 스레드 로컬·세션 전용 고정 크기 버퍼를 두고, 큰 메시지는 청크 단위로 읽어 처리합니다. Composed Operation으로 “헤더 읽기 → 바디 읽기”를 한 비동기 연산으로 묶을 수 있습니다.
- 패킷 큐: 송신할 패킷을 큐에 넣고, 소켓이 쓰기 가능할 때마다 큐에서 꺼내 async_write하는 패턴. 큐에 넣는 쪽과 쓰는 쪽이 같은 Strand에 있으면 락 없이 안전합니다.
세션·패킷 흐름
다음은 mermaid를 활용한 상세한 구현 코드입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.
flowchart LR
subgraph Session[세션]
S1[소켓]
S2[수신 버퍼]
S3[송신 큐]
S4[Strand]
end
subgraph Packet[패킷 처리]
P1[헤더 파싱]
P2[바디 읽기]
P3[비즈니스 로직]
P4[응답 큐잉]
end
S1 --> S2
S2 --> P1
P1 --> P2
P2 --> P3
P3 --> P4
P4 --> S3
S3 --> S1
S4 -.->|직렬화| S1
4. 완전한 시스템 설계 예제
예제 1: 10만 CCU 서버 아키텍처
다음은 mermaid를 활용한 상세한 구현 코드입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.
flowchart TB
subgraph Clients[클라이언트]
C[10만 연결]
end
subgraph Server[단일 서버 프로세스]
subgraph IO[io_context]
IO1[비동기 I/O]
end
subgraph Threads[8 Worker 스레드]
T1[run]
T2[run]
T3[run]
T4[run]
T5[run]
T6[run]
T7[run]
T8[run]
end
subgraph Sessions[세션 풀]
S[10만 세션 객체]
end
end
C --> IO
IO --> Threads
Threads --> Sessions
핵심 설계 결정:
| 항목 | 선택 | 이유 |
|---|---|---|
| I/O 모델 | 이벤트 기반 (epoll/kqueue) | 수만 소켓을 소수 스레드로 처리 |
| 스레드 수 | CPU 코어 수 | 컨텍스트 스위칭 최소화 |
| 세션당 Strand | 1개 | 같은 연결 I/O 직렬화, 락 불필요 |
| 버퍼 | 고정 크기 + 풀 | 단편화·할당 비용 감소 |
예제 2: Acceptor-Worker 분리 코드 골격
다음은 cpp를 활용한 상세한 구현 코드입니다. 필요한 모듈을 import하고, 클래스를 정의하여 데이터와 기능을 캡슐화하며, 비동기 처리를 통해 효율적으로 작업을 수행합니다, 에러 처리를 통해 안정성을 확보합니다, 조건문으로 분기 처리를 수행합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.
#include <boost/asio.hpp>
#include <iostream>
#include <vector>
#include <memory>
namespace asio = boost::asio;
using tcp = asio::ip::tcp;
class Session; // 전방 선언
class Server {
public:
Server(asio::io_context& io_ctx, unsigned short port)
: acceptor_(io_ctx, tcp::endpoint(tcp::v4(), port)) {
do_accept();
}
private:
void do_accept() {
acceptor_.async_accept(
[this](boost::system::error_code ec, tcp::socket socket) {
if (!ec) {
// Worker에 세션 전달 (round-robin 등)
on_new_session(std::move(socket));
}
do_accept(); // 다음 accept
});
}
virtual void on_new_session(tcp::socket socket) = 0;
tcp::acceptor acceptor_;
};
// Worker 풀: 각 Worker가 io_context::run() 실행
// 새 소켓은 round-robin으로 Worker의 io_context에 post예제 3: 세션 + Strand + 패킷 큐
다음은 cpp를 활용한 상세한 구현 코드입니다. 필요한 모듈을 import하고, 클래스를 정의하여 데이터와 기능을 캡슐화하며, 비동기 처리를 통해 효율적으로 작업을 수행합니다, 에러 처리를 통해 안정성을 확보합니다, 조건문으로 분기 처리를 수행합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.
#include <boost/asio.hpp>
#include <queue>
#include <array>
namespace asio = boost::asio;
using tcp = asio::ip::tcp;
class GameSession : public std::enable_shared_from_this<GameSession> {
public:
GameSession(tcp::socket socket, asio::io_context& io_ctx)
: socket_(std::move(socket)),
strand_(asio::make_strand(io_ctx)),
recv_buffer_() {}
void start() {
// 모든 I/O를 strand_를 통해 실행 → 락 없이 순차 보장
asio::async_read(
socket_,
asio::buffer(recv_buffer_),
asio::bind_executor(strand_, [self = shared_from_this()](
boost::system::error_code ec, std::size_t bytes) {
if (!ec) self->on_read(bytes);
}));
}
private:
void on_read(std::size_t bytes) {
// 패킷 파싱 후 비즈니스 로직
// 응답은 send_queue_에 넣고 do_write() 호출
}
void do_write() {
if (send_queue_.empty()) return;
auto& buf = send_queue_.front();
asio::async_write(
socket_,
asio::buffer(buf),
asio::bind_executor(strand_, [self = shared_from_this()](
boost::system::error_code ec, std::size_t) {
if (!ec) {
self->send_queue_.pop();
self->do_write();
}
}));
}
tcp::socket socket_;
asio::strand<asio::io_context::executor_type> strand_;
std::array<uint8_t, 4096> recv_buffer_;
std::queue<std::vector<uint8_t>> send_queue_;
};예제 4: 오브젝트 풀 기반 세션 관리
다음은 cpp를 활용한 상세한 구현 코드입니다. 필요한 모듈을 import하고, 클래스를 정의하여 데이터와 기능을 캡슐화하며, 반복문으로 데이터를 처리합니다, 조건문으로 분기 처리를 수행합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.
#include <vector>
#include <optional>
#include <cassert>
template <typename T>
class ObjectPool {
public:
explicit ObjectPool(size_t capacity) {
pool_.reserve(capacity);
for (size_t i = 0; i < capacity; ++i) {
pool_.emplace_back(std::in_place);
}
free_indices_.reserve(capacity);
for (size_t i = 0; i < capacity; ++i) {
free_indices_.push_back(i);
}
}
T* acquire() {
if (free_indices_.empty()) return nullptr;
size_t idx = free_indices_.back();
free_indices_.pop_back();
return &pool_[idx].value();
}
void release(T* obj) {
size_t idx = obj - &pool_[0].value();
assert(idx < pool_.size());
pool_[idx].reset(); // 소멸자 호출, 상태 초기화
pool_[idx].emplace(); // 기본 생성
free_indices_.push_back(idx);
}
private:
std::vector<std::optional<T>> pool_;
std::vector<size_t> free_indices_;
};5. 자주 발생하는 실수와 해결법
실수 1: 세션 소켓을 여러 스레드에서 동시 사용
문제: 소켓은 스레드 안전하지 않음. 한 스레드에서 async_read, 다른 스레드에서 async_write를 동시에 호출하면 레이스 컨디션.
아래 코드는 cpp를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.
// ❌ 잘못된 예: Strand 없이 여러 스레드에서 같은 세션 접근
void on_packet_received(Session* session, Packet p) {
std::thread([session, p]() {
process(p);
session->send(response); // 다른 스레드! 위험
}).detach();
}해결: 해당 세션의 모든 I/O를 Strand로 직렬화. 아래 코드는 cpp를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.
// ✅ 올바른 예: Strand를 통해 post
void on_packet_received(std::shared_ptr<Session> session, Packet p) {
asio::post(session->strand(), [session, p]() {
auto response = process(p);
session->send(response); // Strand 내부 → 안전
});
}실수 2: 패킷 버퍼를 new/delete로 매번 할당
문제: 초당 수만 패킷 처리 시 할당/해제 비용과 단편화가 심해짐. 아래 코드는 cpp를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.
// ❌ 잘못된 예
void on_read(std::size_t len) {
auto* buf = new uint8_t[len];
parse_packet(buf, len);
process(buf, len);
delete[] buf;
}해결: 세션별 고정 버퍼 또는 버퍼 풀 사용. 아래 코드는 cpp를 사용한 구현 예제입니다. 클래스를 정의하여 데이터와 기능을 캡슐화하며. 코드를 직접 실행해보면서 동작을 확인해보세요.
// ✅ 올바른 예: 세션에 고정 버퍼
class Session {
std::array<uint8_t, 4096> recv_buffer_;
void on_read(std::size_t len) {
parse_packet(recv_buffer_.data(), len);
process(recv_buffer_.data(), len);
}
};실수 3: 세션 반환 시 참조가 남아 있는데 풀에 반환
문제: use-after-free. 다른 스레드나 핸들러가 아직 세션을 참조하는데 풀에 넣고 새 연결에 재할당. 다음은 간단한 cpp 코드 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.
// ❌ 잘못된 예
void on_disconnect(Session* session) {
session_pool_.release(session); // 아직 pending 핸들러가 session 참조 중!
}해결: shared_ptr로 참조 카운트 관리, 또는 weak_ptr + 만료 체크.
아래 코드는 cpp를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.
// ✅ 올바른 예: shared_ptr로 수명 관리
void on_disconnect(std::shared_ptr<Session> session) {
session->close();
// shared_ptr이 핸들러에 캡처되어 있으면, 마지막 핸들러 완료 후 소멸
// 풀 사용 시: session->reset() 후 풀 반환은 모든 참조 해제 후에만
}실수 4: 블로킹 작업을 이벤트 루프에서 실행
문제: async_read 완료 핸들러 안에서 DB 쿼리·파일 I/O 등 블로킹 호출 → 전체 이벤트 루프 블로킹.
아래 코드는 cpp를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.
// ❌ 잘못된 예
void on_read(...) {
auto result = db.query("SELECT ..."); // 블로킹!
send(response);
}해결: 블로킹 작업은 별도 스레드 풀로 오프로드. 아래 코드는 cpp를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.
// ✅ 올바른 예
void on_read(...) {
asio::post(blocking_pool_, [self = shared_from_this(), data]() {
auto result = db.query("SELECT ...");
asio::post(self->strand_, [self, result]() {
self->send(response);
});
});
}실수 5: 수평 확장 시 세션 상태를 서버 로컬에만 보관
문제: 로드 밸런서가 다른 인스턴스로 라우팅하면 세션 손실.
❌ 설계: 세션 상태를 프로세스 메모리에만 저장
→ 인스턴스 장애/재시작 시 세션 모두 손실
→ 스케일 아웃 시 세션 이전 불가해결: 스테이트리스 + Redis 등 공유 저장소, 또는 세션 어피니티 + 복제.
✅ 설계 A: 세션 상태를 Redis에 저장, 서버는 스테이트리스
✅ 설계 B: L4 스티키 세션 + 인스턴스당 세션 유지, 장애 시 복구 로직실수 6: 송신 큐 무한 증가
문제: 클라이언트가 수신을 멈추면 송신 큐가 계속 쌓여 메모리 폭발. 아래 코드는 cpp를 사용한 구현 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.
// ❌ 잘못된 예: 큐 크기 제한 없음
void send(Packet p) {
send_queue_.push(std::move(p));
do_write();
}해결: 백프레셔. 큐 크기 임계값 초과 시 수신 일시 중단 또는 연결 종료. 아래 코드는 cpp를 사용한 구현 예제입니다. 조건문으로 분기 처리를 수행합니다. 코드를 직접 실행해보면서 동작을 확인해보세요.
// ✅ 올바른 예
void send(Packet p) {
if (send_queue_.size() >= MAX_QUEUE_SIZE) {
close_connection("send queue full");
return;
}
send_queue_.push(std::move(p));
do_write();
}실수 7: 타임아웃 미설정
문제: 비활성 연결(클라이언트 종료 미통보)이 세션을 계속 점유.
// ❌ 잘못된 예: 타임아웃 없음
asio::async_read(socket_, ..., on_read);해결: steady_timer로 읽기/쓰기 타임아웃 설정.
아래 코드는 cpp를 사용한 구현 예제입니다. 비동기 처리를 통해 효율적으로 작업을 수행합니다, 조건문으로 분기 처리를 수행합니다. 코드를 직접 실행해보면서 동작을 확인해보세요.
// ✅ 올바른 예
void start_read_timer() {
read_timer_.expires_after(std::chrono::seconds(30));
read_timer_.async_wait([self = shared_from_this()](ec) {
if (!ec) self->close("read timeout");
});
}
// async_read 완료 시 read_timer_.cancel()6. 모범 사례
6.1 스레드 모델
| 패턴 | 사용 시점 | 장점 | 단점 |
|---|---|---|---|
| 1 스레드 1 연결 | 소규모 | 구현 단순 | CCU 제한 |
| 이벤트 루프 + 스레드 풀 | 대규모 | 높은 CCU, 락 최소 | 비동기 코드 복잡 |
| Acceptor-Worker 분리 | 초대규모 | accept 병목 제거 | 설계 복잡 |
6.2 메모리 관리
- 크기 클래스별 풀: 64B, 256B, 1KB, 4KB 등으로 분리해 내부 단편화 감소.
- 스레드 로컬 풀: 스레드당 풀 인스턴스를 두어 락 없이 allocate/deallocate.
- 반환 시 초기화: 풀 반환 시 민감한 데이터 덮어쓰기(보안·use-after-free 방지).
6.3 네트워크
- 고정 헤더 + 가변 바디: 헤더로 길이 파악 후 바디 읽기, Composed Operation 활용.
- 송신 큐:
async_write중 추가 송신 요청은 큐에 넣고, 쓰기 완료 시 큐에서 다음 꺼내 전송. - 타임아웃:
steady_timer로 읽기/쓰기 타임아웃, 비활성 세션 정리.
6.4 모니터링
- 연결 수 Gauge: 현재 세션 수, 풀 사용량.
- 패킷 처리량 Counter: 초당 수신/송신 패킷 수.
- 지연 Histogram: 요청-응답 지연 시간 분포.
7. 프로덕션 패턴
패턴 1: 그레이스풀 셧다운
아래 코드는 cpp를 사용한 구현 예제입니다. 반복문으로 데이터를 처리합니다. 코드를 직접 실행해보면서 동작을 확인해보세요.
// SIGINT/SIGTERM 수신 시
void on_signal() {
acceptor_.close(); // 새 연결 거부
for (auto& session : sessions_) {
session->close(); // 기존 연결 정리
}
io_ctx_.stop();
// 모든 핸들러 완료 대기 후 프로세스 종료
}패턴 2: 백프레셔 (Backpressure)
아래 코드는 cpp를 사용한 구현 예제입니다. 비동기 처리를 통해 효율적으로 작업을 수행합니다, 조건문으로 분기 처리를 수행합니다. 코드를 직접 실행해보면서 동작을 확인해보세요.
// 송신 큐가 일정 크기 초과 시 수신 일시 중단
if (send_queue_.size() > 1000) {
pause_reading(); // async_read 취소
} else {
resume_reading();
}패턴 3: 헬스 체크
// 로드 밸런서용 헬스 체크 엔드포인트
// - /health: 200 OK
// - 연결 수 < 임계값, 메모리 < 임계값일 때만 healthy패턴 4: 캐나리 배포
다음은 간단한 text 코드 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.
1. 새 버전을 소수 인스턴스에만 배포
2. 에러율·지연 메트릭 비교
3. 문제 없으면 점진적 확대
4. 문제 시 즉시 롤백패턴 5: 서킷 브레이커
다음은 간단한 cpp 코드 예제입니다. 코드를 직접 실행해보면서 동작을 확인해보세요.
// 외부 서비스(DB, 캐시) 호출 실패 시
// - 연속 N회 실패 → 서킷 오픈, 즉시 실패 반환
// - 일정 시간 후 half-open, 1회 시도
// - 성공 시 클로즈, 실패 시 다시 오픈패턴 6: 스레드 로컬 메모리 풀
아래 코드는 cpp를 사용한 구현 예제입니다. 조건문으로 분기 처리를 수행합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.
// 스레드당 풀 인스턴스 → 락 없이 allocate/deallocate
thread_local FixedSizePool* tls_pool = nullptr;
void init_thread_pool() {
if (!tls_pool) tls_pool = new FixedSizePool(256, 64);
}
void* fast_allocate() {
init_thread_pool();
return tls_pool->allocate();
}패턴 7: Composed Operation으로 패킷 파싱
다음은 cpp를 활용한 상세한 구현 코드입니다. 비동기 처리를 통해 효율적으로 작업을 수행합니다, 조건문으로 분기 처리를 수행합니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.
// 헤더(4바이트) 읽기 → 바디 길이 확인 → 바디 읽기
void read_packet(std::shared_ptr<Session> self) {
asio::async_read(
socket_,
asio::buffer(header_buffer_),
asio::bind_executor(strand_, [self](ec, bytes) {
if (ec) return;
uint32_t body_len = parse_header(header_buffer_);
if (body_len > MAX_PACKET_SIZE) { /* 에러 */ return; }
asio::async_read(
socket_,
asio::buffer(body_buffer_, body_len),
asio::bind_executor(strand_, [self, body_len](ec, bytes) {
if (!ec) self->on_packet(body_buffer_, body_len);
self->read_packet(self); // 다음 패킷
}));
}));
}성능 벤치마크 및 트레이드오프
할당 방식별 비교 (개요)
| 방식 | 할당 비용 (상대) | 단편화 | 스레드 안전 | 구현 복잡도 |
|---|---|---|---|---|
| new/delete | 1.0 (기준) | 높음 | O | 낮음 |
| 메모리 풀 (락) | ~0.3 | 낮음 | O | 중간 |
| 스레드 로컬 풀 | ~0.1 | 낮음 | 스레드당 | 높음 |
| 오브젝트 풀 | ~0.2 | 낮음 | 풀별 | 중간 |
CCU별 권장 스레드 수
| 목표 CCU | 권장 스레드 수 | io_context | 비고 |
|---|---|---|---|
| 1,000 | 2~4 | 1개 공유 | 소규모 |
| 10,000 | 4~8 | 1개 공유 | Strand 필수 |
| 50,000 | 8~16 | 1~2개 | Acceptor 분리 검토 |
| 100,000+ | 16~32 | 2개 이상 | 수평 확장 병행 |
버퍼 크기 선택 가이드
| 패킷 유형 | 권장 버퍼 크기 | 설명 |
|---|---|---|
| 제어 패킷 | 64~256B | 로그인, 하트비트 |
| 일반 게임 | 256~1KB | 채팅, 아이템 사용 |
| 대용량 | 4KB~16KB | 파일 전송, 스트리밍 |
추가 설계 예제: 수평 확장 아키텍처
다음은 mermaid를 활용한 상세한 구현 코드입니다. 각 부분의 역할을 이해하면서 코드를 살펴보시기 바랍니다.
flowchart TB
subgraph Clients[클라이언트]
C1[Client]
end
subgraph LB[로드 밸런서]
LB1[L4/L7]
end
subgraph Instances[서버 인스턴스]
I1[Instance 1]
I2[Instance 2]
I3[Instance N]
end
subgraph Shared[공유 저장소]
Redis[(Redis)]
end
C1 --> LB
LB --> I1
LB --> I2
LB --> I3
I1 --> Redis
I2 --> Redis
I3 --> Redis
스테이트리스 설계: 세션 상태를 Redis에 저장하면, 어떤 인스턴스로 요청이 와도 처리 가능. 인스턴스 장애 시에도 세션 유지. 세션 어피니티 설계: L4에서 클라이언트 IP/쿠키 기반으로 같은 인스턴스로 라우팅. 인스턴스 메모리에 세션 보관. 장애 시 해당 클라이언트만 재연결.
8. 면접에서 답변할 때 포인트
- “대규모 동시 접속을 어떻게 처리하나요?” → 이벤트 기반 I/O(Asio), 논블로킹 소켓, 스레드 풀에서 run(), Strand로 연결 단위 직렬화. 필요 시 수평 확장·로드밸런싱.
- “메모리 풀을 왜 쓰나요?” → 대량의 단명 객체에서 할당/해제 비용과 힙 단편화를 줄이기 위해. 오브젝트 풀로 생성/파괴 비용도 줄일 수 있다.
- “세션과 패킷을 어떻게 관리하나요?” → 연결당 세션 객체, Strand로 해당 연결의 I/O 직렬화, 패킷은 버퍼 풀·고정 버퍼·Composed Operation으로 처리.
- “10만 CCU를 어떻게 달성하나요?” → 단일 노드: io_context + N개 run() 스레드, 연결당 Strand, 메모리/오브젝트 풀. 한계 도달 시: 수평 확장, 로드 밸런서, 세션 분산.
9. 구현 체크리스트
아키텍처
- 이벤트 기반 I/O (epoll/kqueue/Asio) 적용
- 스레드 수 = CPU 코어 수 (또는 N+1)
- 연결당 Strand로 I/O 직렬화
- Acceptor-Worker 분리 (필요 시)
메모리
- 메모리 풀 또는 오브젝트 풀 도입
- 스레드 로컬 풀 (락 경합 감소)
- 풀 반환 시 참조 정리 확인
세션·패킷
- 연결당 세션 객체
- 고정 버퍼 또는 버퍼 풀
- 송신 큐 + Strand 내 순차 송신
운영
- 그레이스풀 셧다운
- 헬스 체크 엔드포인트
- 메트릭 노출 (연결 수, 지연, 에러율)
- 로그 레벨·구조화 로깅
같이 보면 좋은 글 (내부 링크)
이 주제와 연결되는 다른 글입니다.
- C++ 도메인별 요구 역량 | 네카라쿠배·금융·게임 [#46-3]
- C++ 커스텀 메모리 할당자(Memory Pool) 제작기 [#48-3]
- C++ 메모리 풀 완벽 가이드 | 객체 풀·슬랩·아레나·std::pmr 실전 [#32-2]
이 글에서 다루는 키워드 (관련 검색어)
시스템 설계, C++, 대규모 서버, 동시 접속, 메모리 풀, 게임 서버 아키텍처 등으로 검색하시면 이 글이 도움이 됩니다.
자주 묻는 질문 (FAQ)
Q. 이 내용을 실무에서 언제 쓰나요?
A. C++ 면접 단골 주제인 대규모 동시 접속자 처리 구조, 메모리 풀 기반 객체 관리 설계 등 실전 아키텍처를 다룹니다. 실무에서는 위 본문의 예제와 선택 가이드를 참고해 적용하면 됩니다.
Q. 선행으로 읽으면 좋은 글은?
A. 각 글 하단의 이전 글 링크를 따라가면 순서대로 배울 수 있습니다. C++ 시리즈 목차에서 전체 흐름을 확인할 수 있습니다.
Q. 더 깊이 공부하려면?
A. cppreference와 해당 라이브러리 공식 문서를 참고하세요. 글 말미의 참고 자료 링크도 활용하면 좋습니다.
Q. 메모리 풀과 오브젝트 풀 중 뭘 써야 하나요?
A. 메모리 풀: 바이트 버퍼(패킷, 임시 데이터)처럼 “크기만 중요하고 타입이 없는” 경우. 오브젝트 풀: 세션·엔티티처럼 “생성자/소멸자·상태 초기화”가 필요한 객체. 둘을 함께 쓰는 경우가 많습니다(세션은 오브젝트 풀, 세션 내부 버퍼는 메모리 풀).
Q. Strand 없이 mutex로 보호하면 안 되나요?
A. 동작은 합니다. 하지만 Strand는 락을 걸지 않고 executor 큐에서 순차 실행을 보장하므로, 락 경합·컨텍스트 스위칭이 없어 성능이 좋습니다. Asio 기반이라면 Strand 사용을 권장합니다.