본문 바로가기

Backend study/Backend theory

낙관적 락(Optimistic Locking)과 비관적 락(Pessimistic Locking)

낙관적 락(Optimistic Locking)비관적 락(Pessimistic Locking)데이터의 동시성 제어 방법이다. 여러 프로세스나 트랜잭션이 동시에 데이터를 수정할 때, 데이터의 무결성을 보장하고 충돌을 방지하기 위해 사용된다. 이 두 방식은 락을 거는 시점과 접근 방식이 서로 다르며, 각각의 장단점이 있다.

 

1. 낙관적 락 (Optimistic Locking)

개념

  • 낙관적 락데이터 충돌이 드물 것이라고 가정하는 방식이다. 즉, 여러 트랜잭션이 동시에 데이터를 읽고, 수정할 가능성이 낮다고 생각한다.
  • 데이터에 접근할 때 락을 걸지 않고, 수정하려고 할 때 충돌 여부를 확인한다.
  • 주로 읽기 작업이 많고 쓰기 작업이 적은 환경에서 적합하다.

동작 방식

  1. 데이터를 읽음: 트랜잭션은 데이터를 읽을 때 락을 걸지 않고, 해당 데이터를 읽는다.
  2. 버전 체크: 데이터를 수정할 때, 데이터 버전(version)이나 타임스탬프(timestamp) 등을 비교하여, 다른 트랜잭션이 그 데이터를 수정했는지 확인한다.
  3. 수정 시 충돌 확인:
    • 만약 데이터가 수정되지 않았다면, 트랜잭션은 데이터를 성공적으로 수정하고 커밋한다.
    • 하지만 데이터가 다른 트랜잭션에 의해 수정되었다면, 충돌이 발생한 것으로 간주하고 수정 작업을 중단하며 오류를 발생시킨다.

예시

1. 트랜잭션 AB가 동시에 고객 데이터를 읽음.
2. 트랜잭션 A가 데이터를 수정하고 커밋함. (버전 1 → 버전 2)
3. 트랜잭션 B가 데이터를 수정하려고 시도하지만, 이미 버전이 변경되었음을 확인하고 실패.
4. 트랜잭션 B는 충돌을 감지하고 데이터를 다시 읽고 수정해야 함.

장점

  • 성능 최적화: 락을 거는 작업이 없으므로, 동시 읽기 작업이 많은 상황에서 성능이 뛰어나다.
  • 낮은 대기 시간: 락을 기다리는 시간이 없어 동시성 처리에 유리하다.

단점

  • 충돌 처리 비용: 만약 충돌이 자주 발생하면, 데이터를 다시 읽고 수정해야 하므로 성능 저하가 발생할 수 있다.
  • 재시도 필요: 충돌이 발생할 경우 트랜잭션을 재시도해야 하므로 추가적인 처리 로직이 필요하다.

사용 사례

  • 읽기 작업이 많은 시스템: 충돌 가능성이 적은 환경에서 유리하다. 예를 들어, 데이터 분석 시스템이나 게시판처럼 쓰기 작업이 적고 읽기 작업이 많은 경우에 사용된다.

 

2. 비관적 락 (Pessimistic Locking)

개념

  • 비관적 락데이터 충돌이 자주 발생할 것이라고 가정하는 방식이다. 데이터를 읽는 즉시 락을 걸어 다른 트랜잭션이 해당 데이터에 접근하지 못하도록 막는다.
  • 주로 쓰기 작업이 빈번하고, 충돌 가능성이 높은 환경에서 적합하다.

동작 방식

  1. 락을 걸고 데이터 읽기: 트랜잭션이 데이터를 읽을 때 락을 설정하여, 다른 트랜잭션이 그 데이터를 읽거나 수정하지 못하게 한다.
  2. 데이터 수정: 데이터를 안전하게 수정하고, 수정이 완료된 후에 락을 해제한다.
  3. 락 해제: 트랜잭션이 완료되면 락을 해제하여 다른 트랜잭션이 데이터에 접근할 수 있게 한다.

