[Spring] JPA 비관적 락 적용으로 동시성 문제 해결하기

🤔 문제 상황

 

진행중인 블라썸 프로젝트에서 검색 결과 조회 횟수를 증가시키는 로직을 구현하는 과정에서 동시성 문제가 발생할 수 있는 상황을 확인했습니다. 예를 들어 검색 결과로 꽃 A, B, C 가 조회되면 A, B, C 의 조회 횟수를 각각 1씩 증가시켜야 했는데, 만약 A 의 현재 조회 횟수가 1일 때, 동시에 3번 조회된다면 결과는 4회가 되어야 하지만, 2회가 되는 상황이었습니다. 이를 원하는 방식대로 동작시키기 위해 비관적 락을 적용해보기로 했습니다.

 

 

👻 JPA 동시성 제어 방식

 

JPA 는 엔티티에 대한 무결성을 유지할 수 있도록 동시성 제어 메커니즘을 지원하고 있습니다.

이 메커니즘에는 낙관적 락과 비관적 락이 포함됩니다.

 

 

⛓️ 낙관적 락 (Optimistic Lock)

 

낙관적 락은 DB 가 제공하는 락 기능을 활용하지 않고 JPA 가 제공하는 @Version 어노테이션을 활용해서 엔티티의 버전을 관리하는 방식입니다.

 

@Entity
public class SearchHit {
	@Id
	private Long id;

	private String name;

	private Integer count; // 조회 횟수

	@Version
	private Integer version; // 버전
}

 

다음과 같이 버전 관리용 필드를 작성할 수 있는데, 해당 엔티티가 변경될 때마다 version 값이 증가하게 됩니다.

그리고 엔티티를 수정할 때, 엔티티를 조회한 시점의 버전 값과 수정한 시점의 버전 값이 일치하지 않으면 예외가 발생하게 됩니다.

 

낙관적 락을 적용해서 위에서 언급했던 문제 상황을 해결할 수 있을까?

 

A 의 조회 횟수가 1일 때 버전이 1이라고 가정해보겠습니다. 동시에 세번의 요청이 들어왔고 각각의 트랜잭션을 t1, t2, t3 라고 하면 모두 조회 시점의 버전은 1입니다. 이 때 t1 이 가장 먼저 엔티티를 변경하고 커밋을 완료했다고 하면 A 의 조회 횟수는 2, 버전은 2로 변경됩니다. 나중에 t2 와 t3 모두 조회 횟수 2 로 커밋하려 하지만, 버전이 2로 변경되어 조회한 시점의 버전 값과 일치하지 않아 예외가 발생합니다. 따라서 최초 커밋만 인정되어 조회수는 4가 아닌 2로 업데이트되어 원하는 방식대로 문제를 해결할 수 없습니다.

 

 

⛓️ 비관적 락 (Pessimistic Lock)

 

비관적 락은 DB 가 제공하는 락 기능을 사용합니다. @Lock 어노테이션을 활용해서 구현할 수 있습니다.

 

public interface SearchHitRepository extends JpaRepository<SearchHit, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("select h from SearchHit h where h.id = :id")
    SearchHit findByIdForUpdate(Long id);
    
}

 

Querydsl 을 활용하고 있다면 다음과 같이 적용할 수 있습니다.

 

public class SearchHitRepositoryImpl implements SearchHitRepositoryCustom {

	private final JPAQueryFactory queryFactory;

	@Override
	public SearchHit findByIdForUpdate(Long id) {
		return queryFactory
			.selectFrom(searchHit)
			.where(searchHit.id.eq(id))
			.setLockMode(LockModeType.PESSIMISTIC_WRITE)
			.fetchOne();
	}
}

 

위와 같이 LockModeType 을 PESSIMISTIC_WRITE 로 설정하게 되면 데이터베이스에 select for update 쿼리가 나가게 되고 조회한 레코드 자체에 락을 걸게 됩니다.

 

실제 코드에 적용한 예시

 

이제 다시 문제 상황에 대해 생각해보겠습니다. A 의 조회 횟수가 1일 때 요청이 동시에 3번 들어오면 가장 먼저 A 를 조회한 트랜잭션 t1 이 A 에 대한 락을 획득하게 됩니다. 다른 트랜잭션 t2, t3 는 t1 이 락을 해제할 때까지 대기하게 되고, t1 이 A 의 조회 횟수를 2로 업데이트 한 후에 락을 해제하면 t2 가 락을 획득하여 A 의 조회 횟수를 3으로 업데이트, 마지막으로 t3 가 락을 획득하여 조회 횟수를 4로 업데이트합니다. 원하는 방식대로 문제를 해결할 수 있게 되었습니다.

 

 

❗️ 고려할 점

 

비관적 락을 적용해서 원하는 결과를 얻을 수 있었습니다. 하지만 비관적 락을 적용하게 되면 트랜잭션이 특정 데이터에 대한 락을 해제하기 전까지 다른 트랜잭션들은 대기해야 하기 때문에 성능이 저하될 수 있다는 문제점이 존재합니다. 그렇기 때문에 데이터의 정확성과 성능 저하라는 트레이드 오프를 고려해서 문제 해결 방안을 잘 선택해야 합니다.