서비스 확장을 위한 트랜잭션 분리와 이벤트 기반 설계

 

들어가며

대규모 시스템에서 트랜잭션의 범위와 서비스 간의 결합도는 성능과 확장성에 큰 영향을 미칩니다. 특히, 기존 로직에 영향을 주지 않으면서 부가 기능을 추가하거나, 트랜잭션 경계를 최적화하는 것은 서비스의 유지보수성을 높이는 중요한 작업입니다. 이번 글에서는 현재 콘서트 예약 서비스의 트랜잭션 범위를 분석하고, 서비스들을 기능별로 분리하며 이벤트 기반 설계를 도입하는 과정에 대해 설명하겠습니다.

 

 

 

현재 코드의 트랜잭션 범위 분석

 

트랜잭션 범위

현재 코드에서 @Transactional이 적용된 핵심 로직 중 예약 생성과 결제 처리에 대한 로직에 대해 트랜잭션 범위를 분석해보겠습니다. 두 로직은 아래과 같은 방식으로 동작합니다.

 

 

예약 생성

@Service
class ReservationService(
    private val seatFinder: SeatFinder,
    private val concertManager: ConcertManager,
    private val reservationRepository: ReservationRepository,
) {
    @Transactional
    fun createPendingReservation(
        userId: Long,
        scheduleId: Long,
        seatId: Long,
    ): CreateReservationInfo {
        seatFinder.getAvailableSeat(scheduleId, seatId).reserve()
        occupySeat(scheduleId)
        val reservation = concertManager.createPendingReservation(userId, scheduleId, seatId)
        return reservation.toCreateReservationInfo(success = true)
    }
}

 

결제 처리

@Component
class PaymentFacade(
    private val waitingQueueService: WaitingQueueService,
    private val userService: UserService,
    private val reservationService: ReservationService,
    private val paymentService: PaymentService,
    private val concertService: ConcertService,
) {
    @Transactional
    fun processPayment(command: PaymentCommand): PaymentInfo {
        return runCatching {
            val reservationInfo: ReservationInfo = reservationService.confirmReservation(command.reservationId)
            val seatInfo: SeatInfo = concertService.verifyAndGetSeatInfo(reservationInfo.seatId)
            userService.updateUserBalance(command.userId, seatInfo.price, PointTransactionType.USE)
            waitingQueueService.expireToken(command.token)
            paymentService.savePayment(command.userId, command.reservationId, seatInfo.price)
        }.getOrElse { ex ->
            throw CoreException(
                errorType = ErrorType.PAYMENT_FAILED,
                details = {
                    "cause" to ex.message
                },
            )
        }
    }
}

 

좀 더 보기 쉽게 수도(pseudo) 코드로 다시 작성해보았습니다.

 

예약 생성

// ReservationService.createPendingReservation()
@Transactional
fun 예약생성(사용자ID, 일정ID, 좌석ID) {
    val 좌석 = 사용가능한좌석가져오기(일정ID, 좌석ID)
    좌석.좌석예약()
    좌석점유업데이트(일정ID) // 재고 감소
    val 예약 = 예약생성및저장(사용자ID, 일정ID, 좌석ID)
    return 예약.예약정보변환() // 예약 정보 반환
}

 

결제 처리

// PaymentFacade.processPayment()
@Transactional
fun 결제처리(command): 결제정보 {
    return runCatching {
        val 예약정보 = 예약확인및확정처리(예약ID)
        val 좌석정보 = 좌석정보검증및가져오기(예약정보.좌석ID)
        사용자잔액차감(사용자ID, 좌석정보.가격, USE)
        대기열토큰만료처리(토큰)
        결제정보저장(사용자ID, 예약ID, 좌석정보.가격)
    }.getOrElse { 예외 ->
        throw 익셉션()
    }
}

 

• 예약 생성, 결제 처리의 메서드는 트랜잭션으로 묶여 있어, 모든 작업이 원자적으로 처리됩니다.
• 결제 처리는 애플리케이션 계층에서 파사드로 작성되어 여러 도메인 서비스 호출하면서 결합도가 높은 구조를 가지고 있습니다.

 

 

트랜잭션 처리의 문제점

1. 트랜잭션 경계가 넓음

