Lock 총 정리2 - 낙관적 락, 비관적 락, 데드락, 분산락

저번 글에서는 기본적인 락 개념 & DB 내부 락 구조 에 대해서 알아보았는데요 

 

이번에는 실질적으로 사용되는 락들인 낙관적 락, 비관적 락, 분산락, 데드락 에 대해서 알아보도록 하겠습니다 !

 

1-1. 낙관적 락

낙관적 락은 이름에서 알 수 있듯이 충돌이 발생하지 않는다고 낙관적으로 가정하는 락 방식 입니다.

• DB 가 제공하는 락 기능이 아니라, 애플리케이션 레벨에서 버전 관리 기능을 통해 충돌을 감지하고 처리합니다
• 트랜잭션을 커밋하는 시점에 충돌 여부를 확인하므로, 최종 업데이트 과정에서만 락을 점유하게 됩니다
• 이를 통해 락 점유 시간을 최소화하고, 동시성을 높일 수 있습니다

설명을 통해서는 바로 이해가 어렵기 때문에 실제 예시를 들어보도록 하겠습니다 

 

선착순으로 티켓을 예매하려는 상황에서 두 사람 (A, B) 가 거의 동시에 예매 버튼을 눌렀습니다 !

예매 버튼을 눌렀기때문에 A 와 B 각자 트랜잭션을 시작합니다 !

그리고 A 10 열에 대해서 ROW 정보와 버전을 확인합니다

아직까진 예매한 사람이 없기 때문에 A10 의 상태는 예약 가능, version 은 1 로 나타납니다

A 가 B 보다 살짝 더 먼저 클릭해서 모든 과정을 완료 후 

A 10 열에 대한 정보를 예약 완료 그리고 version 도 2로 업데이트 했네요 !

그리고 한발 늦은 B 는 커밋 시점에 해당 좌석에 대한 ROW 를 업데이트하기 위해서 version 을 체크합니다

어랏 ? 근데 처음 확인한 version 인 1 과 다른 2 라고 DB 가 알려주네요 !

그러면 B 는 예외를 발생시키고 애플리케이션에서 후처리를 해줍니다 !

이를 통해서 A 10 열에 대해서 정합성을 유지할 수 있었네요 !

 

1-2. JPA 에서 낙관적 락 사용하기 

JPA 에서는 @Version 을 사용해서 낙관적 락을 사용할 수 있습니다

낙관적 락이 발생하는 경우 ObjectOptimisticLockingFailureException 예외가 발생하고,

해당 에러를 catch 해서 어플리케이션에서 후처리해주면 됩니다 !

---

2-2. 비관적 락

비관적 락은 낙관적 락과는 다르게 충돌이 발생한다고 비관적으로 가정하는 락 방식입니다

 

• 비관적 락은 DB가 제공하는 락 기능을 사용하여 데이터를 잠금(S-Lock, X-Lock) 처리합니다.
• 트랜잭션이 시작되면 S-Lock 또는 X-Lock을 설정하고, 데이터를 수정할 때 즉시 충돌 여부를 감지할 수 있습니다. (동시성 문제)
• 데이터 수정 시, 트랜잭션 충돌을 바로 알 수 있기 때문에 데이터의 일관성을 쉽게 보장할 수 있지만 성능에 영향을 미칠 수 있습니다.
• 교착 상태(Deadlock) 문제가 자주 발생할 수 있는데, 이는 두 트랜잭션이 서로 다른 자원을 잠그고 대기 상태에 빠지는 경우입니다.

 

비관적 락도 낙관적 락과 마찬가지로 선착순으로 티켓을 예매하려는 상황에서 두 사람(A, B) 을 예시로 들어보도록 하겠습니다 !

 

A 와 B 가 또 A 10 열을 예약하려고 동시에 버튼을 눌렀습니다 

A 가 살짝 더 먼저 클릭해서 트랜잭션을 시작하기 전에 해당 row 에 대해 X-LOCK 을 걸어줍니다

한발 늦은 B 가 트랜잭션을 시작할 때 해당 row 에 대해서 X-LOCK 을 걸려고 시도하지만, 이미 락이 걸려있습니다 !

B 는 이미 잠겨있기 때문에 기다립니다

A 가 예약을 성공적으로 진행하고, A 10 에 대해서 데이터를 예약 완료로 업데이트함과 동시에 락을 해제시켜줍니다

기다리던 B 가 락을 획득하지만 ,,,,, 이미 데이터는 예약 완료로 변경된 상태이기 때문에 예약에 실패하게 됩니다

---

3-1. 교착 상태 (Deadlock)

위에서 잠깐 얘기했던 것처럼 비관적 락은 데이터의 일관성을 쉽게 보장할 수 있지만, 교착상태 문제가 자주 발생하게 됩니다

