지난달, 트래픽이 급증한 마이크로서비스 중 하나가 주기적으로 OOM(Out of Memory)으로 인해 파드가 재시작되는 현상을 겪었다. pprof를 통해 힙 메모리와 고루틴 스택을 분석한 결과, 범인은 명확했다. 수만 개의 고루틴이 종료되지 못한 채 runtime.gopark 상태에 머물러 있었다. 이는 전형적인 고루틴 누수(Goroutine Leak) 현상으로, Golang Concurrency 모델의 강력함 뒤에 숨겨진 가장 흔한 함정이다. 이 글에서는 잘못된 채널 관리로 발생한 누수를 Go Context와 Go 채널 패턴을 통해 어떻게 해결했는지, 그리고 백엔드 최적화를 위해 어떤 전략을 취했는지 공유한다.
Deep Dive: 왜 고루틴은 사라지지 않는가?
Go의 고루틴은 저렴하지만 공짜는 아니다. Java의 스레드와 달리 데몬(Daemon) 모드가 없기 때문에, 메인 함수가 종료되지 않는 한 고루틴은 스스로 작업을 마치거나 리턴해야만 종료된다. 우리 시스템의 문제는 '수신자(Receiver)가 사라진 채널'에 송신자(Sender) 고루틴이 데이터를 밀어넣으려다 영원히 블로킹(Blocking)된 케이스였다.
이러한 Go Spec의 채널 동작을 간과하면, 서버는 시간이 지날수록 메모리 사용량이 계단식으로 증가하다 결국 죽게 된다. 이를 해결하기 위해서는 반드시 타임아웃과 취소(Cancellation) 메커니즘이 필요하다.
The Solution: Context를 활용한 누수 방지 패턴
해결책의 핵심은 Go Context 패키지를 사용하여 작업의 생명주기를 관리하는 것이다. 모든 채널 연산은 select 문을 통해 ctx.Done() 시그널을 감지해야 한다. 아래는 우리가 적용한 실제 Go 채널 패턴의 수정 전후 비교다.
// [Bad Pattern] 누수 발생 코드
func leakySender(ch chan<- int>) {
// 수신자가 사라지면 여기서 영원히 블로킹됨
ch <- 1
}
// [Fixed Pattern] Context를 활용한 안전한 전송
// seo_keywords: Golang Concurrency, 백엔드 최적화
func safeSender(ctx context.Context, ch chan<- int>) error {
select {
case ch <- 1:
return nil
case <-ctx.Done():
// 부모 컨텍스트가 취소되거나 타임아웃 발생 시 즉시 리턴
// 고루틴이 정상 종료되므로 메모리 누수 방지
return ctx.Err()
}
}
// 실제 호출부 예시
func ProcessData() {
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel() // 함수 종료 시 리소스 정리 필수
ch := make(chan int)
go func() {
if err := safeSender(ctx, ch); err != nil {
log.Printf("Sender closed: %v", err)
}
}()
// 비즈니스 로직 수행...
}워커 풀(Worker Pool)을 통한 동시성 제어
단순한 누수 방지를 넘어, 백엔드 최적화를 위해서는 동시에 실행되는 고루틴의 개수를 제어해야 한다. 무제한으로 고루틴을 생성(go func())하는 것은 CPU 컨텍스트 스위칭 비용을 증가시킨다. 우리는 세마포어(Semaphore) 역할을 하는 버퍼 채널을 이용해 간단한 워커 풀을 구현했다.
type WorkerPool struct {
sem chan struct{}
wg sync.WaitGroup
}
func NewWorkerPool(limit int) *WorkerPool {
return &WorkerPool{
sem: make(chan struct{}, limit), // 버퍼 크기로 동시 실행 제한
}
}
func (wp *WorkerPool) Execute(task func()) {
wp.wg.Add(1)
// 세마포어 획득: 슬롯이 꽉 차면 여기서 대기 (Backpressure)
wp.sem <- struct{}{}
go func() {
defer wp.wg.Done()
defer func() { <-wp.sem }() // 작업 완료 후 슬롯 반환
task()
}()
}
func (wp *WorkerPool) Wait() {
wp.wg.Wait()
}성능 검증 (Verification)
수정 배포 후, 동일한 부하 테스트 환경(JMeter 이용, 5000 RPS)에서 고루틴 누수 여부를 검증했다. 결과는 극적이었다.
| 지표 (Metric) | 수정 전 (Before) | 수정 후 (After) | 개선율 |
|---|---|---|---|
| Avg Goroutines | 45,000+ (증가세) | 250 (안정적) | 99% 감소 |
| Memory Usage | 2.4 GB | 120 MB | 95% 절감 |
| P99 Latency | 1.5s | 80ms | 18배 향상 |
Conclusion
Go 언어는 동시성을 다루기 쉽지만, 그만큼 책임이 따른다. 고루틴 누수는 초보자가 겪는 가장 흔한 실수이자, 프로덕션을 망가뜨리는 주범이다. 무작정 go 키워드를 남발하지 말고, 항상 context를 통해 취소 가능성을 열어두어야 한다. 또한, Go 채널 패턴을 적절히 사용하여 시스템이 감당할 수 있는 수준으로 부하를 조절하는 것이 진정한 백엔드 최적화의 시작이다.
Post a Comment