Transactional Outbox Pattern을 이용한 분산 환경에서의 결과적 일관성 확보

문제 상황

사용자 정보를 변경한 후 커밋되었지만 메시지가 발행되지 않는 경우
메시지를 발행했지만 사용자명 변경 내역이 롤백된 경우

다음과 같이 컨트롤러에서 userService를 호출해서 사용자 정보를 변경하여 DB에 커밋한 후 kafkaService를 호출해서 변경된 사용자 정보를 카프카 메시지로 발행한다고 가정하자.

@RestController
@RequiredArgsConstructor
public class UserController {

    private final JwtUtils jwtUtils;
    private final UserService userService;
    private final KafkaService kafkaService;

    @PutMapping("/edit")
    public ResponseEntity editUserInfo(@RequestBody EditUserInfoRequest editUserInfoRequest, HttpServletRequest request) {
        ReadUserResponse readUserResponse = userService.editUserInfo(editUserInfoRequest, jwtUtils.getEmailFromHeader(request));
        kafkaService.publishUserInfoUpdated(readUserResponse.getEmail());
        return ResponseEntity.status(HttpStatus.OK)
                .body(new SuccessResponse("회원 정보 수정 성공", readUserResponse));
    }
}

혹은 다음과 같이 @Transactional이 붙은 UserSerivce에서 KafkaService를 호출하는 방식으로 하나의 트랜잭션으로 묶을 수도 있다.

@RestController
@RequiredArgsConstructor
public class UserController {

    private final JwtUtils jwtUtils;
    private final UserService userService;

    @PutMapping("/edit")
    public ResponseEntity editUserInfo(@RequestBody EditUserInfoRequest editUserInfoRequest, HttpServletRequest request) {
        ReadUserResponse readUserResponse = userService.editUserInfo(editUserInfoRequest, jwtUtils.getEmailFromHeader(request));
        return ResponseEntity.status(HttpStatus.OK)
                .body(new SuccessResponse("회원 정보 수정 성공", readUserResponse));
    }
}

@Service
@Transactional
@RequiredArgsConstructor
public class UserService {

    private final UserRepository userRepository;
    private final KafkaService kafkaService;

    public ReadUserResponse editUserInfo(EditUserInfoRequest dto, String email) {
        User user = findUser(email);
        user.editUserInfo(dto.getName());
        kafkaService.publishUserInfoUpdated(user.getEmail()); // 카프카 메시지 발행
        return new ReadUserResponse(user);
    }
}

그런데 사용자 정보를 업데이트하고 카프카 메시지를 발행하는 작업을 하나의 트랜잭션으로 묶더라도 카프카 메시지를 발행하는 것은 외부의 카프카 서버로 발행하는 분산 환경이므로 다음과 같은 문제가 발생할 수 있다.

사용자 정보를 변경한 후 커밋되었지만 메시지가 발행되지 않는 경우
- 일시적인 네트워크 문제
- 카프카 서버의 문제
- 커밋 완료 후 메시지 발행 직전 해당 애플리케이션 서버의 장애
- ...
메시지를 발행했지만 사용자명 변경 내역이 롤백된 경우
- DB 연결 끊김
- ...

위와 같은 문제들이 있을 수 있는데, 이때 일시적인 네트워크 문제 또는 카프카 서버의 문제로 카프카 서버와의 연결이 끊긴 경우에는 retries 설정을 하면, 설정된 횟수만큼 메시지 발행을 재시도한다. 따라서 카프카 서버와 재연결이 되었을 때 메시지 발행에 성공할 수 있다.

그러나 커밋이 완료되어 변경된 사용자 정보가 DB에 업데이트되었지만, 메시지 발행 직전 애플리케이션 서버가 중단된다면, 메시지는 영영 발행되지 않는다.

Transactional Messaging

이처럼 비동기 메시징 시스템을 활용한 분산 환경에서는 비즈니스 로직의 실행에 따라 이를 표현하는 이벤트도 온전히 발행되는 것이 중요하다. 보통 애플리케이션 로직상 트랜잭션이 완료되기 전에 이벤트 메시지를 발행하는데, 이때 메시지가 발행되었으나 특정 이유로 예외가 발생해 롤백이 될 수 있고, 또는 메시지 발행에 실패했으나 커밋할 수 있다. 즉, DB 커밋과 메시지 발행이 원자적으로 수행되지 않는 문제가 발생할 수 있다.

이와 같이 서비스 로직의 실행과 그 이후의 이벤트 발행을 원자적으로 함께 실행하는 것을 트랜잭셔널 메시징(Transactional Messaging)이라고 한다. 트랜잭션이 커밋되면 메시지도 정상 발행되어야 하고, 트랜잭션이 롤백되면 메시지는 발행되면 안된다.