회고장

👣 개요 캐싱에 따른 검색 속도 향상 여부를 확인하는 실험. 👣 실험 계획 Item 테이블의 Row 갯수는 100만 개 입니다. 테스트를 위해 2개의 메서드를 구성했습니다. 1번째 메서드는 'readById' 메서드로서 단순히 ID값으로 엔티티를 조회하는 메서드입니다. 2번째 메서드는 'readByIdWithCaching' 메서드로서 ' readById'에 단순히 캐싱을 적용했다고 볼 수 있습니다. 실험에 사용되는 테스트 코드는 위와 같이 순차적으로 N번 메서드를 호출하고 해당 실행 시간을 확인하는 형태로 진행된다. 👣 실험 수행 ⚗️ 대조군 - 캐싱 없이 검색 1000번 정도 메서드를 호출했을 때의 결과다. 3149 ms, 즉 3.149초가 걸림을 알 수 있다. ⚗️ 실험군 - 캐싱 적용 후 검색 10..

👣 개요 Projection 연산을 통해 꼭 필요한 정보만 가져와 검색 속도 향상. 👣 실험 계획 Review 테이블의 Row 갯수는 10만 개 입니다. 그리고 Review 테이블의 칼럼 갯수는 총 5개 입니다. 만약 DTO에서 5개의 칼럼을 모두 요구하는 것이 아닌 특정 칼럼만 요구한다는 상황을 가정. ReviewResponse 는 id, rating이라는 2개의 칼럼만 요구하고 있다. 실험에 사용되는 테스트 코드는 위와 같이 순차적으로 N번 메서드를 호출하고 해당 실행 시간을 확인하는 형태로 진행된다. 👣 실험 수행 ⚗️ 대조군 - Projection 없이 그냥 모든 칼럼 가져오기. 50번 정도 메서드를 호출했을 때의 결과다. 16776 ms, 즉 16.776초가 걸림을 알 수 있다. ⚗️ 실험군 -..

👣 개요 N+1 문제 해결 시 검색 속도 향상. 의도적으로 Dto에서 요구하는 엔티티를 Lazy Fetch로 불러와서 N+1 쿼리를 내보내도록 유도함. 그리고 다양한 방법으로 N+1 문제를 해결하면서 성능 향상을 확인. 👣 실험 계획 위 이미지에서 Member 테이블의 ID 칼럼의 1인 데이터와 연관된 Wish 데이터의 갯수는 113개 이다. 즉, 만약 Lazy Fetch로 ID가 1인 Member의 Wish 데이터를 불러오면 1[Member Query] + 113[Wish Query] 개의 쿼리가 불러와질 예정이다. 위와 같이 하나의 Member 정보를 불러올 때, 해당 Member가 Wish 리스트에 추가한 Item들을 함께 불러올 수 있는 DTO인 MemberResponse를 만들고 MemberSe..

👣 개요 반정규화에 의한 통계 쿼리 실행 속도 향상 확인. Item 테이블과 연관 관계에 놓여 있는 Review 테이블의 Rating 칼럼을 이용해 Item 당 평균 평점값을 계산하는 통계 쿼리를 반정규화를 통해 성능 향상 여부를 확인. 👣 실험 계획 Item 테이블의 Row 갯수는 100만 개 있고 Review 테이블의 Row 갯수는 10만 개 있다. Review 테이블의 Dummy Data를 만들기 위해 설정한 것들을 보면 item_id는 1~10까지의 값만 임의로 부여되도록 설정하고 rating은 1~5까지의 값을 임의로 부여되도록 설정했다. 따라서, Review 테이블을 item_id 값으로 Group By하게 되면 위와 같은 결과를 얻어낼 수 있다. 의도적으로 평점 평균을 구하기 위해 동원되는 ..

👣 개요 인덱스의 여부에 따른 삽입 속도 저하 여부를 확인하는 실험. 👣 실험 계획 Item은 name에 인덱스가 부여되지 않았고 해당 Item 테이블의 Row 갯수는 100만 개 입니다. 실험을 위해 사용된 코드는 위와 같이 하나의 엔티티를 저장할 때마다 트랜잭션이 마무리가 되면서 쿼리가 날아가게 된다. 우선 임의의 입력값을 만드는 메서드를 만들어준 다음 대략 10000개의 엔티티를 저장하는 과정을 실행할 계획이었다. 저장한 후, Rollback으로 저장을 취소하는 것이 아닌 최대한 실제 상황과 비슷하게 저장하고 테스트 마지막에 자원을 회수하는 방법으로 테스트를 계획했다. 👣 실험 수행 ⚗️ 대조군 - 인덱스 없이 삽입 우선 10000번 정도 엔티티를 저장했을 때의 결과다. 13936 ms, 즉 13...

