<Spring> Webflux + Coroutine + MDC

📌 MDC란?

Mapped Diagnostic Context의 약자로,

로깅 시스템에서 사용자의 요청이나 특정 실행 경로를 추적하는 데 사용되는 도구이다.

다중 스레드 상황에서 요청 간 구분을 위해 주로 사용한다.

Java의 로거인 SLF4J가 이를 내부적으로 지원해 준다.

 

📌 Webflux와 MDC

MDC는 보통 스레드 로컬을 사용한다.

하지만 어떤 스레드에서 작업을 진행할지 확신할 수 없는 Webflux의 특성상 스레드 로컬 사용이 어렵다.

이에 MVC와 다른 방법을 사용해야 했다.

 

아래 로직을 구현하는데, 아래 블로그를 많이 참고했다.

배달의민족 최전방 시스템! ‘가게노출 시스템’을 소개합니다. | 우아한형제들 기술블로그

 

🔵 MDC 설정

Webflux에서 요청이 전달되는 과정을 보았을 때, 이런 과정을 거쳐서 흘러가게 된다.

요청이 들어왔을 때, 요청에 대한 TraceId 값을 MDC에 넣어줘야 하는데,

이 과정을 WebFilter를 통해 처리했다.

@Component
@Order(Ordered.HIGHEST_PRECEDENCE)
class MdcLoggingFilter : WebFilter {
    override fun filter(exchange: ServerWebExchange, chain: WebFilterChain): Mono<Void> {
        return chain.filter(exchange)
            .contextWrite { it.createPutWithMDC("traceId", UUID.randomUUID().toString()) }
    }
}

Webflux는 Filter가 아니라 WebFilter를 사용한다.

이 필터에서 Context와 MDC에 값을 넣어주는 작업을 수행했다.

아래는 위 작업에 대한 코드이다

private fun Context.toMap(): Map<String, String> = this.stream()
    .map { ctx -> ctx.key.toString() to ctx.value.toString() }
    .toList().toMap()

fun Context.createPutWithMDC(key: String, value: String): Context {
    val mapOfContext = this.stream()
        .map { ctx -> ctx.key to ctx.value }
        .toList().toMap().toMutableMap()
    mapOfContext[key] = value
    MDC.put(key, value)
    return Context.of(mapOfContext)
}

위 과정을 통해 TraceId를 MDC, Context에 넣어줬다.

 

🔵 스레드 간 전파

위에서 언급한 것처럼, WebFlux는 작업이 한 스레드에서 진행된다는 보장을 할 수 없다.

작업 중 스레드 전환이 발생할 수 있다.

이 상황에서도 TraceId가 보존되어야 한다.

이를 위해, 위에서 언급한 블로그에서 본 코드를 사용했다.

하나하나 알아보자

/**
 * @link https://www.novatec-gmbh.de/en/blog/how-can-the-mdc-context-be-used-in-the-reactive-spring-applications/
 */
@Configuration
class MdcContextLifterConfiguration {
    companion object {
        val MDC_CONTEXT_REACTOR_KEY: String = MdcContextLifterConfiguration::class.java.name
    }

    @PostConstruct
    fun contextOperatorHook() {
        Hooks.onEachOperator(
            MDC_CONTEXT_REACTOR_KEY,
            Operators.lift { _, subscriber ->
                MdcContextLifter<Any?>(subscriber)
            }
        )
    }

    @PreDestroy
    fun cleanupHook() {
        Hooks.resetOnEachOperator(MDC_CONTEXT_REACTOR_KEY)
    }
}

위 코드를 통해 Mono/Flux로 생성된 operator에 대하여 적용할 Publisher 대해 커스텀한다.

기본 subscriber를 MdcContextLifter로 wrapping 하도록 한다.

/**
 * Helper that copies the state of Reactor [Context] to MDC on the #onNext function.
 */
class MdcContextLifter<T>(
    private val coreSubscriber: CoreSubscriber<T>,
) : CoreSubscriber<T> {
    override fun onSubscribe(subscription: Subscription) {
        coreSubscriber.onSubscribe(subscription)
    }

    override fun onNext(t: T) {
        coreSubscriber.currentContext().copyToMdc()
        coreSubscriber.onNext(t)
    }

    override fun onError(throwable: Throwable) {
        coreSubscriber.onError(throwable)
    }

    override fun onComplete() {
        coreSubscriber.onComplete()
    }

    override fun currentContext(): Context {
        return coreSubscriber.currentContext()
    }
}

