📌 Outline

<aside> 💡 콘서트 예약 서비스 시나리오 시스템 확장에 따른 MSA로 서비스 분리하는 방안과 분리했을 때의 문제점, 해결 방안을 고려합니다.

</aside>

• 도메인 : 유저, 콘서트, 대기열, 결제

🔍 분석

<aside> 💡 각 서비스 간의 기능을 분석하고 분리 대상 서비스를 판별합니다.

</aside>

• 유저 서비스

  • 기능 : 사용자 정보 관리, 사용자 포인트 관리
  • 분리 고려 사항
    • 확장성 : 사용자 수의 증가에 따라 독립적으로 확장 고려
    • 포인트 관리 : 사용자 포인트 시스템의 독립적인 관리 및 확장 고려
  • 우선순위 : 중간
    • 이유 : 사용자 포인트 관리와 같은 기능은 독립적인 확장이 필요하지만, 다른 서비스보다 우선순위가 낮음.

• 콘서트 서비스

  • 기능 : 콘서트 정보 관리, 좌석 상태 관리, 좌석 예약 관리
  • 분리 고려 사항
    • 확장성 : 콘서트 관련 로직의 독립적 확장 고려
    • 성능 : 콘서트 조회 및 예약 시 성능 최적화 고려
  • 우선순위 : 중간
    • 이유 : 콘서트 같은 경우 독립적인 확장과 성능 최적화가 중요하지만, 복잡한 비지니스 로직이 많지는 않음.

• 대기열 서비스

  • 기능 : 대기열 관리
  • 분리 고려 사항
    • 확장성 : 대기열 관리 로직의 독립적 확장 가능
  • 우선순위 : 낮음
    • 이유 : 이미 레디스 기반으로 구현되어 있어 성능과 확장성 문제가 크지 않음.

• 결제 서비스

  • 기능 : 결제 처리
  • 분리 고려 사항
    • 확장성 : 결제 관련 로직의 독립적 확장 고려
    • 재사용성 : 결제 서비스는 시스템 확장 시 타 서비스에서도 이용할 수 있도록 재사용성이 중요
    • 복잡한 비즈니스 로직 : 포인트 차감, 대기열 토큰 만료, 좌석 배정, 데이터 플랫폼 전송, 카카오톡 메세지 발행 등 여러 서비스와의 연계 로 인해 높은 복잡성과 결합도를 가지고 있음.
    • 긴 트랜잭션 범위 : 결제 과정에서 여러 서비스와의 연계로 인해 긴 트랜잭션 범위를 가지고 있으며, 이는 성능에 영향을 미치고 데이터베이스 락 경합을 증가시킬 수 있음.
  • 우선순위 : 높음
    • 이유 : 결제는 시스템 확장 시 타 시스템에서도 결제 기능을 이용할 수 있고, 복잡한 비즈니스 로직과 여러 서비스와의 연계로 인해 높은 복잡성과 결합도를 가지고 있어 우선순위가 높음.

  서비스	주요 기능	분산 고려사항	우선순위	이유
  유저	사용자 정보 관리, 사용자 포인트 관리	확장성, 포인트 관리	중간	포인트 관리 및 사용자 증가에 따른 확장 필요
  콘서트	콘서트 정보 관리, 좌석 상태 관리, 좌석 예약 관리	확장성, 성능	중간	독립적인 확장, 성능 최적화 필요
  대기열	대기열 관리	확장성	낮음	레디스 기반으로 성능과 확장성 문제 적음
  결제	결제 처리	확장성, 복잡한 비지니스 로직	높음	타 시스템에서도 결제 기능 사용 필요, 복잡한 비즈니스 로직

📝 요약

• 서비스 분리 대상 : 결제 서비스
  • 확장성
    • 결제 서비스는 시스템 확장 시 타 서비스에서도 결제 기능을 사용할 수 있도록 독립적인 서비스로 분리하여 재사용성과 확장성을 높일 수 있습니다.
  • 복잡한 비즈니스 로직의 관리
    • 결제 서비스는 포인트 차감, 대기열 토큰 만료, 좌석 배정, 데이터 플랫폼 전송, 카카오톡 메세지 발송 등 여러 서비스와의 연계 가 되어 있어 높은 복잡성과 결합도를 가지고 있습니다. 서비스 분리를 통해 결제 서비스에서는 결제 정보 저장 및 이벤트 발행만 담당하고, 나머지 도메인 로직은 이벤트를 통해 각 도메인 서비스에서 처리하도록 하여 도메인 관심사를 분리할 수 있습니다.
  • 오버엔지니어링 방지
    • 모든 서비스를 분리할 경우 트랜잭션 보장을 위한 불필요한 관리 포인트가 증가할 수 있습니다. 따라서, 최우선 순위인 결제 서비스만 분리하여 오버엔지니어링을 방지하고 효율적인 관리를 도모합니다.

📌 서비스 분리 후 구조 변화

• AS-IS

  • Facade에서 관련 서비스가 연계 되어 있어 높은 복잡성과 결합도

    @Component
    @RequiredArgsConstructor
    public class PaymentFacade {
    
        private final QueueService queueService;
        private final PaymentService paymentService;
        private final ConcertService concertService;
        private final UserPointService userPointService;
        private final PushClient pushClient;
        private final DataPlatformClient dataPlatformClient;
    
        @Transactional
        public PaymentResult.Pay pay(String token, PaymentCommand.Pay command) {
    
            // 1. 좌석 소유권 배정 (예약됨 > 점유)
            ConcertResult.AssignSeat seatResult = concertService.assignSeat(command.getReservationId());
    
            // 2. 포인트 잔액 차감
            UserResult.UsePoint pointResult = userPointService.usePoint(new UserCommand.UsePoint(command.getUserId(), command.getPrice()));
    
            // 3. 대기열 토큰 만료
            queueService.expireToken(token);
    
            // 4. 결제 정보 저장
            PaymentResult.Pay paymentResult = paymentService.createPayment(command);
            
            // 5. 데이터 플랫폼 전송
            dataPlatformClient.send("결제완료", paymentResult);
            
            // 6. 카카오톡 전송
            pushClient.sendKakaotalk("결제완료", paymentResult);
            
            return paymentResult.toBuilder()
                    .userId(command.getUserId())
                    .point(pointResult.getPoint())
                    .build();
        }
    }
    

• TO-BE

  • 서비스 분리를 통해 결제 서비스에서는 결제 정보 저장 및 이벤트 발행만 담당하고, 나머지 도메인 로직은 이벤트를 통해 각 도메인 서비스에서 처리하도록 하여 도메인 관심사 분리

🖋️ 고려 사항

• 결제 서비스는 높은 트랜잭션 일관성이 요구되지만, 서비스 분리 시 분산 트랜잭션로 인해 일관성 유지에 문제가 발생할 수 있습니다. 이를 해결하기 위해 사가 패턴과 보상 트랜잭션을 고려 할 수 있습니다.