서론채팅에는 이모지와 댓글이 달려 있을 수 있습니다.그래서 채팅 목록을 조회하면 해당 채팅에 달려 있는 이모지와 댓글의 개수를 채팅 마다마다 달아서 프론트에 응답을 해야 했습니다. MongoDB 같은 경우는 조인 연산이 없어 MySQL처럼 table 조회 시 다른 table을 조인해서 데이터를 가져오는 방식으로 생각할 수 없었습니다.처음 생각 한 수정 전 로직에서는 채팅 목록을 불러온 후 채팅 목록만큼 반복문을 돌면서 채팅에 달려있는 이모지와 댓글의 개수만큼 쿼리가 날아가는 문제가 발생했습니다.그래서 이러한 쿼리 개수를 줄이기 위해 수정한 로직에 대해 글을 작성하려 합니다.수정 전 로직특정 channelId에 해당하는 채팅 목록을 불러오고 해당 값들을 DTO로 변환불러온 채팅 개수만큼 반복문을 돌면서 채..
프로젝트/FitTrip
API GATEWAY에서의 JWT 인증 기반의 프로젝트에서 Socket 인증?현재 FitTrip 프로젝트에서는 클라이언트가 요청 헤더에 JWT를 담아서 보내고 api gateway 쪽에서 헤더에 있는 JWT를 파싱 후 해당 JWT 유효성을 검증하고 있다.그런데 WebSocket의 경우 헤더의 토큰을 담아서 보내던 HTTP 프로토콜과는 완전히 달라 인증 처리를 어떻게 하면 좋을지 고민이었다.api gateway는 웹소켓 연결 요청 라우팅이 가능한가?처음에는 HTTP 요청에 대해서는 api gateway에서 다른 서비스로 라우팅 처리가 가능한 걸 봤지만 웹소켓 연결 요청은 채팅 서비스로 라우팅이 가능할까 라는 의문을 가졌다. 그리고 자료를 찾아보면서 아래와 같은 사실을 찾았다.아래 이미지는 토리맘의 한글라이..
1. MongoDB에서 트랜잭션을 도입한 이유교내 캡스톤 디자인 프로젝트인 FitTrip에서 저는 채팅 서비스를 개발했습니다.채팅 서비스의 구조는 아래와 같습니다.1번 유저가 특정 채팅 서비스로 채팅을 보내면 채팅 서비스에서는 해당 채팅을 MongoDB에 저장하고 카프카의 채팅 토픽으로 전송합니다. 그러면 해당 토픽을 구독하고 있는 다른 채팅 서비스들은 채팅 데이터를 가져와 1번 유저와 같은 채팅방에 있는 유저들에게 채팅을 전송합니다.여기서 문제는 1번 유저가 MongoDB에 데이터 저장을 실패했는데 해당 데이터를 카프카에 보낸 경우입니다.이럴 경우 같은 채팅방에 있는 유저들은 실시간으로 채팅을 볼 수 있겠지만 채팅방을 나갔다가 다시 들어오면 해당 채팅을 볼 수 없는 문제가 발생합니다.(채팅방을 들어왔을..
이번 글에서는 채팅 서비스에서의 몽고DB 데이터 모델링한 과정에 대해 알아보겠습니다.그래서 RDBM 안쓰고 왜 MongoDB 쓰는데? NoSQL/MongoDB 이름만 들어본 분들을 위해 특징 및 사용목적을 간단하게만 짚고 넘어가는 게 좋을 것 같습니다. 인터넷 서비스가 점점 많은 곳에 보급되고 데이터를 전송하는 device의 수가 증가하게 되면서, 전통적인 RDB로는 취급하기 어려운 방대한 양의 비정형 데이터들을 적재하고 처리하기 위해 새로운 data storage가 필요했습니다. 즉, RDBMS의 한계를 극복하고자 함이 NoSQL의 등장 이유입니다. 여기서 말하는 RDB의 한계란 1) 비정형 데이터를 처리하기가 힘들며, 2) 확장성이 떨어지고, 3) 상대적으로 속도가 느린 것을 들 수 있습니다.데이터가..
