Request Response 방식

VOD 구독 서비스 예제

예시모델로 사용자 구독 요청을 처리하는 Subscription Service, Payments Service, Recommendations Service를 가정한다.

1. 모든 사용자 정보를 구독서비스로 보내기
2. 구독서비스에선 구독 데비터베이스를 업데이트한 후 결제 서비스에 요청
3. 결제서비스에서는 제3자 신용카드 처리 서비스와 연결하고 확인을 받으면 결제 데이터베이스를 업데이트하고 추천 서비스에 요청
4. 추천서비스가 데이터베이스를 업데이트하면 결제서비스에 응답 전송
5. 결제서비스는 구독 서비스에 응답 전송
6. 구독 서비스는 사용자에게 구독완료 페이지를 보여주기 위한 응답 데이터를 프론트엔드에 전송

장점

• 구독 (요청)이 성공적으로 이루어지고 여러 서비스가 모두 요청을 수신하고 처리했음을 100% 보장하는 것이 가능

단점

• 서버간 요청이 많아짐에 따라 사용자를 매우 긴 시간동안 기다리게 할 수 있다.
  • 100% 보장이 가능하고 모든 것이 원활하게 되어도 부정적인 사용자 경험을 줄 수 있다.
  • 제3자 서비스와 통신할 때 문제가 발생하거나, 서비스 간 연결에 문제가 생겨 재시도를 요구하는 경우 더욱 더 오랜 시간을 기다리게 될 수 있다.

Optimize Limitation

• 5번의 결제 서비스로부터 응답을 받기 전에 구독서비스에서 사용자에게 확인을 보내는 요청을 보낼 수 없다.
  • 결제 서비스에서 실패하거나 요청을 받지 못한 경우, 청구요금에 문제가 생길 수 있다.
• 결제 서비스를 최적화하려고 추천 서비스의 응답을 기다리지 않고 먼저 응답하는 경우, 데이터 일관성이 없는 상태가 발생할 수 있다.
  • 구독에 포함된 추천 또는 개인 맞춤 기능을 사용자가 제공받지 못할 수 있다.

해결방안

Orchestration Service

오케스트레이션은 API와 결합될 수 있지만, 별도의 서비스로 가정.

1. 모든 사용자 정보를 오케스트레이션 서비스로 보내기
2. 오케스트레이션에서 각각의 서비스에 병렬로 트랜잭션 요청
3. 모든 트랜잭션 완료 후 프론트엔드에 응답 전송

장점

• 기존 지연시간 = Subscription + Payment + Recommendation
• 변경된 지연시간 = Max(Subscription, Payment, Recommendation)

문제점

1. 여전히 지연시간이 문제될 수 있다.
   1. Payment Service에서 제3자 신용카드 처리의 성능문제가 발생하거나, Recommendation Service에서 추천 알고리즘의 평균적인 지연시간이 문제될 경우 등 여러 case를 고려해야 한다.
2. 오케스트레이션 서비스가 트랜잭션에 필요한 서비스와 강하게 결합된다.
   1. 서비스의 API들이 변경되거나, 다른 신규 서비스가 추가로 필요하게 될 경우, 오케스트레이션 서비스를 업데이트하여 해당 서비스를 호출해야 한다.
   2. 이는, 의존하는 서비스들의 갱신이 오케스트레이션 서비스의 재배포로 이어진다는 말과 같다.
3. 연결되는 일부 서비스에 문제가 발생한다면 모든 구독요청을 거부해야 한다.

결론

Request/Response 로 구성된 아키텍처에서는 API 요청이 성공하는 것을 보장하는 응답데이터를 반환하는 것이 가능하다.

하지만, 전체 서비스가 커지고, 트랜잭션이 복잡해짐에 따라 서비스 성능저하 및 지연시간에 따른 부정적인 사용자 경험을 유발하는 요소가 존재한다.

이를 위해 오케스트레이션 서비스라는 대안이 있지만, 완벽한 Silver bullet은 아니며, 결합도를 낮추기 위해 MSA를 도입했지만, 오히려 결합도를 높이는 결과를 불러오게 될 수 있다.