Go 배포 후 느려진 서비스, context 취소 체인으로 1시간 내 병목 찾기

Go 개발 배포 후 느려진 서비스는 겉으로는 CPU, DB, 네트워크 이슈처럼 보이지만, 실제로는 context 취소 체인 분석에서 단서가 바로 나오는 경우가 많습니습니다. 특히 배포 직후 타임아웃 정책, 미들웨어 순서, 고루틴 종료 조건이 조금만 달라져도 취소 신호가 예상보다 일찍 또는 늦게 전파되어 지연이 커집니습니다. 이 글에서는 운영 중인 시스템에서 1시간 내 병목 찾기를 목표로, 과한 추측 대신 확인 가능한 순서로 접근하는 방법을 설명합니습니다.

목차

• 배포 후 느려짐을 context 취소 체인으로 보는 이유
• 1시간 내 병목 찾기를 위한 준비와 기준선
• 로그·트레이스·pprof로 취소 전파를 추적하는 방법
• 자주 발생하는 병목 패턴과 수정 포인트
• 재배포 전 검증 체크리스트

배포 후 느려짐을 context 취소 체인으로 보는 이유

배포 후 응답 시간이 급격히 늘어났다면, 먼저 리소스 증설보다 요청 수명주기를 확인하시는 편이 안전합니습니다. Go의 context.Context는 요청 시작부터 DB 호출, 외부 API, 비동기 작업까지 타임아웃과 취소를 전달합니습니다. 이 체인 중 한 지점에서 취소 신호를 무시하거나, 반대로 너무 공격적으로 취소하면 다음과 같은 현상이 동시에 발생합니습니다.

• 재시도 증가로 인해 평균 지연과 tail latency가 함께 상승합니습니다.
• 끝나지 않은 고루틴이 쌓여 스케줄링 오버헤드가 커집니습니다.
• DB 커넥션이 반환되지 않아 대기열이 길어집니습니다.

핵심은 "느려졌다"는 결과보다 "어느 단계에서 취소/타임아웃이 비정상인지"를 먼저 특정하는 것입니습니다. 이 관점이 있어야 1시간 내 병목 찾기가 가능합니습니다.

1시간 내 병목 찾기를 위한 준비와 기준선

context 취소 체인 분석을 빠르게 하려면, 관측 포인트를 먼저 맞춰야 합니습니다. 다음 세 가지를 배포 직후 10분 안에 확인합니습니다.

1. 요청 단위 상관관계 ID: ingress부터 핸들러, 저장소 계층까지 동일한 request ID가 남는지 확인합니습니다.
2. 타임아웃 계층: LB/Ingress, HTTP 서버, 비즈니스 로직, DB 드라이버의 timeout 값이 충돌하지 않는지 확인합니습니다.
3. 취소 로그 표준화: context canceled, deadline exceeded를 동일 포맷으로 기록합니습니다.

운영에서 바로 적용할 수 있는 최소 로그 예시는 아래와 같습니습니다.

start := time.Now()
err := svc.Process(ctx, req)
log.Info("request_done",
  "rid", rid,
  "path", r.URL.Path,
  "dur_ms", time.Since(start).Milliseconds(),
  "ctx_err", context.Cause(ctx),
  "err", err,
)

여기서 중요한 점은 에러 문자열만 남기지 않고 context.Cause(ctx) 또는 동등한 원인 정보를 남기는 것입니습니다. 그래야 취소의 출발점을 거슬러 올라갈 수 있습니습니다.

로그·트레이스·pprof로 취소 전파를 추적하는 방법

Go 개발 배포 후 느려진 서비스에서 병목을 찾을 때는 도구를 순차적으로 적용하면 시간이 줄어듭니습니다. 권장 순서는 로그 → 트레이스 → pprof입니습니다.

1) 로그로 이상 구간 좁히기 (약 15분)
배포 전후 동일 엔드포인트의 p95 지연과 context canceled 비율을 비교합니습니다. 특정 경로에서만 비율이 급증하면 해당 핸들러를 우선 분석합니습니다.

