분산환경 에서의 트랜잭션 보장

MSA에서의 트랜잭션 : 실패 복구 관점에서 보는 SAGA 패턴

이전 글을 통해, 분산 환경에서 트랜잭션 관리가 왜 어려운가? 에 대해서 알아보았습니다.

이를 극복하기 위한 SAGA 패턴의 대략적인 이론적 방법에 대해서도 알아보았습니다.

실제 은행 송금 예제를 통해 운영 가능한 코드를 작성해 보겠습니다.

구성

전체 코드 및 아키텍처

아키텍처 : SAGA 패턴 및 멀티모듈
코드 : Github

실습 환경

JAVA 21
Spring 4.0.0
Kafka 7.5 (& zookeeper)
mysql 8.0
Docker / docker-compose

실습 환경은 반드시 저 내용과 동일할 필요가 없습니다.
각 버전 별로 특정한 기능을 사용하지 않았기 때문에, 더 낮은 버전, 더 높은 버전을 사용해도 전혀 무관합니다.

시스템 구성

사용자는 각자만의 계좌를 가지고 있다.
사용자 끼리 계좌 이체를 통해 돈을 주고 받을 수 있다.
각 도메인은 별도의 서비스로 운영된다.
무언가 실패한다면 그 실패한 기록이 기록되어 추후에 원인 분석에 활용될 수 있어야 한다. (원장 시스템)

만들 시스템은 다음과 같습니다.

Orchestrator (Transfer) service

사용자의 이체 요청을 받는 단일 진입점 입니다.
전체 트랜잭션의 상태를 관리하고, 실패시 복구 트랜잭션을 지시하는 지휘자 역할

Account Service

사용자들의 계좌를 관리합니다.
실제 이체 로직을 처리하고, 처리하기 위한 서비스 로직을 처리합니다.

Notification Service

이체 성공/실패 여부를 사용자에게 알립니다.
Kafka 로 비동기적으로 처리됩니다.

시나리오

오케스트레이션 서버가 계좌 이체 요청을 접수받습니다.
오케스트레이션 서버가 Account 서버에게 출금을 요청합니다.
Account 서버는, 출금이 가능한지 확인 후 출금 처리를 진행합니다.
오케스트레이션 서버는 Account 서버에게 입금을 요청합니다.
Account 서버는, 입금이 가능한지 확인 후, 입금 처리를 진행합니다.
이체가 완료되면, 알림서비스에 알림을 요청합니다.

주요 코드 소개: 오케스트레이션 로직의 핵심

모든 코드를 다 소개하기엔 양이 많기 때문에 중요한 부분만 소개합니다.
전체 코드는 Github 를 참고하시기 바랍니다.

이 코드는 SAGA 패턴의 오케스트레이션 방식이 어떻게 구현되는지를 가장 잘 보여줍니다.

일반적인 모놀리식 환경의 @Transactional 마법에 의존하지 않고, 명시적인 프로그래밍을 통해 분산 트랜잭션을 제어하는 것이 특징입니다.

@Slf4j
@Service
@RequiredArgsConstructor
public class TransferService {

	private final AccountClient accountClient;
	private final SagaLogService sagaLogService;
	private final KafkaTemplate<String, SagaEvent> kafkaTemplate;

