본문 바로가기
T.I.L. :: Today I Learned/항해99 14기 본과정

Day 79. 리팩토링과 기능 개선을 위한 고민

by DaSsom 2023. 6. 20.

SSE 실시간 알림 기능을 위해서 HikariCP DeadLock 문제가 발생하였고 이를 해결하기위해 OSIV 설정을 꺼줌, 이로 인해 DB에 다시 한 번 commit을 해주어야 함. DB에 의도적으로 접근을 해주어야하기 때문에 이 부분이 계속 껄끄럽게 남았다. 그래서 이걸 해결하기 위해 또 다른 기술을 붙여서 개선해볼까 했다. 

 

대안으로 생각중인, 카프카

 

카프카가 무엇이고, 왜 사용하는 것 일까?

메시지 큐와 MOM 출처: https://www.cloudamqp.com/blog/what-is-message-queuing.html 카프카를 이해하기 위해서는 메시지 큐와 MOM을 먼저 알아야한다. 메시지 큐는 분산화된 환경에서 발신자와 수신자 사이에서

hudi.blog

이벤트 / 데이터가 발생했다면 발생 주체가 카프카로 해당 이벤트 / 데이터를 전달하고 필요한 곳에서 직접 가져다가 사용한다. 처리량이 높고 지연시간이 낮아서 대용량 데이터를 실시간으로 처리할 수 있고 모든 메시지를 디스크에 영구 저장하므로 메시지의 내구성이 높다. 카프카 내부에는 여러대의 브로커 서버가 있기 때문에 높은 확장성과 내결함성을 가진다.

 

 

그래서 좀 더 찾아보면 실제로 sse 기능 개선을 위해 카프카를 사용하는 경우도 있음

 

 

Server-Sent Events(SSE), Redis pub/sub, Kafka로 알림 기능 개선하기.

알림이 생성되는 시점이 아니라 클라이언트에서 조회api를 호출해야만 알림이 갱신 됩니다.클라이언트에서 주기적으로 서버로 요청을 보내는 방법입니다.서버에 대한 부담이 크지 않고 요청 주

velog.io

위 블로그에서도 확인할 수 있는데, SSE를 사용하여 실시간 알림 기능을 구현하면 DB Connection이 종료되지 않는 문제가 발생하였다. 그래서 역시 우리와 같은 방법으로 open-in-view 설정을 false로 바꿔주어 해결하였다.

 

카프카가 최선의 대안이 될 수 있을 것이라는 확인은 했지만, 현재 기능 개선을 위해 짧은 개발 시간에 도전을 해야할 지는 의문이다. 개발 속도도 무시할 수 없기 때문에.. 또 카프카에 대해 공부해야만 하고 추가적인 비용이 들어간다고 생각하여 우리가 선택한 방법이 정말 Bad practice일지 고민..! ( 기회가 된다면 나중에 카프카에 대해 좀 더 공부해보고 도입해보는 것으로 결정하였다)

 

그런데 우리가 문제를 해결하기 위해 카산드라를 도입한 것은 조금 아쉬운 것 같긴 하다. 사실 지금 카산드라의 이점은 하나도 사용하지 않고 그저 데이터 저장소만 분리하여 쓰고 있으니.. 결론적으로 카산드라를 사용해서 pending 현상이 잡힌것도 아니어서 괜히 서버에 함께 돌려야하는 아키텍쳐만 늘어난 기분..? 그래서 이 부분도 제거하는게 맞지 않나 싶다.