목표를향한노력

코루틴을 사용하더라도 Spring MVC의 블로킹 구조로 인해 쓰로풋을 향상시키기 어렵다는 사실을 이전 실험에서 다시 한번 확인했다. 그렇다면 Spring MVC의 블로킹 구조가 왜 쓰로풋 향상을 막는지, 반면에 Spring WebFlux는 어떻게 쓰로풋을 향상시킬 수 있는지 살펴보겠다. 본격적인 분석에 앞서 코루틴의 동작 방식에 대해 간단히 짚고 넘어가려 한다.

코루틴은 어떻게 동작하며 왜 사용하는 것일까?

코틀린의 코루틴은 탈출 지점을 기준으로 코드를 여러 조각(코드 블록)으로 나누고, 쓰레드 위에서 중단과 재개를 반복하며 실행할 수 있게 해준다. 이렇게 나눠진 코드 블록이 중단되었다가 다시 재개될 수 있는 이유는 코틀린 컴파일러가 CPS(Continuation-Passing Style) 패턴으로 변환하기 때문이다. CPS 패턴에서는 코드가 실행 도중 특정 지점에서 멈출 수 있으며, 이후 해당 지점부터 다시 시작할 수 있도록continuation을 전달하여 루틴(함수)이 탈출과 진입을 반복할 수 있게 해 준다.

(코틀린 컴파일러가 코루틴 함수를 어떻게 cps 패턴으로 변환하는지 알고 싶으면 Java로 decompile 해보는 걸 추천한다.)

이 방식 덕분에 코루틴은 쓰레드가 블로킹될 수 있는 구간을 탈출하고 다른 코드 블록을 실행하며 쓰레드가 놀고 있는 시간을 최소화할 수 있어, 보다 효율적으로 쓰레드를 활용할 수 있다. 이를 통해 적은 수의 쓰레드로도 높은 동시성을 유지할 수 있으며, 이것이 코루틴을 사용하는 주요한 이유이다.

MVC 환경에서 코루틴이 쓰로풋 향상에 도움이 되지 못한 이유

MVC 환경에서는 요청당 하나의 서블릿 스레드가 배정되어 처리된다. 서블릿 스레드는 요청 처리가 완료될 때까지 대기하며, 이는 서블릿이 블로킹 IO 모델을 사용하기 때문이다. 따라서, 코루틴을 사용해 비동기 논블로킹 코드를 구현하더라도 블로킹 구간이 존재하게 되어 쓰루풋을 높이는 데 한계가 생긴다.

WebFlux환경에서는 코루틴 사용이 쓰로풋을 향상 시킬 수 있었던 이유

추가적으로, 코루틴이 이벤트 루프를 통해 비동기 논블로킹을 구현하는 과정을 설명하자면, 코루틴으로 작성된 코드는 쓰레드 위에서 실행되다가 블로킹 지점에 도달하면, 재개할 태스크를 이벤트 큐에 등록한 후 쓰레드를 반환하게 된다. 반환된 쓰레드는 이벤트 큐에서 꺼내진 새로운 태스크가 할당되어 다시 실행되며, 이 과정이 반복되면서 블로킹 없이 연속적으로 태스크를 처리할 수 있게 된다.

(정리하면)

Netty의 이벤트 루프 + 코루틴을 사용하면,

1. 요청의 등록과 처리를 독립적으로 분리하여 비동기적으로 처리할 수 있고

2. 코루틴을 통해 요청에 대한 처리를 비동기 논블로킹으로 처리할 수 있어진다.

3. 따라서 요청을 처리하는 전 과정에서 블로킹이 일어나지 않아 쓰로풋이 향상될 수 있다.

(물론, 코루틴을 사용하더라도 논블로킹을 지원하지 않는 IO를 사용할 경우 블로킹이 발생하여 쓰로풋이 크게 저하될 수 있으니 주의해야 한다.)

마치며

이 글에서는 Netty의 이벤트 루프 모델과 코루틴이 만나 어떻게 쓰로풋을 향상시키는지 고수준에서 설명했으며, MVC 환경에서는 구조적인 문제로 인해 코루틴을 사용하더라도 쓰로풋 향상이 어려운 이유를 다루었다. 이를 통해 MVC 환경이 아닌 WebFlux 환경에서 코루틴 사용이 권장되는 이유를 명확히 이해하는 데 도움이 되었기를 바래본다.

마지막으로, Netty의 동작 방식은 실제로 훨씬 복잡하고 이해할 부분이 많다. Netty 공식 문서나 Netty In Action과 같은 참고할 만한 자료들이 있으니, 관심이 있다면 한 번 읽어보시기를 추천한다.