결제 처리와 같이 애플리케이션 계층에서 트랜잭션을 시작하는 경우, 모든 서비스 호출이 하나의 트랜잭션으로 묶여 특정 작업 실패 시 전체 롤백이 발생합니다. 예를 들어, 예약 확정과 잔액 차감이 성공했으나 결제 정보 저장이 실패했을 경우 핵심 로직까지 실패하는 경우가 발생하게 됩니다.

 

2. 데이터베이스 커넥션 점유 시간 증가

트랜잭션이 길어지면 DB 커넥션을 오래 점유하게 되어 한정된 쓰레드 풀을 사용하고 있는 경우 다른 작업에 영향을 끼칠 수 있습니다.

 

3. 데드락 가능성

트랜잭션이 길어질수록 다른 트랜잭션과 충돌할 가능성이 높아집니다.

 

4. 확장성 한계

서비스 로직이 복잡해질수록 단일 트랜잭션 내에서 수행하는 작업이 많아지며, 이는 마이크로서비스로 확장할 때 문제가 됩니다.

 

 

 

 

 

서비스 분리 및 개선 방안

 

1. 서비스 기능별 분리

현재 결제 처리 코드는 예약, 결제, 사용자 서비스가 단일 트랜잭션으로 묶여 있습니다. 이를 기능별 서비스로 분리하여 개별 트랜잭션 범위를 좁힐 수 있습니다. 예를 들어, 예약 확정, 잔액 차감, 토큰 만료, 결제 정보 저장은 각각의 서비스로 분리하여 각기 다른 트랜잭션을 가지도록 만들 수 있습니다.

 

2. 트랜잭션 경계 조정

중요한 핵심 작업에 대해서만 트랜잭션을 유지하고, 부가적인 작업은 비동기적으로 처리할 수 있습니다. 예를 들어 결제 처리에서 예약확정, 잔액차감 같은 주요 로직은 트랜잭션을 유지하고, 토큰만료나 결제정보저장을 비동기적으로 처리할 수 있습니다.

외부 API 호출이나 메시지 발행의 경우에도 트랜잭션 외부에서 수행하도록 추가하여 주요 로직에 영향을 주지 않도록 해야 합니다.

 

3. 이벤트 기반 설계 도입

서비스 간 결합도를 낮추기 위해 이벤트 기반 아키텍처를 도입할 수 있습니다. 예를 들어, 예약 생성에서 예약이 완료된 후 이벤트를 발행하고 외부 API가 이를 구독하도록 하면, 해당 로직은 독립적으로 실행됩니다.

이를 통해 한 트랜잭션 내에서 모든 작업을 수행할 필요가 없어지고, 확장성과 유연성이 높아집니다.

 

4. 분산 트랜잭션 및 사가 패턴 도입

마이크로서비스 아키텍처로 확장할 경우, 단일 트랜잭션이 아닌 분산 트랜잭션을 관리해야 할 수 있습니다. 이때 사가 패턴을 도입하여 트랜잭션을 단계별로 나누고, 각 단계가 실패할 경우 보상 작업을 수행하도록 설계할 수도 있습니다.

 

 

 

 

 

예약 생성 로직에 이벤트 처리 추가하기

위의 개선 방안을 토대로 예약 생성 로직에 이벤트 발행 및 구독 처리 로직을 추가하여 외부 API를 호출하는 요구사항을 적용해보겠습니다.

 

 

1. 기존 예약 서비스의 예약 생성 메서드

위에서 봤던 예약 생성의 코드를 다시 보겠습니다.

@Transactional
fun createPendingReservation(
    userId: Long,
    scheduleId: Long,
    seatId: Long,
): CreateReservationInfo {
    seatFinder.getAvailableSeat(scheduleId, seatId).reserve()
    occupySeat(scheduleId)
    val reservation = concertManager.createPendingReservation(userId, scheduleId, seatId)
    return reservation.toCreateReservationInfo(success = true)
}

 

 

2. 예약 이벤트 POJO 클래스 작성

예약 생성 후 이벤트를 전달하기 위한 Event 클래스를 정의했습니다.

참고로, ApplicationEventPublisher 는 스프링 4.2부터 ApplicationEvent 클래스 상속 없이 POJO 객체의 이벤트를 발행할 수 있습니다. 좀 더 자세한 내용은 아래 블로그 아티클에서 확인할 수 있습니다.

