제로페이로드

안녕하세요.

 

이번 글은 이벤트 관련해서 글을 써보고자 합니다.

주제는 밑의 내용 중 제로페이로드의 관한 내용이 있길래 공감되어서 쓰게 되었습니다.

회원시스템 이벤트기반 아키텍처 구축하기 | 우아한형제들 기술블로그

 

zero-payload란

요청의 본문 payload 부분이 없다는 것을 의미합니다.

해당 방식은 모니터링, 하트비트 등에서 사용됩니다.

데이터 전송량을 줄이고, 네트워크 대역폭을 절약하면서도 지속적인 모니터링이 가능하다는 장점이 있습니다.

 

 

MSA에 도입

 

 

B서비스가 A서비스의 의존하고 있을 때가 있습니다.

A서비스가 행동을 하면 부가적인 행동은 B서비스가 해야 할 경우입니다.

예를 들어, A서비스가 주문을 할 경우 B서비스는 포인트를 추가해 줍니다

B는 A서비스에서 무엇이 어떤 행동을 했는지 알아야 그에 따라 알맞은 행동을 할 수 있습니다.

주문 취소의 경우는 포인트를 차감해야 하니 취소 또는 주문인지를 판단해야 합니다.

 

 

A서비스가 무엇을 했는지 B에게 알려주는 방법은 여러 가지입니다.

직접 API를 호출해 정보를 알려주거나, 이벤트 큐에 적재시키는 것입니다. 

그러나 이러한 방식에는 몇 가지 단점이 존재합니다.

단점

1. 장애 전파

API 방식을 사용했을 경우 A서비스는 B서비스를 호출합니다. 하지만 B서비스가 다운된 상태라면 A서비스는 주문이 취소되는 일이 발생합니다.

물론 fallback 장치등을 해 놓으면 장애 전파는 피할 수 있습니다.

 

이벤트 방식을 사용하면 장애를 피할 수 있습니다.

다만 데이터 동기화의 문제는 있습니다.

 

2. 이벤트 순서

저도 고민했던 것이 이벤트에 따라 순서를 지켜야 하는 경우가 있었습니다. 예로 create와 update의 경우 craete보다 update가 먼저 들어오면 예외가 나는 것입니다.

그래서 FIFO의 기능이 있는 SQS FIFO를 썼던 기억이 있습니다.

 

카프카의 경우는 토픽에 파티션 내부는 순서를 보장하지만 여러 개의 파티션이 있을 경우는 순서를 보장할 수 없습니다.

1 파티션 1 컨슈머이면 순서를 보장할 수 있겠네요.

이를 위해 key값을 두는 등의 조치를 취할 수 있습니다.

 

하지만 위의 방식대로 하면 불필요한 조치를 한다고 생각되었습니다.

 

3. 데이터 포맷

A서비스가 B서비스에만 이벤트를 전파할 경우 데이터 포맷은 2개의 부서가 말을 맞추어 정할 수 있습니다.

하지만 여러 서비스가 A서비스를 구독할 경우에는 각 서비스마다 원하는 정보가 달라 데이터 포맷이 커지거나 매번 추가를 위해 배포를 다시 해야 할 것입니다.

 

 

---

 

이때 우아한 형제들은 제로페이로드 방식을 적용한 것으로 보입니다.

설명드리기 전에 간단히 말씀드리면 B서비스에서 A서비스의 정보를 직접 조회하는 것입니다.

 

 

제로페이로드의 장점은 API를 통해 직접 조회하기 때문에 가장 최신의 정보를 얻을 수 있다는 것입니다.

따라서 zero-payload 방식은 API 방식에서 발생할 수 있는 문제를 피하면서 최신 정보를 얻을 수 있는 효과적인 방법입니다.

 

 

단점

1. B서비스는 최소한의 정보를 받고자 할 경우 굳이 API까지 쓰면서 많은 정보를 받아올 수 있다는 것입니다.

이는 최소한의 정보라면 이벤트 payload에 넣어서 해결할 수 있을 것 같습니다.

 

2. A서비스는 B서비스에서 오는 트래픽까지 처리해야 하기 2배의 트래픽을 받는 구조가 될 것입니다.

A서비스와 B서비스가 트래픽을 적절히 소화할 수  있는 아키텍처가 되어야 할 것입니다.

 

 

 

 

 

Microservice Communication Patterns

 

[우아콘2020] - Zero Payload 방식 리뷰