비관락, 낙관락에 대해 설명해 주세요

[3Juhwan]

.

[jimi567]

DB 자원 충돌을 해결하기 위해 락을 거는 방법을 고려할 수 있다.

그 중 비관락, 낙관락이라는 개념이 있다.

---

비관락(Pessimistic lock) : 트랜잭션이 시작 될 때 공유락과 베타락을 거는 방식으로 Repeatable Read 또는 Serializable 정도의 격리성 수준을 제공한다

• 공유락(Shared Lock = Read Lock) : 트랜잭션이 읽기를 할 때 사용하는 락이다, 데이터를 읽기만하기 때문에 같은 공유락끼리는 동시에 접근이 가능하지만, 쓰기 작업은 막는다.

• 배타락 (Exclusive Lock = Write) : Write Lock이라고도 불리며, 데이터를 변경할 때 사용하는 락이다. 트랜잭션이 완료될 때까지 유지되며, 배타락이 끝나기 전까지 read/write를 모두 막는다.

---

낙관락 : 자원에 락을 걸지 않고 동시성 문제가 발생할면 그때 처리하는 방식
낙관적 락은 수정할 때 수정했다고 명시하여 다른 트랜잭션이 동일한 조건으로 값을 수정할 수 없게 하는 것

• 대게 별도의 칼럼을 두어, 충돌 발생을 막는다. 이때 칼럼은 보편적으로 version이라는 이름으로 사용
• 충돌이 발생했을때, DB가 아닌 애플리케이션 단에서 처리 한다.
• 낙관적 락은 UPDATE에 실패해도 자동으로 예외를 던지지 않고, 단순히 0개의 row를 업데이트 한다. 따라서 이때 여러 작업이 묶인 트랜잭션 요청이 실패할 경우, 개발자가 직접 롤백 처리를 해줘야 한다.

---

성능 측면 비교

• 일반적인 상황 : 트랜잭션을 사용하지 않는 낙관락이 낫다.

• 실제 충돌 : update를 한번씩 더 해줘야 하기 때문에, 비관적 락 보다 좋지 않을 가능성이 있음.

• 데이터 무결성이 중요하고, 충돌이 자주 발생할 것 같다. -> 비관락 고려

• 조회 작업이 많고, 충돌이 발생 빈도가 낮을 것 같다. -> 낙관락 고려

[GIVEN53]

낙관락(Optimistic Lock)과 비관락(Pessimistic Lock)은 데이터베이스 트랜잭션에서 동시성 제어를 위한 두 가지 주요 기법입니다.
데이터 일관성을 유지하면서 여러 트랜잭션이 동시에 데이터에 접근할 때 발생할 수 있는 충돌을 해결할 때 사용됩니다.

MySQL 기준으로 서술

낙관락 (Optimistic Lock)

1. 트랜잭션이 데이터를 읽고 작업을 수행한 후에야 충돌이 발생했는지 확인하는 방식이다.
2. 현재 트랜잭션이 먼저 값을 수정했다고 명시해서 다른 트랜잭션이 동일한 조건으로 값을 수정할 수 없게 한다.
   • 일반적으로 version과 같은 별도의 구분 컬럼을 사용한다.
3. lock을 걸지 않아 성능이 저하되지 않는다.
4. 충돌이 발생하면 DB가 아닌 애플리케이션에서 처리한다.
   • 충돌 발생 시 직접 롤백 처리하거나 재시도해야 한다.
5. 충돌이 드물게 발생할 것이라는 가정하에 데이터를 보호하는 방식이다.

4번 첨언

1. db 레벨에서만 사용할 경우

# transaction 1
select * from reservation
where id = 1; # 이 때 version = 1 상태

# transaction 2
select * from reservation
where id = 1; # 이 때 version = 1 상태

# transaction 1
update set status = 'ACCEPTED', version = version + 1
from reservation
where id = 1 and version = 1; # version = 2로 업데이트

# transaction 2
update set status = 'CANCELED', version = version + 1
from reservation
where id = 1 and version = 1; # version = 1이 없기 때문에 단순히 0개 row 업데이트 (예외 x)

