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

이 포스트는 우아콘 2020 발표 중 김영한 님의 '마이크로서비스 여행기'에 일부 내용을 리뷰하였습니다.

 

카프카를 이용한 Event 전달

이전 직장에서 기존 API Call로 데이터 동기화하던 부분을 Kafka로 변경했었다.

 

그 이유는 다른 회사와 동일하게 API 요청을 받는 서비스가 죽었을 때 그 서비스를 참조하는 다른 서비스도 연쇄적으로 장애가 발생하기 때문이다.

 

그래서 Kafka를 통해 Producer 서비스에서 Event를 생성하고, Consumer 서비스에서 필요에 따라 Event를 Consumed 하는 것 까지는 좋았으나 그 후 한 가지 과제가 더 남아 있었다.

 

그래서 Event Data Format은요?

이 부분에 대하여 논의할 때 가장 신경 쓰이는 부분은 두 가지였다.

1. 데이터 포맷 컨벤션을 어떻게 정할 것 인가?
2. 만약 해당 Event를 Consumed 하는 서비스에서 필요한 데이터 형식이 각기 다르다면 이 요구사항을 어떻게 모두 충족시킬 것 인가?

결국 해당 Event를 소비하거나 앞으로(미래에) 소비할 서비스들에서 필요할 것이라 생각되는 데이터를 최대한 많이 담아서 Event Data Format을 만들고 서비스하였다.

 

하지만 되돌아 생각해보면 이러한 설계는 변경에 취약한 부분이 있다.

 

Zero-Payload?

https://youtu.be/BnS6343GTkY - 우아콘2020 김영한님의 '배달의민족 마이크로서비스 여행기' 영상 중 일부

이번 우아콘 2020에서 김영한 님이 발표하신 부분 중 이 부분이 가장 공감이 많이 되었다.

 

만약 가게 정보가 변경되었다면 가게 ID만을 담은 최소한의 Event를 만들어서 Produce, 이후 해당 정보의 동기화가 필요한 서비스에서 API Call 하여 디테일한 정보를 동기화

 

이와 같이 설계한다면 새로운 요구 사항에 따라 Event 데이터가 재설계될 필요는 없을 것이다.

그저 각 서비스에서 필요한 데이터를 담은 API를 따로 관리해주면 된다.

또한 이벤트의 순서 보장을 고민할 필요가 없다.

API Call을 통해 동기화받는 정보가 항상 최신일 거라 신뢰할 수 있기 때문이다.

 

다만 이 방식에서도 두 가지 의문점이 있다.

1. 애초에 최소한의 Event Message를 전달받고자 하는 서비스에서는 오버 엔지니어링 발생

• A라는 서비스는 많은 정보가 필요하지 않다. 그저 2~3개의 필드에 대한 정보만 받으면 그만이지만 설계가 Zero Payload로 통일돼버리면 굳이 API Call을 추가로 진행하여 정보를 받아와야만 한다.
  • 이러한 문제점은 A와 같은 서비스들을 위해 ID값뿐만 아니라 최소한의 정보를 넘겨주는 것으로 해결될 수 있을 것 같다.

2. Event를 발행하는 서비스 장애 시 연쇄 장애 발생 가능성 존재

• 만약 B라는 서비스가 Event를 발행하였고, A라는 서비스가 해당 Event를 Consumed 후 필요하여 API Call → 이때 B가 장애 상황이라면 A 역시 연쇄 장애 발생
  • B라는 서비스는 트래픽이 많이 몰리지 않는 특성을 갖고 있어야 할 것 같다. 즉, 이벤트를 발행하는 주기가 빈번하지 않으며 혹여나 연쇄작용으로 A가 장애가 발생하더라도 다른 서비스에 영향을 주지 않는 서비스 간 결합도가 최소한으로 설계되어져 있어야 할 것이다.