2023.05.29 ~ 2023.06.04
일주일 회고
토요일날 코치님과의 멘토링으로 얻어진 결과는 다음과 같다!
- WebFlux는 하지 않는 걸로!
- RDBMS vs NoSQL
- NoSQL 의 트랜잭션 성능이 많이 올라와 단독 사용 고려할 수 있음
- RDBMS, NoSQL 2중화를 통한 이점도 있음. 해볼 것 이 많겠다라는 측면
- redis의 사용여부
- 단점
- 휘발성
- 메모리는 디스크의 가격보다 높음
- 우리가 생각한 추가적인 단점
- redis는 사실 캐시 db로써 자주 사용되는 데이터들을 저장해둬야 함
- 하지만 우리의 의도는 최신 채팅 데이터를 저장하기에 update가 자주 발생하고 본래 캐시 db의 의도를 잃게 됨
- NoSQL
- 빠른 Insert , 낮은 update
- 단점
-
결론적으로 WebFlux는 자료도 적고 코치님도 안해보셨기에 그쪽으로 도움을 받지 못할 것 같기 때문에 포기했다. 하지만 이번 프로젝트가 아닌 다음 프로젝트에는 꼭 한번 적용해서 Flux로 데이터를 흘려보내는걸 겪어보고싶다~~
-
DB는 RDB로 시작을 하지만 빠른 insert와 read 낮은 update 특성을 가진 채팅 시스템에서 Nosql로 점차 변경하면서 성능을 비교해보기로 결정되었다.
-
redis는 캐시db로 사용하기 위해 고려했었다.정말 많은 고민을 했지만 휘발성의 단점과 메세지 큐로 kafka가 대체할 수 있기 때문에 kafka로 구현하기로 결정하였다.
-
이번 주에는 NoSQL과 Kafka구현을 역할을 맡았기 때문에 Nosql 비교와 선정 이유를 정리하고, mysql과 Nosql을 같이 사용하는 버젼과, nosql로 모두 적용한 버젼을 만들었다. kafka까지 로컬에서 띄우고 consumer에 잘 들어오는 것 까지 확인했다. consumer가 정해진 시간마다(default가 1초였나?) 요청하여 offset에 저장한다고 배웠는데 생각보다 바로 반영이 되는 것 같아 놀랐다.
-
kafka 관련해서 정말 많은 이야기를 나눴던 한 주 였다. 왜 사용해야 하는지에 대한 고민과 채팅 시스템에서 kafka가 필요한지.. (코드를 까보니 하나의 consumer가 stomp MQ를 전달 하고있다?), db에 저장하는 처리를 kafka에게 맡긴다면 유저는 채팅이 온전히 db에 저장되었다는 결과를 받을 수 있는지에 대한 보장을 해줄 수 있는지... 등등
-
kafka connection을 통해 해결할 수 있을 것 같지만 실험도 해보고.. 좀더 알아봐야 될 것 같다!
-
이번 주 아쉬운점은.. 잘 진행되고 있는 것 같지만 DB를 변경했는데도 불구하고 mysql 보다 mongodb에서 성능이 낮게 측정되는 이유를 찾지 못했다는점이다. 현재는 ec2 인스턴스 유형이 t2 micro 이기 때문에 cpu 문제일 것이다, 혹은 spring의 thread pool, db connection 문제일 것이다 라는 생각도 했지만 cpu 2core, 4thread 환경인 t3 micro로 변경했음에도 mysql이 더 빠르다는 결과가 나왔다..
-
DB 연결이나 spring 쿼리가 어떻게 날라가고 있는지에 대해 더 알아봐야겠지만 정말 정말 이해가 잘 되지 않는다..! 다음 주 에는 꼭 원인을 찾아내서 해결하고 싶다!