기존 subscriber와 다른 점은 onNext에 MDC 값을 넣어주는 로직을 추가한 것이다.

reactor가 비동기적으로 데이터 스트림을 처리하며 스레드 전환이 발생할 수 있기 때문에, onNext에 로직을 추가했다.

이 로직을 추가함으로써 onNext 마다 Context의 내용을 MDC로 덮어쓰도록 하여, 로깅에 필요한 메타데이터를 스레드마다 유지할 수 있게 된다.

덮어쓰는 로직은 다음 코드에 나와있다.

fun Context.copyToMdc() {
    if (!this.isEmpty) {
        val map = this.toMap()
        MDC.setContextMap(map)
    } else {
        MDC.clear()
    }
}

private fun Context.toMap(): Map<String, String> = this.stream()
    .map { ctx -> ctx.key.toString() to ctx.value.toString() }
    .toList().toMap()

 

📌 Coroutine과 MDC

🔵 Coroutine에 MDC 적용

Coroutine의 특성상, 현재 진행하는 Coroutine이 중지 후 재개될 때 어떤 스레드에서 작동할지 모른다.

이에 MDC에 값을 넣어두면, 다음 작업 재개 시점에 이 값이 사라져 있는 것을 볼 수 있다.

Coroutine에는 MDC를 지원하기 위해, MDCContext가 존재한다.

MDCContext는 CoroutineContext를 위한 MDC context 요소이다.

 

Coroutine을 사용할 때, MDCContext를 통해 기존 MDC에 존재하던 요소들을 복사하여 코루틴 스코프를 만들 수 있도록 했다.

아래는 해당 로직을 구현한 커스텀 Coroutine 생성 관련 함수이다.

suspend fun <T> withMDCContext(
    context: CoroutineContext = Dispatchers.IO,
    block: suspend () -> T,
): T {
    val contextMap = MDC.getCopyOfContextMap() ?: emptyMap()
    return withContext(context + MDCContext(contextMap)) { block() }
}

fun mdcCoroutineScope(context: CoroutineContext, traceId: String): CoroutineScope {
    val contextMap = MDC.getCopyOfContextMap() ?: emptyMap()
    contextMap.plus("traceId" to traceId)
    return CoroutineScope(context + MDCContext(contextMap))
}

 

🔵 Reactor와 Coroutine

Reactor에서의 MDC 값 전파, Coroutine에서의 MDC 값 전파에 대해 알아보았다.

그런데 이 둘을 같이 사용할 경우엔, 어떻게 값이 전달되는가?

이는 아래 코드를 확인해 보면 된다.

// 여기부터 시작
public fun <T> mono(
    context: CoroutineContext = EmptyCoroutineContext,
    block: suspend CoroutineScope.() -> T?
): Mono<T> {
    require(context[Job] === null) { "Mono context cannot contain job in it." +
            "Its lifecycle should be managed via Disposable handle. Had $context" }
    return monoInternal(GlobalScope, context, block)
}

private fun <T> monoInternal(
    scope: CoroutineScope, // support for legacy mono in scope
    context: CoroutineContext,
    block: suspend CoroutineScope.() -> T?
): Mono<T> = Mono.create { sink ->
    val reactorContext = context.extendReactorContext(sink.currentContext())
    val newContext = scope.newCoroutineContext(context + reactorContext)
    val coroutine = MonoCoroutine(newContext, sink)
    sink.onDispose(coroutine)
    coroutine.start(CoroutineStart.DEFAULT, coroutine, block)
}

internal fun CoroutineContext.extendReactorContext(extensions: ContextView): CoroutineContext =
    (this[ReactorContext]?.context?.putAll(extensions) ?: extensions).asCoroutineContext()

Webflux에서 Coroutine으로 넘어가는 부분에서 위 코드들이 동작한다.

코드의 흐름을 따라가 보면, ReactorContext가 CoroutineContext로 전환되는 부분이 있다.

이처럼 ReactorContext 내부적으로 MDC 값을 가지고 있다면, 코루틴으로 그대로 전달된다.

별다른 작업이 필요 없다는 것이다.

 

* Webflux에서 Coroutine으로 전환되는 자세한 내용은 아래 글을 참고해 주세요

