모아온의 아티클 조회 API의 성능 테스트를 하다가 이상한 현상을 발견했다. 같은 API를 반복 실행할 때 첫 번째만 유독 응답 속도가 느렸다. 캐시와 관련된 것이겠지 단순 추측해 볼 수는 있었지만, 정확히 어떤 매커니즘인지 궁금해졌다. 이 글에서는 해당 현상의 정체를 파헤쳐본다. 이 글에서 다루는 내용InnoDB 버퍼 풀의 구조와 역할LRU 캐시 알고리즘대상 독자MySQL 사용자, 백엔드 개발자메모리 계층 구조와 캐싱에 대한 기본 이해가 있는 사람1. 문제 상황1.1 API 성능 테스트 중 속도 차이 발견성능 테스트를 할 때, 최초 조회가 유독 시간이 많이 걸리는 현상을 흔히 발견할 수 있다. 모아온의 아티클 조회 API 성능 개선을 위해 테스트 데이터를 넣고 실험을 진행했을 때, 해당 실험의 첫 시도..

들어가며이전 글에서 OOM 문제를 해결했지만, 여전히 아티클 조회 API는 빠르면 2초, 느리면 30초 정도로 많은 시간이 소요됐다. 검색, 필터링, 정렬, 무한스크롤 4가지 기능을 하나의 쿼리로 처리하고 있었기 때문이다.시리즈의 이전 글이 궁금하다면:1편: 모아온 조회 API 성능 개선기 (1) - 700만 건 테스트 데이터 생성2편: 모아온 조회 API 성능 개선기 (2) - OOM 문제 해결이 문제를 처리하기 위해 여러가지 경우의 수 별로 테스트를 하고, 문제의 원인을 찾고, 개선하는 과정을 반복했다.이 글에서는 techStack 필터링을 중심으로 쿼리 최적화를 통해 성능 개선 시도와, 그 과정에서 마주친 한계점을 소개하려고 한다.실험환경 및 제약조건이 글에서 다루는 최적화의 대상은 “아티클 탐색 ..

들어가며앞선 모아온 조회 API 성능 개선기 (1) - 700만 건 테스트 데이터 생성에서 조회 성능 테스트를 위한 데이터 세팅 과정을 다뤘다.700만 건의 테스트 데이터를 생성하고 나서 가장 먼저 마주한 문제는 Out Of Memory 에러였다.이 글에서는 조회 API에서 발생한 OOM 문제의 원인과 해결 과정을 정리한다.이 글에서 다루는 내용페이징 API에서 발생할 수 있는 OOM 문제COUNT 쿼리를 잘못 사용한 사례fetch().size() vs COUNT 쿼리 비교예상 독자Spring Boot와 MySQL, QueryDSL을 사용하는 백엔드 개발자1️⃣ Timeout 문제 발생100만 건의 아티클 데이터를 넣고 다양한 케이스로 테스트하던 중, 특정 API 요청에서 5분이 지나도 응답이 오지 않아..

들어가며모아온은 프로젝트와 관련 아티클을 함께 제공하며 인사이트를 전달하는 플랫폼 서비스다. 탐색이 주가 되는 서비스인 만큼 조회 성능이 매우 중요하다. 모아온의 기능 구현을 어느 정도 끝낸 후, 조회 성능 개선을 위한 작업들을 시작했다. 개선 과정은 생각보다 녹록치 않았고, 여러 단계를 거쳐 현재도 진행 중이다. 단계별 개선 과정을 글로 남겨보려고 한다. 그 중 첫 번째로, 성능 테스트를 위한 데이터베이스 세팅 과정을 정리해본다.DataFaker, JdbcTemplate, SSH 터널링을 사용해 개발 서버에 700만 건의 데이터를 생성했다.이 글에서 다루는 내용DataFaker를 이용한 대량 테스트 데이터 생성JdbcTemplate Bulk Insert 성능 최적화 (40배 개선)SSH 터널링을 통한 ..