2) 트레이스로 취소 시작 지점 확인 (약 20분)
스팬에 timeout 값과 취소 원인을 태그로 남겨 두면, 어느 계층에서 먼저 deadline이 만료됐는지 바로 보입니습니다. 특히 외부 API 호출 직전의 잔여 deadline이 지나치게 짧다면 상위 계층 timeout 설계 문제일 가능성이 높습니습니다.

3) pprof로 고루틴/락 대기 확인 (약 15분)
취소가 왔는데도 작업이 계속되면 고루틴 수가 회복되지 않습니습니다. goroutine, block, mutex 프로파일에서 배포 직후 증가한 스택을 찾습니습니다. 취소 체크가 없는 루프, 채널 수신 대기, 커넥션 반환 지연이 흔한 원인입니습니다.

자주 발생하는 병목 패턴과 수정 포인트

실무에서 반복되는 패턴은 크게 네 가지입니습니다.

• 하위 함수가 부모 context 대신 context.Background()를 사용합니습니다. 취소 전파가 끊겨 작업이 불필요하게 지속됩니습니다.
• 재시도 로직이 deadline을 고려하지 않습니습니다. 이미 남은 시간이 없는데 재시도를 반복해 전체 지연을 키웁니습니다.
• DB/HTTP 클라이언트 timeout과 context deadline이 불일치합니습니다. 한쪽이 먼저 끊기며 오류 패턴이 불안정해집니습니다.
• 고루틴 내부 select에서 <-ctx.Done() 분기가 없습니습니다. 취소 후에도 루프가 종료되지 않습니습니다.

수정 시에는 "성공 경로 최적화"보다 "취소 경로 단축"을 우선하시는 것이 좋습니습니다. 취소가 빨리 정리되면 큐 적체가 줄고 정상 요청도 회복됩니습니다.

재배포 전 검증 체크리스트

수정 후 바로 재배포하기 전에 아래 항목을 짧게 검증합니습니다.

1. 부하 테스트에서 deadline exceeded 비율이 이전 대비 감소했는지 확인합니습니다.
2. 배포 후 10~15분 동안 goroutine 수가 안정 구간으로 되돌아오는지 확인합니습니다.
3. 핵심 엔드포인트 p95/p99가 배포 전 기준선 근처로 회복되는지 확인합니습니다.
4. 장애 대응 로그에 request ID, ctx cause, duration이 모두 남는지 확인합니습니다.

이 네 가지가 맞아야 "원인 제거"에 가깝습니습니다. 하나라도 비면 증상만 줄었을 가능성이 있습니습니다.

FAQ

Q1. context 취소 체인 분석만으로 모든 성능 문제를 찾을 수 있나요?
아닙니습니다. CPU 바운드 연산, 인덱스 누락, 네트워크 혼잡 같은 이슈는 별도 분석이 필요합니습니다. 다만 배포 직후 발생한 지연에서 취소/타임아웃 불일치는 매우 높은 우선순위로 확인할 가치가 있습니습니다.

Q2. 1시간 내 병목 찾기가 가능한 전제는 무엇인가요?
요청 ID 추적, 표준화된 에러 로그, 기본 트레이싱이 이미 있어야 합니습니다. 관측 기반이 없으면 먼저 계측을 추가해야 하므로 시간이 더 필요합니습니다.

Q3. context canceled와 deadline exceeded를 같은 문제로 봐도 되나요?
같지 않습니습니다. 전자는 상위 취소 신호 전파인 경우가 많고, 후자는 시간 제한 초과입니습니다. 대응도 다르므로 원인을 분리해 보셔야 합니습니다.

마무리

Go 개발 배포 후 느려진 서비스를 다룰 때는 추정부터 하지 않고, context 취소 체인 분석으로 요청 수명주기를 먼저 복원하시는 것이 가장 빠릅니습니다. 로그로 범위를 좁히고, 트레이스로 취소 시작점을 확인하고, pprof로 잔류 작업을 제거하면 1시간 내 병목 찾기 가능성이 크게 높아집니습니다. 운영 안정성은 기능 추가보다 "취소가 정확히 전파되고 빠르게 정리되는 구조"에서 시작된다는 점을 기억하시면 좋겠습니습니다.

핵심 요약: 위 순서대로 점검하시면 Go 서비스의 context 취소 체인 병목을 빠르게 좁히고, 재배포 전에 안정적으로 검증하실 수 있습니다.