로깅은 엉망이다

로깅의 근본적 문제

기존 로그는 모놀리식 서버 시대를 전제로 만들어져, 현대의 분산 서비스 구조를 반영하지 못함

> 한 요청이 여러 서비스, DB, 캐시, 큐를 거치지만 로그는 여전히 단일 서버 기준으로 기록됨

 

예시 로그에서는 한 요청당 13줄이 생성되어 10,000명이 동시 사용 시 초당 130,000줄이 쏟아지지만 대부분 무의미한 정보임

 

문제 발생 시 필요한 것은 맥락(context)이지만 현재 로그에는 그것이 결여 되어 있음

 

 

 

 

문자열 검색의 한계

사용자가 "결제가 안된다"고 보고했을 때, 이메일이나 ID로 로그를 검색해도 일관된 구조가 없어 유효한 결과를 얻기 어려움

서비스 간 로그 포맷이 달라 연관 이벤트 추적이 불가능

핵심 문제는 로그가 쓰기 중심으로 설계되어 있고, 조회에는 최적화 되어있지 않다는 점

 

 

 

 

 

핵심 개념 

- Structed Logging

문자열 대신 키-값(JSON) 형태로 기록하는 방식

 

- Cardinality (카디널리티)

필드의 고유 값 개수 (예: 사용자 ID)

 

- Demensionality (차원 수)

로그 이벤트 내 필드 개수

많을 수록 분석 가능성이 높음

 

- Wide Event / Canonical Log Line

요청 당 하나의 맥락이 풍부한 단일 로그 이벤트

 

대부분의 로깅 시스템은 고카디널리티 데이터를 비용 문제로 제한하지만, 실제로는 그것이 디버깅에 가장 유용함

 

 

 

 

구현 패턴

요청 수명주기 전체에서 이벤트를 구성하고, 마지막에 한 번만 출력

 

미들웨어에서 request_id, timestamp, method, path 등 기본 필드 초기화

 

핸들러에서 사용자, 장바구니, 결제, 오류정보를 점진적으로 추가

 

최종적으로 logger.info(event)로 단일 JSON 이벤트를 기록

 

 

 

 

 

 

Reference

https://news.hada.io/topic?id=25239

로깅은 엉망이다 | GeekNews