book 의 id 값이 1, 2인 row 에 락을 걸고, 그와 동시에 book 테이블의 FK 관계인 author 테이블에도 동시에 exclusvie lock 을 걸어놓고 (읽기, 쓰기) 안전하게 레코드를 수정하는 방법입니다.
1
2
3
4
SELECT *
FROM book INNER JOIN author
ON book.author_id = author.id
WHERE book.id IN (1, 2) FOR UPDATE;
문제는 XLock (이하 Exclusive lock 은 XLock 으로 멘션하겠습니다.) 의 특성상 XLock 을 획득하지 못한 세션에서 락이 걸려있는 row 의 읽기/쓰기시에 Pending(또는 Waiting) 먼저 XLock 을 획득한 세션이 Rollback or Commit 되기 이전까지 대기해야 하는 블록킹 이슈가 있습니다.
또한, DB의 TPS(초당 트랜잭션의 수) 는 보통 최대 초당 1000건 정도 수준이라서, 크리스마스 타임딜과 같은 분단위 이벤트 발생시 대응하기 어려운 이슈가 있습니다.
그렇다면 순간 급증 트래픽에서 공유 자원을 핸들링하는 방법은?
- 11번가 Kafka 기반의 Queue로 요청을 적재하고 이후 처리하는 방법을 사용하고 있습니다.
https://deview.kr/2019/schedule/305
- 쿠팡은 Redis를 통해서 재고관리를 하고 있습니다. https://www.clien.net/service/board/news/13748885
- 배민은 Redis 를 마치 Queue 처럼 활용하고 있습니다. https://woowabros.github.io/experience/2016/11/28/woowahan_4one_event.html
이러한 내용을 미루어 짐작해보면, Exclusive Lock 은 제한된 사용자가 있는 환경에서는 완벽한 정답이 될 수 있지만, 순간 급증하는 트래픽 환경에서는 적용하기에 한계가 있구나 라는 생각을 미루어 짐작해 볼 수 있습니다. 또한, Redis 같은 경우에는 마치 DB 처럼 믿고 사용하기에도 한계가 있습니다. (예 : 쿠팡의 장애) 그래서, 나오게된 설계안이 바로 람다 아키텍쳐 (Lambda Architecture) 입니다. https://gyrfalcon.tistory.com/entry/%EB%9E%8C%EB%8B%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-Lambda-Architecture 이 부분은 지금은 저도 이해하기 어려워서 차차 살펴볼 생각입니다.
정리
Exclusive Lock 란? 어떤 트랜잭션에서 데이터를 변경하고자 할 때 해당 트랜잭션이 완료될 때까지 해당 테이블 혹은 레코드와 테이블의 FK 관계인 테이블에도 다른 트랜잭션에서 읽기, 쓰기를 못하게 하기 위해 Exclusive lock을 걸고 트랜잭션을 진행시키는 것.
Exclusive Lock 은 동시성 이슈가 적은 상황에 적합.
- ex) 회원의 정보를 수정은 회원본인만 가능하기 때문에 일관성, 무결성 보장. 동시성 이슈가 없음.