JPA 락으로 동시성 문제 해결하기

개요

현재 프로젝트에서는 파티 기능을 구현 중입니다. 유저가 최대 인원수를 설정하여 파티를 생성하면 해당 인원까지만 참여할 수 있습니다.
그런데 여러 유저가 동시에 참여 신청을 하는 경우 참여 인원수 변경이 반영되기 전에 다른 스레드에서 추가적인 참여 로직이 진행되어 최대 인원을 초과하는 문제가 발생했습니다.

 

자바의 동시성 제어 방식

현재 프로젝트는 단일 JVM 환경이기 때문에 자바 수준의 동시성 제어 방식인 synchronized 키워드와 Lock 인터페이스를 먼저 검토해 보았습니다.

 

synchronized

자바의 모든 객체는 내부에 모니터 락을 갖고 있습니다. synchronized 키워드를 메서드 혹은 코드 블록 단위로 적용하면 락을 획득해야만 해당 영역에 접근할 수 있어 동시성 문제를 해결할 수 있습니다.

사용 방법이 편리하다는 장점이 있지만, 락 해제까지 스레드가 무한정 대기해야 하는 문제와 어떤 스레드가 락을 획득할지 알 수 없다는 공정성 문제가 있습니다.

 

Lock 인터페이스

대표적인 구현체로 ReentrantLock이 있습니다. 객체가 갖고 있는 모니터 락이 아닌 명시적 락 메커니즘을 제공하여 synchronized보다 더 유연한 동시성 제어를 가능하게 합니다. 그 예로 synchronized의 단점을 보완하는 기능을 제공하는데, 타임아웃 설정과 인터럽트 허용 등을 통해 무한 대기 문제를 해결할 수 있고, 공정 모드 설정을 통해 공정성 문제를 해결할 수 있습니다.

 

하지만 이러한 방식들은 트랜잭션 범위 전체를 제어하지는 못합니다. ①트랜잭션 시작과 메서드 진입 사이, ②메서드 종료와 트랜잭션 커밋 사이에는 제어가 닿지 않기 때문에 트랜잭션 단위의 동시성을 온전히 보장할 수 없습니다.

 

참고)
파티 참여 인원수를 AtomicInteger로 관리하거나 Redis의 원자적 연산을 사용하면 인원수 증감 자체의 원자성은 보장할 수 있습니다. 그러나 이 역시 앞선 방식들과 마찬가지로 트랜잭션이 커밋되기 전에 다른 트랜잭션에서 값을 변경할 수 있기 때문에 여전히 갱신 손실이 발생할 수 있습니다. 또한 DB 유니크 제약 조건을 활용하는 방식도 검토했지만, 이는 동일 유저의 중복 참여만 막을 수 있을 뿐 최대 인원 초과 자체를 방지하는 용도로는 적합하지 않았습니다.

 

트랜잭션 단위의 동시성 제어 방식

앞선 문제를 해결하기 위해 트랜잭션 단위로 동시성을 제어할 수 있는 JPA 락 메커니즘을 적용하기로 결정했습니다. JPA는 크게 낙관적 락과 비관적 락 두 가지 방식을 제공합니다.

 

낙관적 락 (Optimistic Lock)

충돌이 거의 없을 것이라 가정하고 DB 락을 사용하지 않는 방식입니다. 엔티티의 version 값을 기준으로 충돌을 감지하여 커밋 시점에 version 값이 변경되어 있으면 트랜잭션을 롤백합니다.

별도의 DB 락을 사용하지 않아 비관적 락보다 성능상 유리한 경우가 많지만, 충돌 발생 시 트랜잭션이 롤백되므로 만약 충돌이 잦은 상황이라면 오히려 성능이 저하될 수 있습니다. (+ 별도의 재시도 로직도 필요합니다.)

 

비관적 락 (Pessimistic Lock)

충돌이 자주 발생할 것이라 가정하고 DB 락을 사용하는 방식입니다. SELECT ... FOR UPDATE 쿼리를 통해 데이터 접근 시점부터 다른 트랜잭션의 접근을 차단합니다.

충돌을 사전에 방지하여 데이터 정합성을 확실하게 보장해 주지만, 대기 상태의 트랜잭션이 늘어나 성능이 저하될 수 있습니다. 특히 여러 트랜잭션이 서로 다른 데이터에 락을 건 상태로 상호 대기할 경우 데드락이 발생할 수 있습니다.

 

현재 서비스는 트래픽 규모가 크지 않아 실제 충돌 가능성이 낮다고 판단했습니다. 따라서 트랜잭션마다 락을 선점하는 비관적 락은 비효율적이라고 생각하여 낙관적 락을 채택했습니다.

 

낙관적 락 적용 ✅

Party 엔티티 클래스

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Entity
public class Party extends BaseTimeEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Version
    private Long version;
    
    ...
    
}

@Version을 활용하여 간단하게 버전 필드를 추가해 줍니다.

 

Party 서비스 클래스

