본문으로 건너뛰기
피드

C++20으로 M:N 스케줄러를 밑바닥부터 구현한 교육용 프로젝트 (EBR, Work-Stealing)

backend 약 7분
vote
0
댓글
북마크

C++20 코루틴 기반으로 M:N 비동기 런타임을 약 1,000줄로 직접 구현한 교육용 프로젝트. Work-Stealing, EBR 메모리 회수, Lock-Free 큐, Reactor 패턴 등 고성능 동시성 런타임의 핵심 개념을 최소한의 코드로 보여줌. MacBook M1 Air에서 186,045 QPS를 달성해 Go 구현(193,587 QPS)에 근접한 성능을 기록함.

  • 1

    Chase-Lev Lock-Free Deque 기반 Work-Stealing으로 스레드 간 부하 분산

  • 2

    EBR(Epoch-Based Reclamation)로 Lock-Free 프로그래밍의 ABA 문제와 Use-After-Free 방지

  • 3

    약 1,000줄의 최소 코드로 M:N 스케줄러, Reactor, Channel 등 핵심 컴포넌트 구현

  • 4

    MacBook M1 Air 기준 186,045 QPS로 Go 구현 대비 96% 수준 성능 달성

C++20으로 M:N 스케줄러를 밑바닥부터 구현한 교육용 프로젝트

C++20 코루틴을 활용해 M:N 비동기 런타임을 처음부터 직접 만들어본 교육용 프로젝트 tiny_coro가 공개됨. Seastar나 Folly 같은 산업용 라이브러리의 복잡한 래퍼를 걷어내고, 고성능 동시성 런타임의 핵심 개념만 약 1,000줄의 코드로 보여주는 것이 목표임.

핵심 컴포넌트 구성

  • M:N 스레딩 모델: M개의 코루틴을 N개의 커널 스레드에 매핑해 멀티코어 성능을 최대한 활용함
  • Work-Stealing 스케줄링: Chase-Lev Lock-Free Deque 기반으로, 유휴 스레드가 바쁜 스레드의 큐 꼬리에서 태스크를 훔쳐오는 방식으로 부하를 분산함
  • EBR (Epoch-Based Reclamation): Lock-Free 프로그래밍에서의 ABA 문제를 해결하고, 큐 확장이나 노드 삭제 시 Use-After-Free를 방지하는 메모리 안전 회수 메커니즘
  • AsyncMutex: Baton Passing 기술 기반으로, 깨울 때 락 소유권을 직접 전달해 thundering herd 문제를 회피함
  • Channel: CSP(Communicating Sequential Processes) 모델 구현, 버퍼 모드와 언버퍼 모드 모두 지원

EBR이 왜 필요한가

Lock-Free 큐(StealQueue)에서 한 스레드가 노드 A를 읽고 있을 때, 다른 스레드가 A를 삭제하고 메모리를 해제할 수 있음. 시스템이 이 메모리를 즉시 재사용하면 읽는 쪽 스레드가 크래시하거나 더티 데이터를 읽게 됨. tiny_coro의 EBR 방식은 다음과 같음:

  • 각 스레드가 로컬 Epoch을 유지함
  • 모든 활성 스레드가 따라잡은 후에만 글로벌 Epoch이 전진함
  • 글로벌 Epoch이 2세대(G-2) 이상 앞서간 경우에만 메모리를 실제로 삭제함

Lock-Free 큐의 최적화 디테일

  • alignas(64): top과 bottom 포인터가 같은 캐시 라인에 놓이는 것을 방지해 False Sharing을 차단함
  • seq_cst 배리어: pop 연산에서 Dekker 알고리즘 원리를 따라, 큐에 원소가 하나만 남았을 때의 데이터 레이스를 방지함
  • await_suspend가 bool을 반환하는 기능을 활용해 Fast Path 최적화 구현. 락 획득이나 버퍼 읽기/쓰기 성공 시 코루틴이 서스펜드 없이 바로 계속 실행되므로, 기존의 "서스펜드 -> 큐 삽입 -> 스케줄러 웨이크업" 경로 대비 훨씬 빠름

아키텍처 흐름

전체 구조는 다음과 같이 동작함:

  • Scheduler -> Worker 스레드 풀 시작 + 글로벌 큐 관리
  • Worker: 각각 시스템 스레드에 바인딩되어 run_once() 루프 실행. 우선순위는 로컬 큐 -> 글로벌 큐 -> 다른 Worker에서 훔치기 -> Sleep(Park)
  • EBR Manager: 글로벌 Epoch을 모니터링해 Lock-Free 큐 확장 시 모든 스레드가 크리티컬 섹션을 빠져나간 후에만 메모리를 해제함
  • Parker: Atomic Wait(Futex) 기반으로 Lost Wakeup 문제를 해결하는 효율적 슬립 메커니즘

네트워크 I/O

  • Reactor 패턴: epoll(Linux) / kqueue(macOS) 캡슐화
  • Zero-Copy HTTP 파서: std::string_view로 수신 버퍼에서 직접 동작해 메모리 할당을 회피함
  • 스트림 처리: 코루틴 기반 파일 업로드/다운로드를 8KB 상수 메모리로 처리함

