낙관적(Optimistic) 락과 비관적(Pessimisitc)락

낙관적(Optimistic) 락과 비관적(Pessimisitc)락

두 락의 차이를 알아봅니다.

Goal

  • 낙관적 락과 비관적 락에 대해서 알아봅니다.

  • 비관적 락에 사용되는 공유락(Shared Lock) 과 베타락(Exclusive Lock)에 대해서 알아봅니다.

  • 언제 어떤 락을 써야할지에 대해서 고민해봅니다.

비관적 락

자원 요청에 따른 동시성문제가 발생할것이라고 예상하고 락을 걸어버리는 방법론입니다.

  • 트랜잭션의 충돌이 발생한다고 가정합니다.

  • 하나의 트랜잭션이 자원에 접근시 락을 걸고, 다른 트랜잭션이 접근하지 못하게 합니다.

  • 데이터베이스에서 Shared Lock(공유, 읽기 잠금) 이나 Exclusive Lock(배타, 쓰기 잠금) 을 겁니다.

  • Shared Lock 의 경우, 다른 트랜잭션에서 읽기만 가능합니다. 또한 Exclusive lock 적용이 불가능합니다. (읽는동안 변경하는것을 막기 위해)

  • Exclusive lock 의 경우. 다른 트랜잭션에서 읽기, 쓰기가 둘다 불가능합니다. 또한 Shared, Exclusive Lock 적용이 추가적으로 불가능합니다. (쓰는동안 읽거나, 다른 쓰기가 오는것을 막기위해)

-- Shared Lock이 걸린경우
1번 트랜잭션: 1번 유저의 닉네임을 읽음
2번 트랜잭션: 1번 유저의 닉네임을 jys로 변경함

-- 유저테이블에 1번 유저 unluckyjung 이라는 닉네임이 있다고 가정합니다.

1번 트랜잭션이 unluckyjung 데이터를 먼저 읽고 있을때 2번 트랜잭션이 접근한다면
1번 트랜잭션이 작업하는동안, 2번 트랜잭션은 읽기는 가능하나 jys 으로 변경하진 못합니다.

장점

  • 충돌이 자주 발생하는 환경에 대해서는 롤백의 횟수를 줄일 수 있으므로 성능에서 유리합니다.

  • 데이터 무결성을 보장하는 수준이 매우 높습니다.

단점

  • 데이터 자체에 락을 걸어버리므로 동시성이 떨어져 성능 손해를 많이 보게 됩니다. 특히 읽기가 많이 이루어지는 데이터베이스의 경우에는 손해가 더 두드러집니다.

  • 서로 자원이 필요한 경우에, 락이 걸려있으므로 데드락이 일어날 가능성이 있습니다.

낙관적 락

자원에 락을 걸어서 선점하지말고, 동시성 문제가 발생하면 그때 가서 처리 하자는 방법론입니다.

  • 트랜잭션의 충돌이 발생하지 않을것이라고 기대합니다.

  • 일단 충돌이 나는것을 막지 않고, 충돌이 난것을 감지하면 그때 처리합니다.

  • 일반적으로 version 의 상태를 보고 충돌을 확인하며, 충돌이 확인된경우 롤백을 진행시킵니다. (hashcode나 timestamp를 이용해서 충돌을 확인할 수 도 있습니다.)

  • DB단에서 동시성을 처리하는것이 아닌, 어플리케이션단에서 처리 합니다.

1번 요청: 1번 유저의 닉네임을 jung yoonsung로 변경함
2번 요청: 1번 유저의 닉네임을 jys로 변경함

-- 유저테이블에 1번 유저 unluckyjung 이라는 닉네임이 있다고 가정합니다. 
-- 해당 유저 데이터의 초기버전은 1입니다.
-- 가장 먼저 업데이트 된것을 적용하는 전략을 선택합니다.

1번 요청: 1번 버전의 1번 유저에게 jung yoonsung으로 변경하고 2번 버전으로 업데이트를 쏩니다.
2번 요청: 1번 버전의 1번 유저에게 jys으로 변경하고 2번 버전으로 업데이트를 쏩니다.

-- 만약 2번 요청이 먼저 완료되는경우 
유저이름은 jys로 바뀌고 2번 버전으로 저장됩니다.
1번 요청에는 버전1을 기반으로 요청을 했는데 2번 요청이 완료됨으로 인해 버전이 2번으로 바뀌어, 1번 버전이 없어졌으므로 업데이트에 실패합니다.

  • 이때 여러 작업이 묶인 트랜잭션으로 요청이 간 경우가 실패한경우, 개발자가 직접 롤백 처리 를 해주어야합니다.

장점

  • 충돌이 안난다는 가정하에, 동시 요청에 대해서 처리 성능이 좋습니다.

단점

  • 잦은 충돌이 일어나는경우 롤백처리에 대한 비용이 많이 들어 오히려 성능에서 손해를 볼 수 있습니다.

  • 롤백 처리를 구현하는게 복잡할 수 있습니다.

Conclusion

  • 비관적락 은 데이터의 무결성이 중요하고, 충돌이 많이 발생하여 잦은 롤백으로 인한 효율성 문제가 발생하는것이 예상되는 시나리오에서좋습니다.

  • 낙관적락 은 실제로 데이터 충돌이 자주 일어나지 않을것이라고 예상되는 시나리오에서 좋습니다.

  • 개인적인 생각으로는 데이터베이스 설계 단계에서 충돌여부가 발생하는지 어느정도 추측은 가능하나 확실치 않으므로, 애매한경우 비관적락 을 걸어두고 서비스 도중 실제로 충돌이 자주 일어나지 않는것이 확인 된 경우에 낙관적락 을 사용하는것이 좋지 않을까 생각합니다.

Reference

  • https://stackoverflow.com/questions/129329/optimistic-vs-pessimistic-locking

  • https://stackoverflow.com/questions/11837428/whats-the-difference-between-an-exclusive-lock-and-a-shared-lock

  • https://jeong-pro.tistory.com/94

  • https://sabarada.tistory.com/121

Previous자바 코드 매핑 vs MapStruct vs ModelMapperNext[JPA] jpa에서 Repository를 이용한 낙관적락을 구현

Last updated