2025-12-24

1일 1아티클

Boris Tane (Cloudflare Lead Worker)

로깅의 문제

기존 로깅

• Monolith 시절에 만들어진 방식
• Microservice 시대에서는 사용자 요청 한번이 수십 개의 서비스를 방문 → “시작”, “종료”, “DB 연결” 등 의미 없는 로그 조각 생산
• 문제가 발생해 로그 분석 시도 → 수백 줄의 로그 중 실패 원인 관련 문맥 탐색이 매우 어려움, 단순 문자열 검색(grep) 한계 존재

해결 방안

• 기존 방식 : 코드 실행 과정을 일기 쓰듯 로그로 기록
• Wide Event : 요청 1개당 단 1개의 거대한 이벤트(JSON)을 기록, 그 안에 모든 문맥 정보 기입

Wide Event 예시

  {
    "timestamp": "2025-01-15...",
    "request_id": "req_8bf7...",
    "user_id": "user_456",
    "subscription": "premium",  // 비즈니스 정보 (중요!)
    "cart_total": 15900,        // 장바구니 정보
    "error_code": "card_declined",
    "feature_flags": {"new_checkout": true}, // 기능 플래그 상태
    "duration_ms": 1247
  }

구현 방법 - Middleware 활용

• 요청 발생 시, 비어있는 이벤트 객체 생성
• 코드 실행 중에 계속 해당 객체에 내용 기록
• 요청 종료 (Finally block) 시, 완성된 이벤트를 로그에 1번 기록

비용 문제 해결 방안

• 모든 요청을 기록 시 저장 비용 매우 비쌈
• Sampling (일부 저장) 필수적
• 무작위로 저장 시, 중요 에러를 넘길 수 있음
• Tail Sampling : 요청이 다 끝난 뒤에 저장 여부 결정
  • 에러 발생, 속도 저하, VIP 고객 등의 중요 사항 → 필수 저장
  • 정상적이고 빠른 요청 → 1~5% 수준 랜덤 저장
  • 비용 감소 + 디버깅에 필요한 핵심 정보 저장 가능

오늘 배운 것

1. 관통 프로젝트
   • 발표자료 작성
2. 포트폴리오 작성 (con.)

내일 할 일

1. 싸피데이 준비
2. 포트폴리오 작성 (con.)

참고자료

• Logging sucks.