[Go] goroutine 과 channel 로 API 실행 시간 개선하기

 

목차

- 서론

- 동기식 호출

- 비동기 호출 : Goroutine 활용

- 비동기 호출 개선 : Channel 활용

- 결론

 

 

서론

여러 테크 기업의 기술 블로그를 읽기 좋아합니다. 다만 매번 여러 블로그 홈페이지를 방문하다 보니 자주 가는 블로그는 따로 모아서 읽고 싶은 생각이 들더라고요. 이를 위해 Go를 활용한 테크 블로그 스크래퍼를 개발하기로 했습니다. 이미 그런 서비스는 많지 않냐고요? 맞습니다. 그래도 한번 직접 해보고 싶었습니다🙃.

기업의 블로그들은 다양한 플랫폼을 활용합니다. Medium 부터 자체 블로그를 운영하는 곳까지, 다양한 방식의 기술 블로그를 제공합니다. 각기 다른 형태의 플랫폼을 사용하기 때문에 그에 맞는 스크래핑 방식을 사용해야 합니다. 저는 블로그 플랫폼에 맞는 스크래핑 구현체를 만들어 이를 차례로 호출하는 식으로 진행했습니다.

현재는 다섯 개의 테크 블로그에 대한 스크래핑 구현체를 만들어 사용하고 있지만, 추후에는 외국의 테크 블로그도 가져올 수 있도록 확장할 계획입니다. 외부 API 호출이 5개보다 더 많아질 수 있는 상황이죠. 지금은 다섯 곳의 API만 호출하기에 API를 동기식으로 호출해도 되지만, 앞으로 그 수가 늘어날 것을 대비해 API 를 병렬적으로 호출하기로 했습니다. 단순한 성능 개선을 넘어 Go 언어의 강력한 동시성 모델을 실제 프로젝트에 적용해보는 기회가 될 것이라 생각했습니다.

 

이 글은 다음과 같은 흐름으로 진행됩니다:

우선 각각의 API를 블로킹 방식으로 가져오는 기존 방식에서, Go 언어의 특징인 goroutine 을 활용한 비동기식 API 호출, 그리고 channel을 활용한 최종 개선까지 단계별로 살펴보겠습니다. 각 단계에서 직면한 문제점과 그 해결 과정, 그리고 성능 개선의 결과를 구체적인 코드와 함께 보여드리겠습니다.

 

동기식 호출

각 블로그의 내부 호출 구현을 여기서 보여드리기엔 글의 주제와 거리가 있다고 생각되어 깃헙 레포로 대체하겠습니다.

우선 동기식 호출 부터 살펴보겠습니다. 코드는 간단합니다. 각 테크 블로그에서 스크래핑한 내용을 result 배열에 담습니다. result 배열은 스크래핑 한 모든 포스트를 담고 있는 배열로, 추후에 프론트단 개발 시 리스폰스 할 계획입니다.

result 에 담을 테크 블로그는 카카오페이, 올리브영, 당근, 토스, 뱅크샐러드로 선정했습니다.

 

type Post struct {
	Title   string
	Url     string
	Summary string
	Date    string
	Corp    compnay.Company
}

func main() {
	start := time.Now() // 시작 시간

	var result []Post
	result = callSynchronous(result)

	log.Println("Total :", len(result))
	elapsed := time.Since(start) // 경과 시간
	log.Printf("Execution Time: %s\n", elapsed)
}


// 동기식 처리
func callSynchronous(result []Post) []Post {
	result = append(result, kakaopay.CallApi()...)
	result = append(result, oliveyoung.CallApi()...)
	result = append(result, daangn.CallApi()...)
	result = append(result, toss.CallApi()...)
	result = append(result, banksalad.CallApi()...)
	return result
}

 

동기식 호출 결과 확인

동기식 호출은 3.3초를 걸쳐 완료된 것을 확인했습니다.

상당히 느린것을 볼 수 있는데 제 생각엔 특정 블로그를 스크래핑 할 때 블로킹이 오래 잡히는 곳이 있는 것 같습니다. 개별 블로그 스크래핑에 대한 성능 개선은 추후에 진행하도록 하겠습니다.

