[MSA] 선물하기 프로젝트_Flow설계 및 검토

Flow설계 및 검토

 

선물하기 도메인의 경우 일반 주문과 달리, 주문 과정에서 배송지 주소를 확정할 수 없습니다. 선물하기 주문을 결제한 사람이 해당 주문을 지인에게 선물로 전달하고, 이 후 수령자가 본인의 배송지 주소를 입력해야 배송이 시작되는 구조이기 때문입니다. 또한, 수령자는 선물을 수락하거나 거절할 수 있는 선택이 있기에 거기에 맞는 Flow도 함께 고려를 해야합니다. 

 

선물하기의 특성 상 배송지 주소를 주문 과정에서 확정을 지을수 없기 때문에 주문 API에 요청을 할 경우 일반적으로 3가지 방법을 사용한다고 합니다. 경우에 따라서 적절한 방법을 채택해야 합니다.

 

• 기존 주문 API 수정

기존의 API를 수정할 경우 배송지 주소는 필수값으로 처리가 되는 경우가 있는데 선물하기는 배송지 주소가 필수값이 아니기에 기존 API에서 배송지 주소를 필수값으로 하지 않을 수가 있습니다. 이러한 경우 신규 서비스 구현을 비교적 쉽게 가져갈 수 있는 장점이 있지만 기존 주문처리 과정에서 배송지 주소가 빈값으로 등록될 수 있는 경우의 수가 생기는 단점이 있습니다.

 

• 기존 주문 서비스에 API 추가

주문 도메인에 선물하기로 요청이 들어올 경우 그에 맞는 신규 API를 하나 더 생성을 하는 방법입니다. 이와 같은 방법은 기존 주문 등록 프로세스를 방해하지 않고 신규 API로 선물하기 주문등록을 처리할 수 있습니다. 그러나 선물하기처럼 유사한 도메인들이 생길 경우 그 만큼의 신규 API가 생긴다는 단점이 있을 수 있습니다.

 

• 신규 서비스에서 기존 API Spec 맞추기

기존 API의 Spec을 맞춘다는 것은 기존 API에서는 배송지 주소가 필수값이므로 신규서비스에서는 배송지 주소값을 TEMP값으로 임의의 값을 넘겨줍니다. 기존의 API를 변경하는 일이 없어집니다. 빈값이 아닌 TEMP값으로 넘기는 이유는 MySQL같은 경우 빈값보다는 TEMP값이 들어있는 것이 인덱스를 사용할 때 효과적입니다.

 

 

 

서버간 호출 flow 및 설계 검토

 

선물하기 서비스와 주문 서비스의 위상을 생각하면, 주문 서비스가 선물하기 서비스에 비해 좀 더 보편적이고 다른 서비스에게 기능을 제공하는 역할에 가까울 수 있습니다. 그렇기 때문에 때문에 주문 서비스에서는 다른 서비스의 프로퍼티나 로직이 포함되지 않도록 지속적으로 신경쓰고 관리해야 주문 서비스를 통한 확장성이 유지될 수 있습니다. 그러므로 양방향 호출보다는 단방향 호출로 설계를 하는 것이 좋습니다. 다음 그림은 서버간 전체 flow를 간략히 도식화한 것입니다.

 

 

그렇지만 주문 서비스의 세부 flow를 검토하면, 선물하기 서비스와 주문 서비스 간의 단방향 의존 관계를 가지는 것이 쉽지 않음을 알 수 있습니다. 주문 서비스의 세부 flow는 사용자가 상품을 주문을 하면 PG 결제 화면에서 결제 수단을 선택을 할 것이고 선택한 결제수단으로 PG사에 결제 요청을 할 것입니다. 결제가 완료되면 PG서비스에서 주문 서비스로 응답이 오는 구조로 생각해볼 수 있습니다.

PG의 flow가 추가되면서 선물하기 서비스와 주문 서비스가 양방향 의존 관계를 가지는 것을 알 수 있습니다. 양방향 관계가 추가될 때마다 도메인 로직의 flow를 파악하기가 어려워지며, 주문 서비스가 callbackUrl 실핼할 때, 이를 받아서 처리하는 서비스가 장애 상황이라면 callbackUrl 요청이 유실될 가능성이 있습니다. 이러한 양방향 관계를 개선하기 위해 서비스 간에 메시지 브로커를 두고 메시지 기반 비동기 통신으로 처리할 수 있습니다. 

주문 서비스의 결제 성공 후 message broker에 성공 메시지만 발행하면, 해당 메시지를 수신할 서버가 어디인지 알 필요가 없게 됩니다. 선물하기 서버가 장해 상황이라도 추후 서비스 복구 후에 message broker의 메시지를 읽어서 주문 성공 처리를 할 수 있게 됩니다.

 

* kafka

 

Apache Kafka는 실시간으로 기록 스트림을 게시, 구독, 저장 및 처리할 수 있는 분산 데이터 스트리밍 플랫폼입니다. 이는 여러 소스에서 데이터 스트림을 처리하고 여러 사용자에게 전달하도록 설계되었습니다. 간단히 말해, A지점에서 B지점까지 이동하는 것뿐만 아니라 A지점에서 Z지점을 비롯해 필요한 모든 곳에서 대규모 데이트를 동시에 이동할 수 있습니다.

 

Kafka의 multi consumer 구조를 활용한다면, 주문 서비스를 활용하는 클라이언트가 지속적으로 추가되어도 모든 클라이언트가 결제성공 메시지를 받을 수 있습니다. 주문 서비스에서는 결제 성공 후 보편적인 주문 성공 메시지를 Kafka에 던지고, Kafka를 바라보는 클라이언트는 해당 메시지를 읽어서 각자의 결제 성공 후의 로직을 처리합니다. 다만, 메시지 내부에는 해당 주문의 클라이언트가 어디인지를 구분하는 구분값이 있어야 하고, 각 클라이언트는 자신의 메시지인지를 확인하는 필터링 로직이 추가되어야 하는 단점이 있습니다.