지금까지 배운 트러블 슈팅에 대해 고민하신 후, 가장 적합하다고 생각하는 트러블 슈팅을 스택별로 한 가지 작성해 주세요!
- FE
- BE
프로젝트에 새롭게 도입한 기술이 있다면 정리해 주세요! (도입 이유도 꼭 적어주세요!)
- FE
- BE
이번 주 한 일
- 팀 전체 (리더님께서 필두로 정리해 주세요.)
- FE: 프로젝트 전체 UI 작업 및 배포 준비
- BE: 코드 리뷰 및 리팩토링, MySQL → PostgreSQL 이관작업 중, nginx(무중단 배포 작업)
- 팀원 개인별로 작성해 주세요.
- 송두용
- 유하정
- 천옥수
- 최산하
- 이예진
- 강성지
이외에도 기술적인 방향을 잡기 위한 질문을 정리해오시면 가장 좋습니다!
- 새 멤버 가입, 새로운 채팅 알림 기능
- 채팅 → 메시지 브로커 서버 증설 필요성
- 4인 채팅 후 CPU 20% 확인
- 모임 조회 방식 변경
- 현재: 좌표 기준 가까운 10개 모임
- 개선: 좌표 기준 5Km이내의 모임
- 모임 필터링 요청 방식 개선
- 검색 페이지 개선: 스택검색, 추천 모임
- 커스텀 에러코드
Q. 모임에 참여한 시간을 구하고 싶은데 시작 시간과 끝나는 시간을 뺀 값을 DB에서 쿼리문으로 데이터를 가져와서 처리해야 하는지(쿼리문), 아니면 시작 시간과 끝나는 시간을 가져와서 자바에서 서비스 로직으로 처리해야하나요? -> DB에서 처리를 하면 RDS의 성능이 저하가 될 것이고, 자바에서 처리를 하면 EC2의 성능이 저하될 것이다.
- 현재는 자바에서 서비스 로직으로 처리를 하고 있다.
- 나중에 scheduler 로 계산을 일괄 처리해도 좋을 듯
- 스프링 배치 → join문 한 번에 데이터 가져올 수 있도록 만드는 것도 좋다
Q. 현재 기능별로 디렉토리 구조를 나누어 가독성을 높였는데, 코드를 짜다보니 서비스에서 다른 디렉토리의 레포지토리를 사용하게 되었습니다. 결국 해당 reposoitory는 사용하지 않았는데 이 방법이 맞는 부분인지 궁금합니다. 예. 채팅 부분에서) 채팅 서비스에서 멤버 레포지토리만 가져오고 채팅 레포지토리는 사용하지 않았던 부분
- chat service →member repository (o) 서비스에서 레포 가져오는 건 ㄱㅊ
- member respository → chat service (x) 레포에서 서비스 가져오는 건 안됨
- 다른 디렉토리의 레포지토리를 가져오는 것은 어쩔 수 없음 (클린 아키텍처 읽어보자)
Q. 단일 EC2에서 Docker로 서버를 2개 돌린 뒤 (8080, 8081), health 체크를 진행하는 경우 (https 로드 밸런서) 서버가 다운되는 현상
-
ec2 서버의 스크립트 내용 중, health 체크를 진행하는 시간 동안 (1~2분), Out of Memory
-
원인: CI/CD 스크립트에서 2개의 서버가 돌아갈 때, CPU 및 메모리 급상승
- 서버 1개 메모리: 약 500M → 2개를 동시에 돌린 상황에서 health 체크를 기다릴 여유가 없다..
-
해결 : 서버 스케일 업하거나, health 체크를 진행 x → 무중단배포 포기
⇒ 약 10초 정도 502 badgate 발생
-
-
아키텍처 전체 개편
⇒ 기존에 사용하는 [ 단일서버 + nginx + docker ] 에서 [ beanstalk + docker ]
⇒ beanstalk에서 제공하는 무중단배포로 전환
⇒ 서버 재배포시, 새로운 인스턴스에 서버를 띄운 뒤에 health 체크 통과하면, 기존 EC2 인스턴스 삭제
- 단점: EC2 인스턴스를 생성하고, 서버를 띄우고 health check까지 진행하면 약 4분 정도 소요 ‘
A. 블루그린 , 카나리 , 롤링 차이점, 우리가 이 기술을 적용한 이유에 대해…
4~5분 걸리는 것은 문제 X
Q. WebSocket, 무슨 이유인지 서버가 멈추는 현상
⇒ 원인 찾는 중
Q. 리프레시 토큰 기능: 403에러가 발생하면 리프레시 토큰을 서버로 보내 인증 후 엑세스 토큰을 재발급
- 1안: 엑세스 토큰이 필요한 요청의 경우, 응답한 에러의 코드가 403일 때 리프레시 토큰 api를 요청합니다. 응답받은 엑세스토큰을 다시 로컬 스토리지에 저장하고, 기존의 에러가 발생했던 api를 재요청합니다.
- 2안: 엑세스 토큰을 로컬 스토리지에 저장 할 때 마다 토큰의 유효시간을 계산해 유효시간이 끝나기 전 리프레시 토큰 api를 호출해 엑세스 토큰을 업데이트 합니다.
→ 1안으로 처음 리프레시 토큰 기능을 개발했지만, 웹소켓 통신의 경우 리프레시 토큰을 구현하는 방법을 찾지 못해, 2안으로 변경하였습니다. 2안의 경우 호출 스케쥴을 setTimeout 함수를 이용하고 있는데, 이 경우 별도로 고려해야 할 부분이 있는지 궁금합니다.
숙제: 멘토링 결과 다음 주까지 해올 일
-
팀 전체 (리더와 부리더님께서 필두로 정리해 주세요.)
-
팀원 개인별로 작성해 주세요.