전체 글

문제점 이전까지 문제 없었던 GithubActions를 통한 CI/CD 과정이 Test를 작성하고부터 실패하는 것을 확인했습니다. -i 로 로그를 찍어봤을 때 레디스에 접근을 못하고 있는 문제였습니다. 깃헙액션은 별도의 서버를 통해 CI/CD를 진행합니다. -> 당연히 빌드를 시도하는 GithubActions 서버에도 사용할 수 있는 Redis 제공해야합니다. 해결방법 - Ubuntu서버에 Docker로 Redis를 띄운다. - Embedded Redis를 이용한다. GithubActions Server에 Redis 띄워주기 아래와 같은 구조를 만들어 줘야 하는거죠 Embedded Redis 저는 이전 프로젝트들에서는 모두 Embedded Redis를 이용했었습니다. 이유는 어떤 환경에서 동일하게 실행이..

😐정리 사용자 구분은 viewCount라는 이름으로 브라우저별 random 값을 가진 쿠키를 이용 상품에 대한 중복 접근 체킹은 브라우저별 랜덤 값을 Key로 Redis의 SET이용(itemId저장) 사용자 구분을 위한 쿠키와 중복 접근에 대한 내용을 저장하는 set의 Key값은 자정에 만료 Redis에서 itemId로 조회수를 저장 -> 일정 시간 후 DB반영 1. 저는 혹시 모를 상황에 대해 구현에서의 편의성을 가져가기 위해 Redis로 중복접근을 체킹했습니다. 하나의 쿠키에 중복접근에 대한 정보를 담았을 때 사용자가 게시글 1000개 이상을 읽는다면 문제 발생 -> 쿠키를 여러 개 이용하는 방식으로 확장해야 함 그러나 하루에 1000개 이상의 게시글을 읽는 경우가 생각보다 많이 발생하지 않을것이고 ..

클라이언트 단에서 SocketJS와 Stomp를 이용해 연결했으며 서버 단은 Spring으로 구성했습니다. 문제가 발생했을 당시 상황 아래와 같은 문제점들은 사실 로컬에서도 발생합니다. 보통 웹소켓 연결 endPoint를 잘못 매칭했거나 웹소켓 연결에 CORS설정을 해놓지 않아서 발생하기에 간단히 해결이 됐습니다. 여기서 저희 팀에서 했던 생각은 endPoint매칭 및 CORS에 대한 대처가 됐다 였습니다. 그러나 배포 환경에서 실행했을 때 Websocket connection failed와 CORS가 발생했습니다. Nginx사용 시 문제점 조금 검색해본 결과 nginx와 Websocket을 함께 사용할 시 주의해야 할 점으로 웹소켓 연결을 위해 아래의 헤더를 추가해줘야 한다는 것이었습니다. locati..