인생을 코딩하다.

ThreadPool과 Virtual Thread의 성능 및 메모리 사용 비교

Hyung1 — Sat, 27 Dec 2025 20:44:02 +0900

이미지 출처 : https://blog.stackademic.com/virtual-threads-in-java-21-how-enterprise-scale-to-millions-of-concurrent-connections-without-26601f820614

1. 배경

최근 차세대 마이그레이션을 진행하는 업무를 맡아 수행하게 되었습니다. 이번 마이그레이션에서는 지금까지의 JDK 버전 흐름과 지원 현황을 종합적으로 검토한 결과, 여러 기술적·운영상의 이유로 JDK 25를 도입하는 것이 가장 적합하다고 판단하여 이를 채택하였습니다.

JDK 21부터 정식으로 도입된 Virtual Thread는 동기식 코드 스타일을 유지하면서도 JVM 경량 스레드를 사용하여 적은 리소스로도 높은 동시성을 효율적으로 처리할 수 있는 실행 모델을 제공합니다. 저는 이러한 특징들로 인해 Virtual Thread를 적극적으로 도입하여 아래와 같은 장점들을 경험할 수 있었습니다.

Spring MVC 기반 동기·블로킹 서버의 스레드 풀 구조를 Virtual Thread 기반으로 전환하여, 고부하 상황에서도 안정적인 처리와 자원 효율 개선을 달성하였습니다.
WebFlux(+Coroutine) 기반 서버를 Spring MVC + Virtual Thread 모델로 전환하여, 기존 성능을 유지하면서 복잡도와 유지보수 비용, 개발자 러닝 커브를 낮추고 생산성을 향상시켰습니다.

물론 Virtual Thread를 도입하면서 장점만 있었던 것은 아니었고, 몇 가지 고려해야 단점도 있었습니다.

이러한 경험을 바탕으로, 이번 글에서는 ThreadPool 기반 모델과 Virtual Thread 모델의 성능을 비교해보고자 합니다. (본문에 등장하는 코드는 이해를 돕기 위해 일부 재구성되었습니다.)

2. 테스트 환경

2-1. 서버 구성

Callee Server (외부 API 서버)

Endpoint: http://localhost:8001/api/test/slow
응답 시간: 3초 (데이터 분석용 조회 API)
Tomcat Worker Thread: 200개

Caller Server (테스트 실행 서버)

총 요청 수: 1,000개
JVM Heap Memory: 1GB
CPU Core: 10개

2-2. Configuration 설정

/**
 * 이 설정은 "부하 실험 / 동작 비교"를 위한 값이며,
 * 운영 환경에서는 서비스 특성, 트래픽 패턴, 외부 API SLA에 맞게 반드시 재조정되어야 합니다.
 *
 * ---------------------------------------------------------------------
 * Timeout 설정 기준
 *
 * [readTimeout]
 * - 외부 API 응답 지연을 기준으로 설정
 * - 평균 응답 3초 + 네트워크 지연/스케줄링 여유를 고려해 5초로 설정
 * 
 * ※ connectionRequestTimeout 은 의도적으로 사용하지 않음
 *   - 커넥션 풀 대기 시간 제한은 "풀 병목" 실험이 되어버림
 *   - 본 실험에서는 병목 지점을 callee(외부 서버)로 두기 위해 제거
 *
 * ---------------------------------------------------------------------
 * Connection Pool 설정
 *
 * [maxTotal / maxPerRoute = 1000]
 * - caller 쪽 커넥션 풀이 병목이 되지 않도록 충분히 크게 설정
 * 
 * [connectTimeout = 500ms]
 * - TCP 연결 수립 실패를 빠르게 감지하기 위한 값, DNS 문제, 서버 다운 등 네트워크 장애를 빠르게 드러내기 위함
 *
 * [validateAfterInactivity = 5s]
 * - 일정 시간 이상 유휴 상태였던 커넥션 재사용 전 유효성 검사, 오래된 커넥션 재사용으로 인한 예외 방지 목적
 *
 * [evictIdleConnections = 60s]
 * - 60초 이상 사용되지 않은 커넥션을 정리, 리소스 회수 목적 (실험 결과에는 큰 영향 없음)
 */
@ConfigurationProperties(prefix = "clients.test")
data class TestClientProperties(
    val baseUrl: String = "http://localhost:8001",
    val timeProperties: TimeoutProperties = TimeoutProperties(),
    val connectionPool: ConnectionPoolProperties = ConnectionPoolProperties()
) {
    data class TimeoutProperties(
//        val connectionRequest: Duration = Duration.ofMillis(1000),
        val readTimeOut: Duration = Duration.ofSeconds(5),
    )

    data class ConnectionPoolProperties(
        val maxTotal: Int = 1000,
        val maxPerRoute: Int = 1000,
        val connectTimeout: Duration = Duration.ofMillis(500),
        val validateAfterInactivity: Duration = Duration.ofSeconds(5),
        val evictIdleConnections: Duration = Duration.ofSeconds(60)
    )
}

@Configuration
@PropertySource(
    value = ["classpath:clients-\${spring.profiles.active}.yaml"],
    factory = YamlPropertySourceFactory::class
)
@EnableConfigurationProperties(TestClientProperties::class)
@ImportHttpServices(group = CLIENT_GROUP, basePackageClasses = [TestClient::class])
class TestClientConfiguration(
    private val properties: TestClientProperties
) {

    @Bean
    fun testHttpServiceGroupConfigurer(): RestClientHttpServiceGroupConfigurer {
        val poolProps = properties.connectionPool
        val timeProps = properties.timeProperties

        val connectionConfig = ConnectionConfig.custom()
            .setConnectTimeout(Timeout.ofMilliseconds(poolProps.connectTimeout.toMillis()))
            .setValidateAfterInactivity(Timeout.ofMilliseconds(poolProps.validateAfterInactivity.toMillis()))
            .build()

        val connectionManager = PoolingHttpClientConnectionManager().apply {
            setDefaultConnectionConfig(connectionConfig)
            maxTotal = poolProps.maxTotal
            defaultMaxPerRoute = poolProps.maxPerRoute
        }

        val httpClient = HttpClients.custom()
            .setConnectionManager(connectionManager)
            .evictIdleConnections(TimeValue.ofMilliseconds(poolProps.evictIdleConnections.toMillis()))
            .build()

        val requestFactory = HttpComponentsClientHttpRequestFactory(httpClient).apply {
            setReadTimeout(timeProps.readTimeOut.toMillis().toInt())
            timeProps.connectionRequestTimeout?.let {
                setConnectionRequestTimeout(it.toMillis().toInt())
            }
        }

        return RestClientHttpServiceGroupConfigurer { groups ->
            groups.filterByName(CLIENT_GROUP)
                .forEachClient { _, clientBuilder ->
                    clientBuilder
                        .baseUrl(properties.baseUrl)
                        .requestFactory(requestFactory)
                }
        }
    }

    companion object {
        private const val CLIENT_GROUP = "test"
    }
}

2-2. 테스트 시나리오

총 요청 수: 1000
외부 API 호출 시간: 약 3초
측정 지표:
- 전체 처리 시간
- 성공 / 실패 요청 수
- JVM Thread 상태 변화

@RestController
class LoadTestController(
    private val testClient: TestClient
) {
    /**
     * 1. 스레드풀 Executor 호출 (플랫폼 스레드 100개)
     * - 고정 스레드풀 100개로 1000개 요청 처리
     */
    @GetMapping(
        value = ["/api/test/threadpool"],
        produces = [MediaType.APPLICATION_JSON_VALUE]
    )
    fun testThreadPool() {
        val executor = Executors.newFixedThreadPool(THREAD_POOL_SIZE)
        val successCount = AtomicInteger(0)
        val failCount = AtomicInteger(0)

        val startTime = System.currentTimeMillis()
        log.info("=== ThreadPool Test Started ($THREAD_POOL_SIZE threads) ===")

        val futures = (1..TOTAL_REQUESTS).map { index ->
            CompletableFuture.runAsync({
                try {
                    testClient.slow()
                    successCount.incrementAndGet()
                    if (index % 100 == 0) {
                        log.info("ThreadPool progress: $index/$TOTAL_REQUESTS")
                    }
                } catch (e: Exception) {
                    failCount.incrementAndGet()
                }
            }, executor)
        }

        CompletableFuture.allOf(*futures.toTypedArray()).join()

        executor.shutdown()

        val duration = System.currentTimeMillis() - startTime
        log.info("=== ThreadPool Test Completed in ${duration}ms (${duration / 1000.0}s) ===")
        log.info("=== Success: ${successCount.get()}, Fail: ${failCount.get()} ===")
    }

    /**
     * 2. 가상 스레드 호출 (제한 없음)
     * - Virtual Thread Executor 사용 (무제한)
     * - 1000개 요청 동시 처리
     * - 주의: 외부 API가 감당 못하면 타임아웃 발생 가능
     */
    @GetMapping(
        value = ["/api/test/virtual"],
        produces = [MediaType.APPLICATION_JSON_VALUE]
    )
    fun testVirtualThread() {
        val startTime = System.currentTimeMillis()
        val successCount = AtomicInteger(0)
        val failCount = AtomicInteger(0)
        log.info("=== Virtual Thread Test Started (Unlimited) ===")

        val virtualThreadExecutor = Executors.newVirtualThreadPerTaskExecutor()

        val futures = (1..TOTAL_REQUESTS).map { index ->
            CompletableFuture.runAsync({
                try {
                    testClient.slow()
                    successCount.incrementAndGet()
                    if (index % 100 == 0) {
                        log.info("Virtual Thread progress: $index/$TOTAL_REQUESTS")
                    }
                } catch (e: Exception) {
                    failCount.incrementAndGet()
                }
            }, virtualThreadExecutor)
        }

        CompletableFuture.allOf(*futures.toTypedArray()).join()

        virtualThreadExecutor.close()

        val duration = System.currentTimeMillis() - startTime
        log.info("=== Virtual Thread Test Completed in ${duration}ms (${duration / 1000.0}s) ===")
        log.info("=== Success: ${successCount.get()}, Fail: ${failCount.get()} ===")
    }

    /**
     * 3. 가상 스레드 호출 (Semaphore로 동시 실행 제한)
     * - Virtual Thread Executor 사용
     * - 1000개 요청 생성하되, 동시 실행은 100개로 제한
     */
    @GetMapping(
        value = ["/api/test/virtual-limited"],
        produces = [MediaType.APPLICATION_JSON_VALUE]
    )
    fun testVirtualThreadLimited() {
        val startTime = System.currentTimeMillis()
        val successCount = AtomicInteger(0)
        val failCount = AtomicInteger(0)
        log.info("=== Virtual Thread Test Started (Limited to $SEMAPHORE_PERMITS) ===")

        val virtualThreadExecutor = Executors.newVirtualThreadPerTaskExecutor()
        val semaphore = Semaphore(SEMAPHORE_PERMITS)

        val futures = (1..TOTAL_REQUESTS).map { index ->
            CompletableFuture.runAsync({
                try {
                    semaphore.acquire()  // 허가 받을 때까지 대기
                    try {
                        testClient.slow()
                        successCount.incrementAndGet()
                        if (index % 100 == 0) {
                            log.info("Virtual Thread (Limited) progress: $index/$TOTAL_REQUESTS")
                        }
                    } finally {
                        semaphore.release()
                    }
                } catch (e: Exception) {
                    failCount.incrementAndGet()
                }
            }, virtualThreadExecutor)
        }

        CompletableFuture.allOf(*futures.toTypedArray()).join()

        virtualThreadExecutor.close()

        val duration = System.currentTimeMillis() - startTime
        log.info("=== Virtual Thread (Limited) Test Completed in ${duration}ms (${duration / 1000.0}s) ===")
        log.info("=== Success: ${successCount.get()}, Fail: ${failCount.get()} ===")
    }

    companion object {
        private val log = LoggerFactory.getLogger(LoadTestController::class.java)
        private const val TOTAL_REQUESTS = 1000
        private const val THREAD_POOL_SIZE = 100
        private const val SEMAPHORE_PERMITS = 100
    }
}

3. 테스트 결과

방식	소요 시간	성공	실패	성공률
ThreadPool(100)	30s	1,000	0	100%
Virtual Thread (무제한)	5s	200	800	20%
Virtual Thread + Semaphore(100)	30s	1,000	0	100%

Virtual Thread(무제한) 방식에서는 성공률이 20%에 그쳤습니다. 이는 외부 서버가 동시에 처리할 수 있는 톰캣 워커 수를 200으로 가정했기 때문입니다. 1,000개의 요청이 동시에 전달되면서, 실제로 처리 가능한 200개만 정상 처리되고 나머지 요청은 대기 상태에 들어가 응답 지연이 발생했습니다. 이 중 상당수가 readTimeout(5s)을 초과하면서 실패로 처리되었습니다.

외부 서버의 톰캣 워커 수를 400으로 늘려 다시 테스트하면 성공률은 약 40%까지 증가합니다. 이 결과를 통해, 가상 스레드는 병렬 실행을 매우 쉽게 만들어 주지만 동시 실행에 대한 제한을 제공하지는 않으며, 외부 API의 처리 한계를 초과할 경우 대량의 요청이 동시에 지연되고 타임아웃으로 실패할 수 있음을 확인할 수 있었습니다.

즉, 가상 스레드는 “더 많은 작업을 동시에 시작할 수 있게 해주는 도구”일 뿐, 외부 시스템의 처리 용량을 자동으로 고려하거나 보호해 주지는 않기 때문에 유량 제어가 필요하다는 것을 느꼈습니다.

3-1. 그럼 어떻게 해결할 수 있을까요?

