배경


요약 : 마켓 페이지에서 뮤직 카우처럼 특정 거래가 발생했을 경우 최근 거래 내역을 보여줘야 한다.

현재 우리 시스템에서는 주식의 체결 과정이 Kafka로 이루어져 있고 거래 내역이 빠르게 매칭이 되어 발생을 하게 된다. 하지만 현재 시스템에서 결제 내역을 최근 거래 휴양지로 가져오는 경우 컨텐츠의 변화 속도가 너무 빨리 발생할 수 있다는 것이다. 그래서 Kafka에서 Trigger 하여 메시지를 보내는 것보다 더 나은 방식의 거래 휴양지를 가져와야 한다.

물론, 클라이언트에서 주기적으로 서버 API를 호출하여 데이터를 가져올 수 있다. 하지만 클라이언트의 환경은 우리가 제어할 수 있는 영역이 아니고 주기적으로 API를 호출하는 행위도 사용자에게 부담이 될 수 있다.

고려할 사항들


1. 어떤 프로토콜을 사용할 것인가?

클라이언트와 서버가 주기적으로 데이터를 주고 받는 방식에는 4가지가 존재한다. Polling, Long Polling, Streaming, Websocket 으로 각 프로토콜은 서로 다른 장단점을 가지고 있다.

우리가 사용하고자 하는 최근 거래 휴양지는 클라이언트에게 데이터를 받아 응답할 필요가 없다. 단지, 서버에게 데이터를 받을 뿐이므로 Server-Sent-Event가 적합할 것이다.

2. 접속한 사용자마다 데이터의 일관성은 어떻게 유지할 것인가?

적어도, 쿼리에 따라 결과가 사용자마다 달라지면 안된다는 것이다.

최근 거래 휴양지는 사용자마다 동일한 데이터로 유지가 되어야 한다. Polling 방식을 잘 못 사용하게 되면 데이터를 읽어오는데 있어 오전 10시에 접속한 사용자와 오전 10시 10분에 접속한 사용자가 바라보는 데이터가 달라지게 된다. 물론 거래를 함에 있어 거래가 많이 발생을 하면 데이터의 변동이 발생할 수 있다. 하지만 여기서 중요한 점은 우리가 체결 속도가 빠르다는 것을 강조하는 것이 아니고 현재 다른 사용자가 어떤 휴양지에 투자했고 현재 어떤 휴양지가 거래가 되고 있는지 파악하는 것이다.

만약 그렇다면 초기에 접속한 사용자에게 어떻게 데이터를 전달할 것인지가 중요하다. 데이터를 전달할 때 쿼리를 사용하게 되면 데이터의 일관성을 유지하기가 어려워진다. 10시에 접속한 사용자와 10시 10분에 접속한 사용자사이에 데이터 내용이 급격히 다르거나 변경될 수도 있기 때문이다. 물론 현재 사이드 프로젝트 상에서 대규모 트래픽의 증가나 변경이 발생하지는 않을 것이다. 적어도, 쿼리에 따라 결과가 사용자마다 달라지면 안된다는 것이다.

3. 변경한 데이터의 수집은 어떻게 작동시킬 것인가?