우선은 5개의 외부 API 를 동기식으로 호출할 때 3.3초가 넘는 시간이 걸린 것을 확인했고, 이를 고루틴을 활용해 병렬처리방식으로 개선하기로 했습니다.

 

 

 

그림으로 표현하면 아래와 같습니다. 각각의 테크블로그를 동기식으로 호출하므로 하나의 블로그에서 스크래핑이 완료되어야 다음 블로그 API 를 호출하는 것을 나타냈습니다. (블로그의 호출 순서는 임의로 선정했습니다)

 

 

 

비동기 호출 : Goroutine 활용

 

고루틴(Goroutine)은 Go 언어의 동시성 프로그래밍을 위한 경량 쓰레드입니다. 일반 쓰레드보다 훨씬 적은 메모리를 사용하며 동시에 수천 개의 고루틴을 실행할 수 있어 효율적인 동시성 처리가 가능합니다. go 키워드를 사용하여 고루틴을 생성할 수 있고, 이를 활용해 기존의 동기식 블로킹 Api 호출을  병렬적으로 수행하도록 개선해보겠습니다.

 

블로그를 차례로 호출하던 기존 코드와 다르게 고루틴을 활용한 코드는 이전보다 복잡해졌습니다.

func callGoroutine(result []Post) []Post {
	// (1)
	var mu sync.Mutex
	var wg sync.WaitGroup

	// (2)
	scrapers := []func() []Post{
		kakaopay.CallApi,
		oliveyoung.CallApi,
		daangn.CallApi,
		toss.CallApi,
		banksalad.CallApi,
	}

	for _, scraper := range scrapers {
		wg.Add(1)
		// (3)
		go func(scrapeFunc func() []Post) {
			defer wg.Done()

			// (4)
			posts := scrapeFunc()
            
			mu.Lock()
			result = append(result, posts...)
			mu.Unlock()
		}(scraper)
	}
	// (5)
	wg.Wait()
	return result
}

 

위 함수는 다음과 같은 방식으로 동작합니다:

 

(1) sync.Mutex와 sync.WaitGroup을 사용하여 동시성 제어

(2) 블로그의 스크래핑 함수를 scrapers 슬라이스에 저장

(3) 각 스크래핑 함수에 대해 고루틴을 생성하여 병렬로 실행

(4) 고루틴 내에서: 스크래핑 함수를 실행하여 결과 리턴

(5) WaitGroup을 사용하여 모든 고루틴이 완료될 때까지 대기

 

 

 

 

 

고루틴을 활용한 병렬 처리는 모든 API 호출이 동시에 실행되므로 전체 실행 시간이 크게 단축됩니다. 고루틴을 활용하여 0.6초 만에 모든 블로그의 스크래핑을 완료하며 이전의 동기식 처리(3.3초)에 비해 실행시간을 크게 단축한 것을 확인할 수 있었습니다.

위 코드로도 충분히 나은 성능을 낼 수 있지만 살짝 아쉬운 부분도 존재합니다. 바로 mutex를 사용해 공유 자원(result)에 락을 거는 부분입니다. 고루틴으로 API 호출은 병렬적으로 실행되지만 결과를 공유 자원에 담기 위해선 mutex 락을 사용해야 합니다. mutex 는 공유자원의 경쟁 조건을 방지하며 동시성 이슈를 해결하는 중요한 역할을 하지만, 결국 개별 고루틴이 블로킹 되는 효과를 초래합니다.

 

 

고루틴으로 개선한 흐름은 위의 그림과 같습니다. 5개의 테크블로그 정보를 가져오기 위한 API 를 모두 병렬적으로 실행하는 것을 볼 수 있습니다. 

 

 

Go 의 Mutex 더 알아보기

Go 의 뮤텍스(mutex)는 동시성 프로그래밍에서 중요한 동기화 도구로, 위 코드에서는 여러 고루틴이 공유 자원(result)에 동시 접근 하는 것을 방지합니다. mutex 는 Lock()을 호출하면 락을 획득하고, Unlock()을 호출하면 락을 해제합니다. 한 번에 하나의 고루틴만 뮤텍스의 락을 소유할 수 있으며, 다른 고루틴들은 락이 해제될 때까지 대기합니다.

 

