부하를 적절하게 축소하기 - 서비스 분리 feat MSA..

😀 과제 개요

• 내가 개발한 기능의 트랜잭션 범위에 대해 이해하고, 서비스의 규모가 확장되어 MSA 형태로 서비스를 분리한다면 어떤 서비스로 분리 확장될지 설계하고, 그 분리에 따른 트랜잭션 처리의 한계와 해결방안에 대한 서비스 설계문서 작성

해당 과제의 이유는 한 트랜잭션이 길어질 경우에 대한 대비이다. 트랜잭션 안에 트랜잭션이 불필요한 로직에서 시간이 많이 소비 될 수 있다. 또한 로직이 길어 서로 연관관계가 없을 로직이 실패하게 된다면 전체가 롤백 되어버리기도 한다. 외의 데드락 문제 등을 야기 할 수 있다.

 

이 과제의 핵심은 서비스 분리의 확장으로 보이지만, 사실 트랜잭션을 나눠주는 작업이 중요할 것이다. (MSA 또한 그러한 문제를 해결하기 위함이 있으니..?)

---

📚 시작하기 앞서.. MSA란?

- 도메인 중심을 중심으로 서비스를 모델링하고 구현하는 아키텍처

- 분리된 도메인 서비스들은 HTTP API 또는 비동기 메시징 방식으로 통신

- 여러 어플리케이션으로 나누어서 각 서버에 배포해서 서로 간에 통신을 통해 서비스를 제공

(일단은 도메인에 따라 따로 서버를 구축한다..정도로.. 갈길이 멀다..(벌써 엉덩이가 아파온다))

 

💻 MY 콘서트 대기열 도메인

0. Token (대기열)

  > Redis로 대체되었음 (정확히는 분리되어 MSA가 필요 없음)

1. Wallet (사용자 포인트)

  1.1. 포인트 조회

  1.2. 포인트 충전

2. Reservation (예약)

  2.1 예약 가능 날짜 조회

  2.2 예약 가능 좌석 조회

  2.3 예약

3. Payment (결제)

  3.1. 결제

      3.1.1. 콘서트 임시예약 -> 예약으로 확정

      3.1.2. 좌석 임시예약 -> 예약으로 확정

      3.1.3. 포인트 차감 (금액 부족 시 충전필요)

      3.1.4. 포인트 사용 히스토리 저장

 

!. 정리

해당 서비스는 1번의 사용자 포인트 부분과 2번의 예약은 그대로 떼어내도 될 정도로 해당 기능만을 사용한다. 하지만 3번의 결제는 예약 정보도 불러야하며, 포인트 부분도 불러야 한다. 그럼 딱 2가지로 나눠볼 수 있을 것 같다.

 

!. 변경

1. Wallet (사용자 포인트)

  1.1. 포인트 조회

  1.2. 포인트 충전

  1.3. 포인트 차감 (금액 부족 시 충전필요)

  1.4. 포인트 사용 히스토리 저장

2. Reservation (예약)

  2.1 예약 가능 날짜 조회

  2.2 예약 가능 좌석 조회

  2.3 예약

  2.4. 콘서트 임시예약 -> 예약으로 확정

  2.5. 좌석 임시예약 -> 예약으로 확정

3. Payment (결제)

  2.1 Wallet의 포인트 차감을 가져옴

  2.2 Reservation의 예약확정을 가져옴

 

이렇게 두개의 어플리케이션으로 분리하면 대충 답이 나올 것 같다는 생각이 들었다. 순서도와 코드를 확인해보자.

현재

    public class PaymentService {
    
        @Transactional
        public PaymentCommand.getPaymentInfo pay(PaymentCommand.Pay pay) {
            LocalDateTime now = LocalDateTime.now();
            Long currentTokenUserId = requestTokenUtil.getCurrentTokenUserId();

            // 콘서트 예약 (상태 확정으로 변경)
            ConcertReservation concertReservation = concertReservationRepository.findById(pay.concertReservationId());
            concertReservation.reserved();

            // 콘서트 자리 확정으로 해준다.
            ConcertSeat concertSeat = concertSeatRepository.findById(pay.seatId());
            concertSeat.setSeatStatusAssign(now);

            // 금액 차감
            usePointWithOptimisticLock result = getUsePointWithOptimisticLock(currentTokenUserId, now);

            // 히스토리를 쌓는다.
            walletHistoryRepository.save(getWalletHistory(result.wallet(), result.price(), result.balanceBefore(), result.balanceAfter(), now));

            return new PaymentCommand.getPaymentInfo(예약정보들..);
        }
        
    }