	public TransferDto.TransferResponse transfer(
		TransferDto.TransferRequest request
	) {
		// 1. 계좌 이체 saga 시작
		// 별도의 트랜잭션에서 저장. 해당 saga log 는 롤백되어도 기록됨
		TransferSaga saveSaga = sagaLogService.initSaga(
			request.getFromAccountNumber(),
			request.getToAccountNumber(),
			request.getAmount()
		);

		// 2. 계좌 잔액 확인 및 출금 처리
		AccountTransferDto.AccountWithdrawResponse withdrawResponse;
		try {
			// 2-1. 현재 출금 상태 업데이트
			sagaLogService.updateSagaStep(saveSaga.getSagaId(), SagaStatus.STARTED, TransferStep.WITHDRAW_START);

			// 2-2. 출금 처리 (동기)
			withdrawResponse = accountClient.withdraw(
				new AccountTransferDto.AccountWithdrawRequest(
					saveSaga.getSagaId(),
					request.getFromAccountNumber(),
					request.getAmount())
			);

			// 2-3. 출금 완료 후, 업데이트 처리
			sagaLogService.updateSagaStep(saveSaga.getSagaId(), SagaStatus.PENDING, TransferStep.WITHDRAW_END);

			// 2-4. 로깅 처리
			log.info("출금 처리 완료 response : {}", withdrawResponse.toString());
		} catch (Exception e) {
			// 2-5. 출금 오류 시 처리
			// 출금 자체가 실패하면 롤백할 것이 없음.
			String errorMessage = extractErrorMessage(e);
			sagaLogService.updateSagaStep(saveSaga.getSagaId(), SagaStatus.FAILED, TransferStep.FINISH);
			log.warn("[Saga: {}] 출금 실패 - {}", saveSaga.getSagaId(), errorMessage);

			// 2-6. 출금 오류 시, 알림 발송
			sendNotification(
				saveSaga.getSagaId(),
				request.getFromAccountNumber(),
				"이체 실패: " + errorMessage,
				SendStatus.FAILED
			);

			// 2-7. 실패 결과 return
			return TransferDto.TransferResponse.of(saveSaga.getSagaId(), SagaStatus.FAILED.name(), errorMessage);
		}

		// 3. 보내는 계좌로 송금 처리
		AccountTransferDto.AccountDepositResponse depositResponse;
		try {
			// 3-1. 현재 입금 상태 업데이트
			sagaLogService.updateSagaStep(saveSaga.getSagaId(), SagaStatus.STARTED, TransferStep.DEPOSIT_START);

			// 3-2. 송금 처리 (동기)
			depositResponse = accountClient.deposit(
				new AccountTransferDto.AccountDepositRequest(
					saveSaga.getSagaId(),
					request.getToAccountNumber(),
					request.getAmount())
			);

			// 3-3. 송금 완료 후, 업데이트 처리
			sagaLogService.updateSagaStep(saveSaga.getSagaId(), SagaStatus.PENDING, TransferStep.DEPOSIT_END);
			log.info("입금 처리 완료 response : {}", depositResponse.toString());
		} catch (Exception e) {
			// 3-4. 입금 실패 시, 트랜잭션 롤백 실행 필요.
			// 이전 출금된 계좌에서 다시 입금 처리
			String errorMessage = extractErrorMessage(e);
			log.warn("[Saga: {}] 입금 실패 - {}", saveSaga.getSagaId(), errorMessage);

			withdrawRollback(saveSaga.getSagaId(), request.getFromAccountNumber(), request.getAmount());

			// 3-5. 이체 실패 알림 발송.
			sendNotification(
				saveSaga.getSagaId(),
				request.getFromAccountNumber(),
				"이체 실패(입금오류): " + errorMessage,
				SendStatus.FAILED
			);

			// 3-6. 실패 결과 return
			return TransferDto.TransferResponse.of(saveSaga.getSagaId(), SagaStatus.FAILED.name(), errorMessage);
		}

		// 4. 알림 처리
		// 출금/입금 한 사람 두분에게 모두 알림 처리
		// 비동기로 이벤트 발송 (kafka)
		try {
			sendNotification(
				saveSaga.getSagaId(),
				request.getFromAccountNumber(),
				withdrawResponse.getMessage(),
				SendStatus.SENT
			);
			sendNotification(
				saveSaga.getSagaId(),
				request.getToAccountNumber(),
				depositResponse.getMessage(),
				SendStatus.SENT
			);
		} catch (Exception e) {
			log.warn("[Saga: {}] 알림 발송 실패 : {}", saveSaga.getSagaId(), e.getStackTrace());
		}

		// 5. saga 업데이트
		sagaLogService.updateSagaStep(saveSaga.getSagaId(), SagaStatus.COMPLETED, TransferStep.FINISH);

		// 6. 완료 처리
		return TransferDto.TransferResponse.of(saveSaga.getSagaId(), SagaStatus.COMPLETED.name(), "출금 처리 완료");
	}

