피드로 돌아가기
Dev.toDatabase
원문 읽기
epoll 기반 단일 스레드 아키텍처로 수만 TPS 달성
I built a Redis clone in C: From blocking I/O to epoll to crash safe persistence
AI 요약
Context
Blocking I/O 기반의 초기 서버 구조로 인해 클라이언트 요청 처리 중 전체 서버가 정지하는 병목 현상 발생. 단일 클라이언트가 시스템 전체 리소스를 점유하여 다수 연결 처리 및 응답성 확보에 한계 노출.
Technical Solution
- djb2 해시 함수 및 비트 연산(&) 기반의 Hash Table 구현을 통한 O(1) 데이터 조회 성능 확보
- select의 O(n) 스캔 오버헤드 제거를 위해 커널 내 관심 목록을 유지하는 epoll 기반 Event Loop 도입
- Non-blocking I/O 설계를 통한 I/O Multiplexing 구현으로 단일 스레드 내 수만 개의 동시 연결 관리
- Linked List 기반 Chaining 기법 적용으로 해시 충돌 상황에서의 데이터 정합성 유지
- Valgrind를 활용한 메모리 누수 검증으로 40,000회 이상의 작업 수행 시 안정성 확보
Impact
- epoll 도입을 통해 단일 스레드 구조임에도 불구하고 초당 수만 건의 요청(Tens of thousands of requests per second) 처리 가능
- 40,000회 작업 수행 후 Zero memory leaks 검증 완료
Key Takeaway
멀티스레딩의 복잡성과 Locking 오버헤드 없이도 I/O Multiplexing 최적화를 통해 고성능 서버 아키텍처 설계 가능
실천 포인트
1. 대규모 동시 연결 처리 시 select 대신 epoll/kqueue 등 커널 이벤트 알림 메커니즘 검토
2. 해시 테이블 크기를 2의 거듭제곱으로 설정하여 Modulo 연산을 비트 AND 연산으로 최적화
3. 고성능 서버 설계 시 무분별한 스레드 추가보다 Blocking 지점 제거 및 Event-driven 구조 우선 고려