낙관적 락(Optimistic Locking)과 비관적 락(Pessimistic Locking)은 데이터의 동시성 제어 방법이다. 여러 프로세스나 트랜잭션이 동시에 데이터를 수정할 때, 데이터의 무결성을 보장하고 충돌을 방지하기 위해 사용된다. 이 두 방식은 락을 거는 시점과 접근 방식이 서로 다르며, 각각의 장단점이 있다.
1. 낙관적 락 (Optimistic Locking)
개념
- 낙관적 락은 데이터 충돌이 드물 것이라고 가정하는 방식이다. 즉, 여러 트랜잭션이 동시에 데이터를 읽고, 수정할 가능성이 낮다고 생각한다.
- 데이터에 접근할 때 락을 걸지 않고, 수정하려고 할 때 충돌 여부를 확인한다.
- 주로 읽기 작업이 많고 쓰기 작업이 적은 환경에서 적합하다.
동작 방식
- 데이터를 읽음: 트랜잭션은 데이터를 읽을 때 락을 걸지 않고, 해당 데이터를 읽는다.
- 버전 체크: 데이터를 수정할 때, 데이터 버전(version)이나 타임스탬프(timestamp) 등을 비교하여, 다른 트랜잭션이 그 데이터를 수정했는지 확인한다.
- 수정 시 충돌 확인:
- 만약 데이터가 수정되지 않았다면, 트랜잭션은 데이터를 성공적으로 수정하고 커밋한다.
- 하지만 데이터가 다른 트랜잭션에 의해 수정되었다면, 충돌이 발생한 것으로 간주하고 수정 작업을 중단하며 오류를 발생시킨다.
예시
1. 트랜잭션 A와 B가 동시에 고객 데이터를 읽음.
2. 트랜잭션 A가 데이터를 수정하고 커밋함. (버전 1 → 버전 2)
3. 트랜잭션 B가 데이터를 수정하려고 시도하지만, 이미 버전이 변경되었음을 확인하고 실패.
4. 트랜잭션 B는 충돌을 감지하고 데이터를 다시 읽고 수정해야 함.
장점
- 성능 최적화: 락을 거는 작업이 없으므로, 동시 읽기 작업이 많은 상황에서 성능이 뛰어나다.
- 낮은 대기 시간: 락을 기다리는 시간이 없어 동시성 처리에 유리하다.
단점
- 충돌 처리 비용: 만약 충돌이 자주 발생하면, 데이터를 다시 읽고 수정해야 하므로 성능 저하가 발생할 수 있다.
- 재시도 필요: 충돌이 발생할 경우 트랜잭션을 재시도해야 하므로 추가적인 처리 로직이 필요하다.
사용 사례
- 읽기 작업이 많은 시스템: 충돌 가능성이 적은 환경에서 유리하다. 예를 들어, 데이터 분석 시스템이나 게시판처럼 쓰기 작업이 적고 읽기 작업이 많은 경우에 사용된다.
2. 비관적 락 (Pessimistic Locking)
개념
- 비관적 락은 데이터 충돌이 자주 발생할 것이라고 가정하는 방식이다. 데이터를 읽는 즉시 락을 걸어 다른 트랜잭션이 해당 데이터에 접근하지 못하도록 막는다.
- 주로 쓰기 작업이 빈번하고, 충돌 가능성이 높은 환경에서 적합하다.
동작 방식
- 락을 걸고 데이터 읽기: 트랜잭션이 데이터를 읽을 때 락을 설정하여, 다른 트랜잭션이 그 데이터를 읽거나 수정하지 못하게 한다.
- 데이터 수정: 데이터를 안전하게 수정하고, 수정이 완료된 후에 락을 해제한다.
- 락 해제: 트랜잭션이 완료되면 락을 해제하여 다른 트랜잭션이 데이터에 접근할 수 있게 한다.
예시
1. 트랜잭션 A가 고객 데이터를 읽을 때 락을 걸고 데이터를 수정함.
2. 트랜잭션 B가 같은 데이터를 읽으려고 시도하지만, 락이 걸려 있어 대기.
3. 트랜잭션 A가 데이터를 수정하고 락을 해제한 후, 트랜잭션 B가 데이터를 읽음.
장점
- 데이터 충돌 방지: 락을 걸기 때문에 충돌이 발생하지 않는다. 트랜잭션은 충돌 없이 데이터를 안전하게 수정할 수 있다.
- 확실한 동기화: 데이터 무결성을 보장하며, 데이터를 수정하는 동안 다른 트랜잭션이 개입하지 못한다.
단점
- 성능 저하: 락을 설정하는 과정에서 대기 시간이 길어질 수 있다. 특히, 많은 트랜잭션이 동시에 동일한 데이터를 처리하려고 하면, 병목 현상이 발생할 수 있다.
- 데드락 위험: 여러 트랜잭션이 서로 다른 자원에 대해 락을 걸고, 상대방의 자원이 해제되기를 기다리는 데드락(Deadlock) 상황이 발생할 수 있다.
사용 사례
- 쓰기 작업이 많은 시스템: 충돌 가능성이 높고, 데이터의 무결성이 매우 중요한 은행 시스템, 트랜잭션 처리 시스템 등의 환경에서 비관적 락을 사용한다. 데이터 수정이 빈번하거나 데이터 충돌이 자주 발생하는 상황에서 더 적합하다.
낙관적 락 vs 비관적 락
특징 | 낙관적 락 (Optimistic Locking) | 비관적 락 (Pessimistic Locking) |
충돌 가정 | 충돌이 거의 발생하지 않을 것이라고 가정 | 충돌이 자주 발생할 것이라고 가정 |
락 설정 시점 | 수정 시점에서 충돌 여부를 확인 | 데이터 읽기 시점에서 즉시 락을 설정 |
성능 | 읽기 작업이 많을 때 성능이 좋음 | 충돌이 많을 경우 데이터 무결성을 보장하지만 성능 저하 가능 |
충돌 처리 방식 | 충돌이 발생하면 수정 실패 후 재시도 | 충돌이 발생하지 않음(락으로 보호) |
락 해제 | 충돌 확인 후 데이터 수정 완료 시 | 데이터 수정 후 트랜잭션 종료 시 해제 |
사용 환경 | 충돌이 적고 읽기 작업이 많은 시스템 | 쓰기 작업이 많고 충돌 가능성이 높은 시스템 |
낙관적 락과 비관적 락 선택 기준
- 낙관적 락이 적합한 경우:
- 데이터 충돌 가능성이 적은 시스템.
- 주로 읽기 작업이 많고, 쓰기 작업이 적은 환경.
- 성능이 중요한 대규모 데이터 읽기 시스템이나 데이터 분석 플랫폼.
- 비관적 락이 적합한 경우:
- 데이터 충돌 가능성이 높은 시스템.
- 쓰기 작업이 많고, 데이터 무결성이 중요한 환경.
- 금융 시스템, 트랜잭션 기반 시스템처럼 정확한 데이터 처리가 중요한 시스템.
- 낙관적 락은 데이터를 수정할 때만 충돌을 확인하는 방식으로, 충돌 가능성이 낮은 환경에서 성능을 최적화하는 데 적합하다. 하지만 충돌이 자주 발생하면 성능 저하와 재시도가 필요하다.
- 비관적 락은 데이터를 읽는 시점에 락을 걸어 다른 트랜잭션의 접근을 막는 방식으로, 충돌 가능성이 높을 때 데이터를 안전하게 보호한다. 그러나 대기 시간이 길어질 수 있고, 성능 저하나 데드락 발생 가능성이 있다.
시스템의 요구 사항과 사용 환경에 따라 적합한 락 전략을 선택하는 것이 중요하다.
728x90
'Backend study > Backend theory' 카테고리의 다른 글
뮤텍스(Mutex)와 세마포어(Semaphore) (1) | 2024.09.24 |
---|---|
IPC (Inter-Process Communication) (0) | 2024.09.22 |
TCP's 3-way handshake, 4-way handshake (0) | 2024.09.20 |
TCP 와 UDP (1) | 2024.09.19 |
Blocking과 Non-blocking (2) | 2024.09.18 |