[Backend] - SUSU의 Coroutine

 

하지만 여기서 의문이 있다.

MDC에 값을 넣어주는 부분이 없다.

그런데 컨트롤러에서 찍힌 로그에는 TraceId가 잘 나온다.

이는 Coroutine Context에 대한 설정이 없으면, 기본적으로 Dispatcher.Unconfined로 작동하기 때문이다.

아래 코드를 보자

if (isSuspendingFunction) {
    Object coroutineContext = exchange.getAttribute(COROUTINE_CONTEXT_ATTRIBUTE);
    if (coroutineContext == null) {
        return CoroutinesUtils.invokeSuspendingFunction(method, target, args);
    }
    else {
        return CoroutinesUtils.invokeSuspendingFunction((CoroutineContext) coroutineContext, method, target, args);
    }
}

 

설정된 값이 없으면 위로 진행하게 되는데,

public static Publisher<?> invokeSuspendingFunction(Method method, Object target, @Nullable Object... args) {
    return invokeSuspendingFunction(Dispatchers.getUnconfined(), method, target, args);
}

이 함수를 보면 Dispatcher.Unconfined를 기본적으로 사용하게 된다.

 

즉, 같은 스레드에서 코루틴이 실행된다는 것이고, 이는 스레드 로컬 값을 그대로 들고 온다는 말로 이어진다.

그러므로 별다른 작업 없이 MDC 값을 사용할 수 있는 것이다.

 

위와 같이 다른 Dispatcher로의 변경이 없다면, MDC 관련 로직이 추가될 필요 없을 것이다.

하지만 Dispatcher를 바꾸게 된다면, 추가적인 로직이 필요할 것 같다.

 

📌 MDC Logging

MDC을 로깅에 사용하는 것은 어렵지 않다.

%X{값 이름} 형식으로 패턴에 적어주면 MDC 값이 출력된다.

 

<property name="STDOUT_LOG_PATTERN"
              value="%clr(%d{${LOG_DATEFORMAT_PATTERN:-yyyy-MM-dd'T'HH:mm:ss.SSS}}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) [%25.25thread] %clr([traceId=%X{traceId}]){faint} %clr(---){faint} %clr(${LOG_CORRELATION_PATTERN:-}){faint}%clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}"/>

<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
        <pattern>${STDOUT_LOG_PATTERN}</pattern>
    </encoder>
</appender>

<springProfile name="default, dev">
    <root level="${logLevel}">
        <appender-ref ref="STDOUT"/>
    </root>
</springProfile>

SUSU 서비스에서는 MDC 값을 로그에 표시하기 위해 커스텀 로그 패턴을 사용한다.

STDOUT_LOG_PATTER 이 커스텀 로그 패턴이다

org/springframework/boot/logging/logback/defaults.xml 에 위치하는 CONSOLE_LOG_PATTERN에서 조금 변형한 구조이다.

 

위를 이용하여 로직을 출력하면 아래와 같이 출력된다.

 

📌 마무리

하지만 아직도 미흡한 부분이 남아있다.

2024-05-10T23:35:11.682 DEBUG [       reactor-http-nio-5] [traceId=] --- o.s.w.s.adapter.HttpWebHandlerAdapter    : [c0d73824-2] HTTP GET "/api/v1/users/my-info"
2024-05-10T23:35:11.704 DEBUG [efaultDispatcher-worker-6] [traceId=7618fd85-b1e1-4b62-a968-34d944a9ee7c] --- o.s.orm.jpa.JpaTransactionManager        : Creating new transaction with name [com.oksusu.susu.api.log.application.SystemActionLogService.record]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT

... 생략

2024-05-10T23:35:11.847 DEBUG [efaultDispatcher-worker-6] [traceId=7618fd85-b1e1-4b62-a968-34d944a9ee7c] --- o.s.orm.jpa.JpaTransactionManager        : Closing JPA EntityManager [SessionImpl(921624389<open>)] after transaction
2024-05-10T23:35:11.853 DEBUG [       reactor-http-nio-5] [traceId=7618fd85-b1e1-4b62-a968-34d944a9ee7c] --- o.s.w.s.adapter.HttpWebHandlerAdapter    : [c0d73824-2] Completed 200 OK

맨 첫 줄에 traceId가 안 찍힌다.

이유는 간단하다.

