Pub-Sub 구조에서 자주 발생하는 실수

Kafka를 통해서 Event Driven Architecture를 만들다 보면 흔히 발생하는 실수가 한 가지 있다.

바로 트랜잭션 종료 전에 Event를 전송하게 되는 것이다.

 

가령 상품을 생성하고 상품 번호를 받아서 후처리를 하는 경우, Subscriber에서 상품 번호로 조회를 하고자 하면 조회가 되지 않을 수도 있다.

 

Publisher와 Subscriber 각각 layer 단위로 테스트 할 때는 발견이 되지 않는 문제다.

또한 개발 서버에서 테스트할 때도 Kafka와 DB의 속도 차이에 따라 테스트 중에 발견이 되지 않을 수도 있다.

다른 팀과 함께 협업을 하는 상황이라면 어디에서 잘못된 것인지 알아채기 굉장히 어려운 경우도 종종 있었던 것 같다.

 

Subscriber 기준에서 Retry 설정을 갖추었다면, 그리고 별다른 로그를 심어 놓지 않았다면 최종적 일관성에 도달하게 되겠지만, 최소 한 번 Retry를 하는 쓰레드가 많아질 것이기 때문에 성능에도 좋지 않은 영향을 미친다.

 

트랜잭션 커밋이 완료된 상황에서 이벤트를 전송하는 것이 결과적으로 좋은 방향이라고 생각한다.

코드 상으로는 Application layer이나 Use Case에 대한 코드가 트랜잭션의 경계가 되는데 이것이 끝나고 난 뒤에 이벤트 호출이 되는 것이 바람직하다고 볼 수 있다. 하지만 이러한 구조를 위해서는 트랜잭션 완료 이후 전송하게 될 데이터를 리턴 받거나 새로 조회할 필요가 있을 것으로 보인다.