DB Lock

실무에서 경험한 DB Lock에 대해 정리한 내용입니다.

 

평화롭던 어느 날 서비스에서 타임아웃이 떨어지며 장애가 발생했었습니다. 결제 승인 단계에서 데이터베이스에서 조회하는 과정에서 타임아웃이 떨어지며 Null Exception이 발생했습니다. 데이터베이스 idle transaction을 확인했을 때 idle이 full filled 상태였고 DB Lock이라는 결론을 내렸습니다.

 

DB Lock이란

데이터베이스는 DB 동시성을 보장하기 위해 트랜잭션에서 Lock을 겁니다.

 

쉽게 이야기 하자면 데이터를 수정하는 도중에는 수정되고 있는 데이터를 조회할 수 없게 Lock을 걸게 됩니다.

 

UPDATE가 실행되던 중 SELECT가  실행되면 Lock이 걸리게 되고 UPDATE가 끝나면 Lock이 풀리며 Select가 이루어집니다.

 

이러한 Lock을 예방하기 위해서는 UPDATE와 SELECT가 하나의 테이블을 동시에 발생시키는 구조를 설계상 피해야 합니다.

 

Lock Type이란

Lock에도 타입이 존재합니다. 트랜잭션 격리 수준이라고 표현 가능합니다. 트랜잭션 격리 수준은 데이터베이스마다 다르고 정해진 것이 아니기 때문에 일반적인 정보로 이해하시기 바랍니다.

 

공유락

데이터를 읽을 때 사용되는 Lock으로써 공유 Lock 끼리는 동시에 접근이 가능합니다. 흔히 공유락은 조회를 할 때 발생하기 때문에 공유락 끼리는 동시에 접근이 가능하다는 이유입니다.

 

베타락

데이터가 변경되고자 할 때 발생합니다. 베타락은 해제되기 전까지 다른 트랜잭션의 접근을 막습니다. 위의 설명과 같이 수정될 때 조회를 불가능하게 한다는 이유입니다.

 

Lock Level

- 데이터베이스

- 파일

- 테이블

테이블의 모든 행을 업데이트하는 작업이나, 테이블 전체에 변경이 있을 때 사용됩니다. DDL(create, alter, drop 등) 구문과 함께 사용되면 DDL Lock이라고도 합니다.

- 페이지와 블록

- 칼럼

- 행

행 Lock은 행 기준 Lock으로, DML에 대한 Lock입니다.

 

---

 

다음으로는 Lock으로 발생하는 현상에 대해 이야기해보려 합니다.

 

블로킹(Blocking)

블로킹은 Lock 간의 경합이 발생하여 특정 트랜잭션이 작업을 진행하지 못하고 멈춘 상태를 말합니다.

 

주로 베타락으로 인해 블로킹 현상이 발생하는데, 블로킹을 해결하기 위해서 앞선 트랜잭션이 커밋 또는 롤백이 되어야 합니다.

 

블로킹은 성능에 좋지 않은 영향으로 나타나기 때문에 블로킹되는 현상을 최소화해야 합니다.

 

교착상태(Dead Lock)

교착상태는 두 트랜잭션에 각각의 Lock이 걸려있고, 서로가 서로의 Lock에 접근하여 자원을 요청할 때 발생하게 됩니다.

 

이미 발생한 각각의 트랜잭션이 Lock으로 인해 모두 작업을 처리하지 못하게 됩니다.

 

---

 

실시간으로 서비스가 될 때 데이터는 수시로 쌓이게 됩니다. 이와 동시에 백오피스에서 실시간으로 쌓이는 데이터를 수정하거나 조회를 하다 보면 Lock이 발생하는 현상이 발생한다고 생각합니다. 실시간으로 쌓인 데이터는 트래픽이 낮은 새벽시간에 배치 시스템을 통해 통계되고 집계되어 백오피스로 관리될 수 있게 분리되어야 한다고 생각합니다.

 

실시간으로 쌓이는 데이터는 Insert만 되게 하여야 하고, 백업된 데이터에서 Select, Update 작업이 이루어지는 구조로 나아가야 한다고 생각합니다.

 

실제로 제가 운영하는 서비스에서 과정에서 DB Lock현상이 발생하지 않았지만 최근에 서비스가 성장하면서(건수가 늠) 현재 데이터베이스 구조의 한계를 경험하고 있는 상황입니다.

 

내년에 DB 교체 작업과 이후에 테이블이 분리되는 구조로 변경 계획에 있습니다.

 

감사합니다.