무신사 — 로그가 서비스를 멈춘 원인과 커스텀 Appender로의 해결기

주요 내용

• 컨테이너 환경에서 동기(Synchronous) 로깅 시, 요청 스레드가 stdout에 직접 쓰다가 OS 파이프 버퍼(약 64KB)가 가득 차면 해당 스레드가 DB 커넥션을 보유한 채 블로킹 상태에 빠짐
• 스레드 덤프 분석 결과 수십 개의 스레드가 'stdout write'에서 멈춰 있었으며, 이로 인해 커넥션 풀 고갈 및 요청 30초 주기 일괄 실패 장애 발생
• 장애의 배경에는 전사 표준 로깅 가이드가 있었으며, 해당 라이브러리는 로그를 JSON으로 구조화하고 OpenTelemetry를 통해 trace_id·span_id를 자동 삽입·전파하는 방식
• OpenTelemetry는 W3C Trace Context 표준을 따르며, 서비스 간 traceparent 헤더를 자동으로 파싱·주입해 분산 추적과 로그를 같은 ID로 조회 가능하게 함
• MDC는 스레드별 로컬 맵이라 서비스 경계를 넘는 자동 전파가 불가해 OpenTelemetry를 채택
• 최종적으로 약 30줄 분량의 커스텀 Appender를 개발해 문제를 해결

큐레이터 노트

관측성을 높이기 위해 도입한 표준 로깅 방식이 오히려 서비스 가용성을 저해할 수 있음을 보여주는 실제 사례로, 비동기 로깅 전환을 검토하는 백엔드 개발자에게 관측성과 가용성을 동시에 설계해야 한다는 점을 시사한다.