예시

1. 트랜잭션 A가 고객 데이터를 읽을 때 락을 걸고 데이터를 수정함.
2. 트랜잭션 B가 같은 데이터를 읽으려고 시도하지만, 락이 걸려 있어 대기.
3. 트랜잭션 A가 데이터를 수정하고 락을 해제한 후, 트랜잭션 B가 데이터를 읽음.

장점

  • 데이터 충돌 방지: 락을 걸기 때문에 충돌이 발생하지 않는다. 트랜잭션은 충돌 없이 데이터를 안전하게 수정할 수 있다.
  • 확실한 동기화: 데이터 무결성을 보장하며, 데이터를 수정하는 동안 다른 트랜잭션이 개입하지 못한다.

단점

  • 성능 저하: 락을 설정하는 과정에서 대기 시간이 길어질 수 있다. 특히, 많은 트랜잭션이 동시에 동일한 데이터를 처리하려고 하면, 병목 현상이 발생할 수 있다.
  • 데드락 위험: 여러 트랜잭션이 서로 다른 자원에 대해 락을 걸고, 상대방의 자원이 해제되기를 기다리는 데드락(Deadlock) 상황이 발생할 수 있다.

사용 사례

  • 쓰기 작업이 많은 시스템: 충돌 가능성이 높고, 데이터의 무결성이 매우 중요한 은행 시스템, 트랜잭션 처리 시스템 등의 환경에서 비관적 락을 사용한다. 데이터 수정이 빈번하거나 데이터 충돌이 자주 발생하는 상황에서 더 적합하다.

 

낙관적 락 vs 비관적 락

 

특징  낙관적 락 (Optimistic Locking) 비관적 락 (Pessimistic Locking)
충돌 가정 충돌이 거의 발생하지 않을 것이라고 가정 충돌이 자주 발생할 것이라고 가정
락 설정 시점 수정 시점에서 충돌 여부를 확인 데이터 읽기 시점에서 즉시 락을 설정
성능 읽기 작업이 많을 때 성능이 좋음 충돌이 많을 경우 데이터 무결성을 보장하지만 성능 저하 가능
충돌 처리 방식 충돌이 발생하면 수정 실패 후 재시도 충돌이 발생하지 않음(락으로 보호)
락 해제 충돌 확인 후 데이터 수정 완료 시 데이터 수정 후 트랜잭션 종료 시 해제
사용 환경 충돌이 적고 읽기 작업이 많은 시스템 쓰기 작업이 많고 충돌 가능성이 높은 시스템

낙관적 락과 비관적 락 선택 기준

  • 낙관적 락이 적합한 경우:
    • 데이터 충돌 가능성이 적은 시스템.
    • 주로 읽기 작업이 많고, 쓰기 작업이 적은 환경.
    • 성능이 중요한 대규모 데이터 읽기 시스템이나 데이터 분석 플랫폼.
  • 비관적 락이 적합한 경우:
    • 데이터 충돌 가능성이 높은 시스템.
    • 쓰기 작업이 많고, 데이터 무결성이 중요한 환경.
    • 금융 시스템, 트랜잭션 기반 시스템처럼 정확한 데이터 처리가 중요한 시스템.

 

  • 낙관적 락은 데이터를 수정할 때만 충돌을 확인하는 방식으로, 충돌 가능성이 낮은 환경에서 성능을 최적화하는 데 적합하다. 하지만 충돌이 자주 발생하면 성능 저하와 재시도가 필요하다.
  • 비관적 락은 데이터를 읽는 시점에 락을 걸어 다른 트랜잭션의 접근을 막는 방식으로, 충돌 가능성이 높을 때 데이터를 안전하게 보호한다. 그러나 대기 시간이 길어질 수 있고, 성능 저하나 데드락 발생 가능성이 있다.

시스템의 요구 사항과 사용 환경에 따라 적합한 락 전략을 선택하는 것이 중요하다.

728x90

'Backend study > Backend theory' 카테고리의 다른 글