Cloud Pub/Sub Overview - ep.1

# 해당 포스팅은 Google Cloud Tech Youtube의 Cloud Pub/Sub 관련 영상을 기반으로 작성하였습니다.

 

 

Cloud Pub/Sub Overview - ep.1

 

우리가 온라인 쇼핑몰에서 상품을 주문할 때 아래 사진과 같은 서비스 과정을 거치게 된다.

 

 

1) order manager service receive that users order

-> 유저의 주문을 주문 관리 서비스가 받는다.

 

2) send a message to packaing service and processing (packaging product, send a message to the shipping)

-> 주문이 들어왔음을 상품 출고 서비스(예를 들면 옷 회사)에 알리게 되고, 상품이 출고된다.

-> 또한 상품이 출고되었음을 운송 업체에 알린다. 

 

3) shipping service does the necessary processing (ship the packages and sends a message)

-> 운송 업체가 상품을 잘 배송했다면 결과를 알림 서비스에 보낸다.

 

4) In the same way, the order and packaging service also send messages to the Notification service to send to the
customer the updated information on their order.

-> 같은 방식으로, 주문 관리 서비스와 상품 출고 서비스 역시 알림 서비스에 메시지를 보내서 주문이 잘 처리되었음을 알린다.

 

이러한 방식에는 크게 두 가지 문제점이 발생할 수 있다.

 

1) 너무 복잡한 Flow를 가진다 (just complecated)

2) 만약 서비스 제공 과정 중에 실패한다면? (if Fail Packaging Service)

 

즉, 상품의 재고가 다 떨어져서 출고가 불가능하다면, 재시도 메커니즘(Retry)이 필요하다

 

 

만약 아래 그림처럼 Central Store에서 모니터링 해준다면? (여기서 중요한 건 말 그대로 모니터링이란 것이다)

 

할 수는 있지만 작업량이 많다.

 

그에 대한 예로 테스트에 대해 생각해보자

 

만약 A란 서비스를 테스트하려고 한다.

근데 A란 서비스가 B, C 서비스에 영향을 미치고 있다.

그러면 모든 서비스를 테스트 해야 한다.

 

이러한 테스트를 Central에서 관리하고 있다면 위에서 말했듯 작업량이 너무 많아질 것이다.

 

 

만약 3 instance 를 위에 그림처럼 두고 LB를 둔다면?

 

그럼에도 주문을 취소하는 방법, 주문이 어느 단계에 있는지, 여전히 취소할 수 있는지 알 수 없다

 

이러한 문제점을 해결하기 위해 적합한 것이 Google Cloud Pub/Sub이다.

 

영상에서는 Google Cloud Pub/Sub을 다음과 같이 표현하고 있다.

 

Cloud Pub/Sub is a fully managed, real time messaging service that allows you to send and receive messages between independent applications.

 

즉, 독립된 Application들에게서 메시지, 즉 작업 수행을 지시하고 결과를 받을 수 있는 real time 서비스라는 것이다.

 

Once an event is successfully published as a message, it becomes the job of the service to ensure that all the systems that need to react to this event get it.

 

예를 들어 사진에서 보면 주문이 들어왔다면, 그리고 그 주문에 성공적으로 Pub/Sub에서 게시되었다면(메시지를 받았다면)

이 이벤트에 반응해야 하는 모든 Applicatioin, 그림에서는 오른쪽 3개의 서비스가 이벤트를 받을 수 있도록 한다는 것이다.

 

처음의 그림과 달라진 점들을 살펴보자.

주문 서비스는 메시지를 패키징 서비스에 직접 보내는 대신 Pub/Sub로 보낸다.

패키징 서비스 및 알림 서비스는 푸시 또는 풀을 통해 이러한 메시지를 수신한다.

패키징 서비스는 배송 서비스에 직접 메시지를 보내는 대신 Pub/Sub로 메시지를 보낸다.

그리고 이벤트는 배송 및 알림 서비스로 접수된다.

결론적으로 패키징 서비스는 이 이벤트를 수신하는 서비스(알림 서비스)를 알 필요가 없다.

마찬가지로 배송 서비스는 주문 및 알림 서비스가 해당 메시지를 가져오거나 받는 Pub/Sub로 메시지를 보내기 때문에 알림 서비스를 알 필요가 없다.

 

그럼 위에서 봤던 모니터링 서비스는 에로우가 하나만 필요하게 된다

 

 

이렇게 Cloud Pub/Sub를 사용하여 문제를 해결할 수 있다.

 

 

개념 자체는 어렵지 않다.

 

결국 중앙화된 서비스가 추가된 것이 아닌가? 틀린 말은 아니다.

 

하지만 만약 이 서비스를 우리가 구현해야 됐다면..? 🙃

 

이 부분이 어떻게 사용되는지 다음 포스팅에서 알아보자.

 

https://www.youtube.com/watch?v=cvu53CnZmGI