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

[Spring] kafka 파헤치기현재 캡스톤 프로젝트에는 사용자 개인의 마인드맵 CRUD 과정이 이루어지는 기능이 들어간다. 간단히 말하자면,1. 사용자가 마인드맵을 생성 (마인드맵의 Root Node 생성)2. 사용자가 마인드맵을 수sksmsfbrjs51.tistory.com  이전 포스트에서는, Kafka의 필요성과 Kafka가 어떤 구조로 이루어져있는지 분석해보았다. Kafka를 활용하여 지속적으로 마인드맵 데이터를 Producer에게 전송하여 이를 DB 및 Client에게 전송해줘야 하는 구조임을 알게 되었다. 하지만 여기서 걸리는 것이, 그럼 결국 Publisher에게 호출한 토픽이 같은 경우, 가장 마지막에 요청된 Topic으로 DB에 저장, 수정되거나 사용자에게 반환해줘야 하는게 아닌가? ..

현재 캡스톤 프로젝트에는 사용자 개인의 마인드맵 CRUD 과정이 이루어지는 기능이 들어간다. 간단히 말하자면,1. 사용자가 마인드맵을 생성 (마인드맵의 Root Node 생성)2. 사용자가 마인드맵을 수정 (마인드맵에서 노드를 생성하고 가지를 뻗어나가는 과정)  이때, 사용자의 지속적인 마인드맵 수정 작업이 이루어지는 로직을 기획하고 있었다.[x, y 좌표 배치 및 노드 데이터 변경] 현재는 데이터베이스에 직접 end-to-end 방식으로 API를 호출하는 방식으로 아키텍쳐를 구상한 상황이지만, 크게 4가지의 잠재적인 문제점을 내포했다.  1. 시스템 복잡도의 증가중앙화된 데이터 전송 영역이 없어, 데이터의 흐름을 파악하기 어렵고, 시스템 관리가 복잡함.시스템의 일부분에 문제가 발생하면, 연결된 모든 애..

현재 상황캡스톤 프로젝트를 진행하면서 다음과 같은 디렉터리 구조를 가지고 있는 상황이다. 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..