[Spring] 스프링에서 이벤트의 발행과 구독 방법과 주의사항, 이벤트 사용의 장/단점과 사용 예시 출처: [MangKyu's Diary:티스토리]

 

package hhplus.concertreservation.domain.concert.event

data class ReservationCreatedEvent(
    val userId: Long,
    val scheduleId: Long,
    val seatId: Long,
    val reservationId: Long,
) {
    companion object {
        fun from(reservation: Reservation): ReservationCreatedEvent {
            return ReservationCreatedEvent(
                userId = reservation.userId,
                scheduleId = reservation.scheduleId,
                seatId = reservation.seatId,
                reservationId = reservation.id,
            )
        }
    }
}

 

 

3. 예약 완료 후 이벤트 발행 추가

예약이 완료되면 예약 이벤트를 발행하는 로직을 추가합니다.

@Transactional
fun createPendingReservation(
    userId: Long,
    scheduleId: Long,
    seatId: Long,
): CreateReservationInfo {
    seatFinder.getAvailableSeat(scheduleId, seatId).reserve()
    occupySeat(scheduleId)
    val reservation = concertManager.createPendingReservation(userId, scheduleId, seatId)
    eventPublisher.publish(ReservationCreatedEvent.from(reservation)) // 이벤트 발행
    return reservation.toCreateReservationInfo(success = true)
}

 

4. 외부 데이터 플랫폼 호출 클래스 작성

간단하게 예약 이벤트를 받게 되면 로직을 수행하는 클래스를 작성했습니다.

package hhplus.concertreservation.infrastructure.api

@Component
class DataPlatformApiClient {
    private val log = LoggerFactory.getLogger(this::class.java)
    fun sendReservation() {
        log.info("외부 API 호출: 예약 전송 이벤트 처리 완료")
    }
}

 

 

5. 이벤트 Publisher와 Listener 인터페이스 작성

EventPublisher와 EventListener의 인터페이스를 작성했습니다. 차주 과제에서 Spring의 이벤트 핸들러를 Kafka로 전환하기 때문에 구현체를 변경하기 좋은 구조로 설계하기 위해 작성하였습니다.

package hhplus.concertreservation.infrastructure.event

interface EventPublisher<T> {
    fun publish(event: T)
}

package hhplus.concertreservation.infrastructure.event

interface EventHandler<T> {
    fun handle(event: T)
}

 

 

6. 스프링 이벤트 핸들러 구현체 작성

스프링 컨텍스트에서 제공하는 ApplicationEventPublisher와 @TransactionalEventListener를 사용하여 구현체를 작성했습니다.

 

package hhplus.concertreservation.infrastructure.event.reservation

@Component
class ReservationSpringEventPublisher(
    private val applicationEventPublisher: ApplicationEventPublisher
) : EventPublisher<ReservationCreatedEvent> {

    override fun publish(event: ReservationCreatedEvent) {
        applicationEventPublisher.publishEvent(event)
    }
}

 

package hhplus.concertreservation.infrastructure.event.listener

@Component
class ExternalPlatformEventListener(
    private val dataPlatformApiClient: DataPlatformApiClient
): EventListener<ReservationCreatedEvent> {
    @Async
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    override fun handle(event: ReservationCreatedEvent) {
        dataPlatformApiClient.sendReservation()
    }
}

 

 

참고) Listener에 @Async와 @Transactional(REQUIRES_NEW), @TransactionalEventListener(AFTER_COMMIT)을 사용한 이유

스프링 4.2 버전부터 @EventListener 애노테이션을 사용하여 쉽게 이벤트 구독 처리를 할 수 있습니다.

 

package hhplus.concertreservation.infrastructure.event.listener

@Component
class ExternalPlatformEventListener(
    private val dataPlatformApiClient: DataPlatformApiClient
): EventListener<ReservationCreatedEvent> {
    @EventListener
    override fun handle(event: ReservationCreatedEvent) {
        dataPlatformApiClient.sendReservation()
    }
}

 

하지만, 위 코드는 다음과 같은 문제가 발생할 수 있습니다.

1. 메인 로직과 동일한 트랜잭션 사용: 리스너 로직에서 예외가 발생하면 메인 로직도 롤백됩니다.
2. 동기 처리: 메인 로직과 동기적으로 수행되기 때문에 리스너 로직의 수행 시간이 길어지면 메인 로직의 응답이 지연될 수 있습니다.

 

