문제 상황현재 상황은 다음과 같다. FE : http://localhost:3000BE : https:// ~~ FE에서 BE에 로그인 요청을 보내는 과정인데 다음과 같은 에러가 발생했다. 즉, OAuth2 로그인 과정 자체에서 실패해버리는 것. 과정은 다음과 같다. 1. server_domain/oauth2/authorization/kakao 접속2. localhost:3000/api/auth/callback?code={code} 로 리디렉션3. 해당 임시 코드를 가지고 서버에 Token 발급 API 호출4. Response Body에 AT를, Set-cookie 헤더에 Refresh Token을 발급 쿠키 정책에서 문제가 생긴다. 쿠키를 응답에 추가하는 방식이 문제일 가능성Cookie refres..

문제 상황팀원으로부터 로그인이 되지 않는다는 보고를 받게 되었다... 현재 로그인 로직이 어떻게 되어있냐면 소셜 로그인 진입소셜 로그인 성공 시 임시 코드를 발급하고 콜백 URL에 리디렉션 시켜준 뒤, redis에 만료기한을 1분으로 하여 저장클라이언트는 해당 code를 쿼리 파라미터에 넣어서 API를 호출함. 호출 시 서버에서 AT, RT를 발급하여 반환해주는 로직 그런데, cloudwatch의 로그를 보니까 다음과 같이 로그인은 성공하는데 Redis에서 에러가 발생한다. 즉, Redis에 값을 삽입할 때 나는 문제였다 해결 과정1. Redis Read Replica 설정 문제현재, docker redis image를 pull 받아와 컨테이너에서 돌아가고 있는 상황이다.따라서, redis-cli에..

로깅 및 API 호출 전 사용자 권한 필터 등 다양한 곳에서 로직이 호출되기 이전, 이후에 공통적으로 처리해야 할 기능들이 존재한다. 대표적인 예로 Logging, 인증, 인가, 인코딩 변환 등등이 있다. 공통적인 기능의 코드를 모든 모듈 및 페이지에서 작성하게 되면 코드의 중복이 발생하게 되고 MSA 기반에서는 각 모듈마다 다른 코드가 작성되어 관리가 힘들 수 있다. 이럴 때 filter, Interceptor, AOP를 사용할 수 있다. 🍎 Filter, Interceptor, AOP 차이 - 호출 시기 1. FilterFilter는 Spring이 실행 되기 전에 실행되며 WAS (Tomcat) 에서 처리를 해주게 된다. Request / Response 즉, HTTP 프로토콜로 들어오는 모든 요청..

현재 상황캡스톤 프로젝트를 진행하면서 다음과 같은 디렉터리 구조를 가지고 있는 상황이다. Repo- .github- frontend- backend- gpt... 현재 EC2 내에는 Spring Boot Jar file과 Docker Container에서 Redis Image를 pull 받아와야 하는 상황이다. 일일이 Docker 명령어를 입력하여 container image를 pull 받아오는 것보다 docker-compose를 통해 한 번에 Docker Container에서 이미지를 pull 받아오고자 해당 방법을 진행했다. DB는 RDS를 활용하여 구축했기에, Docker-compose에는 담지 않았다.하지만, EC2 내 로컬 DB를 활용한다면 docker-compose.yml에 DB 관련 코드를 ..

지금까지 프로젝트를 했던 것들을 짚어봤을 때 JWT 토큰을 사용하기 위해 com.auth0.java-jwt 라이브러리를 사용하거나 io.jsonwebtoken (jjwt) 라이브러리를 사용하는 경우가 있었다. com.auth0가 더 좋다, jjwt가 더 좋다 이런 말들이 많아서 직접 조사해보고 정리해보았다.  1. com.auth0:java-jwt💡 장점가볍고 간결한 API코드가 직관적이며, JWT의 생성 및 검증 과정이 상대적으로 간단함.빌더 패턴을 활용한 사용성 향상JWT 생성 시 JWT.create() 메서드를 사용하여 체인 방식으로 쉽게 설정 가능.JDK 내장 라이브러리만 사용별도의 외부 의존성이 거의 없음. (java.security 및 java.util 기반)토큰 검증 시 Claim을 쉽게 ..

매일메일을 통한하루 1개 CS 공부하기 CAP 정리Distributed DataBase System이 CAP 중 2개의 속성만을 제공할 수 있다는 이론Consistency(일관성)모든 Client의 요청은 어느 노드에 연결되어도 같은 데이터를 볼 수 있음Availability(가용성)노드 일부에 문제가 발생하여도 시스템은 클라이언트의 모든 요청에 유효한 응답을 전해줄 수 있어야 함Partition Tolerance(분할 내성)노드 사이에 통신이 불가능한 상황(파티션)에서도 시스템이 계속 동작 3가지 속성을 모두 만족하는 분산DB 시스템은 존재하지 않는다 💡 각 속성 별 조합 예시 3개의 분산 DB가 존재한다고 가정해보자. 해당 분산 DB System에서는 특정 서버에 Write 작업이 발생하면, 나머지..

매일메일을 통한하루 CS 공부하기 캐시 스탬피드 현상이란?대규모 트래픽 환경에서 캐시를 운용하는데, Cache Aside (캐시 미스 발생 시 적재) 전략을 사용한다고 가정하자. 수많은 요청들이 동시에 캐시 미스를 확인하고 원본 저장소에서 데이터를 가져와 캐시에 적재는 상황이 발생할 수 있다. 이를, 캐시 스탬피드 현상 또는 Thundering Herd 문제라고 한다. 이 현상은 원본 DB와 캐시의 성능을 저하할 수도 있다.  문제 해결 방안1. Locking 방식한 요청 처리 스레드가 해당 캐시 키에 대한 Lock을 획득한다. 이 때 다른 요청 스레드는 잠시 대기한다. Lock을 가진 스레드는 사용자 request에 응답하는 과정동안 캐시 적재 작업은 비동기 스레드로 처리할 수 있다. Lock을 사용하..

매일메일을 통한하루하루 CS 공부하기 Cache Aside (Lazy Loading) 방식Cache hit 시 캐시에서 데이터를 불러오며, Cache miss 시 원본 DB에서 조회하여 반환한다 애플리케이션은 Cache miss가 발생하면 해당 데이터를 캐시에 적재한다. 장점실제 요청된 데이터만 캐시에 저장되므로 불필요한 데이터 캐싱을 줄일 수 있다.캐시에 문제가 발생해도 애플리케이션은 원본 데이터에 직접 접근할 수 있기 때문에 서비스가 계속 작동할 수 있다.단점Cache miss가 발생하는 경우에만 데이터를 캐시에 적재하기 때문에, 원본 데이터와 캐시가 일치하지 않는 Cache Inconsistency가 발생할 수 있다.초기에는 대량의 캐시 미스로 인해 DB 부하 발생 가능 Cache Inconsist..