1. 콘서트를 먼저 예약확정 -> 금액차감을 한다 이 로직은 분리하려니 이상해 보였다.
2. '결제'라는 로직으로 분리하려하니, 편의점에 들어갔을 때가 생각이 났다. 담배를 사려고 "프렌치블랙 주세요."라고 말하면 내가 결제할 때까지 담배는 주지 않는다.
3. 그럼  결제라는 행위자체는 포인트 차감에 있다. 순서를 금액 차감 ->콘서트 자리 확정으로 해야한다.
4. '콘서트 자리 확정'은 결제와는 거리가 있다. 물론 결제는 물건을 사는 행위이지만,  '자리 확정'은 마치 쿠팡에서 물건을 사도 배송을 기다려야 하는 것 처럼 그 다음의 행위가 될 수 있다.
5. 물론 다른 방면으로는 '결제'에 '콘서트 자리 확정'을 묶을 수는 있다. 다만 이번에는 분리에 목적이 있으니 최대한 쪼개 보자.

1차 수정로직 (도메인 별로 나눈다)

    public class PaymentPacade {
    
        @Transactional
        public PaymentCommand.getPaymentInfo pay(PaymentCommand.Pay pay) {
            LocalDateTime now = LocalDateTime.now();
            Long currentTokenUserId = requestTokenUtil.getCurrentTokenUserId();

            // 금액 차감 및 히스토리를 쌓는다.
            Wallet result = walletService.getUsePointAndSaveHistory(currentTokenUserId, now);
		
            //예약 확정
            ConcertReservation reservResult = resevationService.reserved(pay.concertReservationId(), pay.seatId(), now);
            return new PaymentCommand.getPaymentInfo(예약정보들..);
        }
        
    }

        
    public class ResevationService {
    
        pulbic ConcertReservation reserved(Long concertReservationId, Long seatId){
            // 콘서트 예약 (상태 확정으로 변경)
            ConcertReservation concertReservation = concertReservationRepository.findById(concertReservationId);
            concertReservation.reserved();

            // 콘서트 자리 확정으로 해준다.
            ConcertSeat concertSeat = concertSeatRepository.findById(seatId);
            concertSeat.setSeatStatusAssign(now);
            
            retrun concertReservation;
        }
        
    }

1. PaymentPacade에서 각각 wallet과 reservation의 서비스를 불러오는 식으로 만들었다.
2. 이상한 점이 있다. 분리 하는 이유는 '도메인 별로 분리 확장'도 있지만, 불필요한 트랜잭션을 만들지 않는 것이다.
3. 하지만 위는 같은 트랜잭션으로 묶이게 된다. 나눠보자.

2차 수정로직 (트랜잭션을 나눈다. feat Event)

    public class PaymentPacade {
    
        @Transactional
        public PaymentCommand.getPaymentInfo pay(PaymentCommand.Pay pay) {
            LocalDateTime now = LocalDateTime.now();
            Long currentTokenUserId = requestTokenUtil.getCurrentTokenUserId();

            // 금액 차감 및 히스토리를 쌓는다.
            Wallet result = walletService.getUsePointAndSaveHistory(currentTokenUserId, now);
		
            //예약 확정
            reservedEventPublisher.publishEvent(pay);
            
            return new PaymentCommand.getPaymentInfo(예약정보들..);
        }
        
    }

        @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
        pulbic void reserved(PaymentCommand.Pay pay){
            // 콘서트 예약 (상태 확정으로 변경)
            ConcertReservation concertReservation = concertReservationRepository.findById(pay.concertReservationId);
            concertReservation.reserved();

            // 콘서트 자리 확정으로 해준다.
            ConcertSeat concertSeat = concertSeatRepository.findById(pay.seatId);
            concertSeat.setSeatStatusAssign(now);
           
        }

 

1. 위 처럼 하면 Event를 이용하기에 트랜잭션의 범위가 나뉘게 되며, 따라서 결합력까지 낮추게 된다.

2. 다만 문제가 있다. 만약 '예약 확정' 로직에서 예외가 터진다면?

