0. 들어가기 전현재 프로젝트에서 자주 호출하는 '동선 기간 조회' API의 조회 성능을 높이기 위해 캐싱을 도입하기로 했습니다. 위의 페이지에서 다음과 같이 '동선 기간 조회' API 호출이 발생합니다.달력 페이지에서 동선 기간 조회 1달 간격으로 조회동선 보관함에서 월별 필터로 조회 해당 페이지들은 서비스에서 핵심적인 페이지들로 사용자들이 자주 사용할 것이라고 판단됐기 때문에,해당 페이지에서 호출되는 '동선 기간 조회' API의 조회 성능을 높이기 위해 '캐싱'을 도입했습니다. 이번 포스팅에서는 프로젝트에 캐싱을 적용한 과정을 담아보겠습니다!1. 캐싱이란?일반적인 CS 관점에서의 캐싱은 다음과 같이 말할 수 있습니다.캐시는 CPU와 RAM과 같이 느린 장치와 빠른 장치의 속도 차이로 인한 병목 현상을..
0. 들어가기 전현재 진행하고 있는 동선을 만드는 프로젝트에서 다음과 같은 요구사항이 존재했습니다.(동선 생성 시 선택한 태그의 태그 선택 횟수가 1씩 증가하는 로직 존재하는 상황)여러 사용자의 동선 생성 동시 요청 시에 태그 선택 횟수가 순차적으로 증가해야 한다. 위의 사진처럼 태그별로 선택 횟수가 표시되었습니다.해당 태그는 사용자들이 동선을 생성할 때 태그를 지정하면 선택 횟수가 1씩 증가하는 로직을 가지고 있습니다. 이러한 상황에서, 여러 사용자가 동시에 요청을 보내게 되면 현재 상황에서는 데이터 정합성이 보장되지 않은 상황이었습니다.멀티 스레드 테스트를 통해 테스트해봤을 때, 다음과 같이 테스트가 실패하는 것을 확인할 수 있었습니다. 그래서 이러한 동시성을 보장하기 위해서 여러 방법들을 생각해보..
0. 들어가기 전현재 진행하고 있는 동선을 만드는 프로젝트에서 다음과 같은 요구사항이 존재했습니다.'사용자는 하루에 1개의 동선만 생성할 수 있다.' 처음에 이를 구현하기 위해서는 단순히 DB에서 회원 식별자와 날짜로 데이터가 존재하는지 확인하는 검증 로직을 수행했었습니다.그래서 요청 시에 이미 DB에 멤버가 가진 해당 날짜의 동선이 존재한다면 예외를 발생시키게 구현했습니다. 그러나 구현 이후에 다음과 같은 상황을 떠올려봤습니다.'사용자가 동선을 만들 때 완료 버튼을 여러번 누르면 어떻게 되지?' 동선을 만들 때 위의 완료 버튼을 누르면 동선 추가 API 요청이 보내지도록 설계가 되어있었습니다.이때 일반적인 상황에서 사용자는 완료 버튼을 1번 누르고 기다리겠지만, 다음과 같은 특수한 상황을 예상해봤습니다..
0. 들어가기 전프로젝트를 진행하다가 멀티 스레드를 통해 동시 요청을 테스트하는 도중에, 초기 데이터를 설정하는 부분에서 문제가 발생했습니다.문제 상황과 원인, 해결 방법을 알아보도록 하겠습니다.1. 문제 상황프로젝트에서 사용자의 중복 요청을 방지하는 로직을 구현해야 했습니다.그래서 중복 요청을 테스트하기 위해 멀티 스레드 테스트를 다음과 같이 작성했습니다.@Test@DisplayName("1명의 사용자가 동선 생성 요청을 여러번 보내는 경우 1번만 성공하고 예외가 발생한다.")@Transactionalvoid throws_multiple_request() throws InterruptedException { ... final ExecutorService executorService ..
