10.1 시스템 간 강결합 문제
주문 서비스 + 결제 서비스(외부)
- 외부 서비스가 정상이 아닐 경우 트랜잭션 처리를 어떻게 해야할까?
- 성능에 대한 문제 → 외부 서비스 성능에 직접적인 영향을 받게 됨
→ 주문 바운디드 컨텍스트와 결제 바운디드 컨텍스트 간의 강결합 때문
→ 해결 방법 : 이벤트를 사용하는 것
10.2 이벤트 개요
- 이벤트 관련 구성요소
- 이벤트 생성 주체
- 이벤트 디스패처(이벤트 퍼블리셔)
- 이벤트 핸들러(이벤트 구독자)
- 이벤트 용도
- 트리거 : 도메인 상태가 바뀔 때 다른 후처리가 필요하면 후처리를 실행하기 위한 트리거로 이벤트를 사용할 수 있음
- 동기화 : 배송지를 변경하면 외부 배송 서비스에 바뀐 배송지 정보를 전송해야 함
→ 이벤트를 사용하여 주문 도메인에서 결제(환불) 도메인으로의 의존을 제거함
10.3 이벤트, 핸들러, 디스패처 구현
이벤트 처리 흐름
- 응용 서비스 - 도메인 - Events - ApplicationEventPublisher - 이벤트 핸들러
- 도메인 기능을 실행한다.
- 도메인 기능은 Events.raise()를 이용해서 이벤트를 발생시킨다.
- Events.raise()는 스프링이 제공하는 ApplicationEventPublisher를 이용해서 이벤트를 출판한다.
- ApplicationEventPublisher는 @EventLister(이벤트타입.class) 애너테이션이 붙은 메서드를 찾아 실행한다.
10.4 동기 이벤트 처리
- 외부 환불 서비스 실행에 실패하였다고 해서 반드시 트랜잭션을 롤백해야 할까?
외부 시스템과의 연동을 동기로 처리할 때 발생하는 성능과 트랜잭션 범위 문제를 해소하는 방법은 이벤트를 비동기로 처리하거나 이벤트와 트랜잭션을 연계하는 것이다.
10.5 비동기 이벤트 처리
- ‘A 하면 이어서 B 하라’ → ‘A 하면 최대 언제까지 B 하라’
→ B를 하는데 실패하면 일정 간격으로 재시도를 하거나 수동 처리를 해도 상관 없는 경우가 있다.
‘→ A 하면 최대 언제까지 B 하라’ = 이벤트를 비동기로 구현하면 됨
로컬 핸들러 비동기 실행
- @EnableAsync 애너테이선을 사용해서 비동기 기능을 활성화한다.
- 이벤트 핸들러 메서드에 @Ansync 어노테이션을 붙임
메시징 시스템을 이용한 비동기 구현
- Kafka, RabbitMQ
- 필요하다면 이벤트를 발생시키는 도메인 기능과 메시지 큐에 이벤트를 저장하는 절차를 한 트랜잭션으로 묶어야 한다.
- 도메인 기능을 실행한 결과를 DB에 반영하고 이 과정에서 발생한 이벤트를 메시지 큐에 저장하는 것을 같은 트랜잭션 범위에서 실행하려면 글로벌 트랜잭션이 필요함
- 글로벌 트랜잭션을 사용하면 안전하게 이벤트를 메시지 큐에 전달할 수 있는 장점이 있지만 반대로 글로벌 트랜잭션으로 인해 전체 성능이 떨어지는 단점도 있음, 글로벌 트랜잭션을 지원하지 않는 메시징 시스템도 있다.
이벤트 저장소를 이용한 비동기 처리
- 포워더 방식 - 스케줄러 사용
- 이벤트가 발생하면 핸들러는 스토리지에 이벤트를 저장한다.
- 포워더는 주기적으로 이벤트 저장소에서 이벤트를 가져와 이벤트 핸들러를 실행한다.
- 포워더는 별도 스레드를 이용하기 때문에 이벤트 발행과 처리가 비동기로 처리된다.
- API 방식 - REST API 요청
- 외부 핸들러가 API 서버를 통해 이벤트 목록을 가져간다.
- 포워더 방식은 이벤트를 어디까지 처리했는지 추적하는 역할이 포워더에 있다면 API 방식에서는 이벤트 목록을 요구하는 외부 핸들러가 자신이 어디까지 이벤트를 처리했는지 기억해야한다.
10.6 이벤트 적용 시 추가 고려 사항
- 이벤트 소스를 EventEntry에 추가할지 여부
- EventEntry는 이벤트 발생 주체에 대한 정보를 갖지 않는다.
- 포워더에서 전송 실패를 얼마나 허용할 것이냐에 대한 것
- 포워더는 이벤트 전송에 실패하면 실패한 이벤트로부터 다시 읽어와 전송을 시도한다. → 이벤트를 전송하는데 3회 실패했다면 해당 이벤트는 생략하고 다음 이벤트로 넘어간다는 등의 정책이 필요하다.
- 처리에 실패한 이벤트를 생략하지 않고 별도 실패용 DB나 메시지 큐에 저장하기도 한다. 처리에 실패한 이벤트를 물리적인 저장소에 남겨두면 이후 실패 이유 분석이나 후처리에 도움이 된다.
- 포워더는 이벤트 전송에 실패하면 실패한 이벤트로부터 다시 읽어와 전송을 시도한다. → 이벤트를 전송하는데 3회 실패했다면 해당 이벤트는 생략하고 다음 이벤트로 넘어간다는 등의 정책이 필요하다.
- 이벤트 손실에 대한 것
- 이벤트 저장소를 사용하는 방식은 이벤트 발생과 이벤트 저장을 한 트랜잭션으로 처리하기 때문에 트랜잭션에 성공하면 이벤트가 저장소에 보관된다는 것을 보장할 수 있다.
- 로컬 핸들러를 이용해서 이벤트를 비동기로 처리할 경우 이벤트 처리에 실패하면 이벤트를 유실하게 된다.
- 이벤트 순서에 대한 것
- 이벤트 발생 순서대로 외부 시스템에 전달해야 할 경우, 이벤트 저장소를 사용하는 것이 좋다.
- 이벤트 저장소는 저장소에 이벤트를 발생 순서대로 저장하고 그 순서대로 이벤트 목록을 제공함
- 이벤트 재처리에 대한 것
- 동일한 이벤트를 다시 처리해야 할 때 이벤트를 어떻게 할지 결정해야 한다.
- 마지막으로 처리한 이벤트의 순번을 기억해 두었다가 이미 처리한 순번의 이벤트가 도착하면 해당 이벤트를 처리하지 않고 무시하는 것
- 멱등성을 보장하도록 처리함
이벤트 처리와 DB 트랜잭션 고려
- 이벤트 처리를 동기로 하든 비동기로 하든 이벤트 처리 실패와 트랜잭션 실패를 함께 고려해야 한다.
- 트랜잭션이 성공할 때만 이벤트 핸들러를 실행하는 것
- @TransactionalEventLister 애너테이션을 지원함
- 스프링은 트랜잭션 커밋에 성공한 뒤에 핸들러 메서드를 실행한다. 중간에 에러가 발생해서 트랜잭션이 롤백되면 핸들러 메서드를 실행하지 않는다.
- 이벤트 핸들러를 실행했는데 트랜잭션이 롤백되는 상황은 발생 하지 않는다.
- 즉, 트랜잭션이 성공할 때만 이벤트 핸들러를 실행하게 되면 트랜잭션 실패에 대한 경우의 수가 줄어 이벤트 처리 실패만 고민하면 됨
방구석개발자