필터보다 앞에서 로그를 남기기 때문이다.

requestId가 로그에 남기 때문에, 어떤 요청인지 식별은 가능하다.

 

해결 방법을 찾아봐야겠다.

 

📌 개선 1. HttpHandler에서 MDC 값 주입

방법을 찾다가 아래 글을 봤다

WebFlux Log Tracing

HttpHandlerDecoratorFactory를 사용하고 있었다.

HttpHandlerDecoratorFactory는 설명에 'Contract for applying a decorator to an HttpHandler'라고 쓰여있는데, 쉽게 말하면 HttpHandler를 변형할 수 있다는 말이다.

HttpHandler에서 MDC 값을 주입할 수 있도록 바꾸면 위 문제를 해결 가능할거라 판단했다.

그래서 아래와 같이 바꿨다.

@Component
class MdcHttpHandlerDecoratorFactory: HttpHandlerDecoratorFactory {
    val logger = KotlinLogging.logger { }
    override fun apply(httpHandler: HttpHandler): HttpHandler {
        return HttpHandler { request, response ->
            val uuid = UUID.randomUUID().toString()
            try {
                MDC.put(TRACE_ID, uuid)
                httpHandler.handle(request, response)
                    .contextWrite { it.insert(TRACE_ID, uuid) }
            } finally {
                MDC.clear()
            }

        }
    }
}

처음엔 MDC를 위에서 사용했던 createPutWithMDC를 이용하여 주입해 줬다.

하지만 문제는 여전했다.

이유는 httpHandler.handle의 구현을 보면 알 수 있다.

@Override
public Mono<Void> handle(ServerHttpRequest request, ServerHttpResponse response) {
	... // 생략
    LogFormatUtils.traceDebug(logger, traceOn ->
            exchange.getLogPrefix() + formatRequest(exchange.getRequest()) +
                    (traceOn ? ", headers=" + formatHeaders(exchange.getRequest().getHeaders()) : ""));
	... // 생략
}

해당 함수의 중간에 log를 남기도록 되어있다.

그러므로 createPutWithMDC에서 MDC 값을 설정하더라도, 위에서 남기는 로그에는 traceId가 남지 않는다.

그래서 MDC 값을 미리 넣어줬고, handle 이후에 MDC 값을 context에 넣어주는 작업만 해줬다.

아래는 insert의 코드이다.

fun Context.insert(key: String, value: String): Context {
    val mapOfContext = this.stream()
        .map { ctx -> ctx.key to ctx.value }
        .toList().toMap().toMutableMap()
    mapOfContext[key] = value
    return Context.of(mapOfContext)
}

 

위 코드를 구현하고 webfilter를 삭제했다.

결과는 아래와 같다.

2024-05-20T21:19:01.607 DEBUG [       reactor-http-nio-3] [traceId=2342c601-a4a6-4f9c-81d9-64bc877d28ca] --- o.s.w.s.adapter.HttpWebHandlerAdapter    : [3f51cbb7-1] HTTP GET "..."
2024-05-20T21:19:01.735 DEBUG [       reactor-http-nio-3] [traceId=2342c601-a4a6-4f9c-81d9-64bc877d28ca] --- o.s.w.s.adapter.HttpWebHandlerAdapter    : [3f51cbb7-1] Completed 200 OK

잘 나온다.

 

📌 개선 2. parZip MDC 값 표시하도록 하기

parZip을 실행시키면 traceId가 찍히지 않는 것을 발견했다.

 

평소 parZip을 아래와 같이 이용했었다.

parZip(
    { voteHistoryService.findByUidAndPostId(user.uid, postId) },
    { voteOptionService.validateCorrespondWithVote(postId, request.optionId) }
) { history, _ -> 
    ...
}

이는 아래와 같은 parZip 함수를 실행시킨다

public suspend inline fun <A, B, C> parZip(
  crossinline fa: suspend CoroutineScope.() -> A,
  crossinline fb: suspend CoroutineScope.() -> B,
  crossinline f: suspend CoroutineScope.(A, B) -> C
): C = parZip(Dispatchers.Default, fa, fb, f)

이 함수를 타고 들어가보면, 아래와 같다.