	/**
	 * 계좌이체 출금 Rollback 로직
	 * @param sagaId
	 * @param rollbackAccountNumber
	 * @param amount
	 */
	private void withdrawRollback(String sagaId, String rollbackAccountNumber, BigDecimal amount) {
		try {
			// 1. Rollback 상태 업데이트
			sagaLogService.updateSagaStep(sagaId, SagaStatus.STARTED, TransferStep.COMPENSATE);

			// 2. Rollback 보상 로직 실행 (동기)
			accountClient.withdrawRollback(
				new AccountTransferDto.AccountWithdrawRollbackRequest(
					sagaId,
					rollbackAccountNumber,
					amount)
			);

			sagaLogService.updateSagaStep(sagaId, SagaStatus.ABORTED, TransferStep.FINISH);
		} catch (Exception e) {
			// 실패 시, 복구 동작이 실패함.
			// 명백하게 개발자/운영자 측에서 확인 후 수동 처리가 필요할 수 있음.
			// 즉, 계좌이체 했는데 돈만 없어진 상황
			log.error("[Saga: {}] 이체 롤백 실패 - 에러: {}", sagaId, e.getMessage());

			sagaLogService.updateSagaStep(sagaId, SagaStatus.FAILED, TransferStep.FINISH);
		}
	}

	/**
	 * 알림 발송 메서드
	 * 비동기적으로 알림 서비스에 알림 요청
	 * @param sagaId
	 * @param recipientAccountNumber
	 * @param message
	 * @param status
	 */
	private void sendNotification(String sagaId, String recipientAccountNumber, String message, SendStatus status) {
		TransferEvent.TransferNotificationEvent notificationEvent = TransferEvent.TransferNotificationEvent.of(
			sagaId, recipientAccountNumber, message, status);

		kafkaTemplate.send(TopicList.TRANSFER_NOTIFICATION_TOPIC, sagaId, notificationEvent);
		log.info("[kafka] 알림 전송 완료. {}, {}", message, status);
	}

	/**
	 * FeignException인 경우 Body(실제 메시지)를 추출하고,
	 * 일반 Exception인 경우 getMessage()를 반환하는 헬퍼 메소드
	 */
	private String extractErrorMessage(Exception e) {
		if (e instanceof FeignException feignException) {
			// AccountService가 String Body로 보냈으므로 그대로 꺼내면 됨
			// 값이 없으면 status code라도 리턴
			String content = feignException.contentUTF8();
			return (content != null && !content.isEmpty()) ? content : "Remote Error: " + feignException.status();
		}
		return e.getMessage();
	}
}

1. Try-Catch를 통한 명시적 흐름 제어와 보상 트랜잭션

코드를 보면 알 수 있듯이, 각 단계(출금 -> 입금)는 try-catch 블록으로 감싸져 순차적으로 실행됩니다.

성공 시: 다음 단계로 진행하며 SagaLogService를 통해 진행 상황을 기록합니다.
실패 시: 즉시 catch 블록으로 넘어가 예외를 포착합니다. 이때 가장 중요한 점은 보상 트랜잭션(Compensating Transaction)의 실행입니다.
- 예를 들어, '입금' 단계에서 실패했다면, 이미 성공한 '출금' 내역을 취소하기 위해 명시적으로 withdrawRollback() 메서드를 호출하여 돈을 원복시킵니다.

2. 알림 서비스와 롤백의 범위 (Side Effect)

코드의 마지막 부분인 알림(Notification) 처리에서는 롤백 로직이 빠져 있는 것을 볼 수 있습니다.

이는 "이 작업이 실패했을 때, 전체 트랜잭션을 취소해야 하는가?"에 대한 고민의 결과입니다.