이를 해결하기 위해 @Async와 @Transactional(propagation = Propagation.REQUIRES_NEW)를 추가하여 비동기 처리와 독립적인 트랜잭션을 사용할 수 있습니다.

package hhplus.concertreservation.infrastructure.event.listener

@Component
class ExternalPlatformEventListener(
    private val dataPlatformApiClient: DataPlatformApiClient
): EventListener<ReservationCreatedEvent> {
    @Async
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    @EventListener
    override fun handle(event: ReservationCreatedEvent) {
        dataPlatformApiClient.sendReservation()
    }
}

 

이렇게 두개의 어노테이션을 추가로 선언하게 되면 위의 문제점을 해결할 수 있습니다. 하지만 여전히 다른 문제가 남아있습니다.

 

메인 로직에서 이벤트 발행 후 예외가 발생하게 되면 메인 로직은 실패하지만 이벤트 처리는 성공해버리는 경우가 생길 수 있습니다. 아래는 그 예시 코드입니다.

@Transactional
fun createPendingReservation(
    userId: Long,
    scheduleId: Long,
    seatId: Long,
): CreateReservationInfo {
    seatFinder.getAvailableSeat(scheduleId, seatId).reserve()
    occupySeat(scheduleId)
    val reservation = concertManager.createPendingReservation(userId, scheduleId, seatId)
    eventPublisher.publish(ReservationCreatedEvent.from(reservation)) // 이벤트 발행
    throw CoreException(ErrorType.SYSTEM_FAILURE, "이벤트 발행 후 예외 발생") // 예외 발생
    return reservation.toCreateReservationInfo(success = true)
}

@Component
class ExternalPlatformEventListener : EventListener<ReservationCreatedEvent> {
    @Async
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    @EventListener
    override fun handle(event: ReservationCreatedEvent) {
        println("예약 외부 API 호출 이벤트 처리 중: $event")
        Thread.sleep(3_000)
        println("예약 외부 API 호출 이벤트 처리 완료.")
    }
}

 

예약 메인 로직은 예외가 발생했으나 이벤트는 성공

 

이를 방지하기 위해 메인 로직의 트랜잭션이 성공적으로 커밋되었을 때, 이벤트 처리 로직을 수행하도록 설정해야 합니다. 이를 위해 @EventListener의 확장된 개념인 @TransactionalEventListener를 사용할 수 있습니다.

@TransactionalEventListener는 TransactionPhase를 통해 이벤트가 실행될 시점을 지정할 수 있습니다.

- AFTER_COMMIT: 트랜잭션이 성공적으로 커밋된 후 이벤트가 처리됨.
- BEFORE_COMMIT: 트랜잭션 커밋 직전에 이벤트가 처리됨.
- AFTER_ROLLBACK: 트랜잭션 롤백 후 이벤트가 처리됨.
- AFTER_COMPLETION: 트랜잭션이 완료된 후(커밋되었는지 롤백되었는지와 상관없이) 이벤트가 처리됨.

 

 

따라서, 최종적으로 다음과 같이 3개의 애노테이션을 추가하여 이벤트 리스너를 구현할 수 있었습니다.

package hhplus.concertreservation.infrastructure.event.listener

@Component
class ExternalPlatformEventListener(
    private val dataPlatformApiClient: DataPlatformApiClient
): EventListener<ReservationCreatedEvent> {
    @Async
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    override fun handle(event: ReservationCreatedEvent) {
        dataPlatformApiClient.sendReservation()
    }
}

 

 

 

 

 

 

마치며

이번 글을 통해 트랜잭션 경계를 분석하고, 서비스 확장을 위해 서비스 분리와 이벤트 기반 설계를 도입하는 방법에 대해 살펴보았습니다. 트랜잭션 경계를 적절히 조정하고 비동기 이벤트 처리를 도입함으로써 서비스의 성능과 확장성을 개선할 수 있었습니다. 다음 주에는 Kafka를 사용하여 이벤트 처리 및 보상 트랜잭션을 도입하여 중요한 로직에서의 오류에 대응할 수 있는 방법도 알아보겠습니다.

 

 

 

패키지 hhplus.concertreservation.config import org.springframework.context.annotation.Configuration import org.springframework.scheduling.annotation.EnableAsync @EnableAsync @Configuration 클래스 AsyncConfig