public suspend inline fun <A, B, C> parZip(
  ctx: CoroutineContext = EmptyCoroutineContext,
  crossinline fa: suspend CoroutineScope.() -> A,
  crossinline fb: suspend CoroutineScope.() -> B,
  crossinline f: suspend CoroutineScope.(A, B) -> C
): C = coroutineScope {
  val faa = async(ctx) { fa() }
  val fbb = async(ctx) { fb() }
  val (a, b) = awaitAll(faa, fbb)
  f(a as A, b as B)
}

인자로 주어진 suspend function을 async로 실행시킨다.

다른 코루틴을 실행시킨다는 뜻이다.

 

그렇다면 traceId가 찍히지 않는 이유는 무엇일까?

이에 대한 원인은 간단하다.

다른 코루틴 실행시, MDCContext가 전달되지 않았고, 이 때문에 MDC에는 traceId 값이 존재하지 않기 때문이다.

그래서 traceId는 찍히지 않는다.

 

이를 간단히 커스텀하여 해결했다.

MDCContext가 전달되지 않는 게 문제였으니, 전달하면 해결된다.

suspend inline fun <A, B, C> parZipWithMDC(
    crossinline fa: suspend CoroutineScope.() -> A,
    crossinline fb: suspend CoroutineScope.() -> B,
    crossinline f: suspend CoroutineScope.(A, B) -> C,
): C {
    val ctx = Dispatchers.Default + MDCContext()
    return parZip(ctx, fa, fb, f)
}

위에서 본 일반적인 parZip과 유사하다.

차이점은 context에 MDCContext도 넘겨주는 것이다.

 

이렇게 될 경우, MDCContext가 다른 코루틴에서도 MDC에 값을 넣어줄 수 있으므로, traceId를 로깅할 수 있다.

 

📌 개선 3. Coroutine 내부 MDC 전파

🔵 CoWebFilter

@Component
class CoMdcFilter : CoWebFilter() {
    override suspend fun filter(exchange: ServerWebExchange, chain: CoWebFilterChain) {
        withContext(Dispatchers.IO) {
            chain.filter(exchange)
        }
    }
}

CoWebfilter는 WebFilter를 상속한다.

이에 필터 체인에 속해서 작동하게 된다.

하지만 차이점이 존재한다. 

final override fun filter(exchange: ServerWebExchange, chain: WebFilterChain): Mono<Void> {
    val context = exchange.attributes[COROUTINE_CONTEXT_ATTRIBUTE] as CoroutineContext?
    return mono(context ?: Dispatchers.Unconfined) {
        filter(exchange, object : CoWebFilterChain {
            override suspend fun filter(exchange: ServerWebExchange) {
                exchange.attributes[COROUTINE_CONTEXT_ATTRIBUTE] = currentCoroutineContext().minusKey(Job.Key)
                chain.filter(exchange).awaitSingleOrNull()
            }
        })}.then()
}

protected abstract suspend fun filter(exchange: ServerWebExchange, chain: CoWebFilterChain)

이는 CoWebFilter의 함수이다.

자세히 보면 CoWebFilter의 작동할 때, 현재 CoroutineContext를 exchange에 넣어준다.

이 값은 위에서 설명했던 Suspend 함수인지 검사하는 부분에서 쓰인다.

CoWebFilter를 통해 Context를 지정해 주면, 값이 null이 아니므로 이에서 지정한 Context를 기반으로 Coroutine이 작동하게 된다.

 

🔵 문제점

위에서 제시한 CoWebFilter와 같이 구현할 경우, Coroutine이 처음 시작될 때 Dispatcher.IO로 시작하게 된다.

또한 아래 코드를 실행할 경우, 결괏값은 아래 사진과 같다.

suspend fun getAllVotes(
    user: AuthUser,
    searchRequest: SearchVoteRequest,
    pageRequest: SusuPageRequest,
): Slice<VoteAndOptionsWithCountResponse> {
    logger.info { "1" }
    val userAndPostBlockIdModel = blockService.getUserAndPostBlockTargetIds(user.uid)

    logger.info { "7" }
    ...
}

suspend fun getUserAndPostBlockTargetIds(uid: Long): UserAndPostBlockIdModel {
    logger.info { "2" }
    val blocks = findAllByUid(uid)
    logger.info { "6" }
    ...
}

suspend fun findAllByUid(uid: Long): List<UserBlock> {
    logger.info { "3" }
    return withMDCContext(Dispatchers.IO) {
        logger.info { "4" }
        val a = userBlockRepository.findAllByUid(uid)
        logger.info { "5" }
        a
    }
}

