1코어 서버로 31만 명, 4코어로 143만 명? 언어별 웹서버 한계를 겨루는 'Server Challenge' 시리즈

들어가며
"우리 서버는 동시 사용자를 몇 명까지 버틸 수 있을까?" 백엔드 개발자라면 한 번쯤 해봤을 고민이죠. 이 질문을 오픈소스 대회 형식으로 풀어낸 프로젝트가 있습니다. 개발 유튜버 arjaythedev가 진행하는 Server Challenge 시리즈입니다.
여러 프로그래밍 언어와 프레임워크로 같은 API를 구현하고, 같은 하드웨어에서 동시 사용자 처리 성능을 비교합니다. 단순한 "Hello World" 벤치마크와는 다릅니다. 실제 DB 조회·쓰기와 JWT 인증까지 들어간 웹 애플리케이션을 기준으로 측정하기 때문에 실무와 꽤 가까운 결과를 볼 수 있습니다.
한눈에 보는 핵심 요약
- 동일한 API 명세를 다양한 언어·프레임워크로 구현해 동시 사용자 처리량을 비교합니다.
- 누구나 GitHub PR로 구현체를 제출할 수 있고, 동일한 하드웨어에서 검증한 뒤 리더보드에 공개됩니다.
- 챌린지는 세 가지입니다: $12 Server, Multicore Server, Million Users
- 현재 1위 기록:
- 1코어: Rust(io_uring) 31만 명
- 8코어(DB 공유): Rust(epoll) 23만 명
- 4코어: C#(epoll) 143만 명
1. $12 Server Challenge: 저렴한 서버로 어디까지 버틸까?
월 12달러짜리 소형 서버 환경을 가정한 챌린지입니다.
- 사양: 1 vCPU, RAM 2GB
- 과제: SQLite 기반 소셜 피드 API 5개 구현
- 데이터 규모: 사용자 5만 명, 게시물 50만 개, 좋아요 200만 개
- 조건: SQLite WAL 모드 사용, 쓰기 트랜잭션의 영속성(durability) 보장 필수
- Nginx는 써도 되고 안 써도 됩니다.
📊 현재 결과: 구현체 175개를 측정했고, 1위는 Rust(io_uring) 구현으로 동시 사용자 31만 명, 약 29,000 RPS를 기록했습니다.
💡 코어 하나와 SQLite만으로 31만 명이라는 숫자가 나왔습니다. 작은 서비스라면 비싼 인프라가 꼭 필요하지 않을 수도 있다는 걸 보여주는 사례입니다.
2. Multicore Server Challenge: 멀티코어를 얼마나 잘 쓰는가
두 번째 챌린지는 멀티코어 활용 능력을 봅니다. 과제도 실제 서비스에 더 가깝습니다.
- 사양: 8 vCPU, RAM 16GB
- 과제: PostgreSQL 18 기반 RealWorld Conduit(Medium 클론) API 19개 구현
- 작업 내용: 게시물, 댓글, 팔로우, 로그인 등
- 특징: PostgreSQL과 웹서버가 같은 하드웨어의 CPU와 메모리를 나눠 씁니다
- 부하 패턴: 가상 사용자가 평균 7초마다 페이지를 이동하며, 전체 요청의 약 5%가 쓰기 작업입니다.
📊 현재 결과: 구현체 126개를 측정했고, 1위는 Rust(epoll) 구현으로 동시 사용자 23만 명, 약 59,000 RPS를 기록했습니다.
💡 DB와 웹서버가 자원을 나눠 쓰기 때문에 웹서버만 빨라서는 이길 수 없습니다. DB 부하까지 함께 고려한 설계가 필요합니다.
3. Million Users Challenge: 서버 한 대로 100만 동시 사용자
이름 그대로 서버 한 대로 100만 명을 처리하는 데 도전합니다.
- 사양: 16 vCPU, RAM 32GB
- 과제: PostgreSQL 18 기반 소셜 피드 API 5개 구현
- DB 분리: DB는 별도의 16코어 서버에서 실행되므로 웹서버 자체의 처리 성능만 겨룹니다.
- 조건: Nginx 없이 HTTP 연결을 직접 처리해야 하며, 사용자마다 keep-alive 연결을 유지합니다.
- 100만 사용자는 평균 약 42,000 RPS에 해당합니다.
- 16·8·4코어 환경에서 각각 측정하며, 16코어는 100만 명까지만 평가합니다.
📊 현재 결과: 구현체 74개를 측정했습니다. 16코어에서는 여러 구현이 100만 명에 도달했고, 4코어 최고 기록은 C#(epoll)의 143만 명입니다.
상위권 구현체의 공통 기법
- 자체 HTTP 파서 구현
- epoll / io_uring 기반 이벤트 루프
- PostgreSQL wire protocol 직접 구현
- 쿼리 파이프라이닝
💡 C#이 4코어에서 143만 명을 기록했다는 점이 눈에 띕니다. 언어 자체보다 I/O 모델과 시스템 수준의 설계가 성능을 크게 좌우한다는 걸 알 수 있습니다.
공통 규칙과 평가 방식
꼼수를 막는 규칙이 꽤 엄격합니다.
✅ 필수 조건
- API 적합성 테스트 100% 통과
- 실제 DB 접근과 쓰기 트랜잭션 커밋 보장
🚫 금지 사항
- 요청 간 응답·쿼리 결과 캐싱
- 벤치마크 전용 하드코딩
📏 성능 기준
| 지표 | 기준 | |---|---| | p95 응답시간 | 500ms 미만 | | p99 응답시간 | 1초 미만 | | 오류율 | 1% 미만 |
이 조건을 지키면서 5분 동안 유지한 최대 동시 사용자 수가 최종 점수입니다.
각 저장소에는 SPEC.md, 테스트 코드, 부하 생성기, 환경 구성 스크립트가 모두 공개되어 있어 누구나 결과를 재현하고 검증할 수 있습니다.
마치며: 이 챌린지에서 얻을 수 있는 것
이 시리즈가 흥미로운 이유는 순위표 자체보다 비교 학습 자료로서의 가치에 있습니다.
- 일반적인 프레임워크 기반 구현과 HTTP 서버, 이벤트 루프, DB 클라이언트까지 직접 만든 구현을 나란히 비교할 수 있습니다.
- 언어별 런타임 특성(GC, 비동기 모델 등)이 실제 성능에 어떤 영향을 주는지 확인할 수 있습니다.
- epoll, io_uring, 쿼리 파이프라이닝 같은 시스템 수준 최적화의 효과를 숫자로 볼 수 있습니다.
자주 쓰는 언어나 프레임워크가 리더보드에서 몇 위인지 찾아보는 것도 재미있고, 직접 구현해서 PR을 보내볼 수도 있습니다. 성능 최적화를 공부하고 있다면 상위권 구현체 코드를 읽어보는 것만으로도 배울 점이 많을 거예요. 🚀
원문: https://news.hada.io/topic?id=36697&utm_source=geeknews&utm_medium=rss&utm_campaign=news