항해 플러스 9주차 회고

9주차 책임 분리를 통한 애플리케이션 설계

 

1. 문제

비즈니스 로직과 트랜잭션 범위 고려

@Transactional
void payment() {
    결제_요청_검증()
    유저_포인트_차감()
    결제_정보_저장()
    주문_정보_전달() //외부 플랫폼 API 호출    
}

 

예를 들어서 상품을 결제하는 결제 함수가 있다.

결제처리 하는 비즈니스 로직 안에 여러 가지 함수들이 존재하며, 결제 처리가 끝난 후 최종적으로 주문 정보를 외부 API를 호출하여 전송해 주는 기능까지 존재한다. 즉, payment()가 정상적으로 성공 처리 되기 위해서는 외부 API에 호출 또한 정상적으로 통신이 되어야 한다.

 

위에 로직은 정상적인 것 같지만 심각한 문제가 있다.

- 외부 플랫폼 API 호출 시 네트워크 이슈로 인해 통신이 오래 걸리는 경우 pamyent()로직 자체가 오래 걸리게 된다. (하나의 트랜잭션으로 동작하기 때문에)

- payment()가 실행되면서 모든 로직이 성공적으로 다 처리 되었지만 외부 API에서 문제가 생기는 경우 전부 롤백된다.

 

주문 정보 전달은 부가 로직 이므로 주요 로직인 결제 처리에 영향을 끼치면 안 된다.

 

2. 시도 & 해결

문제점을 해결하기 위해서 이벤트를 사용해서 부가 로직과 주요 로직의 결합을 끊어낼 수 있다.

@Transactional
void payment() {
    결제_요청_검증()
    유저_포인트_차감()
    결제_정보_저장()
    applicationEventPublisher.publishEvent(주문_정보_전달()) //외부 플랫폼 API 호출    
}

 

스프링에서 제공하는 이벤트리스너 기 등을 사용해서 이벤트로 비즈니스 로직을 수정하였다.

이벤트의 동작 과정 : 이벤트 생성 주체 -> 이벤트 디스패처(이벤트 퍼블리셔) -> 이벤트 핸들러(이벤트 구독자)

 

스프링 이벤트를 사용

이렇게 이벤트를 사용해서 부가 로직(외부 API)에 의해서 주요 로직의 영향이 없도록 만들 수 있지만!!!! 단순히 이벤트로 처리한다고 해서 영향이 없는 건 아니다. 

 

이벤트는 크게 동기 방식과 비동기 방식이 있는데 동기 방식으로 하는 경우에는 하나의 트랜잭션 범위로 동작하기 때문에 여전히 외부 서비스에 영향을 받게 된다.

비동기 방식은 (이벤트 리스너에서 @Async를 사용) 다른 스레드에서 동작하기 때문에 우리가 원하는 대로 처리하기 위해서는 비동기 방식을 사용해서 처리해야 한다. 외부 시스템과의 연동을 동기로 처리할 때 발생하는 성능과 트랜잭션 범위 문제를 해소하기 위해서는 이벤트를 비동기로 처리하거나 이벤트와 트랜잭션을 연계하는 방법이 있다.

 

비동기 방식을 사용하기 위해서는 @EnableAsync를 통해서 비동기를 활성화시켜야 한다!!!!

-> 처음에 @Async만 적용했다가 로그에 같은 스레드로 동작하는 걸 보고 이상함을 감지..

 

로컬 핸들러 비동기 실행이 아니라 외부 메시징 시스템을 이용해서도 해결할 수 있다.

나는 저기 저 어깨너머로 듣기만 했던 카프카를 사용해서 처리해 봤지만 카프카 너무 어렵다..

 

카프카를 적용하면서 만약 메시지 발행에 대해서 실패하는 경우? 에 대한 고민을 해결해 보기 위해서 Transactional Outbox Parttern을 사용하는 것을 보고 대략적으로 설계는 해봤지만 아직 실제로 적용해보진 못했다. 이 부분도 카프카를 공부해 보면서 나중에 적용해 볼 계획이다.

 

4. 목표

카프카를 (찍먹!?) 사용해봤지만.. 대용량 트래픽을 수월하게 카프카에 대한 필요성과 중요성이 느껴졌다.

조만간 아파치 카프카 애플리케이션 프로그래밍 with 자바 정독을 목표로 잡고 카프카에 대해서 제대로 알아 가는 시간이 필요할 것 같다.

https://www.yes24.com/Product/Goods/99122569