돈과 관련된 작업(출금/입금): 데이터 정합성이 깨지면 안 되므로 반드시 롤백해야 합니다.
외부 알림(이메일/SMS): 이미 발송된 이메일을 회수(Un-send)하는 것은 기술적으로 불가능하며, 알림 발송이 실패했다고 해서 잘 처리된 송금을 취소하는 것은 비즈니스적으로 올바르지 않습니다.

따라서 알림 발송 실패는 전체 트랜잭션의 성공/실패 여부에 영향을 주지 않도록 설계하였으며, 단순 로깅 처리로 마무리하였습니다. 이는 MSA에서 핵심 트랜잭션과 부가 기능(Side Effect)을 분리하는 중요한 기준이 됩니다.

상태 관리의 핵심: SagaLogService (트랜잭션 분리)

Orchestrator(TransferService) 구현에 앞서 가장 먼저 살펴봐야 할 것은 바로 상태를 기록하는 SagaLogService 입니다.

코드를 보면 단순히 DB에 저장하고 업데이트하는 로직처럼 보이지만, 여기에는 분산 트랜잭션의 생존을 위한 중요한 장치가 숨어 있습니다. 바로 @Transactional(propagation = Propagation.REQUIRES_NEW) 옵션입니다.

@Service
@RequiredArgsConstructor
public class SagaLogService {

	private final TransferSagaRepository transferSagaRepository;

	@Transactional(propagation = Propagation.REQUIRES_NEW)
	public TransferSaga updateSagaStep(String sagaId, SagaStatus status, TransferStep step) {
		TransferSaga saga = transferSagaRepository.findById(sagaId)
			.orElseThrow(() -> new RuntimeException("Saga not found"));

		saga.updateStatusStep(status, step);
		return transferSagaRepository.save(saga);
	}

	/**
	 * 초기 Saga 시작 기록
	 * 메인 트랜잭션과 별개로 항상 저장되어 관리되어야 함
	 * @param fromAccountNumber 출금 계좌
	 * @param toAccountNumber 입금 계좌
	 * @param amount 금액
	 * @return 생성된 계좌이체 Saga
	 */
	@Transactional(propagation = Propagation.REQUIRES_NEW)
	public TransferSaga initSaga(String fromAccountNumber, String toAccountNumber, BigDecimal amount) {
		String generatedSagaId = UUID.randomUUID().toString();
		TransferSaga saga = TransferSaga.newTransferSaga(
			generatedSagaId,
			fromAccountNumber,
			toAccountNumber,
			amount
		);

		return transferSagaRepository.save(saga);
	}
}

💡 왜 별도의 서비스와 REQUIRES_NEW가 필요한가요?

일반적인 모놀리식 개발에서는 비즈니스 로직이 실패하면 모든 데이터가 깨끗하게 롤백되는 것이 미덕입니다.

하지만 SAGA 패턴의 오케스트레이터는 다릅니다.

"비즈니스(송금)는 실패해서 롤백되더라도, '실패했다'는 기록(로그)은 반드시 남아야 합니다."

만약 TransferService와 SagaLogService가 하나의 트랜잭션으로 묶여 있다면 다음과 같은 대참사가 발생합니다.

사용자 송금 요청
Saga 기록: STARTED (메모리에 반영)
외부 계좌 서비스 호출 -> 예외 발생(Exception) & 롤백!
결과: DB가 롤백되면서 2번에서 기록한 STARTED 로그까지 같이 증발함.
문제: 운영자는 송금 시도가 있었는지조차 알 수 없게 됨 (증거 인멸).

이 문제를 해결하기 위해 Propagation.REQUIRES_NEW 를 사용합니다.

이 옵션은 부모 트랜잭션(TransferService)의 존재 여부와 상관없이 항상 새로운 트랜잭션을 열고, 즉시 커밋합니다.

그래서 저는 SagaLogService를 분리하여 프록시가 정상적으로 트랜잭션을 분리할 수 있도록 설계했습니다.

MSA에서의 트랜잭션 : 은행 송금 예제를 통한 SAGA 패턴 학습 (Orchestration)