낙관적 락(Optimistic Lock)과 비관적 락(Pessimistic Lock)
1. 락이란?
여러 개의 트랜잭션이 동시에 접근했을 때, 데이터의 일관성이 깨질 수 있기 때문에 락(잠금)을 걸고 이를 관리하는 것을 Locking이라고 합니다.
예를 들어, 3000원이 있는 계좌에 A와 B가 3000원을 입금했는데 이 과정이 동시에 이루어져서 A와 B가 동시에 3000원을 읽어서 3000원을 더해버리는 바람에 최종 금액이 9000원이 아니라 6000원이 되버리는 현상을 막기 위해 필요합니다.
2. Optimistic Lock
기본적으로 데이터 갱신시 충돌이 발생하지 않을 것 으로 간주하는 방식을 Optimistic Lock(낙관적인 락)이라고 합니다.
설명 그대로 데이터 갱신시 충돌이 발생하지 않을 것이라고 예상하기 때문에, 락을 걸지 않습니다.
낙관적인 락은 Version을 사용해 관리합니다.
- Alice와 Bob이 같은 데이터를 읽어 Version1 값을 가져갑니다.
- Bob이 먼저 업데이트 커밋을 보내게 되면서 Version이 2로 올라갑니다.
- Alice도 업데이트 커밋을 날리면서 Version 2로 올립니다.
- 이미 Version2가 존재하기 때문에 OPtimistic Lopck Exception이 터집니다.
DB단에는 관계없이 단순히 칼럼 정보 하나만을 갖고 처리하기 때문에 애플리케이션에서 거는 락 애플리케이션 락이라고 합니다.
충돌이 발생하지 않을 것이라 가정하지만, 충돌이 생기면 이를 방지하는 정도로 충돌 방지를 수행합니다.
3. Pessimistic Lock
기본적으로 데이터 갱신시 충돌이 발생할 것 으로 보고 미리 잠금을 하는 방식을 Pessimistic Lock(비관적인 락)이라고 합니다.
설명 그대로 데이터 갱신시 충돌이 발생할 것으로 예상하고, 우선적으로 락을 겁니다.(조회 시점부터)
- 운영자가 주문 정보를 조회합니다. 이 순간 데이터에 락이 걸립니다.
- 고객이 같은 주문 정보를 조회하지만 락이 걸려있기에 대기합니다.
- 운영자가 작업을 끝내고 잠금을 해제하면 이때, 고객의 로직이 수행됩니다.
무결성에 장점이 있지만 데드락의 위험성이 존재합니다.
낙관적인 락에 추가 설정이 가능합니다.
- Exclusive Lock
- 위에서 설명한 그림
- 다른 사용자가 읽기, 수정, 삭제 모두 불가능
- Shared Lock
- 다른 사용자가 동시에 읽을 수는 있지만, Update, delete 작업은 방지
4. Optimistic vs Pessimistic
읽기와 수정의 비율이 어디에 가까운지를 잘 판단해서 결정해야 합니다.
수정의 비율이 높다면 Pessmistic을 사용하고 읽기의 비율이 높다면 Optimistic을 사용합니다.
일반적으로 웹 애플리케이션은 주로 읽기 수행작업이 많기 때문에 Optimistic Lock을 주로 사용합니다.
5. 정리
| 구분 | Optimistic Lock | Pessimistic Lock |
|---|---|---|
| 정의 | 충돌이 없을 것으로 가정하여 락을 걸지 않음 | 충돌을 예상하고 미리 락을 검 |
| 사용법 | JPA 사용시 @Version | Mode 설정 및 쿼리에 직접 사용, DB단에서 설정 가능 |
| 별칭 | 낙관적인 락 / 비선점적인 락 | 비관적인 락 / 선점적인 락 |
| 장점 | 데드락 가능성이 적으며 성능의 이점 | 충돌에 대한 오버헤드가 줄어들며 무결성을 지키기 용이 |
| 단점 | 충돌이 발생하면 오버헤드 발생 | 충돌이 없으면 오버헤드가 발생 |