성능 결과

MacBook M1 Air 로컬 루프백 wrk 테스트 기준:

  • tiny_coro 기반 간단한 HTTP 서버: 186,045 QPS
  • 동일 로직의 Go 구현: 193,587 QPS
  • ASAN, TSAN 테스트 모두 통과함

Go가 Google의 깊은 최적화와 OS 통합의 이점을 가진 점을 감안하면, 교육용 프로젝트로서 매우 인상적인 수치임.

학습 가이드

이 프로젝트는 프로덕션용이 아니라 순수 교육 목적임. 버그가 존재하지만 코드의 최소한의 가독성을 유지하기 위해 의도적으로 수정하지 않은 상태임. 대신 자체 개발한 coroTracer 도구로 버그의 근본 원인을 분석한 기록이 포함되어 있음.

  • 입문자: how_to_make_your_MN_scheduler.md 문서를 따라 순서대로 학습할 수 있음. 기본 C++ 문법만 알면 충분함
  • 코루틴에 익숙한 개발자: docs 폴더에서 모듈별로 독립적으로 참고 가능함
  • 전체 코드가 약 1,000줄 수준이라 통독하기에도 부담이 적음

참고 및 영감

  • Tokio(Rust): Work-Stealing과 Reactor 설계의 영감 소스
  • Go Runtime: M:N 모델과 Channel 설계 참고
  • picohttpparser: HTTP 파싱용 (코루틴 스케줄러 자체는 외부 의존성 없음)

C++20 코루틴의 내부 동작 원리를 "직접 만들어보면서" 이해하고 싶은 개발자에게 매우 좋은 학습 자료가 될 것으로 보임.

Seastar나 Folly 같은 산업용 프레임워크의 핵심 원리를 1,000줄로 압축해 보여주는 점이 인상적임. C++20 코루틴의 내부 동작을 직접 구현하며 배우고 싶은 시니어 개발자에게 좋은 참고 자료가 될 것으로 보임.

댓글

댓글

댓글을 불러오는 중...

backend

클릭하우스가 PgBouncer 처리량을 4배로 끌어올린 방법

ClickHouse Managed Postgres 팀은 단일 스레드인 PgBouncer를 여러 프로세스로 띄우고 `so_reuseport`와 피어링(peering)을 조합해 16 vCPU 머신을 제대로 쓰게 만들었다. 동일한 AWS 환경에서 단일 프로세스는 약 8.7만 TPS 근처에서 막혔지만, 16개 프로세스 구성은 약 33.6만 TPS까지 올라갔다.

backend

SQLite 쓸 거면 STRICT 테이블을 기본값으로 보자는 주장

SQLite의 STRICT 테이블은 INTEGER 컬럼에 문자열이 들어가는 식의 타입 실수를 막아주는 기능이다. 글쓴이는 SQLite 특유의 유연한 타입 시스템보다, 실수는 빨리 터뜨리는 쪽이 실무에서 낫다고 주장한다. 다만 기존 테이블을 바로 STRICT로 바꾸기 어렵고, SQLite 3.37.0 이상에서만 쓸 수 있다는 제약도 있다.

backend

왜 아직도 Lisp를 배워볼 만한가

Lisp는 괄호가 많은 이상한 언어처럼 보이지만, 핵심은 문법이 아니라 언어 자체를 확장할 수 있다는 점에 있음. 매크로, 코드-데이터 동일성, REPL 중심 개발이 합쳐지면 프로그램을 '작성'한다기보다 살아 있는 시스템을 계속 진화시키는 방식으로 개발하게 됨.

backend

EDB 포스트그레스 AI, 포레스터 멀티모델 데이터 플랫폼 리더 선정

EDB의 AI 데이터 플랫폼 EDB 포스트그레스 AI가 2026년 2분기 포레스터 웨이브 멀티모델 데이터 플랫폼 보고서에서 리더로 선정됐음. 트랜잭션, 분석, AI 워크로드를 하나의 플랫폼에서 다루는 흐름이 강해지는 가운데, EDB는 전략과 현재 제공 기능 모두에서 높은 평가를 받았다고 밝힘.

backend

Bun, Zig에서 Rust로 갈아탔다: 11일짜리 초대형 런타임 포팅 실험

Bun 팀이 53만 줄이 넘는 Zig 코드베이스를 Rust로 기계적으로 포팅했고, Bun v1.4.0부터 Rust 기반으로 전환될 예정임. 핵심 이유는 성능보다 안정성이었고, use-after-free, double-free, 메모리 누수 같은 문제를 컴파일러와 타입 시스템으로 더 빨리 잡기 위해서였음. Claude Code 워크플로 64개를 병렬로 돌려 11일 만에 전 플랫폼 테스트 통과까지 밀어붙인 사례라, LLM 기반 대규모 코드 마이그레이션의 꽤 강한 신호탄임.