SSE 실시간 알림 기능을 위해서 HikariCP DeadLock 문제가 발생하였고 이를 해결하기위해 OSIV 설정을 꺼줌, 이로 인해 DB에 다시 한 번 commit을 해주어야 함. DB에 의도적으로 접근을 해주어야하기 때문에 이 부분이 계속 껄끄럽게 남았다. 그래서 이걸 해결하기 위해 또 다른 기술을 붙여서 개선해볼까 했다.
대안으로 생각중인, 카프카
이벤트 / 데이터가 발생했다면 발생 주체가 카프카로 해당 이벤트 / 데이터를 전달하고 필요한 곳에서 직접 가져다가 사용한다. 처리량이 높고 지연시간이 낮아서 대용량 데이터를 실시간으로 처리할 수 있고 모든 메시지를 디스크에 영구 저장하므로 메시지의 내구성이 높다. 카프카 내부에는 여러대의 브로커 서버가 있기 때문에 높은 확장성과 내결함성을 가진다.
그래서 좀 더 찾아보면 실제로 sse 기능 개선을 위해 카프카를 사용하는 경우도 있음
위 블로그에서도 확인할 수 있는데, SSE를 사용하여 실시간 알림 기능을 구현하면 DB Connection이 종료되지 않는 문제가 발생하였다. 그래서 역시 우리와 같은 방법으로 open-in-view 설정을 false로 바꿔주어 해결하였다.
카프카가 최선의 대안이 될 수 있을 것이라는 확인은 했지만, 현재 기능 개선을 위해 짧은 개발 시간에 도전을 해야할 지는 의문이다. 개발 속도도 무시할 수 없기 때문에.. 또 카프카에 대해 공부해야만 하고 추가적인 비용이 들어간다고 생각하여 우리가 선택한 방법이 정말 Bad practice일지 고민..! ( 기회가 된다면 나중에 카프카에 대해 좀 더 공부해보고 도입해보는 것으로 결정하였다)
그런데 우리가 문제를 해결하기 위해 카산드라를 도입한 것은 조금 아쉬운 것 같긴 하다. 사실 지금 카산드라의 이점은 하나도 사용하지 않고 그저 데이터 저장소만 분리하여 쓰고 있으니.. 결론적으로 카산드라를 사용해서 pending 현상이 잡힌것도 아니어서 괜히 서버에 함께 돌려야하는 아키텍쳐만 늘어난 기분..? 그래서 이 부분도 제거하는게 맞지 않나 싶다.
'T.I.L. :: Today I Learned > 항해99 14기 본과정' 카테고리의 다른 글
Day 81. zombie process? (0) | 2023.06.22 |
---|---|
Day 80. 테스트코드 짜야하는데.. (0) | 2023.06.21 |
Day 78. 본격 유저 피드백 반영 시작 (0) | 2023.06.19 |
Day 77. 이번 주도 열심히 살았다! (0) | 2023.06.18 |
Day 76. 드디어 유저 테스트 시작 ! (0) | 2023.06.17 |