2. 애플리케이션에서 사용할 경우
   -> row 업데이트 개수 확인해서 트랜잭션 직접 롤백

JPA는 ObjectOptimisticLockingFailureException 예외가 발생한다.
비즈니스 성격에 따라 예외가 발생했을 때 요청을 종료하지 않고 try-catch로 잡아서 재시도할 수도 있다.
ex) 재고 감소 로직에 낙관적 락을 적용하고 예외 발생 시 재고가 아직 남아있으면 재시도

JPA에서 사용하기

@Entity
public class Reservation {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    // ...

    @Version
    private Long version;
}

public interface ReservationRepository extends JpaRepository<Reservation, Long> {

	@Lock(LockModeType.OPTIMISTIC)
	@Query("select r from Reservation r where r.id = :id")
	Optional<Reservation> findByIdWithOptimisticLock(Long id);
}

비관락 (Pessimistic Lock)

1. 데이터에 접근할 때마다 잠금을 설정하여 다른 트랜잭션이 해당 데이터에 접근하지 못하도록 한다.
2. 트랜잭션이 시작될 때 Shared Lock(S-Lock, 공유락) 또는 Exclusive Lock(X-Lock, 베타락)을 걸고 시작한다.
3. 잠금을 자주 설정하고 해제하기 때문에 트랜잭션이 오래 지속되면 성능 저하가 발생할 수 있다.
4. Repeatable Read 또는 Serializable 정도의 격리성 수준을 제공한다.
5. 충돌이 자주 발생할 것이라는 가정하에 데이터를 보호하는 방식이다.

S-Lock

Read Lock이라고도 하며 다른 트랜잭션에서 write 작업을 수행하지 못하도록 한다.

• 다른 트랜잭션에서 SELECT 및 S-Lock을 사용할 수 있다. (S-Lock끼리 호환 가능)
• 읽는 동안 수정이 발생하지 않게 잠그는 것
• SELECT ... LOCK IN SHARE MODE, MySQL 8.0부터 SELECT ... FOR SHARE

X-Lock

Write Lock이라고도 하며 다른 트랜잭션에서 write 작업 및 S-Lock을 획득하지 못하도록 한다.
SELECT는 가능한데, 락이 걸린 것은 읽을 수 없어야 하는게 맞지만 InnoDB는 SELECT 때 Consistent Nonlocking Reads로 동작해서 undo 로그에 있는 snapshot을 읽기 때문에 가능하다.
reference : https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html

MySQL의 격리 수준 기본값이 REPEATABLE READ인데 Phantom Read가 발생하지 않는 이유와 유사하다고 느껴짐

• 다른 트랜잭션의 X-Lock, S-Lock과 호환되지 않는다.
• 쓰는 동안 수정이 발생하지 않게 잠그는 것
• SELECT ... FOR UPDATE

JPA에서 사용하기

public interface ReservationRepository extends JpaRepository<Reservation, Long> {

	@Lock(LockModeType.PESSIMISTIC_WRITE)
	@Query("select r from Reservation r where r.id = :id")
	Optional<Reservation> findByIdWithPessimisticLock(Long id);
}

• @Lock(LockModeType.PESSIMISTIC_WRITE) : X-Lock 쿼리 수행
• @Lock(LockModeType.PESSIMISTIC_READ) : S-Lock 쿼리 수행

결론

	낙관락	비관락
충돌 가능성	드뭄	빈번
성능	향상(?)	저하
lock	사용하지 않음	사용

• Race Condition이 자주 일어난다 -> 비관락
• 데이터 무결성이 중요하다 -> 비관락
• 조회 작업이 많아 동시 접근 성능이 중요하다 -> 낙관락

추가 키워드

• spring 낙관적 락 : @Version만 사용 vs @Version + @Lock(LockModeType.OPTIMISTIC)
• @Lock의 LockModeType 종류
• X-Lock, S-Lock의 데드락 발생 가능성
• Named Lock