traceId가 없다.

Coroutine을 통해 스레드가 전환되었지만, 전환된 스레드에서 MDC 값을 넣어주지 않았기 때문이다.

이 경우는 Unconfined로 설정했다면 볼 수 없을 것이다.

 

또한 아래와 같은 상황에서 이와 동일한 문제가 발생했다.

자식 Coroutine이 끝나서 부모 Coroutine으로 돌아왔지만, MDC 값이 초기화되어 traceId가 찍히지 않는다.

이 뒤로 끝까지 traceId는 찍히지 않았다.

이 또한 원인은 같았다.

이 부분은 Dispatcher에 상관없이 발생했다.

 

🔵 삽질

MDCContext가 Coroutine의 중단, 실행 시 MDC 값을 유지해 줄 수 있다.

이를 코루틴이 처음 생성될 때, Context에 넣어주면 되지 않을까 생각했다.

그래서 아래와 같이 구성했다.

class CoMdcFilter : CoWebFilter() {
    override suspend fun filter(exchange: ServerWebExchange, chain: CoWebFilterChain) {
        withContext(Dispatchers.Unconfined + MDCContext()){
            chain.filter(exchange)
        }
    }
}

Dispatcher.Unconfined로 해둔 이유는, blocking 로직이 아니라서 바꿀 기존 디폴트 값을 바꿀 필요가 없다고 생각했다.

그래서 Context를 Dispatcher.Unconfined + MDCContext() 조합으로 구성했다.

하지만 이는 정상적으로 작동하지 않았다.

그 이유는 MDCContext의 동작 방식에 존재한다.

MDCContext는 생성 시 context를 지정해주지 않을 경우, MDC.getCopyOfContextMap() 값을 가진다.

코루틴이 시작할 때, 이 값은 Null이다. 

CoWebFilter에서 MDCContext()를 초기화할 때, 들어간 값이 Null이기 때문이다.

그러므로 Coroutine이 다시 시작되며 MDC 값이 초기화될 수 없다.

 

결론적으로, CoWebFilter에서 Context에 MDCContext()를 넣는 방식은 정상적으로 작동하지 않는다.

 

🔵 해결

Coroutine이 resumeWith 될 때, 즉 Coroutine이 수행될 때마다 MDC 값을 주입해 주면 될 거라 생각했다.

이를 ContinuationInterceptor를 커스텀하여 구현했다.

class MdcContinuationInterceptor(private val dispatcher: CoroutineDispatcher) : ContinuationInterceptor {
    override val key: CoroutineContext.Key<*>
        get() = ContinuationInterceptor

    override fun <T> interceptContinuation(continuation: Continuation<T>): Continuation<T> {
        return MdcContinuation(dispatcher.interceptContinuation(continuation))
    }
}

class MdcContinuation<T>(private val continuation: Continuation<T>) : Continuation<T> {
    val logger = KotlinLogging.logger {  }

    override val context: CoroutineContext
        get() = continuation.context

    override fun resumeWith(result: Result<T>) {
    	logger.info { "resume" }
        continuation.context[ReactorContext]?.context?.get<String>(MDC_KEY_TRACE_ID)?.run {
            MDC.put(MDC_KEY_TRACE_ID, this)
        }
        continuation.resumeWith(result)
    }
}

 

이에 MDC 값을 넣어주는 로직이 필요하다 생각했다.

Dispatcher의 Continuation이 resumeWith 될 때마다 Context에 있는 traceId 값을 MDC에 넣어주도록 했다.

그리고 이를 CoWebFilter에 적용했다. 

@Component
class CoMdcFilter : CoWebFilter() {
    override suspend fun filter(exchange: ServerWebExchange, chain: CoWebFilterChain) {
        withContext( MdcContinuationInterceptor(Dispatchers.Unconfined)) {
            chain.filter(exchange)
        }
    }
}

이를 실행하면 아래와 같은 로그가 남는다.

코루틴이 실행되며 resumeWith이 수행되고, 이와 동시에 MDC 값이 주입돼서 traceId가 표시되는 것을 볼 수 있다.

 

이를 통해, Coroutine에 계속 MDC 값을 유지할 수 있으며, 이를 기반으로 내부 MDCContext에도 값을 유지할 수 있도록 할 수 있었다.