@Retryable(
    retryFor = {OptimisticLockingFailureException.class},
    backoff = @Backoff(delay = 100)
)
@Transactional
public void joinParty(String loginId, Long partyId) {
    User user = userRepository.findByLoginId(loginId)
        .orElseThrow(() -> new ApplicationException(USER_NOT_FOUND));

    // 이미 파티에 참여중인 유저는 중복 신청 불가능
    if (partyUserRepository.existsByPartyIdAndParticipantId(partyId, user.getId())) {
        throw new ApplicationException(PARTY_ALREADY_JOINED);
    }

    Party party = partyRepository.findByIdWithFetchJoin(partyId)
        .orElseThrow(() -> new ApplicationException(PARTY_NOT_FOUND));

    // 파티 삭제 여부 확인
    if (party.isDeleted()) {
        throw new ApplicationException(PARTY_ALREADY_DELETED);
    }

    // 파티 마감 여부 확인
    if (party.isClosed()) {
        throw new ApplicationException(PARTY_ALREADY_CLOSED);
    }

    // 파티 생성자는 본인의 파티에 참여 신청 불가능
    if (loginId.equals(party.getHost().getLoginId())) {
        throw new ApplicationException(PARTY_CREATOR_CANNOT_JOIN);
    }

    // 인원 초과 여부 검증 및 참여자 수 증가
    party.incrementParticipantCount();

    // partyUser 객체 저장 및 유니크 제약 조건 위반 예외 처리
    PartyUser partyUser = new PartyUser(party, user);
    partyUserRepository.save(partyUser);
}

@Retryable을 활용하여 OptimisticLockingFailureException 발생 시 파티 참여 로직을 자동으로 재시도하도록 구성했습니다. 앞서 언급한 것처럼 현재 서비스는 충돌 가능성이 낮다고 판단했기 때문에, maxAttempts(재시도 횟수)와 multiplier(지수 백오프 증가 비율)는 기본값인 각각 3회, 0.0을 그대로 사용했습니다. 또한 요청량이 많지 않아 재시도 간격을 좀 더 짧게 가져가도 부담이 없다고 판단하여 delay는 100ms로 설정했습니다.

 

테스트

초기 데이터 구성

INSERT INTO users (id, login_type, login_id, password, nickname, profile_image, gender, birth_date, is_deleted)
VALUES (1, 'NORMAL', 'user1', 'password1', 'UserA', null, 'MALE', '1990-01-01', false),
       (2, 'NORMAL', 'user2', 'password2', 'UserB', null, 'FEMALE', '1992-02-02', false),
       (3, 'NORMAL', 'user3', 'password3', 'UserC', null, 'MALE', '1994-03-03', false),
       
       ...
       
       (31, 'NORMAL', 'user31', 'password31', 'UserEE', null, 'MALE', '2005-02-24', false);

INSERT INTO party (id, title, image_url, max_capacity, deadline, is_closed, host_id)
VALUES (1, 'PartyA', null, 6, '2024-12-31T23:59:59', false, 1);

 

테스트 코드

@DisplayName("동시에 여러 파티 가입 요청이 와도 파티의 최대 인원을 초과하지 않습니다.")
@Test
void prevent_exceeding_max_capacity_with_concurrent_requests() throws InterruptedException {
    int threadCount = 30;
    ExecutorService executorService = Executors.newFixedThreadPool(4);
    CountDownLatch latch = new CountDownLatch(threadCount);

    Long partyId = 1L;
    String loginIdPrefix = "user";
    for (int i = 2; i <= threadCount + 1; i++) {
        String loginId = loginIdPrefix + i;
        executorService.submit(() -> {
            try {
                partyService.joinParty(loginId, partyId);
            } catch (ApiException e) {
                System.out.println(e.getErrorCode().getMessage());
            } finally {
                latch.countDown();
            }
        });
    }
    latch.await();
    
    assertThat(partyUserRepository.countByPartyId(1L)).isEqualTo(5);
}

 

테스트 결과

🔴 JPA 락 미적용

• 동시 요청으로 인해 최대 인원을 초과하는 문제가 발생합니다.
• 각 트랜잭션이 독립적으로 처리되므로, 한 트랜잭션에서 이미 최대 인원이 채워졌더라도 다른 트랜잭션에서 진행 중인 파티 참여 로직은 계속 진행됩니다.

 

🟢 JPA 락 적용

• 낙관적 락을 적용하여 동시 요청 상황에서도 데이터 정합성을 유지할 수 있었고, 파티의 최대 인원을 초과하는 문제가 발생하지 않았습니다.

 

결과

JPA 낙관적 락을 적용하여 동시 요청 상황에서도 트랜잭션 단위로 파티 인원수 검증을 올바르게 처리하여 참여 인원을 정확하게 유지할 수 있었습니다.

또한 이 과정을 통해 여러 해결 방안을 검토하고, 현재 상황에 가장 적합한 방식을 선택해 적용하는 경험을 할 수 있었습니다.