JPA 1차 캐싱을 이용한 성능 튜닝, 그리고 1차 캐싱이 되지 않는 경우와 우회법

1. 서론

진행중인 프로젝트에서 아래 사진과 같은 기능을 구현하게 되었다.

기능 설명부터 간단히 하면

본인이 올린 공고글이 있으면 특정 노동자에게 일자리를 제안할 수 있는 기능이다.

이때 노동자의 출역 가능한 날짜와 공고글의 출역 날짜를 비교하여 제안할 수 있다.

기업은 노동자에게 일자리를 제안할 때 여러 개의 공고글을 제안할 수 있다. 동시에 각 공고글은 여러 날을 선택하여 제안할 수 있다.

예를 들어 1,2,3일을 일하는 공고글 A와 2,3,4일을 일하는 공고글 B가 있고, C라는 노동자는 2일날 출역이 확정된 상황이 있다고 가정하자.

그럼 기업은 C노동자에게 공고 A의 1,3일, 공고 B의 3,4일을 제안할 수 있는 것이다.

요청 JSON은 다음과 같다.

{
  "resumeId": 1,
  "offerJobPostRequest": [
    {
    	"jobPostId": 1,
    	"workDateIdList": [1,2]
    },
    {
    	"jobPostId": 1,
    	"workDateIdList": [3,4]
    }
  ]

이제 내가 해야할 일은 요청온 pk 값들이 실제로 있는 값인지 확인해야 하고 각 workDateId 값들이 jobPostId와 연관관계가 맺어져있는지 확인해야한다.

리펙토링 전 코드는 아래와 같이 작성했었다.

public void offerJobPost(Long companyId, OfferRequest request) {
    Member company = memberRepository.findById(companyId)
            .orElseThrow(() -> new CustomException(ErrorCode.MEMBER_NOT_FOUND));
    Resume resume = resumeRepository.findByIdWithMember(request.getResumeId())
            .orElseThrow(() -> new CustomException(ErrorCode.RESUME_NOT_FOUND));
    Member worker = resume.getMember();

    // 코드 생략

    for (OfferJobPostRequest offerJobPostRequest : request.getOfferJobPostRequest()) {
        // jobPost 조회
        JobPost jobPost = jobPostRepository.findById(offerJobPostRequest.getJobPostId())
                .orElseThrow(() -> new CustomException(ErrorCode.JOB_POST_NOT_FOUND));

        // 코드 생략

        // jobPostId, workDateId로 workDate 조회
        List<WorkDate> workDateEntityList = workDateRepository.findByIdList(offerJobPostRequest.getWorkDateIdList(), jobPost.getId())

        // 코드 생략
    }
    // 코드 생략
}

2. 문제점

반복문 안에 쿼리 호출 로직이 들어가있어 N개의 쿼리가 호출되었다. 위와 같은 경우는 단순히 fetch join을 사용하거나 default_batch_fetch_size를 적용해 해결할 수 있는 문제가 아니다.

그냥 검증 과정에서 그렇게 호출될 수 밖에 없는 상황이기 때문이다.

3. 해결 시도(1)

우선 db에서 idList 값으로 미리 전부 조회한 다음 id 값을 key로 갖고 본인을 value로 갖는 Map을 생성하는 방법으로 해결하려 시도했다. request 에서 JobPostIdList 와 WorkDateIdList를 추출한 다음 Map으로 변환시켜 주었다.

그리고 반복문에서 값이 필요할 때 db에서 조회하는 것이 아닌 map에서 조회했다.

    public void offerJobPost_(Long companyId, OfferRequest request) {
        Member company = memberRepository.findById(companyId)
                .orElseThrow(() -> new CustomException(ErrorCode.MEMBER_NOT_FOUND));
        Resume resume = resumeRepository.findByIdWithMember(request.getResumeId())
                .orElseThrow(() -> new CustomException(ErrorCode.RESUME_NOT_FOUND));
        Member worker = resume.getMember();

        // 코드 생략


        List<Long> jobPostIdList = request.getOfferJobPostRequest().stream()
                .map(OfferJobPostRequest::getJobPostId)
                .collect(Collectors.toList());

        List<Long> workDateIdList = request.getOfferJobPostRequest().stream()
                .flatMap(o -> o.getWorkDateIdList().stream())
                .collect(Collectors.toList());

        Map<Long, JobPost> jobPostMap = jobPostRepository.findByIdList(jobPostIdList)
                .stream()
                .collect(Collectors.toMap(JobPost::getId, Function.identity()));

        Map<Long, WorkDate> workDateMap = workDateRepository.findByIdList(workDateIdList)
                .stream()
                .collect(Collectors.toMap(WorkDate::getId, Function.identity()));


        for (OfferJobPostRequest offerJobPostRequest : request.getOfferJobPostRequest()) {
            // jobPost 조회
            JobPost jobPost = jobPostMap.get(offerJobPostRequest.getJobPostId());

            // 코드 생략
            
            // jobPostId, workDateId로 workDate 조회
            List<WorkDate> workDateEntityList = offerJobPostRequest.getWorkDateIdList().stream()
                    .map(workDateMap::get)
                    .collect(Collectors.toList());

            // 코드 생략
        }
        // 코드 생략
    }

어떻게 보면 Redis 같은 캐시를 이용하는 느낌이었다.

위 처럼 코드를 바꾼 후 쿼리는 더이상 N번 나가진 않았지만 허점이 있었다. 조회한 workDate 값이 JobPost와 연관관계가 맺어지지 않은, 즉 JobPost와는 전혀 엉뚱한 workDate가 조회된다 해도 이를 발견할 방법이 없다.

고심 끝에 JPA 1차 캐싱을 떠올렸다.

3. 해결 시도(2)

JPA 1차 캐싱을 이용해보기로 했다.

검증 로직 이전에 id값들에 해당하는 데이터를 모두 역속성 컨텍스트에 넣은 후 다시 조회하면 쿼리가 나가지 않을 것으로 예상했다.

JPA 1차 캐시란?

1차 캐시란 영속성 컨텍스트(Persistence Context) 내에서 엔티티를 저장하고 관리하는 캐시이다.

1차 캐시의 과정은 세 가지 과정과 같다.

조회 시 처음 1차 캐시에 해당 데이터가 있는지 탐색을 한다. -> 만약 있으면 바로 리턴
조회 결과 1차 캐시에 데이터가 없으면 데이터베이스에 접근해 값을 탐색한다.
탐색 결과를 바로 리턴하는 것이 아닌 다음 탐색에서 재사용할 수 있도록 1차 캐시에 저장한다.

조회한 엔티티들은 1차 캐시에 항상 저장하고 있는 것이 아니다. EntityManager는 트랜잭션 단위이기 때문에 트랜잭션이 끝나면 1차 캐시도 지워버린다. 굉장히 짧은 찰나의 순간에만 장점이 있다.

public void offerJobPost_(Long companyId, OfferRequest request) {
    Member company = memberRepository.findById(companyId)
            .orElseThrow(() -> new CustomException(ErrorCode.MEMBER_NOT_FOUND));
    Resume resume = resumeRepository.findByIdWithMember(request.getResumeId())
            .orElseThrow(() -> new CustomException(ErrorCode.RESUME_NOT_FOUND));
    Member worker = resume.getMember();

    // 코드 생략


    List<Long> jobPostIdList = request.getOfferJobPostRequest().stream()
            .map(OfferJobPostRequest::getJobPostId)
            .collect(Collectors.toList());

    List<Long> workDateIdList = request.getOfferJobPostRequest().stream()
            .flatMap(o -> o.getWorkDateIdList().stream())
            .collect(Collectors.toList());

    // 1차 캐싱 처리
    jobPostRepository.findByIdList(jobPostIdList);
    workDateRepository.findByIdList(workDateIdList);


    for (OfferJobPostRequest offerJobPostRequest : request.getOfferJobPostRequest()) {
        // jobPost 조회
        JobPost jobPost = jobPostRepository.findById(offerJobPostRequest.getJobPostId())
                .orElseThrow(() -> new CustomException(ErrorCode.JOB_POST_NOT_FOUND));

        // 코드 생략

        // jobPostId, workDateId로 workDate 조회
        List<WorkDate> workDateEntityList = workDateRepository.findByIdList(workDateIdList, jobPost.getId());

        // 코드 생략
    }
    // 코드 생략
}

동일 트랜잭션에서 이전에 조회한 엔티티에 대해선 DB에서 조회하는 것이 아닌 영속성 컨텍스트에 저장되어있는 엔티티를 가져오기 때문에 for문 안에서 엔티티를 조회할 땐 쿼리가 나가지 않을 것으로 예상했다.

하지만 내 생각대로 동작하지 않았다.

결과는 jobPost는 1차 캐시에서 가져올 수 있었지만 workDate는 그러지 못했고 쿼리가 나갔다.

이유를 찾아보니 1차 캐시를 사용하기 위해선 몇가지 조건이 있었다.

결론부터 말하자면

1차 캐시는 PK가 아니면 작동하지 않는다

1차 캐시 동작 조건

캐시에 저장되는건 커스텀 쿼리(JPQL)을 사용해도 문제 없이 1차 캐시에 저장된다.
단, 캐시에서 값을 가져오는건 PK를 기반으로한 find (entity manager를 쓸때 find() 메서드 혹은 data-jpa의 findById)에서만 동작한다.
select c from Comment c where c.id = :paramId 와 같은 PK기반 JPQL도 쿼리가 날아간다. (em.createQuery 가 호출됨)
트랜잭션이 종료되거나, flush()될 경우 캐시는 초기화된다.
PK 기반 find 조회를 하더라도, 처음 불러오는 엔티티면 쿼리가 날아간다.

2, 3번 조건이 중요하다.

JobPost를 조회할 땐 findById로 조회했기 때문에 1차 캐시에서 엔티티를 가져올 수 있었지만, WorkDate를 조회할 땐 커스텀 JPQL을 사용했을 뿐더러 pk만을 사용한 조회도 아니었기 때문에 1차 캐시 조회가 되지 않았던 것이다.

3. 해결 시도 (3) - 최종

최종으로 JPA 1차 캐싱과 Map 두 방법을 모두 이용하여 해결했다. 코드는 아래와 같다.

    public void offerJobPost(Long companyId, OfferRequest request) {
        Member company = memberRepository.findById(companyId)
                .orElseThrow(() -> new CustomException(ErrorCode.MEMBER_NOT_FOUND));
        Resume resume = resumeRepository.findByIdWithMember(request.getResumeId())
                .orElseThrow(() -> new CustomException(ErrorCode.RESUME_NOT_FOUND));
        Member worker = resume.getMember();

        List<Long> jobPostIdList = new ArrayList<>();
        List<Long> workDateIdList = new ArrayList<>();

        for (OfferJobPostRequest offerJobPostRequest : request.getOfferJobPostRequest()) {
            jobPostIdList.add(offerJobPostRequest.getJobPostId());
            workDateIdList.addAll(offerJobPostRequest.getWorkDateIdList());
        }

        // jpa 1차 캐싱을 위한 조회 및 캐시 Map 생성
        Map<Long, List<WorkDate>> workDateMap = getWorkDateMap(jobPostIdList, workDateIdList);

        for (OfferJobPostRequest offerJobPostRequest : request.getOfferJobPostRequest()) {
            JobPost jobPost = jobPostRepository.findById(offerJobPostRequest.getJobPostId())
                    .orElseThrow(() -> new CustomException(ErrorCode.JOB_POST_NOT_FOUND));

            // 코드 생략

            List<WorkDate> workDateEntityList = workDateMap.get(jobPost.getId());
            if (workDateEntityList.size() != offerJobPostRequest.getWorkDateIdList().size()) {
            	throw new CustomException(ErrorCode.WORK_DATE_NOT_MATCH);
            }
        }
        // 코드 생략
    }

    private Map<Long, List<WorkDate>> getWorkDateMap(List<Long> jobPostIdList, List<Long> workDateIdList) {
        jobPostRepository.findByIdList(jobPostIdList);
        List<WorkDate> workDateList = workDateRepository.findByIdList(workDateIdList);

        Map<Long, List<WorkDate>> workDateMap = new HashMap<>();
        for (WorkDate workDate : workDateList) {
            Long jobPostId = workDate.getJobPost().getId();
            // Key가 jobPostId인 List 가져오거나, 새로 생성
            List<WorkDate> innerList = workDateMap.computeIfAbsent(jobPostId, k -> new ArrayList<>());
            // innerMap에 workDateId와 workDate를 추가
            innerList.add(workDate);
        }
        return workDateMap;
    }

이전엔 JobPost와 WorkDate 각각의 pk값을 key로 설정하고 value를 각 엔티티로 설정했다면 이번엔

JobPost는 1차 캐시를 이용하여 조회하고

WorkDate는 연관관계가 맺어진 JobPost의 pk 값을 key로 설정하고 List<WorkDate>를 value로 설정해주어 캐시 역할을 하는 Map을 만들어주었다. 이렇게 JobPost와는 관계가 없는 WorkDate가 조회되는 것을 막을 수 있었다.

4. 결론

JPA 영속성 컨텍스트를 배우며 영속성 컨텍스트의 특징으로 1차 캐싱, 쓰기 지연, 변경 감지.. 등 특징들을 학습했고 기억하고 있었다. 하지만 1차 캐시를 이용해야겠다는 생각을 하지 못 했고 지금까지 사용해본적도 없었다. 정확히 사용할 일이 없었던 것 같다.

나와 같은 기능을 개발할 상황이 있다면 1차 캐시를 적극 이용하는걸 추천한다. 또 캐시 기능을 할 수 있는 Map을 임시로 만들어 사용하는 것도 좋아 보인다. Map은 생각보다 쓸 상황이 자주 생기는 것 같다.

단, Map은 잘못 사용할 시 메모리 누수의 원인이 되므로 잘 사용해야 한다.

참고

https://velog.io/@im_h_jo/JPA-1%EC%B0%A8-%EC%BA%90%EC%8B%9C-%EC%9E%91%EB%8F%99-%EC%A1%B0%EA%B1%B4

https://dingdingmin-back-end-developer.tistory.com/entry/Spring-Boot-JPA-1%EC%B0%A8-%EC%BA%90%EC%8B%9C-%EC%A0%95%EB%A6%AC

'Spring Boot, JAVA 🌱' 카테고리의 다른 글

[Spring Batch] Paging 기반의 ItemReader 사용 시 발생하는 데이터 건너뛰기 현상 (해결 방법 2가지) (0)	2024.03.15
[Spring Batch] ItemReader cursor vs paging (0)	2024.03.11
[Event] 실제 프로젝트에서 Spring Event를 적용해 복잡한 의존 관계 해소하기 (0)	2024.02.23
[Event] Spring Event 도입 시 트랜잭션 처리에 대한 고민 (1)	2024.02.22
[Event] Spring Event란? 이벤트 발행과 구독 방법 (0)	2024.02.21