mu.Lock()과 mu.Unlock()는 개별 고루틴을 블로킹하는 동작입니다. 이 코드는 메인 고루틴이 아닌 각 고루틴이 result에 데이터를 안전하게 추가하기 위해 **Mutex(뮤텍스)**를 사용해 잠금을 걸고 해제하는 과정입니다.

 

mu.Lock():

 

각 고루틴은 result에 데이터를 추가하기 전에 mu.Lock()을 호출하여 뮤텍스를 잠금니다.

잠금이 걸린 고루틴이 result를 업데이트하는 동안 다른 고루틴은 mu.Lock()에서 대기(블로킹)합니다. 즉, mu.Lock()을 호출한 고루틴만이 result에 접근할 수 있고, 다른 고루틴은 뮤텍스가 해제될 때까지 기다려야 합니다.

 

mu.Unlock():

 

데이터 추가 작업이 완료되면 mu.Unlock()을 호출하여 잠금을 해제합니다.

다른 고루틴 중 하나가 mu.Lock() 대기 상태에서 깨어나 result에 접근할 수 있게 됩니다.

 

즉 개별 고루틴이 블로킹되면서 한 고루틴이 mu.Lock()을 걸고 result를 업데이트하는 동안, 다른 고루틴들은 mu.Lock()에서 블로킹되어, result에 접근하지 못하고 대기합니다. 이 때 메인 고루틴은 블로킹되지 않음: 메인 고루틴은 wg.Wait()에서 모든 고루틴이 완료되기를 기다리기 때문에, mu.Lock()과 관련된 동작에는 관여하지 않습니다. mu.Lock()과 mu.Unlock()은 고루틴 간의 경쟁 상태를 방지하기 위한 기법이며, 메인 고루틴이 직접적으로 블로킹되지 않습니다.

 

비동기 호출 개선: channel 활용

고루틴을 활용하며 API 를 비동기 호출했지만 위의 방식은 mutex 락을 사용하므로 일부 구간에서 블로킹이 발생할 수 있습니다.

뮤텍스(mutex)로 공유 자원의 접근을 제어하는 것은 일반적인 방법이지만, 여러 고루틴이 빈번하게 공유 자원에 접근하는 경우엔 뮤텍스로 인한 블로킹이 전체 프로그램의 성능을 저하시킬 수 있다고 생각했습니다.

 

이러한 상황에서 Go는 채널(channel)이라는 대안을 제공합니다.

Go 의 채널은 고루틴을 연결해주는 통로입니다. 채널은 양방향으로 데이터를 전달할 수 있으며, 아래 이미지처럼 고루틴은 동일한 채널을 이용해 데이터를 교환할 수 있습니다.

 

채널을 사용하면 각 데이터를 개별 고루틴에서 처리하고 그 결과를 채널을 통해 전송합니다. 메인 고루틴은 채널에서 결과를 수집합니다. 결국 공유자원에 대한 모든 접근을 단일 고루틴으로 관리할 수 있기에, 채널을 사용하면 복잡한 동기화 로직 없이도 고루틴 간의 작업을 조율할 수 있습니다.

* 📌 그렇다고 채널이 뮤텍스를 완전히 대체할 수 있단 의미는 아닙니다. 채널은 주로 고루틴 간의 통신과 작업 조율에 사용되며, 뮤텍스는 짧은 시간 동안의 공유 자원 보호에 효과적입니다. 둘은 각각 적절히 사용할 때가 있으며 때로는 둘을 함께 사용하는것이 해결책이 될 수도 있다고 생각합니다.

 

다음은 채널을 이용해 개선된 코드입니다:

func callGoroutineChannel(result []Post) []Post {
	scrapers := []func() []Post{
		kakaopay.CallApi,
		oliveyoung.CallApi,
		daangn.CallApi,
		toss.CallApi,
		banksalad.CallApi,
	}
	resultChan := make(chan []Post, len(scrapers))

	var wg sync.WaitGroup
	for _, scraper := range scrapers {
		wg.Add(1)
		go func(scrapeFunc func() []Post) {
			defer wg.Done()
			resultChan <- scrapeFunc()
		}(scraper)
	}

	go func() {
		wg.Wait()
		close(resultChan)
	}()

	for posts := range resultChan {
		result = append(result, posts...)
	}

	return result
}

 

 

1. 버퍼된 채널 생성

resultChan := make(chan []Post, len(scrapers))

버퍼의 크기는 scarppers 배열의 길이로 설정된 resultChan 채널을 생성합니다. 이 채널은 각 고루틴이 스크래핑한 결과를 전달하는 통로로 사용됩니다. 버퍼된 채널을 이용함으로, 고루틴이 결과를 채널에 전송하는 과정에서 블로킹되지 않도록 합니다. 버퍼의 크기가 충분하다면, 고루틴이 결과를 즉시 전송하고 종료될 수 있습니다.

 

2. 고루틴으로 비동기 처리

각 스크래핑 함수를 고루틴으로 병렬 실행하며, 각 고루틴은 스크래핑 결과를 resultChan에 전달합니다. 모든 고루틴이 완료되면 WaitGroup을 사용해 개별 고루틴의 작업이 끝났는지 확인할 수 있습니다.

 

3. 채널 수신 및 결과 수집

for posts := range resultChan 구문을 통해 채널에서 결과를 순차적으로 수신합니다. 채널이 닫힐 때까지 이 동작이 반복되며, 채널이 닫히면 for 루프도 종료됩니다. 이는 range 구문이 <- resultChan 과 동일한 수신 동작을 반복적으로 처리하는 것으로 이해할 수 있습니다.

 

4. WatiGroup 과 채널 종료

별도의 고루틴에서 wg.Wait()를 호출해, 모든 고루틴이 완료될 때 채널을 close(resultChan)로 닫습니다. 채널이 닫히면 더 이상 새로운 값이 전송되지 않으며, 채널의 데이터는 안전하게 모두 처리됩니다.

 

 

channel 을 사용한 결과는 0.5초로 mutex 를 사용한 방식과 비교했을 때 생각보다 유의미한 개선은 없습니다.

현재 프로젝트 규모에서는 mutex 락이 성능에 그리 큰 영향을 미친다고 보기 어려울 수 도 있고, 네트워크 지연 같은 외부 요인도 의심해 볼 수 있습니다. 그 외에도 각 고루틴 생성과 채널 통신시 발생하는 약간의 오버헤드도 고려해볼수 있습니다. 이는 오버헤드와 뮤텍스 사용 시 발생하는 성능 저하가 크게 다르지 않을 수 있기 때문에, 작업의 규모가 작거나 고루틴에서 수행하는 작업이 길지 않은 현재의 프로젝트에서는 이런 오버헤드가 더 두드러질 수 있습니다. 해당 부분의 개선은 다음 포스트에서 더 다뤄보도록 하겠습니다.

 

결론

 

동기식 보다 비동기식이 빠른건 사실 너무 당연한 얘기지만 ㅎㅎ,, 이번 프로젝트를 통해 Go 언어의 동시성 모델을 실제로 적용해볼 수 있었습니다. 스크래퍼 호출 과정에서 동기식 호출부터 goroutine을 활용한 비동기 처리, 그리고 channel을 이용한 개선까지 단계적으로 접근하며 각 방식의 특징을 이해할 수 있었습니다.

Goroutine 을 사용한 간단하고 효율적인 동시성을 구현할 수 있었고, mutex 를 사용한 공유 자원 접근 제어의 중요성과 한계를 파악했습니다. 나아가 channel 을 활용해 lock 을 제거하여 더욱 유연하고 Go 스러운(?) 동시성 처리방식에 대해서도 알게 됐습니다.

이번 글에서는 API 호출과정을 점진적으로 개선하는 과정만 다뤘는데, 추후에는 개별 블로그 스크래핑 성능 최적화와 고루틴과 채널 사용 시 오버헤드 최소 방안을 더 고려한 글을 작성해보겠습니다.