안녕하세요, 오늘은 최종프로젝트 문서화 작업한 내용을 정리해 보았습니다.
트러블슈팅
-
문제 :
어드민 작업중에 프론트에서 백엔드 데이터를 가져오지 못하는 문제가 발생했습니다.
어디서부터 접근해야 하는지에 대해 고민하면서 여러가지 방법을 시도했습니다. -
해결과정:
- 백엔드 페이지네이션 로직이 프론트 로직과 매칭되지 않았을 수 있겠다고 판단하여 페이지네이션 로직 삭제하고 매칭시도해보았습니다. 그러나 해결되지 않았습니다.
- 프론트 디자인을 따로 해두고 후에 백엔드를 연결하다 보니, 안맞았을 수도 있겠다 판단하여, 백엔드 로직 기준으로 프론트 디자인 단순하게 구현해서 연결해보았습니다. 그러나 해결되지 않았습니다.
- 인가 문제일수 있겠다는 생각에 WebSecurityConfig에서 /api/admin/** permitAll 해보았으나 마찬가지로 해결되지 않았습니다.
- 로그인 정보에 토큰이 들어가지 않아서 그럴 수 있다고 판단되어, 프론트 토큰 로직을 확인해보았습니다. 로그인 후에 토큰을 받아오지 못하고 있었고, 로컬 스토리지에 토큰을 받아 오도록 로직 변경을 하고 문제가 해결되었습니다.
- 결론:
이와 같은 케이스를 포함하여 백엔드와 프론트를 연결할 때, 다양한 문제가 발생하였습니다.
이 때, 이번 케이스처럼 다각적으로 문제에 접근하되, 개발자 모드를 활성화하여 네트워크, 콘솔, 어플리케이션 등을 확인하여 메시지를 통해 문제의 범위를 좁혀 들어가는게 보다 효율적이라는 걸 깨닫게 되었습니다.
기술적 의사결정
- 동시성 제어 적용할 대상 선택
- 스코프 확장 차원에서 동시성 제어를 구현해보기로 결정하였고, 그 대상에 대해서 결정이 필요했습니다.
- 1안은 포인트로 상품을 구매할 수 있는 기능 추가였습니다.
- 2안은 챌린지 참가인원 제한 기능 추가였습니다.
- 1안의 경우 테이블을 추가하고 구현해야 하는 api가 단순 CRUD의 반복이 많았기 때문에, 기존 api가 구현되어 있어서 비교적 CRUD 추가작업이 적고, 똑같은 동시성 제어 상황을 제공할 수 있는 2안으로 결정하였습니다.
- 동시성 제어 구현 방법 선택
- 참가인원 제한이 선착순 개념이기 때문에 락을 획득한 트랜잭션에서만 참가 신청이 가능하게 하고, 락을 획득하지 못한 트랜잭션은 읽기만 허용하도록 하는게 가장 알맞은 방법이라고 판단하였습니다.
- 이러한 상황과 특징을 고려하여 비관적 락을 ( Shared lock, PESSIMISTIC_READ ) 적용하였습니다.
- 낙관적 락의 경우 동시 요청에 대해 DB에 락을 걸지 않고 많은 사용자가 동시에 데이터에 접근할 수 있는 장점이 있었습니다.
- 그러나 참가인원 제한 로직이 결국, 참가하기 버튼을 클릭하면 아주 짧은 시간안에 로직이 실행되고 종료되므로 위의 장점이 크게 다가오지 않고, 반면에 version 컬럼을 추가하고 변경사항이 발생할 때 버전이 올라가는 로직과 예외처리 등을 추가해야하는 코드적인 복잡도가 올라가기 때문에 낙관적 락을 배제하였습니다.
새로운 시작~!