7편. 상담 애플리케이션 예시와 함께하는 MSA (with Spring Boot)

이전에 진행했었던 데브톡이라는 상담 애플리케이션 예제와 함께 Micro Service 내부 구성에 대해 간략하게 애기해보겠다.

 

1. 상담 Aggregate

예시로 가져온 상담 애플리케이션에 대해 간단하게 설명하겠다.

액터는 상담사, 내담자로 구성되며 현재 가져온 예시는 상담 매칭 Micro Service를 대상으로 한다.

Consultation이라는 도메인 Entity는 아래와 같이 구성되어 있다. 상담이라는 Aggregate는 상담 등록, 수정, 취소, 리뷰 작성에 대한 책임을 갖고 있으며, 여러 Entity와 관계를 가지고 있다.

헥사고날 아키텍처를 엄격하게 따르자면 JPA Entity와 POJO Entity를 구분하는게 맞지만, JPA는 어노테이션 기반으로 그렇게 도메인에 대한 이해를 방해한다고 생각하지 않기 때문에 이 예제에서는 JPA Entity 하나만을 정의했다.

@Entity
@AllArgsConstructor(access = AccessLevel.PRIVATE)
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class Consultation extends BaseTime {

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "consultation_id")
    private Long id;

    @Column(nullable = false)
    private Long productId;

    @Column(nullable = false)
    private Long consulterId;

    @Column(nullable = false)
    private String consulterName;

    @Column(nullable = false)
    private Long consultantId;

    @Column(nullable = false)
    private String consultantName;

    @Column(unique = true)
    private Long paymentId;

    @Embedded
    private ConsultationDetails consultationDetails;

    @Column(nullable = false, length = 20)
    private ProcessStatus status;

    @Column(nullable = false)
    private Money cost;

    @OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL, orphanRemoval = true)
    @JoinColumn(name = "review_id")
    private Review review;

    @OneToOne(mappedBy = "consultation", fetch = FetchType.LAZY, cascade = CascadeType.ALL)
    private ConsultationCancellation consultationCancellation;

    @Column(nullable = false)
    private boolean canceled = false;
    
    ...
    
    public static Consultation createConsultation(Long consulterId, String consulterName,
                                                  Long consultantId, String consultantName,
                                                  Long productId, ConsultationDetails consultationDetails,
                                                  Integer cost) {
        Consultation newConsultation = Consultation.builder()
                .consulterId(consulterId)
                .consulterName(consulterName)
                .consultantId(consultantId)
                .consultantName(consultantName)
                .productId(productId)
                .consultationDetails(consultationDetails)
                .cost(cost)
                .build();
        newConsultation.setStatus(ACCEPT_WAIT);
        return newConsultation;
    }
    
    public void writeReview(Integer score, String content,
                            String photoUrl, String photoOriginName, String photoStoredName, LocalDate reviewAt) {
        if (!this.status.equals(PAID)
                && this.consultationDetails.getReservationDate().isAfter(reviewAt)
                && this.consultationDetails.getReservationDate().plusDays(7).isBefore(reviewAt)
                && this.review != null) {
            throw new BusinessRuleException(REVIEW_IMPOSSIBLE_STATUS);
        }
        this.review = Review.createReview(this.consultantId, this.consulterName, this.consultantId, this.consultantName, score, content);
    }

    private ConsultationCancellation cancel(ProcessStatus status, String canceledReason) {
        this.status = status;
        this.canceled = true;

        ConsultationCancellation consultationCancellation = createConsultationCancellation(this.productId, canceledReason);

        changeConsultationCancellation(consultationCancellation);

        return consultationCancellation;
    }
    ......
}

 

 

2. 상담 승인 Application Service

상담 승인 과정에 대해서 간략하게 말하자면, 내담자가 상담사의 상담 상품을 결제하고 상담사에게 요청을 보내면, 상담사가 승인 혹은 거절 처리를 하게 된다. 이때, 상담 요청을 승인 하는 Use case에 대해서 살펴보겠다.

@Service
@RequiredArgsConstructor
public class AcceptConsultationService implements AcceptConsultationUseCase {

    private final ConsultationQueryableRepo consultationQueryableRepo;
    private final ProductProducer productProducer;
    private final PaymentProducer paymentProducer;
    
    @Transactional
    @Override
    public void acceptConsultation(Long consultantId, Long consultationId) {
        Consultation findConsultation = consultationQueryableRepo.findByIdWithConsultantId(consultationId, consultantId)
                .orElseThrow(() -> new NotFoundException(NOT_FOUND_CONSULTATION));

        findConsultation.accept();
        productProducer.sendConsultationInfoProduct("consultation-topic", findConsultation);
        paymentProducer.sendConsultationInfoPayment("approved-consultation", findConsultation);
    }
}

 

