TIL; 22/05/31(월)

1. Stream vs Batch

5월 커뮤니티 리뉴얼이 끝나고 6월 신규 피쳐 개발 전에 시간이 조금 있어서 백로그의 일감을 하나 처리하기로 맘 먹었다. 재밌어보이는 것도, 어려워 보이는 일감도 많아 고르르는 재미(?) 가 있었다. 그 중에서 내가 고른 일감은 두근두근 코인 시세 배치 -> 스트림 전환!

일감을 고른 이유

• 그동안 신규 피쳐도 나가고 장애대응도 하고 어드민도 뚝딱 만들면서 서버 로직에 경험치가 쌓이던 참이었는데, 시세 쪽은 볼 기회가 많이 없었다. 또 배치랑 스트림은 직접 구현해 본 경험도 없어서 이 기회에 공부도 하고 시세 쪽 로직도 익힐 수 있겠다 싶어서 이걸로 정했다!
• 잘 고른 것 같다.

고민했던 것

• 기존 코인 앱도 1분 마다 시세를 잘 받아오고 있다. 근데 이걸 스트림으로 전환하면 뭐가 좋은지?
  -> 배치 앱은 올라가는 시간이 있어서 처리까지 latency가 발생할 수 있다 등등
• 근데 사실 글로만 읽다 보니 그렇게 막 와닿지 않았던 것도 사실이다.

그리고 발생한 버그아닌 버그같은 너

상황

9시에 수익률 랭킹이 갱신이 되지 않음

이유

랭킹 배치가 10분 마다 돌 때, 로직 수행시간이 2~3분정도 소요된다. 따라서 9시에 배치가 시작되어도 실제 완료 시간은 차이가 있다. + 캐시 반영 등등

깨달은 점

아..! 이게 배치 latency 문제란 이런거구나!! 확 와닿는 순간이었다.

2. 실시간 시세

그래서 사실 제일 궁금한건 그래서!! 실시간으로 시세가 어떻게 나가는 데!!였다. 나에게 실시간이란 막연히 동경하는 미지의 세계였달까.

기존의 이해

• source -> processor -> sink . 그리고 각각을 이어주는 mq - kafka!
• sink에서 가공된 정보를 redis에 저장
• weflux 서버에서 /rates/{stockId} 등의 조회 api 를 제공하고 client 에서 필요할 때 호출하면 시세를 return 해준다.

잘못된 이해

• weflux 서버에서 /rates/{stockId} 등의 조회 api 를 제공하고 client 에서 필요할 때 호출하면 시세를 return 해준다. (x)

올바른 이해

• 시세는 polling 방식이 아니다. 지속적인 HTTP 요청이 발생하기 때문에 리소스 낭비가 발생한다.

• 시세는 SSE 방식이다. 이벤트가 [서버 -> 클라이언트] 방향으로만 흐르는 단방향 통신 채널이다. SSE는 클라이언트가 polling과 처럼 주기적으로 http 요청을 보낼 필요없이 http 연결을 통해 서버에서 클라이언트로 데이터를 보낼 수 있다.

Flux< String > vs Flux < ServerSentEvent >