개요
Spring의 복잡도와 WordPress의 무거움에 지쳐서 C로 직접 만든 블로그 엔진, Fly.Board를 개발하였다. HTTP/3(QUIC) over TLS 1.3 환경을 지원하며, HTTP/2 over TLS 1.3에서 실제 C10k/C100k/C1m 연결을 유지하며 측정한 결과가 흥미로워서 정리해 본다.
핵심은 단순함이다. 커스텀 프레임워크(CWIST), 자체 메모리 관리 도구(LibTTAK), 그리고 단일 바이너리로 구성되어 있다.
벤치마크 환경
| 항목 | 값 |
|---|---|
| OS | Linux 7.0.0-mountain+ |
| 아키텍처 | x86_64 |
| CPU | AMD Ryzen 5 5600X @ 3.70GHz (6 cores / 12 threads) |
| RAM | 64 GB |
| 디스크 | Samsung SSD 980 1TB (NVMe) |
| OpenSSL | 3.5.6 |
| 벤치마크 도구 | h2load |
| CWIST | patches/cwist |
C10k 벤치마크
CWIST_WORKERS=4 /usr/bin/time -v ./fly_board로 측정했다. h2load로 10,000개 동시 연결을 유지하며 측정한 결과는 다음과 같다.
| 항목 | 값 |
|---|---|
| 동시 연결 수 | 10,000 |
| 지속 시간 | 21.72 s |
| 최대 RSS | 약 117 MB (120,184 KB) |
| CPU 사용량 | 약 200% |
| User time | 35.19 s |
| System time | 8.39 s |
| Major page faults | 1 |
| Minor page faults | 57,581 |
| Voluntary context switches | 2,235,918 |
| Involuntary context switches | 405,099 |
| Swaps | 0 |
| File system inputs | 136 |
| File system outputs | 8 |
| 총 요청 수 | 20,000 |
| 총 성공 수 | 20,000 |
| 총 실패 수 | 0 |
| 대략적 총 RPS | 1,291.35 |
| 성공률 | 100.00% |
| 종료 상태 | 0 |
C100k 벤치마크
CWIST_WORKERS=12 /usr/bin/time -v ./fly_board로 측정했다. h2load로 100,000개 동시 연결을 유지하며 측정한 결과는 다음과 같다.
| 항목 | 값 |
|---|---|
| 동시 연결 수 | 100,000 |
| 지속 시간 | 2:46.70 |
| 최대 RSS | 약 174 MB (178,056 KB) |
| CPU 사용량 | 약 88% |
| User time | 118.41 s |
| System time | 28.31 s |
| Major page faults | 0 |
| Minor page faults | 150,669 |
| Voluntary context switches | 6,984,249 |
| Involuntary context switches | 1,081,830 |
| Swaps | 0 |
| File system inputs | 0 |
| File system outputs | 8 |
| 총 요청 수 | 200,000 |
| 총 성공 수 | 200,000 |
| 총 실패 수 | 0 |
| 대략적 총 RPS | 1,244.21 |
| 성공률 | 100.00% |
| 종료 상태 | 0 |
C1m 벤치마크
CWIST_WORKERS=24 /usr/bin/time -v ./fly_board로 측정했다. h2load로 1,000,000개 동시 연결을 유지하며 측정한 결과는 다음과 같다.
| 항목 | 값 |
|---|---|
| 동시 연결 수 | 1,000,000 |
| 지속 시간 | 10:13.39 |
| 최대 RSS | 약 216 MB (220,888 KB) |
| CPU 사용량 | 약 55% |
| User time | 201.98 s |
| System time | 136.96 s |
| Major page faults | 1 |
| Minor page faults | 220,927 |
| Voluntary context switches | 38,926,712 |
| Involuntary context switches | 4,460,022 |
| Swaps | 0 |
| File system inputs | 8 |
| File system outputs | 8 |
| 총 요청 수 | 2,000,000 |
| 총 성공 수 | 607,048 |
| 총 실패 수 | 1,392,952 |
| 대략적 총 RPS | 989.66 |
| 성공률 | 30.35% |
| 종료 상태 | 0 |
참고: HTTP/2 (TLS 1.3) 상에서 실제 클라이언트 연결을 유지하며 측정한 값이다.
구조적 비교
개인 VPS 하나로 운영하는 블로그 엔진 입장에서 본다.
WordPress: PHP-FPM + MySQL 기반. 페이지 하나 띄우는 데도 수십~수백 MB를 소모하며, C10k는 사실상 불가능하다. 보통 Nginx + Varnish + 다단 캐싱 레이어를 쌓아야 버틴다.
Spring Boot: JVM 힙만 기본 256~512MB, 운영에서는 1GB 이상이 일반적이다. DI 컨테이너, 리플렉션, GC 튜닝까지 “블로그 하나 띄우자”고 하기엔 복잡도가 과하다.
Fly.Board: idle 상태 약 82MB, C10k에서 117MB, C100k에서 174MB, C1m에서 216MB. 단일 바이너리에 캐싱 레이어 없이 C10k와 C100k를 소화한다.
설계 포인트
- LibTTAK: 자체 메모리 관리 도구. 비동기 처리와 유사 GC Wrapper를 제공해서 C의 속도는 챙기면서 메모리 안전성을 확보했다. 100만 개의 동시 연결(C1m) 환경에서도 최대 RSS를 216 MB 수준으로 제어하여 선형적인 자원 억제 능력을 보여준다.
- NukeDB: SIGINT 수신 후에도 8개의 FS output으로 데이터를 안전하게 저장했다. (실 운영시에는 High-RTT 불안정성으로 인해 일반 SQLite 바인딩을 사용하였다.)
- 프로토콜 스택: HTTP/3(QUIC) + TLS 1.3을 커스텀 C 스택으로 지원. HTTP/2 over TLS 1.3 벤치마크는 단순한 PoC 수준이 아님을 보여준다.
- 연결당 메모리: C10k 기준 120,184 KB / 10,000 = 약 12 KB. 이 수치는 Nginx와 비교할 때도 경쟁력이 있다.
아쉬운 점
C1m 벤치마크에서 성공률이 30.35%에 머물렀다. 607,048개의 성공 응답을 기준으로 계산한 실질 RPS는 약 989.66 수준이다. 1,000,000개 연결과 2,000,000개 요청 규모에서는 파일 디스크립터 한계, 커널 파라미터, h2load 측 클라이언트 병목 외에 내부 아키텍처의 자원 경합이 복합적으로 작용한 것으로 보인다.
특히 C10k(CWIST_WORKERS=4)일 때 CPU 사용량은 약 200%였으나, 연결이 10배 늘어난 C100k(CWIST_WORKERS=12)에서 CPU 사용량은 88%로 급감하고 지속 시간은 2분 46.7초(166.7초)로 늘어났다. 테스트 장비의 물리 하드웨어 스레드(12 threads) 임계치에 도달하거나 이를 초과하는 워커 설정(CWIST_WORKERS=24 등)으로 인해 워커 간 락 경합 및 불필요한 문맥 교환(Context Switch)이 폭증했기 때문이다.
이로 인해 C1m으로 갈수록 System time(136.96s)이 User time(201.98s)에 근접하는 커널 오버헤드가 발생했으며, 워커 간 경합으로 요청이 직렬화되거나 블로킹 상태에 빠져 자원을 효율적으로 쓰지 못하는 병목이 관찰된다. 대규모 연결 환경에서 가용성과 성능 간의 균형을 잡으려면 epoll 루프 최적화나 io_uring 도입 등 구조적 개선이 선행되어야 할 것이다.
결론
Fly.Board는 Spring이나 WordPress를 대체할 개발자 블로그 엔진으로 상당한 잠재력을 보인다. C10k와 C100k를 단일 바이너리로 소화하고, 1GB VPS에서도 여유롭게 운영 가능한 메모리 곡선은 개인 호스팅 입장에서 매력적이다.
프로덕션 쇼핑몰이 아닌, 개발자가 직접 관리하는 블로그 엔진이라는 타겟에서는 기술적 완성도가 이미 높은 편이다. C1m 안정화, 장기적인 메모리 누수 테스트, 그리고 쓰기 부하 벤치마크만 추가로 거치면 충분히 실용적인 대안이 될 수 있을 것 같다.