유량 제어를 적용하는 방법에는 여러 가지가 있을 수 있습니다. 다만 개인적으로는, 자바 진영에서도 이미 이러한 문제를 인지하고 있었을 것이고, 공식적으로 권장하는 방식이 존재할 것이라 생각해 관련 문서를 찾아보았습니다.

https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html#GUID-E695A4C5-D335-4FA4-B886-FEB88C73F23E

조사해보니, Java 공식 문서에서도 가상 스레드 환경에서의 동시성 제어 방식으로 Semaphore 사용을 예시로 안내하고 있었습니다. 즉, 가상 스레드는 실행 비용이 매우 낮기 때문에 무제한으로 생성할 수 있지만, 외부 리소스 접근 시에는 별도의 동시성 제한 장치를 두는 것이 필요하다는 점을 명확히 하고 있습니다.

이에 따라 본 실험에서도 세마포어를 이용해 동시 실행 수를 제한하는 방식으로 유량 제어를 적용하였습니다. 실제 구현 관점에서도 세마포어는 다음과 같은 장점이 있습니다.

구현이 단순하고 직관적임
동시 실행 개수를 명확하게 제한할 수 있음
가상 스레드와 함께 사용해도 부담이 적음
별도의 프레임워크 의존 없이 JDK 기본 기능으로 사용 가능

이러한 이유로, 가상 스레드를 사용하는 환경에서 외부 API 호출에 대한 유량 제어가 필요하다면 세마포어를 사용하는 방식이 가장 현실적이고 적절한 선택이라고 판단했습니다. 동일한 질문을 AI에게 문의했을 때 역시 세마포어 기반의 제어 방식을 권장하는 답변을 확인할 수 있었으며, 이는 공식 문서의 방향성과도 일치하였었습니다.

정리하면, 가상 스레드는 동시 실행을 쉽게 만들어 주지만, 외부 시스템의 처리 한계를 자동으로 보호해 주지는 않습니다. 따라서 실제 서비스 환경에서는 세마포어와 같은 명시적인 유량 제어 수단을 함께 사용해야함을 알게되었습니다. 이후 세마포어로 유량 제어하면서 다시 요청했을 경우 성공률이 100%인 것을 확인하였습니다.

3-2. 매트릭 지표 확인

빨간선 점선 기준으로 ThreadPool(100) → Virtual Thread(무제한) → Virtual Thread + Semaphore(100) 세 가지 방식의 지표 상태 변화를 비교한 결과입니다. (가운데 중간에 비어있는 부분은 서버를 잠시 종료시켜서 비어보이는 것이니 무시하셔도 됩니다.)

3-2-1. Thread

우선 톰캣 워커, HTTP 클라이언트, JVM 내부 스레드 등으로 인해 우선 테스트 시작 전부터 항상 약 100개 내외의 스레드가 기본적으로 존재했었습니다. 이 기준을 감안하여, 기본 100개를 제외한 증가분 중심으로 해석하였습니다.

# ThreadPool(100)

ThreadPool 구간에서는 전체 live 스레드가 약 190~200 수준까지 증가하였습니다. 기본 스레드가 약 100개 존재하므로, 실제로 테스트로 인해 추가된 스레드는 약 +100개 수준입니다. 그래프는 아래와 같이 해석할 수 있을 것 같습니다.

요청은 최대 100개까지만 동시에 실행됨
그 이상은 큐에서 대기
스레드 수 증감이 매우 안정적

즉, ThreadPool 자체가 자연스러운 유량 제어 장치 역할을 수행하고 있는 것을 확인하였습니다.

# Virtual Thread (무제한)

Virtual Thread 구간에서는 live thread 수가 약 110개 수준으로 유지되었으며, 이는 ThreadPool(100) 방식 대비 약 1/10 수준인 것을 확인하였습니다. 이는 JVM이 논리 CPU 개수만큼의 Carrier Thread만 유지하고, 그 위에서 다수의 Virtual Thread를 스케줄링하기 때문입니다. 그 결과 적은 수의 스레드로도 동일한 요청 처리가 가능했습니다.

하지만 이 구간에서는 아래와 같은 문제가 있었습니다.

요청 1,000개가 거의 동시에 실행됨
가상 스레드가 대량 생성됨
외부 서버(톰캣 200) 처리 한계를 초과
다수 요청이 대기 상태로 밀림
응답 지연 누적으로 readTimeout 발생
결과적으로 성공률 20%

즉, 스레드 수가 늘지 않았다고 해서 부하가 적은 것은 아니였습니다. 가상 스레드는 커널 스레드를 늘리지 않을 뿐, 논리적인 동시 실행 자체는 무제한으로 발생하는 것을 확인할 수 있었습니다. 따라서 유량 제어가 필요함을 느꼈습니다.

# Virtual Thread + Semaphore(100)

Virtual Thread (무제한) 방식과 동일하게 live thread 수가 유지되었습니다. 하지만 중요한 차이는 아래와 같습니다.

동시에 실행되는 작업 수가 100으로 제한됨
초과 요청은 가상 스레드 상태로 park 되어 대기
외부 API 처리 한계를 넘지 않음
read timeout 발생 없음
모든 요청 성공

즉, 가상 스레드의 가벼움 + 명시적 유량 제어가 결합된 구조로 모든 요청을 성공적으로 처리할 수 있었습니다.

3-2-2. CPU Usage

CPU Bound 작업이 아닌 I/O Bound 작업이라 CPU Usage는 세 방식 모두 비슷하였습니다.

3-2-3. JVM Heap

Virtual Thread는 OS 스레드를 직접 늘리는 구조가 아니라, 많은 수의 가상 스레드 객체를 생성하여 실행합니다. 가상 스레드는 실행이 중단되거나 I/O 대기 상태에 들어가면, 스택을 네이티브 스택에 유지하지 않고 힙에 저장되는 continuation 형태로 보관합니다. 이때 스택은 하나의 큰 연속 메모리가 아니라, 여러 개의 stack chunk(청크 스택) 단위로 분할되어 힙에 저장됩니다. 이후 다시 실행될 때는 이 stack chunk들을 복원하여 이어서 실행합니다.

이 구조 덕분에 가상 스레드는 매우 가볍게 생성·중단될 수 있지만, 동시에 많은 가상 스레드가 존재하면 각 스레드가 보유한 continuation과 stack chunk 객체들이 힙에 함께 존재하게 됩니다. 그 결과, ThreadPool 방식처럼 동시 실행 수가 제한된 구조에 비해 힙 사용량이 상대적으로 더 증가하게 됩니다.

즉, 가상 스레드는 OS 스레드 사용량을 줄이는 대신, 힙 기반 구조(continuation + stack chunk)를 활용하는 모델이며, 이로 인해 동시 실행 수가 많아질수록 힙 메모리 사용량이 증가하는 특성을 가집니다.

따라서, 그래프에서도 ThreadPool 방식에 비해 Virtual Thread 방식에서 힙 사용량이 더 증가하는 것을 확인할 수 있었습니다. GC 또또한 ThreadPool 방식에 비해 Virtual Thread 방식이 더 증가하였습니다. 따라서 가상 스레드를 사용할 때도 무제한 실행보다는 세마포어 등의 기법으로 동시성을 제어하는 것이 메모리 안정성 측면에서 중요할 것 같다고 생각됩니다.

3-2-4. NativeMemory

ThreadPool 방식은 Virtual Thread와 달리 OS 스레드(= 플랫폼 스레드) 가 직접 생성됩니다. 즉, 지정한 개수만큼(혹은 무제한으로) OS 스레드가 늘어나며, 각 스레드는 고정 크기의 네이티브 스택 메모리를 차지하게 됩니다.

반면 Virtual Thread는 OS 스레드가 아니라 JVM 내부 객체로 생성되며, 실제 실행은 소수의 carrier thread 위에서 이루어집니다. 따라서 Virtual Thread의 개수가 늘어나더라도 OS 스레드 수는 거의 증가하지 않고, 대신 힙 메모리 사용량만 소폭 증가하게 됩니다.

즉, ThreadPool 방식은 네이티브 메모리 사용량이 증가하고 Virtual Thread 방식은 힙 메모리 사용이 증가하는 구조라고 볼 수 있습니다.

네이티브 메모리란?

네이티브 메모리는 JVM 힙 외부에서 사용되는 메모리 영역으로, 대표적으로 다음을 포함합니다.
- OS 스레드 스택 메모리 (-Xss)
- JNI 메모리
- 코드 캐시(Code Cache)
- 클래스 메타데이터
- 기타 JVM 내부 구조체

이 중 스레드 수 증가와 직접적으로 연결되는 영역이 바로 스레드 스택 메모리입니다

저는 이것 또한 실제 눈으로 확인해보기 위해 실험해보았습니다.

네이티브 메모리 사용량을 확인하기 위해 JVM의 Native Memory Tracking 기능을 활성화했습니다.

 tasks.withType<BootRun> {
      jvmArgs = listOf(
          "-XX:NativeMemoryTracking=summary"
      )
  }

이후 실행 중인 JVM에 대해 아래 명령어로 스레드 관련 네이티브 메모리 변화를 확인했습니다.

jcmd <PID> VM.native_memory baseline
# 테스트 실행
jcmd <PID> VM.native_memory summary.diff scale=MB | grep -A 3 "Thread"

[ThreadPool 방식 (플랫폼 스레드-100개)]

