어디서 터졌는지 어떻게 알지? 분산 로그 추적

모놀리스와 마이크로서비스의 디버깅 차이

과거 단일 서버(Monolith) 환경에서는 디버깅이 직관적이었습니다. 에러가 발생하면 해당 서버에 접속해서 로그 파일 하나만 열어보면 되었습니다. 하나의 요청은 처음부터 끝까지 하나의 서버 안에서 처리되었기 때문에, 시간 순서대로 쭉 읽어 내려가기만 하면 어디서 문제가 생겼는지 쉽게 파악할 수 있었습니다.

하지만 마이크로서비스에서는 이야기가 다릅니다. 사용자가 '상품 구매' 버튼을 한 번 눌렀을 뿐인데, 그 이면에서는 API 게이트웨이 -> 주문 서비스 -> 결제 서비스 -> 재고 서비스 -> 배송 서비스로 수많은 네트워크 호출이 이어집니다.

미로 속의 실타래: Trace ID (추적 ID)

이 문제를 해결하는 핵심 아이디어는 놀랍도록 단순합니다. 사용자의 첫 요청이 들어올 때 고유한 '꼬리표'를 붙여주고, 다른 서비스를 호출할 때마다 이 꼬리표를 계속 전달하는 것입니다.

이 고유한 꼬리표를 분산 추적(Distributed Tracing)에서는 Trace ID라고 부릅니다.

Trace ID가 전달되는 과정

1. 사용자가 API 게이트웨이에 접근하면, 게이트웨이는 `Trace ID: abc-123`이라는 식별자를 생성합니다.
2. 주문 서비스를 호출할 때 HTTP 헤더(Header)에 `X-Trace-Id: abc-123`을 담아 보냅니다.
3. 주문 서비스는 로그를 남길 때 무조건 이 Trace ID를 포함하여 로그를 적습니다.
4. 주문 서비스가 다시 재고 서비스를 호출할 때도 헤더에 똑같이 `abc-123`을 담아 보냅니다.

이제 에러가 발생했다고 가정해 봅시다. 개발자는 엘라스틱서치(Elasticsearch)나 데이터독(Datadog) 같은 중앙화된 로그 시스템 검색창에 `abc-123`만 입력하면 됩니다. 그러면 5개의 서로 다른 서버에서 남긴 로그들이 Trace ID로 묶여서 마치 하나의 서버에서 남긴 로그처럼 깔끔하게 정렬되어 나타납니다.

```http
POST /orders HTTP/1.1
Host: order-service
X-Trace-Id: a1b2c3d4-5678
Content-Type: application/json

{"userId": 99, "itemId": 100}
```

Span ID: 더 상세한 여정 기록하기

Trace ID가 전체 요청의 '실타래'라면, 그 안에서 구체적으로 어떤 서비스가 얼만큼의 시간을 썼는지 측정하기 위해 Span ID라는 개념을 함께 사용합니다.

• Trace: 전체 요청의 여정 1개 (예: 전체 상품 구매 과정)
• Span: 그 여정 속에서 발생한 개별 작업 단위 (예: 주문 서비스 내부 로직, 외부 결제사 API 연동 시간 등)

Trace ID와 Span ID를 수집하면 텍스트 로그를 넘어 시각적인 폭포수(Waterfall) 차트를 그릴 수 있습니다. "아, 전체 응답에 3초가 걸렸는데, 재고 서비스에서 DB를 조회하는 구간(Span)에서 무려 2.5초를 소모했구나!" 하고 직관적인 성능 병목 파악이 가능해집니다.