Skip to content

2021 02 22 회의록

Jump to bottom
Donggeon Lee edited this page Feb 22, 2021 · 2 revisions

진행상황

이동건: jwt 인증토큰 생성로직 완료. 기존의 AccountController 적용이 필요함.

  • 현재의 구조는 jwt 토큰에 주어진 email값 (사용자 고유 데이터)을 토대로 DB에 다시 조회를 요청해서 특정 값을 가져오는 구조. jwt 토큰을 사용한다면, 굳이 모든 요청에 다시 DB까지 가지 않아도 조회하거나 접근할 수 있는 기능이 있어야 할 것 같음.
  • 어떤 데이터를 jwt에 담을 것인지.... 기존 서비스의 동작방식을 더 알아야 해결할 수 있음.

문예은: chatting 고도화

  • rabbitmq로 채팅 데이터 producer / consumer로 처리하도록 변경 (현재는 채팅데이터를 queue로 넘기는 동시에 broadcast하는 구조)
    • 여러 서버에서 rabbitmq를 구독할 때, 동일한 서버 내에서 접속한 사용자끼리만 subscribe한 메시지가 전송되는 문제가 있음. (구독한 메시지를 다른 서버의 구독자에게 전송하는 게 안되고 있음)
    • 해결법: pub / sub은 redis로, chat data의 consumer는 데이터베이스로 이원화하는 방식을 고려 중.

논의해볼 점

  • jwt 토큰에 넣어서 DB호출을 줄일 만한 필드값에는 무엇이 있는지?
    • 현재 프론트에서 필요로 하는 데이터 중 DB호출 없이 바로 넘겨줄 수 있는 데이터들에는 어떤 것이 있을지
  • DB값이 변경되었을 때 -> 토큰에 어떻게 반영할 것인지. (새로운 방에 입장했다거나 할 때)
  • jwt 토큰에 많은 값을 넣게 될 경우 개인정보 이슈 -> jwt payload값 자체를 다시 암호화하는 방법은 어떨까
  • 현재 rabbitmq에서 consumer가 메시지를 가져가는 구조는 round robin. A서버에서 보낸 채팅메시지를 B서버에서 받아 저장하는 구조. => 안정적인가? 만약 B서버에서 mongoDB 커넥션만 죽은 채 서버가 돌고 있다면? 대안은?
    • noSQL 특성상 중복허용 / Eventual Consistency를 지향하는 구조. 각 서버마다 mongoDB에 각각 데이터를 저장하고, mongoDB 노드끼리 데이터 정합성을 맞추는 방식이라면 오히려 괜찮을 것 같다.
    • 그러면, rabbitMQ에 연결된 모든 서버에 동일한 메시지를 전송해야 한다는 것을 의미하고, 즉 Queue 개수가 서버 개수만큼.. 생겨야 한다 (one connection, one channel per one queue라고 함). kafka로 partitioning하는 이유가 이건가 혹시 (rabbitmq는 메모리에 저장하고, kafka는 파일 시스템으로 저장한다고 함)
  1. 프로젝트 분리 시 기존 api 서버에서 사용하던 데이터 같은 경우 공통모듈로 빼서 사용 ? or api 요청으로 가져옴? (아마 후자가 맞겠죠..?)

할일

  • 이동건: 인증된 사용자가 접근하는 로직들 확인하고, jwt로 옮길 수 있는 것들 / 옮길만한 것들 체크한 뒤 프엔과 같이 셋이 회의
  • 문예은: 채팅 작업 진행 + 서비스 분리
Clone this wiki locally