그렇다면 교착상태란 무엇일까요 ? 

 

교착상태란 두 트랜잭션이 영원히 기다리게 되어 처리가 진행되지 않는 상태를 가리킵니다 

영원히 기다리는 건 두 트랜잭션이 서로 다른 자원에 대해 락을 걸고, 각 트랜잭션이 상대방이 걸고 있는 락을 기다리고 있는 상황에서 발생하게 되는데요 !

 

데드락이 발생되는 시나리오는 다음과 같습니다

트랜잭션 A가 Resource1 데이터를 수정하려고 X-Lock을 걸고, 그 후 Resource2 데이터를 수정하려고 합니다.

트랜잭션 B는 Resource2 데이터를 수정하려고 X-Lock을 걸고, 그 후 Resource1 데이터를 수정하려고 합니다.

트랜잭션 A 가 Resource1 에 대해서 락을 가지고 있는 상황에서 Resource 2 를 수정하기 위해서 접근합니다

하지만, Resource 2 는 트랜잭션 B 가 락을 가지고 있음으로 대기합니다

마찬가지로 트랜잭션 B 가 Resource2 에 대해서 락을 가지고 있는 상황에서 Resource 1 를 수정하기 위해서 접근합니다

하지만, Resource 1 는 트랜잭션 A 가 락을 가지고 있음으로 대기합니다

 

그러면 트랜잭션 A 와 트랜잭션 B 는 Resource 1과 Resource 2에 대해서 누구도 쓸 수 없는 상황이기 때문에 

교착상태 (Deadlock) 에 직면하게 됩니다 !!!!!!!!

 

3-2. 교착 상태 발생의 네 가지 조건

데드락은 다음 네 가지 조건이 동시에 성립할 때 발생합니다.

이 네 가지 조건이 충족되면, 시스템 내에서 자원에 대한 무한 대기 상태가 발생하고, 해결되지 않으면 시스템이 멈추게 됩니다.

이러한 조건 중 하나라도 성립하지 않으면 데드락을 예방할 수 있습니다.

조건	설명	해결 방법
상호 배제	한 번에 하나의 프로세스만 자원을 사용할 수 있다	여러 프로세스가 자원을 공유할 수 있도록 설정하거나, 자원의 복제를 통해 여러 프로세스가 동시에 사용할 수 있게 합니다.
점유 대기	자원을 한 개 이상 보유하고 있는 상태에서 다른 자원을 기다리는 경우	프로세스가 실행되기 전에 필요한 모든 자원을 할당하도록 합니다. 즉, 필요한 자원을 한 번에 요청하고, 기다림 없이 모든 자원을 확보하는 방식입니다.
비선점	한 번 할당된 자원을 강제로 빼앗을 수 없다.	자원을 요청하는 프로세스가 다른 자원을 요구할 때, 이미 점유하고 있는 자원을 반납하게 합니다. 이렇게 하면 자원은 재할당되어 다른 프로세스가 이용할 수 있게 됩니다.
순환 대기	대기 프로세스의 집합이 순환 형태로 자원을 기다리고 있다.	자원에 고유한 번호를 할당하고, 프로세스가 자원을 요청할 때 번호 순서대로 요청하게 함으로써 순환 대기를 예방합니다. 이렇게 하면 순환 형태로 자원을 대기하는 상태를 방지할 수 있습니다.

 

---

4-1. 분산락 

서버가 여러 대일 때 동일한 데이터에 대한 동기화를 보장하는 것이 중요합니다.

이때, 여러 서버에서 동시에 동일한 자원을 접근하거나 수정하려고 할 때, 충돌을 방지하는 방법으로 분산 락을 사용합니다.

 

분산락은 여러 서버들간 동기화된 처리가 필요하고, 공통된 락을 적용해야 하기 때문에 공통된 데이터 저장소를 사용해 분산락을 이용합니다. Redis 나 MySQL 을 사용해서 분산락을 사용할 수 있습니다 !

 

예를 들어 Redis 를 사용해서 분산락을 사용하는 과정을 예시로 들어보겠습니다!

 

 

서버 A가 자원에 접근하려고 할 때, Redis에 해당 자원에 대한 락을 요청합니다.

Redis는 자원에 락이 걸려 있는지 확인하고, 락이 없다면 해당 자원에 락을 걸어 서버 A에게 자원을 사용할 수 있도록 허용합니다.

서버 A가 자원 사용을 마친 후, Redis에 락을 해제하여 다른 서버가 해당 자원에 접근할 수 있도록 합니다.

 

락 개념 & DB 내부 락 구조

기본적인 락 개념 & DB 내부 락 구조