우리는 적은 리소스로도 높은 쓰로풋(Throughtput)을 달성하기 위해 비동기 프로그래밍을 활용한다. 스프링 개발자들은 주로 리엑터(Reactor)와 코틀린의 코루틴을 통해 비동기를 구현한다. 그러나 리엑터는 그 복잡성으로 인해, 많은 개발자들이 코루틴을 선호하는 경향이 있다. 코루틴은 주로 논블로킹 환경을 지원하는 Spring WebFlux와 함께 사용된다. 반면 Spring MVC와는 잘 사용되지 않는다. 그 이유는 코루틴을 사용하더라도 Spring MVC의 블로킹 구조로 인해 쓰로풋이 향상되기 어렵기 때문이다. 이제 간단한 테스트를 통해 이 차이점을 좀 더 자세히 설명을 해보겠다.

MVC와 WebFlux 환경에서의 쓰로풋 비교

테스트 개요

1. 해당 테스트는 BFF 환경에서 User 서비스의 사용자 정보와 Order 서비스의 주문 정보를 조회하고, 이를 조합하여 mobile 클라이언트에 전달하는 과정을 재현하였다.
2. Spring MVC를 사용하느냐 Spring WebFlux를 사용하느냐에 차이가 있을 뿐, 비즈니스 로직은 동일하다.
3. Spring MVC는 Tomcat을 사용하고, 스레드 풀 크기는 기본 값인 200으로 설정하였다. 이는 스레드 수가 증가함에 따라 발생할 수 있는 컨텍스트 스위칭 비용이 요청 처리 성능에 부정적인 영향을 미치지 않도록 하기 위함이다. 물론, 필자가 작성한 테스트 코드는 복잡한 비즈니스 로직이 없기 때문에 스레드 풀 크기를 200 이상으로 설정하면 동시성은 높아질 수 있다. 하지만, 비즈니스 로직이 복잡한 서버에서는 오히려 성능 저하를 초래할 수 있으며, 일반적인 서버는 필자가 작성한 코드보다 더 복잡한 로직을 처리하는 경우가 많다. 이번 테스트는 그러한 일반적인 환경을 가정하고 동시성 및 성능을 측정하려는 목적이 있다.
4. Spring WebFlux는 Netty를 사용하였으며 기본 설정을 적용하였다.

테스트 환경

테스트 시 사용한 코드

(공통)

@RestController
class UserController(private val bffService: BffService) {
    @GetMapping("/mobile/users/{id}")
    suspend fun getUserDetails(@PathVariable id: Long): UserDetailsResponse {
        return bffService.getUserDetails(id)
    }
}

@Service
class BffService(private val userService: UserService, private val orderService: OrderService) {
    suspend fun getUserDetails(id: Long): UserDetailsResponse = coroutineScope {
        val userDeferred = async { userService.getUserById(id) }
        val ordersDeferred = async { orderService.getOrdersByUserId(id) }
        
        UserDetailsResponse(userDeferred.await(), ordersDeferred.await())
    }
}

@Service
class UserService {
    suspend fun getUserById(id: Long): User {
        delay(1000) // NIO 호출을 시뮬레이션하기 위한 1초 지연
        return User(id, "User$id")
    }
}

@Service
class OrderService {
    suspend fun getOrdersByUserId(userId: Long): List<Order> {
        delay(1000) // NIO 호출을 시뮬레이션하기 위한 1초 지연
        return listOf(
            Order(1, "Item A", 100),
            Order(2, "Item B", 200)
        )
    }
}

data class User(val id: Long, val name: String)
data class Order(val orderId: Long, val itemName: String, val price: Int)
data class UserDetailsResponse(val user: User, val orders: List<Order>)

(MVC)

dependencies {
	implementation("org.springframework.boot:spring-boot-starter-web")
}

(WebFlux)

dependencies {
	implementation("org.springframework.boot:spring-boot-starter-webflux")
}

테스트 결과

1. MVC 테스트

• 유저: 200명 (200명 이상 설정 시 에러가 발생하여, 동시에 처리 가능한 요청 수가 200개로 추정됨)
• 루프카운트: 250
• 요청 처리량: 5만건
• 실행 시간: 04:19
• 쓰로풋: 192.6/sec

2. WebFlux 테스트

• 유저: 5000명 (5000명 이상 설정 시 에러가 발생하여, 동시에 처리 가능한 요청 수가 5000개로 추정됨)
• 루프카운트: 10
• 요청 처리량: 5만건
• 실행 시간: 00:18
• 쓰로풋: 2709.7.sec

3. 결과 비교

코루틴을 MVC 환경에서 사용했을 때 쓰로풋은 192.6/sec, WebFlux 환경에서는 2709.7/sec로 나타났다. 단순히 쓰로풋만 비교했을 때, 약 14배의 차이가 발생했다.