로직을 살펴보면 아래와 같이 크게 4단계로 구성되어 있다.

1. 내담자가 상담을 요청할 때 생성한 상담 Entity를 조회해 (CQRS패턴으로 조회용 QueryableRepo 분리)
2. 상담 Entity의 상태를 "승인됨"으로 변경
3. 상담 상품 이벤트 발행 Producer를 통해 상담 상품 Micro Service에 상품 "구매불가" 상태로 변경 Event 발행 (비동기)
4. 결제 이벤트 발행 Producer를 통해 결제 Micro Service에 상담 "결제 대기" 상태로 변경 Event 발행 (비동기)

 

 

Event 발생 Producer의 경우 DIP를 적용하여, 외부 adapter 패키지에 구현체가 존재하고, 내부 application 패키지에 interface가 존재하는 방식으로 내부 애플리케이션 서비스에서는 Producer Interface를 참조하게 된다.

 

Event Publish, Subscribe 매니커니즘을 위해서는 Kafka를 이용하는 것이 가장 대표적이고, 해당 기술을 Producer나 Consumer 구현체에서 적용하여 구현할 수 있다. 

 

 

3. 상품 상태 변경 Event Producer

이번에는, 상품 상태 변경을 위한 ProductProducer Interface의 구현체인 ProductKafkaProducer에 대해서 얘기해보겠다.

이미 이름에서 유추가능하듯이, Kafka라는 Event Driven Architecture 기술을 적용하여 구현했다.

@Service
@Slf4j
@RequiredArgsConstructor
public class ProductKafkaProducer implements ProductProducer {

    private final KafkaTemplate<String, String> kafkaTemplate;

    public void sendConsultationInfoProduct(String topic, Consultation consultation) {
        String jsonInString = "";
        try{
            jsonInString = serializeMapper().writeValueAsString(consultation);
        } catch (JsonProcessingException e) {
            throw new RuntimeException(e);
        }

        kafkaTemplate.send(topic, jsonInString);
        log.info("카프카 메시지 전송 성공 : " + consultation);
    }

    public ObjectMapper serializeMapper() {
		....
    }
}

상담 Micro Service에서 "상품 승인 상태 변경 토픽"에 대해 ProductKafkaProducer를 통해 이벤트를 발행하고, 해당 토픽을 구독하고 있는 상품 Micro Service에서 ProdcutKafkaConsumer를 통해 해당 이벤트를 읽어 상품 상태를 변경하는 로직까지 실행될 것이다.

 

 

4. 상품 상태 변경 Event Consumer

이번에는 상품 Micro Service의 상품 상태 변경 Event Consumer에 대해서 설명해보겠다.

 

상담 Micro Service로부터 이벤트가 발행된 것이 감지가 되면, 해당 이벤트를 읽어 적절한 로직을 처리하게 된다. 이번 케이스는 상담 상품 승인 상태 변경 로직이 실행될 것이다. 

@Service
@Slf4j
@RequiredArgsConstructor
public class MatchingKafkaConsumer {
    private final CancleUseCase cancleUseCase;
    private final ReserveUseCase reserveUseCase;

    @KafkaListener(topics = "consultation-topic")
    public void receiveConsultationInfo(String kafkaMessage) {
        log.info("Kafka Message: " + kafkaMessage);

        ProductReservedReq productReservedReq = null;
        try{
            productReservedReq = deserializeMapper().readValue(kafkaMessage, ProductReservedReq.class);
        } catch (JsonProcessingException ex){
            ex.printStackTrace();
        }
      
        dataSynchronization(productReservedReq);
    }

    private void dataSynchronization(ProductReservedReq productReservedReq) {
        if (productReservedReq.getStatus() == ProcessStatus.ACCEPTED) {
            reserveUseCase.reserveProduct(productReservedReq);
        }
        if (productReservedReq.getStatus() == ProcessStatus.CONSULTANT_REFUSED
                ||productReservedReq.getStatus() == ProcessStatus.CONSULTANT_CANCELED
                || productReservedReq.getStatus() == ProcessStatus.CONSULTER_CANCELED){
            cancleUseCase.cancleConsultation(productReservedReq);
        }
    }

  	.....
}

 

여기까지, 상담 Micro Service 예제를 이용한 설명이었다. 역시🤔, 개발자는 코드로 설명하는 것이 가장 편하고 직관적이라고 생각한다.