동일한 테스트 환경을 구성하기 위해서 도커로 서버를 띄우려고 했다.근데... Redis, Rabbitmq, Mysql 모두 도커로 사용하다 보니 이들을 docker-compose.yml을 이용해서 브릿지 네트워크를 구성해줘야 했다. version: '3.8'services: app: build: . container_name: blackfriday ports: - "8080:8080" depends_on: - mysql - redis-cache - redis-session - rabbitmq environment: SPRING_DATASOURCE_URL: jdbc:mysql://localhost:3306/blackfrida..

스프링 시큐리티 흐름 1. 사용자의 인증 요청이 들어오면 우선 DelegatingFilterProxy에서 SecurityFilterChain으로 요청을 전달해 준다.2. 이후 사용자의 요청들이 필터들을 타고 들어가서 인증 or 인가 과정을 거치게 된다.3. WebSecurity의 HttpSecurity를 통해서 적용되는 필터들을 Custom 해줄 수 있다. 코드 예시@Beanpublic SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf(AbstractHttpConfigurer::disable) .formLogin(FormLoginConfigurer::disable) ..

지난 글에서 AOP를 이용하는 방법에 대해서 알아보았다. Spring AOP를 이용하여 부가 기능을 핵심 기능으로부터 분리할 수 있는데, 락을 거는 것은 부가 기능으로 볼 수 있다.따라서 이번에는 기존에 동시성 처리를 위해 만들어 놓은 분산락을 AOP 기능을 통해 분리를 해보려고 한다. 기존 구현 방식@Component@Slf4j@RequiredArgsConstructorpublic class RedissonLockHandler { private final RedissonClient client; public void execute(String name, long waitTime, long leaseTime, Runnable runnable) { RLock lock = client..

Spring의 AOP에 대해서 알아보자 애플리케이션은 크게 핵심 기능과 부가 기능으로 나눠진다.  핵심 기능은 말그대로 애플리케이션을 작동하는 데 있어서 필요한 로직들이고 Serivce, Repository의 비즈니스 로직부가 기능은 핵심 기능을 보조하는 기능이라고 생각하면 된다. 예를 들어 로그, 예외 처리, 트랜잭션 등등... 이러한 부가 기능들을 공통적으로 여러 핵심 기능에서 사용한다고 해보자.예를 들어 Controller 단, Service 단, Repository단에서 모두 로그를 적용한다면? 위 그림처럼 각각 로직에 모두 로그를 적용시키는 방법이 있을 것이다. 하지만 이렇게 똑같은 코드를 반복적으로 작성하는 것은 비효율적이다. 그래서 이런 부가기능들을 모듈화 시켜 핵심 기능과 부가 기능을 분리..

이전 글에서는 이벤트 상품 동시성 처리를 동기적으로 하였다.이번 글에서는 비동기적으로 처리하는 방법에 대해서 알아보겠다. 우선 동기적으로 처리하면 Lock을 사용하기 때문에 다른 스레드들이 Blocking 되기 때문에 TPS 감소 및 성능 저하가 발생한다.따라서 Message Queue를 이용하여 비동기 처리를 해보려고 한다.Redis pub/sub휘발성 특징 때문에 메시지를 전송하고 나면 데이터가 사라짐. 따라서 실제로 이벤트 상품 요청을 보냈는지 검증하기 힘듬메세지의 신뢰성이나 지속성이 중요하지 않은 서비스에 적합하고 대규모 처리가 어려움Kafka디스크에 저장되서 데이터 유실이 적고, 속도측면에서도 빠르고 대규모 분산 시스템에 적합함. 하지만 설정과 관리가 복잡하며, 초기 구성과 유지보수에 대한 학습..

무신사 블랙프라이데이 이벤트를 보고 한정된 수량의 이벤트 상품을 동시에 여러 명의 사용자들이 접근하여 주문을 하면 어떻게 처리할까? 처음 이 프로젝트를 시작했을 때 여러명의 사용자들(= 여러 개의 스레드 or 프로세스)이 이벤트 상품에 접근하면 당연히 race condition이 발생할 것이라 생각했고, 이를 어떤 구조 및 기술을 사용하여 효율적으로 처리하는지에 대해서 공부하고 싶었다. 운영체제에서 배운 개념을 토대로 생각하면 단순히 세마포어나 뮤텍스를 사용하여 Critical Section에 동시에 접근하는 불상사를 막을 수 있다. 하지만 실제 운영환경은 멀티코어 환경에 여러 개의 서버를 가지고 운영하기 때문에 락을 거는 방법을 택하는 순간 성능이 비약적으로 떨어질 것이고, 서비스 운영 자체의 문제가 ..