Thread (reserved=216MB +100MB, committed=13MB +5MB)
       (threads #198 +100)
       (stack: reserved=215MB +100MB, committed=12MB +5MB)

OS 스레드 증가: +100
네이티브 스택 증가: 약 +100MB
스레드 1개당 약 1MB 사용

ThreadPool 방식에서는 스레드 수 증가만큼 네이티브 메모리가 선형적으로 증가함을 확인할 수 있었습니다.

[Virtual Thread + Semaphore(100) 방식]

Thread (reserved=125MB +10MB, committed=8MB +1MB)
       (threads #108 +10)
       (stack: reserved=125MB +10MB, committed=8MB +1MB)

OS 스레드 증가: 약 +10 (캐리어 스레드)
네이티브 스택 증가: 약 +10MB
가상 스레드 수 증가와 무관하게 네이티브 메모리는 거의 증가하지 않음

Virtual Thread 방식에서는 네이티브 메모리가 거의 증가하지 않았습니다. 이는 가상 스레드가 OS 스레드가 아닌 JVM 객체로 관리되며, 실제 실행은 CPU 개수 수준의 캐리어 스레드에서 이루어지기 때문입니다.

즉, 위 차이를 통해 다음을 확인할 수 있었습니다.

ThreadPool 방식은 플랫폼 스레드 수만큼 네이티브 메모리가 증가한다.(+100MB)
Virtual Thread는 캐리어 스레드 수만큼만 네이티브 메모리가 증가한다.(+10MB)
따라서 대량의 동시 요청 환경에서는 Virtual Thread가 훨씬 메모리 효율적이다

정리하자면, ThreadPool은 스레드 수만큼 네이티브 메모리를 소모하지만, Virtual Thread는 캐리어 스레드 수만큼만 네이티브 메모리를 사용하는 것을 알 수 있었습니다.

3-2-5. Duration

Duration 같은 경우 ThreadPool 방식보다는 Virtual Thread 방식이 좀 더 길었던 것을 확인할 수 있었습니다.

우선 Virtual Thread + Semaphore 방식은 ThreadPool과 동일한 수준의 동시 실행 개수를 유지하지만, 작업을 처리하는 방식에는 구조적인 차이가 있습니다. ThreadPool은 내부적으로 BlockingQueue 기반의 작업 큐를 사용하여 요청을 정렬한 뒤, 가용한 스레드가 순차적으로 작업을 가져가 처리합니다. 이 때문에 실행 순서가 비교적 안정적이며, 작업이 배치 형태로 처리되는 특성을 가집니다.

반면, Virtual Thread + Semaphore 방식은 별도의 작업 큐를 두지 않고, 각 요청이 세마포어의 permit을 직접 획득하기 위해 경쟁하는 구조입니다. 이 과정에서는 요청 간 실행 순서가 보장되지 않으며, permit이 반환되는 시점에 어떤 가상 스레드가 먼저 실행 권한을 얻느냐는 스케줄링 타이밍에 따라 달라집니다. 그 결과 일부 요청은 비교적 빠르게 처리되는 반면, 일부 요청은 permit 획득이 뒤로 밀리면서 실행 시점이 늦어질 수 있습니다.

이러한 특성 때문에 요청 완료 순서가 뒤섞이고, 마지막 요청들이 늦게 종료되면서 전체 처리 시간이 ThreadPool 방식보다 약간 길어지는 현상이 발생하지 않았을까? 추측됩니다. 이는 성능 저하라기보다는, 블로킹 큐 기반 처리와 경쟁 기반 처리라는 스케줄링 방식의 차이에서 비롯된 자연스러운 현상일 것으로 보입니다. 따라서 대량의 트래픽을 Virtual Thread + Semaphore 방식으로 처리할 경우 ThreadPool 방식에 비해 Duration이 좀 더 길어질 수 있다는 점도 고려해봐야하지 않을까 싶습니다.

4. 마치며..

실제로 Virtual Thread를 도입해보며 느꼈던 장단점과, 실험을 통해 확인한 성능 · 메모리 특성을 정리해보았습니다. 특히 네이티브 메모리 사용량을 기준으로 비교해보니, 왜 Virtual Thread가 “가볍다”고 이야기되는지 체감할 수 있었습니다.

단순히 이론이 아니라, 실제 수치로 확인해보니 인상적이었습니다. 모든 상황에서 무조건 Virtual Thread를 써야 하는 것은 아니지만, I/O 비중이 높은 서버라면 충분히 검토해볼 만한 선택지라고 느꼈습니다. 이 글이 도입을 고민하시는 분들께 작은 참고가 되었으면 합니다.

Jackson 2 vs Jackson 3 성능 비교 실험기

Hyung1 — Sun, 21 Dec 2025 01:46:21 +0900

1. 실험을 하게 된 배경

최근 차세대 마이그레이션을 진행하는 업무를 맡아 수행하게 되었습니다. 이번 마이그레이션에서는 지금까지의 JDK 버전 흐름과 지원 현황을 종합적으로 검토한 결과, 여러 기술적·운영상의 이유로 JDK 25를 도입하는 것이 가장 적합하다고 판단하여 이를 채택하였습니다.

JDK 25의 주요 변화 중 하나는 Jackson 메이저 버전이 Jackson 2에서 Jackson 3으로 전환되었다는 점입니다. Jackson 3로의 전환 배경과 상세한 변경 사항에 대해서는 아래의 공식 문서와 커뮤니티 자료에 잘 정리되어 있어, 본 글에서는 해당 내용을 깊게 다루지는 않았습니다. 관련 내용은 아래 문서들을 참고하시면 됩니다.

Jackson 3 마이그레이션 가이드
https://github.com/FasterXML/jackson/blob/main/jackson3/MIGRATING_TO_JACKSON_3.md
Jackson 3.0 공식 릴리즈 노트
https://github.com/FasterXML/jackson/wiki/Jackson-Release-3.0

본 글에서는 Jackson 2와 -> Jackson 3로 전환하면서 비교했던 성능 비교 실험 결과를 중심으로 내용을 구성하였습니다. 잘못된 내용이 있으면 댓글 남겨주세요.

2. 왜 JMH를 사용했는가

일반적인 System.currentTimeMillis()나 단순 반복 루프 기반 측정은 JVM 환경에서는 신뢰하기 어렵습니다. 이유는 다음과 같습니다.

JVM은 실행 중에 JIT 컴파일을 수행합니다.
코드가 실행될수록 최적화 수준이 달라집니다.
GC, OS 스케줄링, 캐시 상태에 따라 결과가 크게 흔들릴 수 있습니다.

이런 문제를 피하기 위해 OpenJDK에서 공식적으로 제공하는 JMH(Java Microbenchmark Harness) 를 사용했습니다.

JMH는 다음을 자동으로 처리해줍니다.

워밍업과 실제 측정 구간 분리
JVM Fork(새 JVM 실행)
통계적 평균, 표준편차, 신뢰 구간 계산
벤치마크 코드의 잘못된 최적화 방지

3. 테스트 환경

3-1. 실행 환경

OS: macOS (Apple Silicon)
실행 위치: 로컬 머신
원격 서버, 컨테이너, CI 사용 없음

로컬 환경을 선택한 이유는 다음과 같습니다.

두 Jackson 버전을 완전히 동일한 머신 조건에서 비교하기 위함
외부 네트워크, 서버 부하 등 변수를 제거하기 위함
테스트 편의성(단순히 직렬화, 역직렬화시의 성능을 벤치마킹하기 위함)

3-2. JVM 선택

Jackson 3 테스트: JDK 25
Jackson 2 테스트: JDK 17

Jackson 3는 최신 JDK 환경에서의 사용을 염두에 두고 설계된 반면, Jackson 2는 여전히 JDK 17 환경에서 가장 많이 사용되고 있기 때문에 각각 현실적인 사용 환경을 기준으로 테스트했습니다. 중요한 점은, 각 비교는 같은 JVM 내에서 Jackson 버전만 바꿔서 수행되었다는 점입니다. (Jackson 2 vs 3 비교 시 JVM 자체는 동일하게 유지)

3-3. 소스코드

@State(Scope.Benchmark)
@BenchmarkMode(Mode.Throughput, Mode.AverageTime) // ops/s + 평균 시간 둘 다 측정
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@Warmup(iterations = 3, time = 3, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 3, timeUnit = TimeUnit.SECONDS)
@Fork(value = 2, jvmArgs = ["-Xms2g", "-Xmx2g"]) // 힙 크기 고정으로 GC 영향 최소화
open class JacksonBench {

    @Param("1000", "10000")
    var bigSize: Int = 0
	
    // A 프로젝트에서는 JsonMapper, B 프로젝트에서는 ObjectMapper로 로직 변경하며 테스트
    // tools.jackson.databind.json.JsonMapper
    private lateinit var mapper: JsonMapper

    // import com.fasterxml.jackson.databind.ObjectMapper
    // private lateinit var mapper: ObjectMapper

    private lateinit var small: SmallDto
    private lateinit var big: BigDto

    private lateinit var smallBytes: ByteArray
    private lateinit var bigBytes: ByteArray

    @Setup(Level.Trial)
    fun setup() {
        mapper = GLOBAL_OBJECT_MAPPER

        small = SmallDto.sample()
        big = BigDto.sample(size = bigSize)

        // deserialize 벤치에서 매번 serialize하지 않도록 미리 만들어둠
        smallBytes = mapper.writeValueAsBytes(small)
        bigBytes = mapper.writeValueAsBytes(big)
    }

    // ---------- Small: Serialize / Deserialize ----------

    @Benchmark
    fun serializeSmall(bh: Blackhole) {
        val bytes = mapper.writeValueAsBytes(small)
        bh.consume(bytes)
    }

    @Benchmark
    fun deserializeSmall(bh: Blackhole) {
        val obj = mapper.readValue(smallBytes, SmallDto::class.java)
        bh.consume(obj)
    }

    @Benchmark
    fun serializeBig(bh: Blackhole) {
        val bytes = mapper.writeValueAsBytes(big)
        bh.consume(bytes)
    }

    @Benchmark
    fun deserializeBig(bh: Blackhole) {
        val obj = mapper.readValue(bigBytes, BigDto::class.java)
        bh.consume(obj)
    }
}

data class SmallDto(
    val id: Long,
    val name: String,
    val email: String?,
    val age: Int,
    val score: Double,
    val active: Boolean,
    val status: Status,
    val createdAt: Instant,
    val updatedAt: Instant?,
    val requestId: String,
) {
    companion object {
        fun sample(): SmallDto = SmallDto(
            id = 123456789L,
            name = "jeonghyeongil",
            email = "jeonghyeongil@gmail.com",
            age = 29,
            score = 98.76,
            active = true,
            status = Status.ACTIVE,
            createdAt = Instant.parse("2025-12-20T00:00:00Z"),
            updatedAt = Instant.parse("2025-12-20T01:02:03Z"),
            requestId = UUID.randomUUID().toString()
        )
    }
}

data class Item(
    val id: Long,
    val sku: String,
    val title: String,
    val price: Int,
    val tags: List<String>,
    val attrs: Map<String, String>?,
    val createdAt: Instant
)

data class BigDto(
    val id: Long,
    val items: List<Item>
) {
    companion object {
        fun sample(size: Int): BigDto {
            val rnd = Random(1)
            val tagsPool = listOf("a", "b", "c", "d", "e", "f")

            val items = (0 until size).map { i ->
                Item(
                    id = i.toLong(),
                    sku = "SKU-$i",
                    title = "Item Title $i",
                    price = rnd.nextInt(1000, 100_000),
                    tags = List(3) { t -> tagsPool[(i + t) % tagsPool.size] },
                    attrs = if (i % 10 == 0) null else mapOf(
                        "color" to "black",
                        "size" to "M",
                        "idx" to i.toString()
                    ),
                    createdAt = Instant.ofEpochMilli(1_700_000_000_000L + i)
                )
            }

            return BigDto(
                id = 1L,
                items = items
            )
        }
    }
}

3-4. 힙 메모리를 고정한 이유

@Fork(
    value = 2,
    jvmArgs = ["-Xms2g", "-Xmx2g"]
)

힙 메모리를 2GB로 초기 크기와 최대 크기를 동일하게 설정했습니다. 이렇게 설정한 이유는 다음과 같습니다.

JVM 힙 확장/축소로 인한 노이즈 제거

JVM은 기본적으로 필요에 따라 힙 크기를 늘리거나 줄입니다. 이 과정에서 GC 패턴이 바뀌고, 측정 결과가 흔들릴 수 있습니다.

serialize / deserialize 자체 비용만 보고 싶었기 때문

이번 실험의 목적은

“메모리가 부족할 때 어떻게 되는가”가 아니라
“같은 메모리 조건에서 순수 처리 성능이 어떤가”

이기 때문에, 힙 크기를 고정하여 환경 변수를 최대한 제거했습니다

3-5. 왜 Fork를 사용했는가 (Fork = 2)

@Fork(2)

Fork는 JVM을 완전히 새로 띄워서 벤치마크를 실행하는 옵션입니다. Fork를 사용한 이유는 다음과 같습니다.

JVM은 실행 초기에 JIT 컴파일을 진행합니다.
한 JVM에서만 실행하면, 이전 실행의 최적화 상태가 다음 측정에 영향을 줄 수 있습니다.

Fork를 사용하면:

JVM을 새로 띄운 상태에서
동일한 벤치마크를 다시 실행하고
두 결과를 평균냅니다.

즉, JVM을 껐다 켠 상태에서 같은 실험을 여러 번 반복하는 효과를 얻을 수 있습니다. 이번 실험에서는 신뢰도를 확보하면서 실행 시간이 과도하게 늘어나지 않도록 Fork = 2로 설정했습니다.

3-6. Warmup을 왜 이렇게 설정했는가

@Warmup(iterations = 3, time = 3, timeUnit = TimeUnit.SECONDS)

Warmup의 의미

Warmup은 측정하지 않는 구간입니다. 이 구간에서는 JIT 컴파일, 클래스 로딩, 내부 캐시 준비 등이 이루어집니다.

왜 3초 × 3회인가

1회만으로는 JVM 최적화가 충분히 끝나지 않는 경우가 많습니다.
너무 길게 잡으면 전체 실행 시간이 과도하게 증가합니다.

그래서 3초 동안 최대한 많이 실행하고 이를 3번 반복 하는 설정을 선택했습니다. 이는 JVM이 충분히 “몸을 푼 상태” 이지만 실행 시간이 과하지 않은 타협점이라고 판단했습니다.

3-7. Measurement 설정 의도

@Measurement(iterations = 5, time = 3, timeUnit = TimeUnit.SECONDS)

Measurement는 실제 결과로 사용되는 구간입니다.

“3초 동안 실행”의 의미

이것은 “3초 동안 한 번 실행”이 아니라, 3초 동안 해당 메서드를 최대한 많이 반복 실행한다는 의미입니다. 예를 들어 메서드 한 번이 2ms 걸린다면 3초 동안 약 150만 번 실행됩니다. 이렇게 많은 샘플을 모아야 OS 스케줄링, GC 타이밍, 순간적인 노이즈 를 평균으로 눌러서 안정적인 수치를 얻을 수 있습니다.

iterations = 5

이 3초짜리 측정을 5번 반복하여 평균, 표준편차, 신뢰 구간 을 계산합니다.

3-8. Throughput + AverageTime를 동시에 측정한 이유

@BenchmarkMode(Mode.Throughput, Mode.AverageTime)

두 모드는 같은 현상을 다른 관점에서 보여줍니다.

Throughput (ops/ms)
→ 서버 처리량 관점
→ “1ms에 몇 번 처리 가능한가”
AverageTime (ms/op)
→ 지연 시간 관점
→ “1번 처리하는 데 평균 얼마나 걸리는가”

3-9. 코드 설계 의도

State와 Setup

@State(Scope.Benchmark)
@Setup(Level.Trial)

벤치마크 실행 동안 동일한 객체를 공유
테스트 시작 시 한 번만 데이터 준비

이렇게 한 이유는 serialize / deserialize 자체 비용만 측정하기 위함입니다. 특히 deserialize 테스트에서

smallBytes = mapper.writeValueAsBytes(small)
bigBytes = mapper.writeValueAsBytes(big)

를 미리 수행한 이유는 deserialize 성능을 측정하는데 serialize 비용이 섞이지 않도록 하기 위함입니다.

Small DTO

일반적인 API 응답 DTO 크기

Big DTO

내부에 List<Item> 포함
대량 리스트 응답 DTO 크기

Big DTO는:

1,000개
10,000개

두 케이스로 나누어 크기에 따른 선형 증가 여부도 함께 확인했습니다.

4. 결과 요약 및 해석

Jackson3

Benchmark                      (bigSize)   Mode  Cnt     Score     Error   Units
JacksonBench.deserializeBig         1000  thrpt   10     0.837 ±   0.043  ops/ms
JacksonBench.deserializeBig        10000  thrpt   10     0.086 ±   0.001  ops/ms
JacksonBench.deserializeSmall       1000  thrpt   10   541.207 ±  22.379  ops/ms
JacksonBench.deserializeSmall      10000  thrpt   10   550.785 ±   6.788  ops/ms
JacksonBench.serializeBig           1000  thrpt   10     2.837 ±   0.046  ops/ms
JacksonBench.serializeBig          10000  thrpt   10     0.274 ±   0.004  ops/ms
JacksonBench.serializeSmall         1000  thrpt   10  1708.548 ±  36.480  ops/ms
JacksonBench.serializeSmall        10000  thrpt   10  1640.783 ± 114.743  ops/ms
JacksonBench.deserializeBig         1000   avgt   10     1.194 ±   0.054   ms/op
JacksonBench.deserializeBig        10000   avgt   10    11.696 ±   0.363   ms/op
JacksonBench.deserializeSmall       1000   avgt   10     0.002 ±   0.001   ms/op
JacksonBench.deserializeSmall      10000   avgt   10     0.002 ±   0.001   ms/op
JacksonBench.serializeBig           1000   avgt   10     0.349 ±   0.006   ms/op
JacksonBench.serializeBig          10000   avgt   10     3.588 ±   0.070   ms/op
JacksonBench.serializeSmall         1000   avgt   10     0.001 ±   0.001   ms/op
JacksonBench.serializeSmall        10000   avgt   10     0.001 ±   0.001   ms/o

Jackson2

Benchmark                      (bigSize)   Mode  Cnt     Score    Error   Units
JacksonBench.deserializeBig         1000  thrpt   10     0.677 ±  0.046  ops/ms
JacksonBench.deserializeBig        10000  thrpt   10     0.075 ±  0.002  ops/ms
JacksonBench.deserializeSmall       1000  thrpt   10   502.430 ±  4.089  ops/ms
JacksonBench.deserializeSmall      10000  thrpt   10   487.280 ± 14.380  ops/ms
JacksonBench.serializeBig           1000  thrpt   10     2.016 ±  0.025  ops/ms
JacksonBench.serializeBig          10000  thrpt   10     0.190 ±  0.004  ops/ms
JacksonBench.serializeSmall         1000  thrpt   10  1425.201 ± 36.081  ops/ms
JacksonBench.serializeSmall        10000  thrpt   10  1458.080 ± 51.928  ops/ms
JacksonBench.deserializeBig         1000   avgt   10     1.420 ±  0.029   ms/op
JacksonBench.deserializeBig        10000   avgt   10    13.221 ±  0.096   ms/op
JacksonBench.deserializeSmall       1000   avgt   10     0.002 ±  0.001   ms/op
JacksonBench.deserializeSmall      10000   avgt   10     0.002 ±  0.001   ms/op
JacksonBench.serializeBig           1000   avgt   10     0.500 ±  0.017   ms/op
JacksonBench.serializeBig          10000   avgt   10     5.068 ±  0.092   ms/op
JacksonBench.serializeSmall         1000   avgt   10     0.001 ±  0.001   ms/op
JacksonBench.serializeSmall        10000   avgt   10     0.001 ±  0.001   ms/op

기준

thrpt 개선율 = 처리량 기준 (높을수록 좋음)
avgt 개선율 = 1건 처리 시간 기준 (낮을수록 좋음)
절감 시간 = 객체 1건 처리 시 줄어든 실제 시간

Big DTO

항목	Size	Jackson 2	Jackson 3	thrpt 개선율	avgt 개선율	1건당 절감 시간
serializeBig	1000	2.016 ops/ms 0.500 ms/op	2.837 ops/ms 0.349 ms/op	+40.7%	-30.2%	0.151 ms
serializeBig	10000	0.190 ops/ms 5.068 ms/op	0.274 ops/ms 3.588 ms/op	+44.2%	-29.2%	1.480 ms
deserializeBig	1000	0.677 ops/ms 1.420 ms/op	0.837 ops/ms 1.194 ms/op	+23.6%	-15.9%	0.226 ms
deserializeBig	10000	0.075 ops/ms 13.221 ms/op	0.086 ops/ms 11.696 ms/op	+14.7%	-11.5%	1.525 ms

Small DTO (절대 시간이 1~2ms 수준이라 개선율은 존재하지만 단일 요청 체감은 거의 없습니다.)

항목	Jackson 2	Jackson 3	thrpt 개선율	avgt 개선율
serializeSmall	1425 ~ 1458 ops/ms	1641 ~ 1709 ops/ms	+12.5% ~ +19.9%	~0.001 ms/op
deserializeSmall	487 ~ 502 ops/ms	541 ~ 551 ops/ms	+7.7% ~ +13.0%	~0.002 ms/op

정리하면 다음과 같습니다.

Small DTO
→ Jackson 3가 더 빠르지만, 절대 시간이 매우 작아 단일 요청 체감은 제한적입니다.
Big DTO
→ Jackson 3는
- 직렬화 기준 최대 약 40~45% 처리량 개선,
- 역직렬화 기준 약 15~25% 처리량 개선,
- 객체 1건당 약 0.15~1.48ms, 역직렬화는 객체 1건당 약 0.23~1.53ms의 밀리초 단위의 실질적인 시간 절감

대용량 JSON 처리 구간에서 실제로 의미 있는 개선을 확인할 수 있었습니다.

5. 정리

이번 실험은 동일 코드, 동일 데이터 구조, 동일 JMH 설정 동일 머신 환경 에서 Jackson 버전만 변경하여 수행되었습니다. 그 결과 Jackson 3는 Jackson 2 대비 특히 대용량 JSON 처리에서 명확하고 일관된 성능 개선을 보여주었습니다. Small DTO 위주의 서비스에서는 체감이 크지 않을 수 있지만, Big DTO일때는 체감이 꽤나 컸습니다.

6. 왜 Jackson3이 더 빠를까?

Jackson3이 왜 더 빠른지 실제 라이브러리 내부 코드를 확인해보았습니다. Jackson 3은 직렬화 과정에서 반복과 런타임 판단을 최대한 제거하는 방향으로 성능을 개선한 것을 확인하였습니다. 대표적으로 아래와 같은 최적화들이 적용되었습니다.

6-1. UnrolledBeanSerializer (반복문 + 배열 접근 제거)

기존 구조 (Jackson 2)

// 배열을 순회하면서 프로퍼티 직렬화
protected void _serializePropertiesNoView(
        Object bean,
        JsonGenerator gen,
        SerializationContext provider,
        BeanPropertyWriter[] props
) {
    int i = 0;
    int left = props.length;

    do {
        BeanPropertyWriter prop = props[i];
        prop.serializeAsProperty(bean, gen, provider);

        prop = props[i + 1];
        prop.serializeAsProperty(bean, gen, provider);

        i += 2;
        left -= 2;
    } while (left > 1);
}

문제점

props[i] 접근마다 bounds check 발생
i, left 같은 카운터 변수 관리 필요
반복 조건을 매번 검사

개선 구조 (Jackson 3 – UnrolledBeanSerializer)

// 프로퍼티를 배열이 아닌 필드로 보관
protected BeanPropertyWriter _prop1;
protected BeanPropertyWriter _prop2;
protected BeanPropertyWriter _prop3;
protected BeanPropertyWriter _prop4;
protected int _propCount;

protected void serializeNonFiltered(
        Object bean,
        JsonGenerator gen,
        SerializationContext provider
) throws IOException {
    gen.writeStartObject(bean);

    switch (_propCount) {
        case 4:
            _prop1.serializeAsProperty(bean, gen, provider);
        case 3:
            _prop2.serializeAsProperty(bean, gen, provider);
        case 2:
            _prop3.serializeAsProperty(bean, gen, provider);
        case 1:
            _prop4.serializeAsProperty(bean, gen, provider);
    }

    gen.writeEndObject();
}

개선 효과

배열 접근 제거
반복문 제거
조건 체크 제거
switch fall-through 구조로 CPU 분기 예측에 유리

6-2. 직렬화 사전 결정

기존 구조 - 매번 타입 확인(Jackson 2)

public void serializeAsProperty(
        Object bean,
        JsonGenerator g,
        SerializationContext ctxt
) throws Exception {
    Object value = get(bean);

    ValueSerializer<Object> ser = _serializer;
    if (ser == null) {
        Class<?> cls = value.getClass();
        PropertySerializerMap m = _dynamicSerializers;

        ser = m.serializerFor(cls);
        if (ser == null) {
            ser = _findAndAddDynamic(m, cls, ctxt);
        }
    }

    ser.serialize(value, g, ctxt);
}

매 호출마다 발생하는 작업

직렬화기 존재 여부 체크
런타임 타입 확인
캐시 조회
필요 시 신규 생성

객체 수 × 프로퍼티 수만큼 반복됩니다.

개선 구조 - 생성 시점에 한 번만 결정(Jackson 3)

@Override
public void resolve(SerializationContext provider) throws JsonMappingException {
    for (BeanPropertyWriter prop : _props) {
        if (prop.hasSerializer()) {
            continue;
        }

        JavaType type = prop.getType();

        // final 타입은 런타임에 바뀌지 않음
        if (type.isFinal()) {
            ValueSerializer<Object> ser =
                provider.findPrimaryPropertySerializer(type, prop);
            prop.assignSerializer(ser);
        }
    }
}

실제 직렬화시

public void serializeAsProperty(
        Object bean,
        JsonGenerator g,
        SerializationContext ctxt
) throws Exception {
    Object value = get(bean);

    // final 타입이면 이미 serializer가 할당되어 있음
    _serializer.serialize(value, g, ctxt);
}

6-3. 요약

항목	Jackeson2	Jackson3
배열 접근	O	X
반복문	O	X
런타임 타입 체크	매번	생성 시 1회
CPU 분기 예측	어려움	쉬움

이 외에도 Jackson 3에는 다음과 같은 개선이 함께 적용되었습니다.

PropertySerializerMap에서 단일 타입 사용 시 해시맵을 우회하는 빠른 조회 경로 추가
SerializerCache에 읽기 전용 캐시를 분리하여 락 없는 조회 가능
리스트 직렬화 시 Iterator 대신 인덱스 기반 접근 사용
Java 17 환경에서 Record 타입의 구조적 특성을 활용하여 리플렉션 비용 감소

[Kafka] 파티션이 증가할수록 commit_offset log file 리소스도 증가할까?

Hyung1 — Sun, 6 Apr 2025 21:11:13 +0900

안녕하세요. 이전에 파티션 증가 없이 동시 처리량을 늘리기 위해 Parallel Consumer에 관해 살펴보고 PoC를 진행해보았습니다. 파티션이 증가하게 되면 아래와 같은 문제들이 발생합니다

브로커 파일 시스템 리소스 증가
장애에 더 취약한 구조
복제 비용 증가

저는 이러한 문제들을 해결하기 위해 파티션 증가 없이 동시 처리량을 늘려보고자 하였고 이에 대한 글도 작성하였습니다.

저는 기존 카프카에서 파티션이 증가할 수록 브로커 파일 시스템 리소스가 증가할 것이라고 생각했습니다. 왜냐하면 동시 처리량을 늘리기 위해서는 파티션과 컨슈머를 늘려야합니다. 컨슈머 수가 늘어난 만큼 오프셋 커밋도 늘어나서 comit_offset log file에 기록되는 리소스 또한 증가할 것이라고 생각했기 떄문입니다.

오프셋 커밋은 consumer가 요청하고, 그 요청을 broker의 group coordinator가 받아서
__consumer_offsets라는 내부 topic에 기록하는 구조입니다. consumer마다 발생합니다.

하지만, 테스트 결과 제 생각은 틀렸다는 것을 확인할 수 있었습니다.

파티션이 증가할수록 commit_offset log file 리소스도 증가할까?

저는 Kafka에서 토픽 파티션 수(1 vs 3)에 따라__consumer_offsets log 파일 시스템 리소스 용량 차이가 발생하는지 직접 확인해보았습니다. 파티션 수를 1과 3으로 각각 설정하고 메시지를 십만 건 발행, 컨슘, 오프셋 커밋하여 파일 시스템 리소스 용창 차이를 확인해보았습니다.

아래의 명령어로 파일 시스템 리소스 용량 차이를 확인해보았습니다.

# 커밋 로그가 기록된 __consumer_offsets 파티션 확인
find .data -name '*.log' | grep __consumer_offsets

# 각 offsets 파티션별 log 파일 크기 확인
du -ch .data/kafka*/__consumer_offsets-*/*.log

# 전체 __consumer_offsets log 파일 총합 확인
du -ch $(find .data -name '*.log' | grep __consumer_offsets) | tail -n1

또한 동일한 consumer group ID를 유지한 채, 메시지 key를 각각 다르게 설정해보았고, key에 % 2 연산을 적용하여 일부러 분산되도록 구성해보기도 했습니다.

실험 결과

파티션 1개 / 파티션 3개 모두 특정 __consumer_offsets-N 디렉토리 하위의 .log file 하나만 리소스 증가
- 파티션 수 변경시 로그 파일은 초기화하고 다시 테스트하였습니다.
파일 사이즈도 두 경우 모두 64KB로 동일
즉, 파티션 수가 늘어나도 파일 시스템 사용량에는 차이 없음

// find .data -name '*.log' | grep __consumer_offsets
// du -ch .data/kafka*/__consumer_offsets-*/*.log

  
0B	.data/kafka1/__consumer_offsets-11/00000000000000000000.log
0B	.data/kafka1/__consumer_offsets-14/00000000000000000000.log
896K	.data/kafka1/__consumer_offsets-29/00000000000000000000.log
.. 생략
0B	.data/kafka3/__consumer_offsets-7/00000000000000000000.log

두 경우 모두 파일 사이즈가 64KB로 동일한 이유가 무엇일까요?

파티션이나 컨슈머 수가 많아도 메시지 단위로 오프셋 커밋하면 커밋 횟수가 같기 때문입니다.
메시지 단위를 배치로 커밋해도 결국 <groupId, topic, partition> 단위의 최신 오프셋만 유지되므로, 메모리 사용량은 크게 달라지지 않습니다.
Kafka는 compacted topic 구조를 사용해 offset을 <groupId, topic, partition> 기준으로 덮어쓰기 때문에, 메시지 key가 다르든 같든, 배치 커밋이든 메시지당 커밋이든 관계없이 각 key별로 최신 오프셋만 유지되며, 그 결과 디스크 사용량이 최적화됩니다.
Kafka가 offset 커밋을 compacted topic에 덮어쓰는 이유는, “어디까지 읽었는가”만 중요하고, 과거에 뭐까지 읽었는지는 중요하지 않기 때문입니다.

두 경우 모두 특정 __consumer_offsets-N 디렉토리 하위의 .log file 하나만 리소스가 증가한 이유가 무엇일까요?

Kafka는 offset commit을 groupId 기준으로 해싱하여 __consumer_offsets 파티션 중 하나에만 기록하기 때문입니다.
따라서 같은 groupId를 사용하면, 모든 커밋이 같은 offsets 로그 파일에만 몰리게 됩니다.

Reference

https://docs.confluent.io/kafka/design/log_compaction.html?utm_source=chatgpt.com

[Kafka] Kafka에서 파티션 증가 없이 동시 처리량을 늘리는 방법 - Parallel Consumer

Hyung1 — Fri, 31 Jan 2025 00:14:44 +0900

보통 Kafka 사용 시 처리량을 늘리기 위해 컨슈머와 파티션 수를 늘린 후 병렬처리를 통해 처리량을 증가시킵니다. 하지만 저는 처리량을 늘릴 때마다 파티션을 추가하는 것이 최선인지에 대한 의문을 가지고 있었습니다. 파티션을 늘리는 대신, 한 파티션에서 단일 메시지가 아니라 여러 개의 메시지를 가져와 병렬 처리하면, 파티션 개수를 증가시키지 않고도 성능을 높일 수 있지 않을까 하는 고민을 해왔습니다. 이러한 고민을 하게 된 이유는 아래와 같습니다.

인프라 비용 증가
- 파티션이 많아질수록 추가적인 브로커가 필요할 가능성이 높아지고 브로커 노드 수 증가에 따른 서버 비용, 네트워크 비용 등이 상승할 수 있습니다.
브로커 파일 시스템 리소스 사용량 증가
- Kafka 브로커는 각 파티션별로 데이터를 저장합니다. 데이터 정보(.log 파일)뿐만 아니라 메타 정보(.index, .timeindex, .snapshot 파일)도 함께 저장되며, 파티션 수가 증가할수록 파일 오픈 비용, 디스크 사용량이 증가합니다.
장애에 더 취약한 구조
- 단일 브로커에 많은 파티션 리더가 배치되면, 브로커 장애 또는 재시작 시 영향받는 범위가 넓어질 수 있습니다.
복제 비용 증가
- 파티션 단위로 설정된 replicas 수만큼 복제가 이루어지므로, 복제 과정에서 디스크 사용량 증가 및 레이턴시 증가가 발생합니다

처리량을 높이기 위해 무조건 파티션을 늘려 인프라 비용을 증가시키기보다는, 기존 파티션 수를 유지한 채 하나의 파티션에서 여러 개의 메시지를 조회하는 방식으로 불필요한 비용 증가를 방지할 수 있다고 판단하였습니다. 또한 파티션 수가 적은 환경에서는 이러한 문제가 크지 않을 수 있지만, 과도하게 증가한 환경에서는 심각한 성능 저하로 이어질 수 있다고 생각하였습니다.

이 문제를 해결할 방법을 찾던 중, Confluent Inc.에서 개발한 오픈소스 라이브러리인 Parallel Consumer를 발견하였고, 이를 활용한 PoC(Proof of Concept)를 진행해보았습니다.

개요

Parallel Consumer는 Confluent Inc.에서 개발한 오픈소스 라이브러리로, 단일 파티션 내에서 여러 컨슈머 스레드를 활용하여 동시 처리량을 증가시키는 기능을 제공합니다. 일반적으로 Kafka에서는 하나의 파티션이 하나의 컨슈머 스레드에 의해 처리되지만, Parallel Consumer를 사용하면 파티션 개수를 증가시키지 않고도 병렬 처리 성능을 향상시킬 수 있습니다. 해당 글에서는 Parallel Consumer의 내부 구조를 분석하고, 연동 및 개발 과정에서 수행한 PoC(Proof of Concept) 결과를 정리하였습니다.

아래는 기존 kafka Consumer(위)과 Parallel Kafka Consumer(아래)를 비교한 그림입니다.

Parallel Consumer의 주요 특징

단일 파티션 내 동시성 증가
- 기존 Kafka의 소비 모델은 하나의 파티션이 단일 컨슈머 스레드에 의해 처리됩니다.
- Parallel Consumer는 하나의 파티션 내에서 여러 개의 워커 스레드가 메시지를 병렬로 처리할 수 있습니다.
오프셋 관리 개선
- Kafka의 기본 컨슈머 모델에서는 특정 레코드가 처리되지 않으면 다음 레코드로 진행할 수 없습니다.
- Parallel Consumer는 개별 레코드 단위로 오프셋을 관리하여 특정 메시지가 지연되더라도 다른 메시지를 먼저 처리할 수 있습니다.
순서 보장 옵션 제공
- 메시지 처리 순서를 엄격하게 유지해야 하는 경우, 특정 키 또는 파티션 단위로 순서를 보장하는 옵션을 제공합니다.
  - KEY: 동일 키의 메시지 순서를 보장.
  - PARTITION: 파티션 내 순서만 보장.
  - UNORDERED: 순서 보장 없이 병렬 처리.
- 비순차 처리가 가능한 경우에는 높은 처리량을 달성할 수 있도록 최적화 되어 있습니다.

좀 더 자세한 내용은 해당 글을 참고해주세요.

조건

1 ~ 100 사이의 key를 가진 message 100개를 생성하고 topic에 send 합니다.

@RestController
class UserController(
    private val userMessageProducer: UserMessageProducer,
) {

    @PostMapping("/send")
    fun send() {
        generateUserMessages().forEach { userMessageProducer.sendMessage(it) }
    }

    @PostMapping("/parallel-send")
    fun parallelSend() {
        generateUserMessages().forEach { userMessageProducer.sendParallelMessage(it) }
    }

    @PostMapping("/batch-parallel-send")
    fun batchParallelSend() {
        generateUserMessages().forEach { userMessageProducer.sendBatchParallelMessage(it) }
    }

    private fun generateUserMessages() = (1..100).map { index ->
        UserMessage(
            id = index.toLong(),
            age = index.toLong(),
            name = "name$index",
        )
    }
}

kafkaListener, ParallelKafkaListener(단 건, 배치)를 통해 topic의 message를 consume 합니다.
- 해당 글에서는 배치 consume은 테스트 하지 않습니다.
명확한 처리 시간 비교를 위해 message consume후 Thread.sleep(1000)을 걸어줍니다.
ParallelKafkaListener의 ordering는 UNORDERED로 지정합니다.

@Component
class UserMessageConsumer(
    private val objectMapper: ObjectMapper,
) {

    @KafkaListener(
        topics = [USER_TOPIC],
        groupId = "user-consumer-group",
        concurrency = "2"
    )
    fun listen(
        record: ConsumerRecord<String, String>,
        acknowledgment: Acknowledgment,
    ) {
        try {
            val message = objectMapper.readValue(record.value(), UserMessage::class.java)
            log.info("[Main Consumer(${Thread.currentThread().id})] Message arrived! - $message")
            Thread.sleep(1000)
            acknowledgment.acknowledge()
        } catch (e: InterruptedException) {
            e.printStackTrace()
            log.info(e.message)
        }
    }

    @KafkaParallelListener(
        topics = [PARALLEL_USER_TOPIC],
        groupId = "parallel-user-consumer-group",
        concurrency = 2,
        ordering = ParallelConsumerOptions.ProcessingOrder.UNORDERED
    )
    fun parallelListen(
        record: ConsumerRecord<String, String>,
        acknowledgment: Acknowledgment
    ) {
        try {
            val message = objectMapper.readValue(record.value(), UserMessage::class.java)
            log.info("[Thread ${Thread.currentThread().id}] Partition ${record.partition()} - Message arrived! - $message")
            acknowledgment.acknowledge()
            Thread.sleep(1000)
        } catch (e: InterruptedException) {
            e.printStackTrace()
            log.info(e.message)
        }
    }

    @KafkaParallelListener(
        topics = [BATCH_PARALLEL_USER_TOPIC],
        groupId = "batch-parallel-user-consumer-group",
        concurrency = 1,
        batchSize = 10,
        ordering = ParallelConsumerOptions.ProcessingOrder.UNORDERED
    )
    fun batchListen(
        records: List<ConsumerRecord<String, String>>,
    ) {
        try {
            val messages = records.map { it.value() }
            log.info("[Main Consumer(${Thread.currentThread().id})] Messages arrived! - $messages")
            Thread.sleep(1000)
        } catch (e: InterruptedException) {
            e.printStackTrace()
            log.info(e.message)
        }
    }

    companion object {
        private val log = LoggerFactory.getLogger(this::class.java)
    }
}

Kafka Parallel Consumer 라이브러리는 @Listener 같은 어노테이션을 지원해주지 않아서 직접 개발하였습니다.

@Target(AnnotationTarget.CLASS, AnnotationTarget.FUNCTION, AnnotationTarget.ANNOTATION_CLASS)
@Retention(AnnotationRetention.RUNTIME)
annotation class KafkaParallelListener(
    val topics: Array<String>,
    val groupId: String = "",
    val concurrency: Int = ParallelConsumerOptions.DEFAULT_MAX_CONCURRENCY,
    val batchSize: Int = 1,
    val ordering: ParallelConsumerOptions.ProcessingOrder = ParallelConsumerOptions.ProcessingOrder.KEY,
    val clientIdPrefix: String = "",
    val clientIdSuffix: String = "",
)

class KafkaParallelStreamProcessorFactory<K, V> {

    fun createParallelStreamProcessor(
        kafkaConsumerFactory: ConsumerFactory<K, V>, // Kafka Consumer를 생성하는 팩토리
        topics: Array<String>, // 구독할 Kafka 토픽 목록
        ordering: ParallelConsumerOptions.ProcessingOrder, // 메시지 처리 순서 설정 (UNORDERED, PARTITION, KEY)
        concurrency: Int, // 병렬로 처리할 최대 동시 실행 개수
        batchSize: Int, // 한 번에 가져올 메시지 배치 크기 (1 이상일 경우 배치 처리)
        groupId: String, // Kafka Consumer Group ID (같은 그룹이면 메시지를 분배하여 처리)
        clientIdPrefix: String, // Kafka Consumer의 Client ID 접두사 (개별 Consumer 식별용)
        clientIdSuffix: String, // Kafka Consumer의 Client ID 접미사 (여러 개의 Consumer 구별용)
    ): ParallelStreamProcessor<K, V> {
        val options: ParallelConsumerOptions<K, V> = ParallelConsumerOptions.builder<K, V>()
            .ordering(ordering)
            .maxConcurrency(concurrency)
            .batchSize(batchSize)
            .consumer(
                kafkaConsumerFactory.createConsumer(
                    groupId.takeIf { it.isNotEmpty() },
                    clientIdPrefix,
                    clientIdSuffix,
                ),
            )
            .build()
        val eosStreamProcessor = ParallelStreamProcessor.createEosStreamProcessor(options)
        eosStreamProcessor.subscribe(topics.toList())
        return eosStreamProcessor
    }
}

@Component
class KafkaParallelStreamProcessor(
    private val kafkaConsumerFactory: ConsumerFactory<String, Any>,
    private val kafkaParallelListenerValidator: KafkaParallelListenerValidator,
) : BeanPostProcessor, DisposableBean {

    private val kafkaParallelConsumerFactory = KafkaParallelStreamProcessorFactory<String, Any>()
    private val consumers = mutableListOf<ParallelStreamProcessor<String, Any>>()

    override fun postProcessAfterInitialization(
        bean: Any,
        beanName: String
    ): Any? {
        bean.javaClass.methods
            .mapNotNull { method -> method.getAnnotation(KafkaParallelListener::class.java)?.let { method to it } }
            .forEach { (method, annotation) -> processKafkaParallelListenerMethod(bean, method, annotation) }
        return bean
    }

    private fun processKafkaParallelListenerMethod(
        bean: Any,
        method: Method,
        kafkaParallelListener: KafkaParallelListener,
    ) {
        kafkaParallelListenerValidator.validate(kafkaParallelListener)

        val processor = with(kafkaParallelListener) {
            kafkaParallelConsumerFactory.createParallelStreamProcessor(
                kafkaConsumerFactory = kafkaConsumerFactory,
                topics = topics,
                ordering = ordering,
                concurrency = concurrency,
                batchSize = batchSize,
                groupId = groupId,
                clientIdPrefix = clientIdPrefix,
                clientIdSuffix = "",
            )
        }
        processor.poll { context: PollContext<String, Any> ->
            try {
                val records = context.consumerRecordsFlattened
                val parameterType = method.parameterTypes.firstOrNull()
                if (parameterType != null && parameterType.isAssignableFrom(List::class.java)) {
                    method.invoke(bean, records)
                    return@poll
                }
                records.forEach { method.invoke(bean, it) }
            } catch (e: Exception) {
                log.error("Error while processing message", e)
            }
        }
        consumers.add(processor)
    }

    override fun destroy() {
        consumers.forEach(ParallelStreamProcessor<String, Any>::close)
    }

    companion object {
        private val log = LoggerFactory.getLogger(this::class.java)
    }
}

전체적인 코드는 https://github.com/Hyung1Jung/kafka-parallel-consumer를 참고해주세요.

Kafka Consumer vs Kafka Parallel Consumer 처리 시간 비교

partition, concurrency 수	kafka consumer	kafka parallel consumer
partition=1, concurrency=2	100s	50s
partition=2, concurrency=2	50s	50s

위의 조건 기반으로 테스트 해본 결과 kafka parallel consumer 경우 파티션을 늘리지 않고도 동시 처리량을 늘릴 수 있는 것을 확인할 수 있습니다.

추가로, parallel consumerd의 경우 partition=1, concurrency=2, partition=2, concurrency=2 의 처리 시간이 동일한 것을 볼 수 있는데요. Parallel Consumer에서 concurrency는 전체적인 병렬 실행 수를 제한하며, 각 파티션별 concurrency를 설정하는 것이 아님을 테스트를 통해 확인할 수 있었습니다.

Case 1) partition=1, concurrency=2

파티션 1개에서 최대 2개 동시 실행

[Thread 1] - Message 1
[Thread 2] - Message 2
(1초 후)
[Thread 1] - Message 3
[Thread 2] - Message 4
...

Case 2) partition=2, concurrency=2

각 파티션이 아닌 전체적 파티션 기준으로 랜덤하게 최대 2개 실행

[Thread 1] - Message 1 (Partition 0)
[Thread 2] - Message 51 (Partition 1)
(1초 후)
[Thread 1] - Message 2 (Partition 1)
[Thread 2] - Message 52 (Partition 1)
(1초 후)
[Thread 1] - Message 3 (Partition 0)
[Thread 2] - Message 53 (Partition 0)
...

Kafka Parallel Consumer는 전체적으로 처리량을 조절하지만, 매번 각 파티션에서 정확히 한 개씩 가져오지는 
않고 파티션마다 번갈아 가며 메시지를 가져옴.

- 파티션 0,1에서 각각 한 개씩 → 기본적인 Fetch 동작 (각 파티션에서 균등하게 메시지를 가져옴)
- 파티션 1에서 두 개 → 특정 Poll 타이밍에 따라 파티션 1에서 먼저 Fetch되는 경우 발생
- 파티션 0에서 두 개 → Kafka가 Offset Commit 상태를 기반으로 특정 파티션을 우선적으로 Poll할 수 있음

즉, Parallel Consumer는 전체 동시 실행 개수를 조절하지만, 특정 시점에서 어떤 파티션이 먼저 가져가는지는 
Kafka의 Poll 타이밍과 Offset Commit 상태에 따라 달라짐

순서 보장이 필요 없는 경우 Kafka Parallel Consumer는 기존 Kafka와 다르게 Partiton을 늘리지 않고 concurrency만 늘림으로써 처리량을 높일 수 있는 것을 확인할 수 있었습니다. 처리량을 높일때 순서 보장이 필요 없다면 굳이 기존 Kafka를 사용하여 파티션을 늘리는 것보단 Parallel Consumer을 사용하여 파티션을 늘리지 않고 인프라 비용 절감, 성능 최적화 등의 이점을 얻는게 좋을 것 같습니다.

Kafka Parallel Consumer Key, Unordered, Partition 동작 방식 및 처리 시간 비교

이번엔 Kafka Parallel Consumer의 순서 보장 방식인 Unordered, Key, Partition의 동작 방식 및 처리 시간을 비교해보았습니다. .

    @PostMapping("/parallel-send")
    fun parallelSend() {
        generateUserMessages().forEach { userMessageProducer.sendParallelMessage(it) }
    }
    
    private fun generateUserMessages() = (1..100).map { index ->
        UserMessage(
            id = index.toLong() // or index.toLong() % 2,
            age = index.toLong(),
            name = "name$index",
        )
    }    
    
    @KafkaParallelListener(
        topics = [PARALLEL_USER_TOPIC],
        groupId = "parallel-user-consumer-group",
        concurrency = 2,
        ordering = ParallelConsumerOptions.ProcessingOrder.UNORDERED // or KEY or PARTITION
    )
    fun listen(
        record: ConsumerRecord<String, String>,
    ) {
        try {
            val message = objectMapper.readValue(record.value(), UserMessage::class.java)
            log.info("[Thread ${Thread.currentThread().id}] Partition ${record.partition()} - Message arrived! - $message")
            Thread.sleep(1000)
        } catch (e: InterruptedException) {
            e.printStackTrace()
            log.info(e.message)
        }
    }

1. Unordered

partition=1, concurrency=2

	처리 개수	처리 순서	처리 시간
Key가 고유한(1~100) message 100개	2개씩	전체 순서 X	50s
Key가 고유하지 않은((1~100)%2) message 100개	2개씩	전체 순서 X, 같은 키 끼리 순서 X	50s

partition=2, concurrency=2

	처리 개수	처리 순서	처리 시간
Key가 고유한(1~100) message 100개	2개씩	전체 순서 X, 파티션내 순서 X,	50s
Key가 고유하지 않은((1~100)%2) message 100개	2개씩	전체 순서 X, 파티션내 순서 X, 같은 키 끼리 순서 X	50s

이유

Unordered는 순서를 보장하지 않는 방식입니다.
Key에 따라 특정 파티션으로 가더라도, 같은 키라도 동시성(concurrency) 때문에 순서가 보장되지 않습니다.
Concurrency가 2이므로 같은 파티션 내에서도 여러 개의 메시지가 동시에 처리될 가능성이 있습니다. → 파티션 내 순서 X.

2. Key

partition=1, concurrency=2

	처리 개수	처리 순서	처리 시간
Key가 고유한(1~100) message 100개	2개씩	전체 순서 X	50s
Key가 고유하지 않은((1~100)%2) message 100개	2개씩	전체 순서 X, 같은 키 끼리 순서 O	50s

partition=2, concurrency=2

	처리 개수	처리 순서	처리 시간
Key가 고유한(1~100) message 100개	2개씩	전체 순서 X, 파티션내 순서 X	50s
Key가 고유하지 않은((1~100)%2) message 100개	2개씩	전체 순서 X, 파티션내 순서 O, 같은 키 끼리 순서 O, 같은 파티션 내 다른 키끼리 순서 X	50s

이유

같은 Key는 같은 파티션으로 가기 때문에 Key별 순서는 보장됩니다.
하지만 파티션 내에서는 concurrency(병렬 처리)로 인해 순서가 보장되지 않을 수도 있습니다.
Key가 고유하면 여러 파티션으로 분산될 가능성이 높아지고, 병렬처리되면서 순서가 꼬일 가능성이 커집니다.

3. Partition

partition=1, concurrency=2

	처리 개수	처리 순서	처리 시간
Key가 고유한(1~100) message 100개	1개씩	전체 순서 O	100s
Key가 고유하지 않은((1~100)%2) message 100개	1개씩	전체 순서 X, 같은 키 끼리 순서 O	100s

partition=2, concurrency=2

	처리 개수	처리 순서	처리 시간
Key가 고유한(1~100) message 100개	2개씩	전체 순서 X, 파티션내 순서 O	50s
Key가 고유하지 않은((1~100)%2) message 100개	2개씩	전체 순서 X, 파티션내 순서 O, 같은 키 끼리 순서 O, 같은 파티션 내 다른 키 끼리 순서 X	50s

이유

Partition 모드는 각 파티션 내에서만 순서를 보장합니다.
파티션이 하나면(Partition=1) 전체 순서가 유지되지만, 여러 개이면 전체 순서는 틀어집니다.
같은 키는 같은 파티션으로 가므로 같은 키 순서는 유지되지만, 파티션 내에서 다른 키가 섞이면 같은 파티션 내에서 순서가 섞일 수 있습니다.

결과 정리 및 주요 차이점

	전체 순서	파티션 내 순서	같은 키 순서	같은 파티션 내 다른 키 순서
Unordered	X	X	X	X
Key	X	O (같은 키)	O	X
Partition	X	O	O	X

Unordered: 완전한 무질서입니다.
Key: 같은 키는 순서 보장되지만, 파티션 내에서 다른 키끼리는 섞일 수 있습니다.
Partition: 파티션 내 순서가 유지되고, 같은 키 순서 보장됩니다.

마치며

파티션을 늘리는 것이 항상 나쁜 것은 아니라고 생각합니다. 트래픽이 적고 기존 파티션이 많지 않다면 1~2개 추가하는 것으로 충분히 해결 가능할 것 같습니다. 하지만, 인프라 비용 최적화가 필요하거나 단일 메시지 처리 속도 개선이 어려운 상황이거나 기존 파티션이 이미 너무 많이 생성된 상황이라면 Parallel Consumer을 고려해볼만 할 것 같습니다.

특히 순서 보장이 필요 없는 경우에는 Parallel Consumer을 사용하여 사전에 인프라 비용을 최적화 하는 것이 좋을 것 같습니다.

Reference

[Kafka] 카프카 메시지 중복 컨슘, 누락이 발생할 수 있는 경우

Hyung1 — Sun, 3 Mar 2024 23:03:43 +0900

카프카를 사용시 consume이 단 한 번만 일어나면 좋겠지만 실제로 그렇지 않은 경우가 종종 있습니다.

consume이 딱 한 번만 일어나지 않으면 어떤 문제가 발생할까요?

consumer가 카프카 브로커로부터 메시지를 가져와서 데이터 처리를 할 텐데, 만일 중복 consume이 발생하면 그 데이터 처리도 중복으로 처리될 수 있습니다.
때로는 consume 누락이 발생할 수도 있습니다. 그럼 데이터 처리도 누락됩니다.

이 문제를 막기 어려운 근본적인 이유는 아래와 같습니다.

commit 시점과 데이터 처리 완료 시점이 완벽하게 일치할 수 없는 경우(그 시간 간극 동안 리밸런싱이 발생할 수도 있음)
offset 관리가 consumer측이 아니라 broker 측에서 이루어지는 경우(_consumer_offsets 토픽)
개발자 자의에 의해 offset reset을 해서 다시 consume할 일이 있는 경우

그럼 누락이 발생하는 경우부터 알아보도록 하겠습니다.

자동커밋(Auto comit) - 누락 발생

* 주기 : auto.commit.interval.ms

fetch 후에

데이터를 처리하는 쪽에서는 101번, 102번 까지 데이터를 처리
commit 103번까지 완료

인 상황에서 Rebalnce가 시작되었다면 컨슈머와 파티션 간의 관계는 끊어지고 다시 새로운 관계를 만들게 됩니다. 그럼 broker의 기록을 기준으로 message consume이 다시 시작되게 됩니다. 이 경우 broker 입장에서는 103번 부터는 데이터 처리가 되었다고 보기 때문에 message consume는 104번부터 다시 fetch 되게 됩니다.

따라서 데이터를 처리하는 쪽에서도 103번 message는 pass하고 104번부터 처리하게 됩니다.

그럼 이제 중복 컨슘이 발생하는 경우를 알아보도록 하곘습니다.

자동커밋(Auto comit) - 중복 발생

fetch 후에

데이터를 처리하는 쪽에서는 102번까지 처리한 상황입니다.

하지만 아직 commit하지 않았는데 갑자기 Rebalnce가 발생하여 broker측에서는 100번까지만 commit된 것으로 기록합니다. 그리고 파티션과 컨슈머의 관계가 재형성됩니다.

이 경우에 브로커는 100번까지만 커밋했으니 101번부터 메시지를 다시 가져가라고 하기 때문에 데이터를 처리하는 쪽에서 101, 102번 데이터를 한 번더 처리하게 됩니다. 이 경우에 중복 컨슘이 발생할 수 있습니다.

수동 커밋도 마찬가지 입니다.

수동커밋(Auto comit) - 중복 발생

수동 커밋은 보통 데이터를 다 처리한 뒤에 커밋하게 됩니다. 하지만 커밋을 하기전에 리밸런싱이 발생하면 자동 커밋처럼 똑같이 중복이 발생할 수도 있습니다. 따라서 수동 커밋은 데이터 처리 타이밍과 커밋 타이밍을 개발자가 원하는 데로 조절할 수 있지만 그 시점을 완전히 일치 시킬 수는 없습니다. 이러한 근본적인 문제는 해결할 수가 없습니다.

결국에는 Rebalncing이 문제

지금까지의 경우를 살펴보았을때 Rebalncing이 문제인 것을 알수가 있습니다. Rebalncing이 자주 발생하면 여러가지 문제가 될 수 있습니다.

Rebalncing이 발생하면 중복 Consume 혹은 Consume 누락 가능성이 발생하는 타이밍이 생깁니다.
심지어, Rebalncing이 발생하는 동안 Consume이 멈추기 때문에 성능상 문제도 발생합니다.

Rebalncing은 언제 생기는건데?

파티션이 추가 되거나 리어사인이 되서 서로 관계를 바꿔야 하는 경우 (broker의 변화)
컨슈머그룹 내 컨슈머가 추가되거나 제거된 경우 (컨슈머 측의 변화)

이 경우 좀 더 유심히 봐야할 건 컨슈머 측의 변화입니다. 컨슈머 측에서 능동적인 변화가 발생한 경우가 아니더라도 컨슈머 측의 변화중에서는 비정상 적인 변화의 경우도 존재합니다.

session.timeout.ms와 heatbeat.interval.ms

heartbeat(consumer이 정상인지 주기적으로 보내는 신호)가 한동안 broker쪽으로 오지 않아서 결국 timeout이 발생하면 broker쪽에서는 consumer 상태 비정상인 것으로 판단합니다.
따라서 보통은 session.timeout.ms 대비 heatbeat.interval.ms을 짧게(3분의 1 정도) 가져갑니다. 이렇게 성정하면 heartbeat를 두 번 정도 보내지 않아도 한 번정도 기회가 남기 때문입니다.

max.poll.interval.ms

consumer쪽에서 poll을 한동한 해가지 않으면 consumer 상태를 비정상으로 판단합니다.
- consumer에서는 매번 건건이 시간이 오래 걸리는 로직을 수행하서는 안됩니다. 안그러면 consumer가 poll을 하지 못해서 max.poll.interval.ms를 넘겨버리고 계속 중단되는 상황이 발생하기 때문입니다.
- 또한 중단되는 경우에 conumser에 lag이 계속 쌓이는 상황도 발생합니다.

정리

사실 consume 중복 및 누락은 consumer만의 입장입니다.

위 그림 및 설명들을 다시 생각해보면 commit 실제로 한 번만 발생합니다. 즉, 단 한번만 레코드를 다루고 있습니다. 결국 comiit을 하는 건 broker 쪽이고 그리고 이것을 consume하는 건 결국 consumer 쪽입니다.

consume 중복 및 누락을 대비하기 위해서는

Rebalncing을 줄일 수 있게 옵션 값을 잘 설정해야 합니다.
자동 커밋으로 설정할지 수동 커밋으로 설정할지는 고려해봐야 합니다.
- 일반적으로 중복이 누락보다는 낫다고 생각합니다. 중복 같은 경우는 해결할 수 있는 여러 대안(redis, outbox pattern 등)들이 존재하지만 유실 같은 경우는 해결할 수 있는 방법이 없습니다. 따라서 유실을 해결할 수 없는 자동 커밋보다는 유실을 사전에 방지하고 중복을 해결할 수 있는 방향인 수동 커밋을 사용하는게 나을 것 같다고 생각합니다. (유실의 경우도 outbox pattern으로 해결 가능할 것 같긴 하네요)
- 하지만 어느 정도의 누락은 별로 상관없을 수도 있습니다. 예를들어 로그 데이터 같은 경우 전체적인 통계에 큰 영향을 미치지 않을 수도 있기 때문입니다.
- 따라서 상황에 따라 적절한 설정이 필요하다고 생각됩니다.

도메인 주도 설계 첫걸음 4장

Hyung1 — Wed, 7 Feb 2024 23:54:37 +0900

컨트랙트

바운디드 컨텍스트 모델은 서로 독립적으로 발전하고 구현될 수 있다. 그러나 바운디드 컨텍스트 자체는 독립적이지 않고 서로 상호작용 해야한다. 결국, 바운디드 컨텍스트 사이에는 항상 접점이 있는데 이것을 컨트랙트라 고 부른다.

왜 상호작용 해야하는데?

비즈니스 프로세스 흐름: 예를 들어, 주문이 생성되고 처리되는 과정에서 고객 관리, 재고 관리, 결제 시스템 등 여러 컨텍스트 간의 상호작용이 필요할 수 있음
데이터 공유: 서로 다른 컨텍스트 간에는 종종 데이터를 공유해야함. 예를 들어, 고객 정보를 처리하는 서비스는 주문 처리 시스템과 고객 정보를 공유해야 할 수 있음.
업무 통합: 여러 바운디드 컨텍스트 간의 상호작용은 업무 통합을 가능하게. 서로 다른 컨텍스트 간에 정보를 교환하고 업무를 조율함으로써 전체 비즈니스 프로세스를 효율적으로 관리할 수 있음.
경계 조정: 서로 다른 바운디드 컨텍스트 간의 상호작용은 컨텍스트 경계를 조정하는 데 도움이됨. 예를 들어, 한 컨텍스트에서 발생한 이벤트가 다른 컨텍스트에 영향을 주는 경우, 이를 통해 경계를 조정하고 업데이트할 수 있음.
시스템 확장성: 바운디드 컨텍스트 간의 상호작용은 시스템의 확장성을 향상시킬 수 있다. 각 컨텍스트가 독립적으로 작동하면서도 필요에 따라 상호작용할 수 있기 때문에 시스템을 쉽게 확장하고 변경할 수 있음.

협력형 패턴 그룹

한 팀의 성공이 다른 팀의 성공에 달려있고, 그 반대도 마찬가지인 의존적 목표가 있는 팀에 해당. 다시 말해, 이 패턴이 적합한 요건은 팀의 커뮤니케이션과 협업 수준에 있음.

파트너십 패턴

바운디드 컨텍스트 간의 연동은 애드훅 방식으로 조정한다. 한 팀은 다른팀에게 API의 변경을 알리고 다른 팀은 충돌없이 이를 받아들인다.
연동의 조정은 양방향에서 한다.
양 팀은 차이점을 함께 해결하고 가장 적절한 솔루션을 찾기위해 협력하고 선정한다.

장점	단점
양방향 조장이 필요하지만 어느 정도는 독립적	팀 간의 잦은 동기화가 필수

주의 사항

커뮤니케이션의 어려움으로 인해 지리적으로 떨어져 있는 팀에게는 적합하지 않을 수 있음

공유 커널 패턴

바운디드 컨텍스트가 모델의 경계임에도 불구하고, 하위 도메인의 동일 모델이 여러 바운디드 컨텍스트에서 구현되는 경우
공유 커널(Shared Kernel)과 같은 공유 모델은 모든 바운디드 컨텍스트의 필요에 따라 설계된다.
권한 모델은 각 바운디드 컨텍스트에서 수정할 수 있고 이 변경은 다른 바운디드 컨텍스트에 영향을 준다.

장점	단점
지리적인 제약이나 조직의 정치적 문제로 커뮤니케이션 또는 협업이 어려워서 파트너십 패턴을 구현하기 어려운 경우에 대안 고려할 수 있음	겹치는 형태의 모델은 해당되는 바운디드 컨텍스트의 수명주기도 서로 엮이게 한다. 공유 모델의 변경은 바운디드 컨텍스트에 즉시 영향을 준다.
레거시 시스템을 점진적으로 현대화할 경우에 시스템을 서서히 바운디드 컨텍스트로 분해해서 공유 코드베이스로 만드는 것이 실용적인 중간 솔루션	어떤 방식이든 공유 커널에 대 한 변경이 생길 때마다 영향을 받는 모든 바운디드 컨텍스트와 연동 테스트(통합)를 수행해야 한다.
바운디드 컨텍스트의 연동 컨트랙트를 명시적으로 정의할 수 있음	공유 커널은 소스코드의 모든 변경이 즉시 연동되도록 구현해야함. 이를 지키지 않으면 모델의 일관성이 깨질 수 있음

주의 사항

변경의 연쇄 영향을 최소화하기 위해 양쪽의 겹치는 모델을 제한해서 바운디드 컨텍스트에서 공통으로 구현돼야 하는 모델의 일부분만 노출하도록 해야함.
공유 커널은 여러 바운디드 컨텍스트에 속하기 때문에 변경은 지속적으로 통합
중복 비용이 조율 비용보다 클 경우에 고려

사용자-제공자 패턴 그룹

제공자는 사용자에게 서비스를 제공한다.
서비스 제공자는 ‘업스트림(upsteam)’이고, 고객 또는 사용자는 ‘다운스트림(downstream)’이다.
업스트림과 다운스트림은 서로 독립적으로 성장할 수 있지만 연동 컨트랙트를 주도하는 권력의 불균형이 존재한다.

순응주의자 패턴

다운스트림 팀이 업스트림 팀의 모델을 받아들이는 바운디드 컨텍스트의 관계
제공자의 모델에 따라 정의된 연동 컨트랙트를 제공할 뿐이므로 사용자의 선택지는 이를 받아들이거나 떠나거나 둘 중 하나다.

업스트림이 노출한 컨트랙트가 산업 표준이거나 잘 구축된 모델 또는 다운스트림의 요건에 충분하다면 다운스트림이 팀의 자율성의 일부를 포기하는 결정은 정당화 될 수 있다.

충돌 방지 계층 패턴

힘의 균형이 업스트림에 치우쳐 있을 때 다운스트림 바운디드 컨텍스트가 업스트림에 순응하지 않을 경우 충돌 방지 계층을 통해 업스트림의 모델을 스스로에 맞게 가공할 수 있다.

충돌 방지 계층(ACL: anticorruption layer) 패턴은 다음 사례와 같이 제공자의 모델을 따르는 것을 원치 않거나 순응에 필요한 노력이 가치가 없을 경우를 다룬다.

조건	설명
다운스트림 바운디드 컨텍스트가 핵심 하위 도메인을 포함할 경우	핵심 하위 도메인은 각별한 주의가 필요하다. 제공자의 모델이 자칫 문제 도메인에 대한 모델링을 방해할 수 있다.
업스트림 모델이 사용자의 요건에 비효율적이거나 불편한 경우	바운디드 컨텍스트가 혼란에 순응하면 그 자체로 위험에 빠지게 된다. 이런 경우는 레거시 시스템과 연동할 때 종종 발생한다.
제공자가 컨트랙트를 자주 변경하는 경우	사용자는 잦은 변경으로부터 모델을 보호하기를 원한다.

오픈 호스트 서비스 패턴

오픈 호스트 서비스(OHS, Open-Host Service) 패턴은 충돌 방지 계층 패턴의 반대로 사용자 대신 제공자가 내부 모델 번역을 구현한다.
이 패턴은 제공자는 사용자를 보호하는 데 관심이 있고 힘의 균형이 사용자 측에 치우쳐 있다.
구현 모델의 변경으로부터 사용자를 보호하기 위해 퍼블릭 모델과 내부 구현 모델을 분리한다.

제공자의 퍼블린 인터페이스는 연동 지향 언어를 통해 사용자에게 더 편리한 프로토콜을 노출 시킨다. 이런 퍼블릭 프로토콜을 공표된 언어(published language)라고 한다.
오픈 호스트 서비스 패턴은 충돌 방지 계층 패턴의 반대다. 사용자 대신 제공자가 내부 모델 번역을 구현한다.
구현 모델과 연동 모델을 분리하면 업스트림 바운디드 컨텍스트는 다운스트림 컨텍스트에 영향을 주지 않으면서 자신의 구현을 자유롭게 발전시킬 수 있다.

또한 연동 모델을 분리하면 업스트림 바운디드 컨텍스트는 이미 공표된 언어의 여러 버전을 동 시에 노출할 수 있어서 사용자가 점진적으로 새로운 버전으로 이관할 수 있게 한다

분리형 노선

분리형 노선(Separated Ways) 패턴은 전혀 협력하지 않는 것이다.

커뮤니케이션 이슈
일반 하위 도메인
- 일반 하위 도메인이 일반 솔루션과 연동하는 것이 쉽다면 각 바운디드 컨텍스트 내에서 각자 연동하는 것이 더 효과적일 수 있다.
- 예를 들어 로깅 프레임워크처럼 기능 중복이 없을 경우보다 솔루션을 연동했을 때 복잡성이 커진다면 이를 서비스로 노출하는 것은 바람직하지 않다.
모델의 차이
- 모델이 너무 달라서 순응주의자 관계가 불가능하고, 충돌 방지 계층을 구현하는 것도 기능 중복보다 효과적이지 않을 수 있다. 이런 경우에는 팀이 각자의 길을 가는 것이 더 비용 효과적이다.

결론

바운디드 컨텍스트는 독립적이지 않고 서로 상호작용 해야 한다.

파트너십	바운디드 컨텍스트는 애드혹 방식으로 연동된다.
공유 커널	두 개 이상의 바운디드 컨텍스트가 참여하는 모든 바운디드 컨텍스트가 공유하는 제한적으로 겹치는 모델을 공유해서 연동한다.
순응주의자	사용자는 서비스 제공자의 모델에 순응한다.
충돌 방지 계층	사용자는 서비스 제공자의 모델을 사용자의 요건에 맞게 번역한다.
오픈 호스트 서비스	서비스 제공자는 사용자의 요건에 최적화된 모델인 공표된 언어를 구현한다.
분리형 노선	협력과 연동보다 특정 기능을 중복으로 두는 것이 더 저렴한 경우다.

[DB] reWriteBatchedInserts, rewriteBatchedStatements

Hyung1 — Wed, 7 Feb 2024 23:42:44 +0900

reWriteBatchedInserts은 MySql 전용 옵션입니다. 사실 PostgreSql에서도 동일하게 사용되는 것으로 착각하고 있었으나 PostgreSql에서는 reWriteBatchedInserts가 아닌 rewriteBatchedStatements 사용하는게 맞습니다.

mySql	postgreSql
reWriteBatchedInserts	rewriteBatchedStatements

그럼 reWriteBatchedInserts, rewriteBatchedStatements은 무엇일까요?

- 주말에 작성하기

ColpletableFuture

Hyung1 — Sat, 20 Jan 2024 20:13:59 +0900

ColpletableFuture

2014년에 발표된 java8에소 처음 도입
비동기 프로그래밍 지원
Lambda, Metho reference 등 java 8의 새로운 기능 지원

Method reference

:: 연산자를 이용해서 함수에 대한 참조를 간결하게 표현
method reference
statuc method reference
instance method reference
constructor method reference

ColpletableFuture 클래스

CompletableFuture
Future	CompletionStage
비동기적인 작업을 수행	비동기적인 작업을 수행
해당 작업이 오한료되면 결과를 반환하는 인터페이스	해당 작업이 완료되면 결과를 처리하거나 다른 CmpletionStage를 연결하는 인터페이스

Future 인터페이스

Executor Service

쓰레드 풀을 이용하여 비동기적으로 작업을 실행하고 관리
별도의 쓰레드를 생성하고 관리하지 않아도 되므로, 코드를 간결하게 유지 가능
쓰레드 풀을 이용하여 자원을 효율적으로 관리

ExecutorService Method

excute: Runnalbe 인터페이스를 구현한 작업을 쓰레드 풀에서 비동기적으로 실행
submit: Callable 인터페이스를 구현한 적업을 쓰레드 풀에서 비동기적으로 실행하고, 해당 작업의 결과를 Future<T> 객체로 반환
shutdown: ExecutorService를 종료. 더 이상 task를 받지 않는다.

Excutors - ExecutorService 생성

newSungleThreadExectutor: 단일 스레드로 구성된 스레드 풀을 생성. 한 번에 하나의 작업만 실행
newFixedThreadPool: 고정된 크기의 쓰레드 풀을 생성. 크기는 인자로 주어진 n과 동일
newCachedThreadPool: 사용 가능한 쓰레드가 없다면 새로 생성해서 작업을 처리하고, 있다면 재사용. 쓰레드가 일정시간 사용되지 않으면 회수
newScheduledThreadPool: 스케줄링 기능을 갖춘 고정 크기의 쓰레드 풀을 생성. 주기적이거나 지연이 발생하는 작업을 실행
newWorkStealngPool: work steal 알고리즘을 사용하는 ForkJoinPool을 생성.

FutureHelper

getFuture: 새로운 쓰레드를 생성하여 1을 반환
getFutureCompleteAfter1S : 새로운 쓰레드를 생성하고 1초 대기 후 1을 반환

Future: isDone(), isCancelled()

future의 상태를 반환
isDone: task가 완료되었다면, 원인과 상관없이 true 반환
isCancelled: task가 명시적으로 취소된 경우 true 반환

Future: get()

결과를 구할 때까지 thread가 계속 block
future에서 무한 루프나 오랜 시간이 걸린다면 thread가 blocking 상태 유지

Future: get(long timeout, Timeunit unit)

결과를 구할 때까지 timeout동안 thread가 block
timeout이 넘어가도 응답이 반환되지 않으면 TimeoutException 발생

Future: cancel(boolean mayInterruptIfRunning)

future의 작업 실행을 취소
취소할 수 없는 상황이라면 false를 반환
mayInterruptIfRunning가 false라면 시작하지 않은 작업에 대해서만 취소

Future 인터페이스의 한계

cancel을 제외하고 외부에서 future를 컨트롤 할 수 없다.
반환된 결과를 get()해서 접근하기 때문에 비동기 처리가 어렵다.

완료되거나 에러가 발생했는지 구분하기 어렵다.

CompletionStage 인터페이스

CompletionStage 연산자 조합

50개에 가까운 연산자들을 활용하여 비동기 task들을 실행하고 값을 변경하는 등 chaining을 이용한 조합 가능
에러를 처리하기 위한 콜백 제공

ForkJoinPool - thread pool

CompleteableFuture는 내부적으로 비동기 함수들을 실행하기 위해 ForkJoinPoll을 사용
ForkJoinPool의 기본 size = 할당된 cpu 코어 -1
데몬 쓰레드. main 쓰레드가 종료되면 즉각적으로 종료

ForkJoinPool - fork & join

task를 for를 통해서 subtask로 나누고
thread pool에서 steal work 알고리즘을 이용해서 균등하게 처리해서
join을 통해서 결과를 생성

CompletionStage 연산자

함수형 프로그래밍을 지원하기 위해 java8부터 도입

1개의 추상 메서드를 갖고 있는 인터페이스
함수를 1급 객체로 사용할 수 있다
- 함수를 변수에 할당하거나 인자로 전달하고 반환값으로 사용 가능
Function, Consumer, Supplier, Runnable등
함수형 인터페이스를 구현한 익명 클래스 람다식으로 변환 가능

CompletionStage 연산자와 연결

consumer - accept method -> thenAccept(Coinsumer action)
Function - apply method -> thenApplu(Function fn)
Function - compose method ( abstract method X) -> thenCompose(Function fn)
Runnable - run method -> thenRun(Runnable action)

thenAccept[Async]

Consumer를 파라미터로 받는다.
이전 task로부터 값을 받지만 값을 넘기지는 않는다.
다음 task에게 null이 전달된다.
값을 받아서 action만 수행하는 경우 유용

Helper

finishedStage: 1을 반환하는 완료된 CompletableFuture 반환
runningStage: 1초를 sleep한 후 1을 반환하는 completableFuture

thenAccept[Async]의 실행 스레드

done 상태가 아닌 thenAccept는 callee(forkJoinPoll)의 쓰레드에서 실행
done 상태가 아닌 completionStage에 thenAccept를 사용하는 경우, callee를 block 할 수 있다.

thenAccept vs thenAcceptAsync

.. 작성중

I/O 관점에서 Blocking/Non-blocking

Hyung1 — Sat, 20 Jan 2024 19:44:11 +0900

공부한 것 기록하기..

Blocking의 종류

blocking은 thread가 오랜 시간 일을 하거나 대기하는 경우 발생
CPU-bound blocking: 오랜 시간 일을 한다.
IO-bound blocking: 오랜 시간 대기한다.

CPU-bound blocking

thread가 대부분의 시간 CPU 점유
연산이 많은 경우
추가적인 코어를 투입

IO-bound blocking

thread가 대부분의 시간을 대기
파일 일기/쓰기, netowrk 요청 처리, 요청 전달 등
IO-bound non-blocing 가능하다.

Blocking의 전파

하나의 함수에서 여러 함수를 호출하기도 하고, 함수 호출은 중첩적으로 발생
callee는 caller가 되고 다시 다른 callee를 호출
blocking한 함수를 하나라도 호출한다면 caller는 blocking이 된다.

함수가 non-blocking하려면 모든 함수가 non-blockingdldjdi gksek.
따라서 I/O bound blocking 또한 발생하면 안된다.

두 I/O 모델의 공통점과 차이점

Application이 Kernel 결과에 관심이 있다.
Application의 Kernel로 부터 받은 결과를 이용해서 다음 작업을 수행한다.
caller는 callee의 결과에 관심이 있다 -> 동기

A 모델	B 모델
Kernel이 응답을 돌려주기 전까지 Application은 아무것도 하지 않는다.	Kernel이 응답을 돌려주기 전에 Application은 다른 일을 수행한다.
caller는 Callee가 완료될때까지 대기 -> Blocking	caller는 callee를 기다리지 않고 본인의 일을 한다 -> Non-blocking

동기 Blocing I/O	동기 Non-blocking I/O
recvfrom을 호출	recvfrom을 주기적으로 호출
blocking socket을 이용해서 read/writer을 수행	non-blocking socket을 이용해서 read/write 수행
쓰레드가 block 된다.(wait queue에서 기다린다)	작업이 완료되지 않았다면 EAGAIN/EWOULDBLOCK 에러 반환

두 I/O 모델의 공통점

kernel이 Application의 실행을 막지 않는다.
caller는 callee를 기다리지 않고 본인의 일을 한다 -> Non-blocking

B 모델	C 모델
Application은 Kernel의 결과에 관심이 있다.	Thread1은 Kernel의 결과에 관심이 없다.
결과를 이용해서 액션을 수행한다.	Kernel은 작업을 완료 후 Thread2에게 결과를 전달한다.
caller는 callee의 결과의 감시이 있다 -> 동기	caller는 callee의 결과에 관심이 없다 -> 비동기

동기 Non-blocking I/O	비동기 Non-blocking I/O
recvfrom을 주기적으로 호출	aio_read를 호출
non-blocking socker를 이용해서 read/write 수행	작업이 완료되면 커널이 완료 시그널을 보내거나 callback을 호출
작업이 완료되지 않았다면 EAGAIN/EWOULDBLOCK 에러 반환

I/O 모델

	동기	비동기
Blocking	Application은 Kernel가 I/O 작업을 완료할 때까지 기다린다. 그 후 결과를 직접 이용해서 이후 본인의 일을 수행한다.	X
Non-blocking	Application은 Kerenl에 주기적으로 I/O 작업이 완료되었는지 확인한다. 중간중간 본인의 일을 할 수 있고 작업이 완료되면 그때 본인의 일을 수행한다.	Application은 Kernel에 I/O 작업 요청을 보내고 본인의 일을 한다.작업이 완료되면 Kernel은 signal을 보내거나 callback를 호출한다.

함수 호출 관점에서 동기/비동기, Blocking/Non-blocking

Hyung1 — Sat, 20 Jan 2024 19:16:57 +0900

공부한 것 기록하기

함수 호출 관점에서 동기와 비동기

함수형 인터페이스

함수형 프로그래밍을 지원하기 위해 java8 부터 도입
1개의 추상메서드를 갖고 있는 인터페이스
함수를 1급 객체로 사용할 수 있다.
- 함수를 변수에 할당하거나 인자로 전달하고 반환값으로 사용 가능
Function, Consumer, Suppier, Runnable등
함수형 인터페이스를 구현한 익명 클래스를 람다식으로 변경 가능

함수형 인터페이스는 호출한 쓰레드에서 실행된다.

두 모델의 차이점

A 모델	B 모델
main는 getResult의 결과에 관심이 있다.	main은 getResult의 결과에 관심이 없다.
main은 결과를 이용해서 다음 코드를 실행한다.	getResult는 결과를 이용해서 함수형 인터페이스를 실행한다.

동기	비동기
caller는 callee의 결과에 관심이 있다.	caller는 callee의 결과에 관심이 없다.
caller는 결과를 이용해서 action을 수행한다.	callee는 결과를 이용해서 callback를 수행한다.

함수 호출 관점에서 Blocking과 Non-blocking

두 모델의 공통점

A 모델	B 모델
main는 getResult가 결과를 돌려주기 전까지 아무것도 할 수 없다.	main은 getResult가 결과를 구하고 callback을 실행하기 전까지 아무것도 할 수 없다.
main은 getResult가 완료될때까지 대기한다.	main은 getResult가 완료될 때까지 대기한다.

Blocking

callee를 호출한 후, callee가 완료되기 전까지 caller가 아무것도 할 수 없다.
제어권을 callee가 가지고 있다.

두 모델의 차이점

A 모델	C 모델
getResult를 호출한 후, getResult가 완료되지 않으면 main은 본인의 일을 할 수가 없다.	getResult를 호출한 후, getResult가 완료되지 않더라도 main은 본인의 일을 할 수 있다.

Non-Blocking

caller를 호출한 후, callee가 완료되지 않더라도 caller은 본인의 일을 할 수 있다.
제어권을 caller가 가지고 있다.

Blocking vs Non-blocking

Bloking	Non-blocking
caller는 callee가 완료될때까지 대기한다.	caller는 callee를 기다리지 않고 본인의 일을 한다.
제어권을 caller가 가지고 있다.	제어권을 caller가 가지고 있다.
caller와 다른 별도의 thread가 필요하지 않다.(혹은 thread를 추가로 쓸 수도 있다)	caller와 다른 별도의 thread가 필요하다.

D 모델

main은 getResult의 결과에 관심이 없다.
- 비동기이다.
getResult를 호출한 후, getResult가 완료되지 않더라도 main은 본인의 일을 할 수 있다.
- non-blocking이다.
즉, D 모델은 비동기 non-blocking이다.

동기 Blocking vs 비동기 Blocking

함수 호출 모델

	동기	비동기
Blocking	caller는 아무 것도 할 수 없는 상태가 된다. 결과를 얻은 후 직접 처리한다.	caller는 아무것도 할 수 없는 상태가 된다. 결과는 callee가 처리한다.
Non-blocking	caller는 자기 할 일을 할 수 있다, 결과를 얻은 후 직접 처리한다.	caller는 자기 할 일을 할 수 있다. 결과는 callee가 처리한다.

인생을 코딩하다.

ThreadPool과 Virtual Thread의 성능 및 메모리 사용 비교

목차

1. 배경

2. 테스트 환경

2-1. 서버 구성

2-2. Configuration 설정

2-2. 테스트 시나리오

3. 테스트 결과

3-1. 그럼 어떻게 해결할 수 있을까요?

3-2. 매트릭 지표 확인

3-2-1. Thread

3-2-2. CPU Usage

3-2-3. JVM Heap

3-2-4. NativeMemory

3-2-5. Duration

4. 마치며..

Jackson 2 vs Jackson 3 성능 비교 실험기

목차

1. 실험을 하게 된 배경

2. 왜 JMH를 사용했는가

3. 테스트 환경

3-1. 실행 환경

3-2. JVM 선택

3-3. 소스코드

3-4. 힙 메모리를 고정한 이유

JVM 힙 확장/축소로 인한 노이즈 제거

serialize / deserialize 자체 비용만 보고 싶었기 때문

3-5. 왜 Fork를 사용했는가 (Fork = 2)

3-6. Warmup을 왜 이렇게 설정했는가

Warmup의 의미

왜 3초 × 3회인가

3-7. Measurement 설정 의도

“3초 동안 실행”의 의미

iterations = 5

3-8. Throughput + AverageTime를 동시에 측정한 이유

3-9. 코드 설계 의도

State와 Setup

Small DTO

Big DTO

4. 결과 요약 및 해석

5. 정리

6. 왜 Jackson3이 더 빠를까?

6-1. UnrolledBeanSerializer (반복문 + 배열 접근 제거)

문제점

개선 구조 (Jackson 3 – UnrolledBeanSerializer)

개선 효과

6-2. 직렬화 사전 결정

매 호출마다 발생하는 작업

개선 구조 - 생성 시점에 한 번만 결정(Jackson 3)

6-3. 요약

[Kafka] 파티션이 증가할수록 commit_offset log file 리소스도 증가할까?

파티션이 증가할수록 commit_offset log file 리소스도 증가할까?

실험 결과

Reference

[Kafka] Kafka에서 파티션 증가 없이 동시 처리량을 늘리는 방법 - Parallel Consumer

개요

Parallel Consumer의 주요 특징

조건

Kafka Consumer vs Kafka Parallel Consumer 처리 시간 비교

Case 1) partition=1, concurrency=2

Case 2) partition=2, concurrency=2

Kafka Parallel Consumer Key, Unordered, Partition 동작 방식 및 처리 시간 비교

1. Unordered

2. Key

3. Partition

결과 정리 및 주요 차이점

마치며

Reference

[Kafka] 카프카 메시지 중복 컨슘, 누락이 발생할 수 있는 경우

consume이 딱 한 번만 일어나지 않으면 어떤 문제가 발생할까요?

자동커밋(Auto comit) - 누락 발생

자동커밋(Auto comit) - 중복 발생

수동커밋(Auto comit) - 중복 발생

결국에는 Rebalncing이 문제

Rebalncing은 언제 생기는건데?

정리

도메인 주도 설계 첫걸음 4장

컨트랙트

협력형 패턴 그룹