이슈

백엔드 , 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

웹소켓(채팅 서버) 내의 별도의 보안조치가 필요함

  1. 웹소켓 최초 연결 시 토큰을 검증함. (HandshakeInterceptor)

  2. 웹소켓 세션에 accessToken을 담음(해당 토큰은 만료기간에 상관없이 세션을 식별하기 위한용도)

  3. 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