Show GN: LogXide — 12.5배 빠른 Rust 기반 Python 로깅 프레임워크
(github.com/Indosaram)안녕하세요, Python 웹 애플리케이션 및 데이터 파이프라인과 같은 고부하 환경에서 파일 I/O 및 로깅 병목을 겪는 분들을 위한 LogXide를 소개합니다.
1. 만든 이유 (The Problem)
Python의 기본 logging 모듈은 순수 Python으로 작성되어 있습니다. 일반적인 환경에서는 충분하지만, 트래픽이 몰리는 구간이나 대규모 로깅 파이프라인에서는 I/O 작업 중 GIL(Global Interpreter Lock)을 점유하며 애플리케이션 전체의 성능을 저하시키는 원인이 됩니다.
2. 어떻게 해결했나 (Architecture)
LogXide는 코어 로직과 핸들러를 Rust로 작성하고 PyO3로 바인딩했습니다.
-
Python-side Level Check:
FastLoggerWrapper를 두어 로그 레벨이 비활성화된 경우(예: INFO 레벨 설정 시 DEBUG 호출),PyObject생성이나 PyO3 경계 통과 없이 Python 단에서 즉시 무시합니다. 이 최적화로 빈 호출 시 속도가 2~5배 향상되었습니다. -
논블로킹 I/O: StreamHandler, HTTPHandler, OTLPHandler는
crossbeam채널과 백그라운드 스레드를 이용해 비동기적으로 로그를 처리합니다. 주 애플리케이션 스레드를 블로킹하지 않습니다. -
동기 직접 write: FileHandler의 경우
Mutex<BufWriter>를 사용해 직접 OS I/O를 수행하며, 필요 시에만 flush를 수행하여 I/O 오버헤드를 극단적으로 줄였습니다.
3. 주요 벤치마크 (macOS ARM64, Python 3.12 기준)
- FileHandler: 2.09M msgs/sec (stdlib 167K 대비 12.5배 빠름)
- StreamHandler: 2.14M msgs/sec (stdlib 11K 대비 186배 빠름)
- C로 작성된
Picologging보다 실제 파일 포맷팅 I/O에서 25% 더 빠르고, 순수 파이썬인Structlog보다 2.4배 빠릅니다.
4. 내장 기능 및 사용법
from logxide import logging 한 줄만 변경하면 기존의 logging.getLogger() 코드를 그대로 사용할 수 있는 구조입니다. 최근 백엔드 아키텍처 트렌드에 맞춰 다음 핸들러들을 Rust 네이티브 수준에서 내장했습니다:
- OTLPHandler: OpenTelemetry 에이전트 없이 Protobuf 기반 직접 전송
- HTTPHandler: 배치(Batch) 모아 보내기 기능
-
SentryHandler: 에러 로깅 통합 지원 (
pip install logxide[sentry]) - ColorFormatter: ANSI 제어 문자를 활용한 터미널 컬러 출력 지원
5. 명확한 한계 (Trade-offs)
도입을 검토하실 때 100% Drop-in replacement가 아님을 아셔야 합니다:
- Python으로 작성된 커스텀
logging.Handler를 상속받아 등록할 수 없습니다. (Rust로 구현된 내장 핸들러만 사용해야 최고 성능이 유지됩니다). -
Logger나LogRecord객체를 서브클래싱할 수 없습니다. - pytest 환경에서는 빌트인
caplog대신 LogXide가 제공하는caplog_logxidefixture를 사용해야 합니다.
성능 병목으로 인해 C 기반 로거나 구조화된 로깅 라이브러리를 찾고 계셨다면 훌륭한 대안이 될 것입니다! Django, FastAPI, Flask에 바로 적용 가능한 연동 가이드도 공식 문서에 포함되어 있으니 한 번 살펴봐 주시고 피드백 주시면 감사하겠습니다.