3. 상황에 따라 다르겠지만 위의 경우, 포인트 차감은 롤백이 되어야 한다.

 

3차 수정로직 (롤백 정책)

    public class PaymentPacade {
    
        @Transactional
        public PaymentCommand.getPaymentInfo pay(PaymentCommand.Pay pay) {
			...
            //포인트 차감
            pay.Wallet(wallet);
            //예약확정 이벤트 호출
        }
        
    }

        @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
        pulbic void reserved(PaymentCommand.Pay pay){
           try {
            // 콘서트 예약 (상태 확정으로 변경)
            ConcertReservation concertReservation = concertReservationRepository.findById(pay.concertReservationId);
            concertReservation.reserved();

            // 콘서트 자리 확정으로 해준다.
            ConcertSeat concertSeat = concertSeatRepository.findById(pay.seatId);
            concertSeat.setSeatStatusAssign(now);
           } catch(Exception e) {
           		log.warn("오류발생");
                포인트차감롤백Publisher.publishEvent(pay);
           }
        }
        
        @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
        pulbic void RollbackPoint(PaymentCommand.Pay pay){
            try {
            	Wallet wallet = pay.wallet;
            	wallet.RollbackPoint(pay);
           } catch(Exception e) {
           		재시도 로직..
           }
        }

1. 예외가 터지면 포인트를 차감하는 롤백을 또 불러와야한다.

2. 롤백 로직에도 또 예외가 터질 수 있다. 그럼 어떻게 할 것인가??????? 

 

        @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
            public void rollbackPoint(PaymentCommand.Pay pay) {
                int attempts = 0;
                boolean success = false;
        
                while (attempts < MAX_RETRIES && !success) {
                    try {
                        Wallet wallet = pay.wallet;
                        wallet.rollbackPoint(pay);
                        success = true; // 성공하면 반복문 종료
                    } catch (Exception e) {
                        attempts++;
                        if (attempts >= MAX_RETRIES) {
                            // 로깅 또는 알림 추가 가능
                            log.warn("재시도 횟수 초과: " + e.getMessage());
                            
                            //**DB에 해당 실패 정보를 담아준다
                        } else {
                            log.warn("재시도 중... 시도 횟수: " + attempts);
                }
            }
        }
    }

 

1. 이렇게 재시도 후에도 계속 예외가 터진다면 어쩔 수 없다. 해당 정보를 잘 조합해 db에 담는다.

2. DB에 담긴 정보를 후에 배치에 돌린다. 그래도 안되면 개발자에게 알림을 발송해서 해당 프로그램을 수정해야 한다는 생각이 들었다.

3. 마지막으로 해당 로직이 MSA로 수정된다면?

 

4차 수정로직 (MSA..?)

    public class PaymentPacade {
    
        @Transactional
        public PaymentCommand.getPaymentInfo pay(PaymentCommand.Pay pay) {
            LocalDateTime now = LocalDateTime.now();
            Long currentTokenUserId = requestTokenUtil.getCurrentTokenUserId();

            // 금액 차감 및 히스토리를 쌓는다.
            Wallet result = walletService.getUsePointAndSaveHistory(currentTokenUserId, now);
		
            //예약 확정
            reservedEventPublisher.publishEvent(pay);
            
            return new PaymentCommand.getPaymentInfo(예약정보들..);
        }
    }

        @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
        pulbic void reserved(PaymentCommand.Pay pay){

			//아웃박스 패턴?
            String result = reservedClient.reserved(pay);
				
            if(result.equals("fail")){
            	//재시도 로직
                // 재시도 실패 시 DB 저장..
            }
        }

 

1. 위의 로직처럼 다른 api를 호출해서 정보를 받는다.

2. 실패시 재시도 로직을 사용한다.

3. 만약 api 요청 중에 대상 api에서 문제가 생겨 연결이 끊긴다면 아웃박스 패턴을 사용한다고 한다.

4. 호출 부분의 해당 요청을 db에 넣고 잘 도착했을 때에 db에 도착완료로 상태 값을 넣어주는 식으로 해당 요청의 성공여부를 판단할 수 있게 된다.

 

 

끝으로

아직 트랜잭션 분할에 대해 미숙하여 많이 미흡했다. 작은 설계이지만 트랜잭션을 어떻게 분리해야 되는지에 대한 감을 잡는 소중한 시간이었다고 생각한다.