이슈
백엔드 , DevOps 이슈 , 협업 이슈관리 대장
백엔드, DevOps 이슈
여러 서비스가 하나의 인스턴스에서 처리될 경우 엄청난 부하가 예상됌
서비스별 인스턴스(서버)를 둠으로서 부하를 분산
2024-11-10
서비스 별 프로젝트를 진행중 , 동일한 설정(Config, 공통응답코드)에 있어 유지보수에 있어 어려움을 느낌
멀티 모듈프로젝트로 전환 , 서비스별 모듈을 나누고 , 공통모듈을 따로 둠
2024-11-12
사람을 매칭해주는 로직에서 요청자에 대한 매칭 결과를 산출하기 전
다른 사람이 매칭 대기열에 접근하여 데이터정합성을 깨는 문제가 일어남
레디스 분산락을 도입하여 정합성 문제 해결
2024-12-02
배포과정에서 Junit 통합테스트가 돌아가기전 mysql 컨테이너가 뜨기전에 테스트가 먼저 되어버려 datasource가 주입되지않는 현상
workflow 파일 내 명시적으로 mysql컨테이너를 먼저 띄우고 , healthCheck를 통해 충분한 시간보장을 한 뒤 Junit 통합테스트 진행
2024-12-04
RDBMS 수정 트랜잭션(회원정보 수정 등) 에서 만약 기본 값을 읽고 , 그 값에 대한 수정을 하는 작업일 때 , 그 시점에 다른 사람이 해당 데이터를 읽어 수정하면 데이터 정합성이 깨질 위험이 예상됌.
SELECT FOR UPDATE를 통해 읽기작업시 행 단위 잠금 수행
2024-12-10
매칭, 채팅 서버는 분산환경이므로 웹소켓,sse의 연결이 어느 인스턴스에 되어있는지 모름
Redis Pub/Sub 도입
2024-12-12
웹소켓(채팅 서버) 내의 별도의 보안조치가 필요함
웹소켓 최초 연결 시 토큰을 검증함. (
HandshakeInterceptor)웹소켓 세션에 accessToken을 담음(해당 토큰은 만료기간에 상관없이 세션을 식별하기 위한용도)
Stomp 전환 이후 통신과정에서의 토큰검증 추가 (ChannelInterceptor)
2024-12-22
채팅웹소켓 서버에서 I/O 작업(데이터베이스) 까지수행하면 부하가 심할것으로 예상됌
채팅웹소켓 서버와 , 채팅 I/O작업 서버를 나누어 웹소켓서버에서 I/O작업시 WebFlux(WebClietn) API 호출을 통해 비동기로 처리
2024-12-27
협업이슈(보라색 : 주요이슈)
헤더로 부터 받은 토큰이 프론트엔드에서 접근이 불가함
백엔드 서버내 토큰에 대한 헤더 노출설정
2024-12-02
백엔드에서 Stomp 웹소켓 통신개발 중 테스트를 할 만한 도구가 없음 ( 개발중 테스트 불가)
프론트엔드 - > stomp 테스트 화면 제작 , 제공
2024-12-20
최초 채팅목록리스트에서 상대 채팅회원의 기본정보, 최근 채팅 메시지정보에 대해 정상 채팅방, 채팅방을 나간회원, 탈퇴한 회원에 대한 데이터를 어떻게 가공할지에 대한 고민이 생김
탈퇴한 회원 존재한 채팅방일시 비정상 플래그 , 채팅방을 나간 회원이 있을시 UNACTIVE상태로 주어 프론트엔드에서 UI가공
2024-12-29
STOMP통신을 할때마다 채팅방 목록을 refresh를 하는상황은 서버에게 상당한 부담이 가고 , 반복적인 I/O작업으로 많은 부하를 줄것으로 예상됌. 해결책이 반드시 필요함
최초 채팅방 목록 조회, 새로운 채팅방 생성 시 등 정합성이 매우중요한 상황에서는 API를 호출하고 ,
그 외 STOMP 웹소켓 통신간에는 optimistic update로 UI를 업데이트하여 사용자 경험을 증진시킨다.
데이터 정합성을 위해 5분간격으로 react query로 sync를 맞춘다.
2024-12-29
Last updated