kqueue와 epoll의 시스템 아키텍처 및 설계 철학 비교 (Linux vs BSD)

서버 백엔드 개발에서 리눅스 환경은 epoll을, macOS 및 FreeBSD 등 BSD 계열은 kqueue를 I/O 멀티플렉싱 기술로 사용합니다. 본 글에서는 두 기술의 단순 성능 비교를 넘어, 시스템 아키텍처 관점에서의 설계 철학 차이를 분석합니다.

1. 모든 것은 파일이다(Everything is a File)와 범용 이벤트 서브시스템의 차이

리눅스(epoll)는 유닉스의 모든 것은 파일이다라는 철학을 따릅니다. 이에 따라 소켓 외의 시스템 자원도 파일 디스크립터(File Descriptor, FD)로 추상화하여 관리합니다. * 타이머: timerfd * 시그널: signalfd * 이벤트: eventfd

이 방식은 read, close 등 표준 파일 API를 일관되게 사용할 수 있다는 장점이 있습니다. 그러나 파일이 아닌 객체를 관리하기 위해 FD를 생성해야 하므로 커널 메모리를 소비하고 FD 테이블의 슬롯을 점유하게 됩니다.

반면, BSD의 kqueue는 범용 이벤트 통지 시스템(Generic Event Notification)으로 설계되었습니다. 파일 소켓, 타이머, 시그널, 프로세스 상태 변경 등을 모두 독립적인 '이벤트(kevent)'로 취급합니다. 따라서 파일이 아닌 이벤트를 감지하기 위해 별도의 FD를 생성할 필요 없이, 해당 이벤트에 맞는 필터(EVFILT_READ, EVFILT_TIMER, EVFILT_PROC)를 설정하여 처리합니다.

2. 상태 변경 시 시스템 콜 호출 구조: O(N) vs O(1)

다수의 감시 대상 상태를 변경해야 할 때, 두 시스템은 API 호출 구조에서 차이를 보입니다.

• epoll: 기본적으로 epoll_ctl 시스템 콜을 사용하여 감시 대상을 추가하거나 수정합니다. 여러 대상을 수정하려면 대상의 수(N)만큼 시스템 콜을 호출해야 합니다. (단, epoll_wait는 이벤트 수신만 담당)
• kqueue: kevent 함수는 이벤트의 등록과 수신(Poll)을 동시에 수행할 수 있도록 설계되었습니다. 변경 사항(changelist)을 배열로 구성하여 kevent 호출 시 한 번에 전달할 수 있으므로, 다수의 상태 변경 시 시스템 콜 호출 횟수를 최소화할 수 있습니다.

3. 자원 효율성: 타이머 처리 방식

타이머 구현 방식에서 자원 관리의 차이가 발생합니다.

• epoll (Linux): 고해상도 타이머를 사용하기 위해 timerfd_create를 호출하여 FD를 생성해야 합니다. 대량의 클라이언트(예: 1만 개)에 대해 개별 타이머를 설정할 경우, 1만 개의 추가적인 FD가 생성되어 ulimit 제한에 도달하거나 커널 구조체 오버헤드가 발생할 수 있습니다.
• kqueue (BSD): EVFILT_TIMER를 사용합니다. 이는 FD를 생성하지 않고 커널 내부의 타이머 기능을 직접 참조합니다. 따라서 사용자 프로세스는 FD 소모 없이 다수의 타이머 이벤트를 등록 및 관리할 수 있습니다.

4. 인터페이스 통합 수준 (Unified Interface)

이벤트 감지를 위한 API 구성에서도 차이가 있습니다.

• Linux: 감시 대상에 따라 서로 다른 API를 사용해야 하는 경우가 많습니다.
  • 파일 변경 감지: inotify
  • 프로세스 상태 감지: waitpid 또는 signalfd
  • 소켓 I/O: epoll
• BSD: kqueue 하나의 인터페이스로 다양한 이벤트를 통합 처리합니다.
  • 파일 변경 감지: EVFILT_VNODE
  • 프로세스 종료 감지: EVFILT_PROC
  • 시그널 감지: EVFILT_SIGNAL

5. 결론: 설계 접근 방식의 차이

kqueue는 struct kevent 구조체와 다형적인 필드(data, fflags)를 사용하여 초기 학습 비용이 높을 수 있습니다. 그러나 이는 다양한 이벤트를 단일 메커니즘으로 처리하기 위한 설계의 결과입니다.

요약하자면, 리눅스는 기존의 파일 디스크립터 모델을 확장하여 새로운 기능을 수용하는 방식으로 발전해 왔으며, BSD는 별도의 통합된 이벤트 서브시스템을 구축하는 방식을 택했습니다. 이러한 설계의 차이는 대규모 동시성 처리 및 자원 관리 효율성 측면에서 서로 다른 특성을 보입니다.