PostgreSQL의 격리수준과 비관적 락

PostgreSQL의 격리수준에 대해

PostgreSQL의 기본 격리 수준은 READ COMMITTED 이다.

 

READ COMMITTED란 ?

다른 트랜잭션이 데이터를 새로 커밋하면, 현재 트랜잭션 도중에도 최신 커밋된 값을 읽을 수 있는 것이다.

즉, 현재 트랜잭션 안에서 동일한 row를 두 번 이상 조회 했을때, 중간에 다른 값이 나올 수도 있다.

 

한정된 수량을 실시간으로 판매하는, 한정판매 이벤트에서 READ COMMITTED 여서 발생할 수 있는 문제는 무엇일까?

* 바로 재고가 중복 감소 되는 것이다. *

• 예를 들어 A 와 B가 동시에 재고를 조회하여 둘 다 남은 재고가 한 개 라고 한다면, 둘 다 주문이 가능할 것이고, 남은 재고를 초과하는 주문이 발행될 것이다.

따라서 동시 접근 시 데이터 정합성이 깨지는 문제가 발생할 수 있다.

 

이러한 원인은 트랜잭션이 완전히 끝나기 전에 다른 스레드들도 동일한 데이터를 읽고 처리할 수 있어 발생하는 것이므로

→ “락”을 걸어 여러 트랜잭션이 한 번에 데이터를 읽고, 수정할 수 없게 하여 동시성 충돌을 방지하면 된다.

 

락을 적용하지 않았을때와 적용했을때 비교 테스트 :

락과 트랜잭션이 적용이 안된 상태로 테스트 :

예외처리를 해둔 덕분에 최종 재고는 0이였지만,

100개의 재고를 훨씬 초과하는 1083개의 주문이 이루어 졌다.

 

 

비관적 락과 트랜잭션이 적용된 상태로 테스트 :

 

시작 재고와 성공 개수가 정확히 일치했고, 정합성이 보장됨을 확인할 수 있었다.

 

하지만 락을 적용했을 경우, 전체 테스트 수행 시간이 약 1.5배 더 걸렸다.

 

PostgreSQL은 기본적으로 락을 얻기 위해 무한히 대기하도록 설정되어 있어서

실시간 처리와 빠른 응답이 중요한 서비스에서는 심각한 지연을 유발 할 수 있다.

 

이를 방지하기 위해 lock_timeout을 설정해 줄 수 있지만,

한정판매 이벤트처럼 순서가 중요한 상황에서는 순번안에 들어왔는데 timeout 때문에 주문을 하지 못하고 순번이 뒤로 밀리는 경우가 생길 수 있어 timeout 설정이 오히려 문제가 될 수 있다.

 

따라서 비관적 락의 시간적 문제를 해결하기 위해 다음 단계로 Redis 도입할 예정이다.