👣 개요 인덱스의 여부에 따른 검색 속도 향상 여부를 확인하는 실험. 👣 실험 계획 Item은 name에 인덱스가 부여되지 않았고 해당 Item 테이블의 Row 갯수는 100만 개 입니다. 실험을 위해 사용된 코드는 위와 같이 Name 칼럼을 기준으로 검색하는 메서드다. 실험에 사용되는 테스트 코드는 위와 같이 순차적으로 N번 메서드를 호출하고 해당 실행 시간을 확인하는 형태로 진행된다. 👣 실험 수행 ⚗️ 대조군 - 인덱스 없이 검색 우선 100번 정도 메서드를 호출했을 때의 결과다. 20129 ms, 즉 20.129초가 걸림을 알 수 있다. 겨우 100번 호출했음에도 불구하고 20초나 걸린다는 것을 알 수 있다. ⚗️ 실험군 - 인덱스 생성 후 검색 인덱스를 만들기 위해 다음과 같은 쿼리를 실행한다...

👣 개요 그동안의 프로젝트는 기능 구현에 초점이 맞춰져 있을 뿐 서버 최적화에 대해 진지한 논의가 있던 프로젝트는 없었다. 때문에 오로지 서버 최적화에 대해서만 실험하는 프로젝트를 진행하고자 하여 Optimizer 프로젝트를 진행하고자 한다. Optimizer 프로젝트는 다음과 같은 형식으로 진행될 예정이다. 1. 다양한 연관 관계의 엔티티들을 정의한다. 더보기 Item, Member라는 기본 엔티티 오직 Member 만으로 연관 관계가 설정된 Follow 엔티티 Member와 Item과의 연관 관계가 설정된 Wish 엔티티 차후 평균 별점과 같은 통계를 위한 Rating 엔티티 2. 각 엔티티를 위한 더미 데이터를 최소 1만개 ~ 최대 100만개 적재한다. GitHub - iksadNorth/sql-m..

👣 개요 프로젝트 진행 중 React와 Spring을 동시에 사용해서 프로젝트를 구성했기 때문에 CORS 문제는 언제나 따라다녔습니다. CORS 문제 이외의 구현은 테스트 코드를 작성해서 문제를 조기에 예방했기 때문에 버그 발생 확률이 현저히 낮았습니다. 하지만 CORS 문제의 경우, 브라우저를 이용해야 버그가 발생하기에 조기에 발견하기 너무 어려웠습니다. 혹시나 하는 마음에 CORS 테스트 코드를 찾고자 구글링을 해보아도 간단한 JS 코드를 이용해 웹 페이지에서 직접 서버로 API 호출하는 경우 이외에는 뾰족한 수가 보이지 않았습니다. 하지만 CORS에 대해 조금 더 공부해본 결과 브라우저에서 CORS 정책대로 유효성을 확인해볼 때, Preflight 요청을 보낸다는 것에 착안해서 테스트 코드를 작성해..

👣 구현 배경 Re:USE 프로젝트는 의류 중고 거래 웹 서비스로서 사용자와 사용자가 직접 거래를 하기 위해선 판매자와 구매자의 거리가 짧을수록 좋을 것이라 가정했습니다. 때문에 사용자에게 추천하는 상품 중 거리가 가까운 상품을 보여줘야 할 필요성이 느껴져서 해당 기능을 구현하고자 기획했습니다. 사용자에게 받는 주소는 문자열 형식의 주소를 받게 되어 있으며 예를 들자면, " 서울특별시 중구 세종대로 110"와 같은 도로명 주소로 입력되도록 유도했습니다. 👣 구현 시도 1st - 행정 구역 기준 카테고리화 처음에는 도로명 주소로 입력받은 위치를 시/도/동/구 등등으로 Parsing하고 각 카테고리가 동일하면 동일할수록 거리가 가까운 것으로 가정하자는 논의가 이뤄졌습니다. 예를 들어, 3개의 주소가 주워졌다..

👣 개요 해당 프로젝트는 개발 초기에 WireFrame이 확정되지 않았기 때문에 각 API가 전달해야 하는 응답 JSON 형식이 수시로 바뀌는 상황이었다. 때문에 Lazy Loading에 의존해서 API를 제작했고 Entity를 DTO로 변환하는 과정 중 N+1 문제가 발생했었다. 때문에 MVP 달성 이후 더이상 변경될 확률이 적은 API를 보다 최적화시키기 위해 Projection 기능과 적절한 Join 연산으로 1개의 쿼리로 필요한 모든 정보를 불러올 계획을 세웠다. 하지만 이전 프로젝트 경험 중 정상 작동되는 API를 함부로 수정했다가 오류를 일으킨 경우가 있었기에 코드 리펙토링 이전에 테스트 코드를 작성하고자 했다. 👣 테스트 계획 처음 테스트는 통합 테스트로 진행하려 했었다. 왜냐 하면, 단순히..