데드락 발생 원인과 로그 분석

들어가며

안녕하세요. 원더월 백엔드 개발자 이찬희입니다.

원더월은 서비스 특성상 스파이크성 트래픽이 자주 발생합니다. 가수들의 앨범 판매 오픈이나 한정판매와 같은 이벤트성 판매에서 주로 발생하는데요, 순간적으로 트래픽이 몰리다 보면 결제쪽에서 가끔 데드락이 발생하는 문제가 있었습니다.
이번 포스트에서는 원더월 서비스에서 데드락이 발생하는 원인과 그에 대한 로그를 분석해 보도록 하겠습니다.

데드락이란

이미지 출처: 땔감툰

검색을 해보면 많은 곳에서 아래와 같이 데드락을 정의하고 있습니다.

운영체제에서 데드락(교착상태)이란 시스템 자원에 대한 요구가 뒤엉킨 상태로, 다음과 같은 조건이 동시에 충족될 때 발생합니다.

1. 상호 배제 (Mutual Exclusion): 자원은 동시에 여러 개의 작업이 사용할 수 없고, 한 번에 하나의 작업만 사용할 수 있습니다.
2. 점유 대기 (Hold and Wait): 작업은 이미 어떤 자원을 점유한 상태에서 다른 자원을 기다립니다.
3. 비선점 (No Preemption): 다른 작업이 점유한 자원을 강제로 뺏을 수 없습니다. 자원은 해당 작업이 자발적으로 반납할 때까지 점유됩니다.
4. 순환 대기 (Circular Wait): 작업 간에 자원을 기다리는 순환 형태의 사이클이 형성됩니다.

데드락의 발생 원인은 여러가지가 있지만 이번 포스트에서는 2번 점유 대기 상황에서의 데드락 발생의 사례를 분석해 보겠습니다.

공유 락과 배타 락

로그 분석에 앞서, 락의 종류에 대해 잠깐 짚고 넘어가겠습니다.

Lock의 범위

• Record Lock: 로우가 아닌 DB의 index record에 걸리는 Lock.
• Gap Lock: 레코드들 사이의 갭(Gap)을 락하는 것을 의미합니다. 다른 트랜잭션이 해당 범위에 속하는 레코드를 추가하거나 삭제할 수 없도록 막아줍니다.

Lock의 종류

S락과 X락은 데이터베이스에서 동시성 제어를 위해 사용되는 락의 종류입니다. 각각 공유 락(Shared Lock, S락)과 배타적 락(Exclusive Lock, X락)으로도 불리며 여러 트랜잭션 간의 데이터 접근 충돌을 방지하고 데이터 일관성을 유지하기 위해 사용됩니다.

• S Lock (Shared Lock) 공유 락이라고도 불리며, 여러 트랜잭션이 동시에 해당 자원을 읽을 수 있게 합니다. 여러 트랜잭션 간에 S락을 동시에 획득할 수 있으며, 읽기 작업에 사용됩니다. S락을 획득한 트랜잭션은 다른 트랜잭션에서 해당 자원을 읽을 수 있지만, 변경 작업은 수행할 수 없습니다.

• X Lock (Exclusive Lock) 배타적 락이라고도 불리며, 해당 자원에 대한 배타적인 접근을 제공합니다. 트랜잭션이 X락을 획득하면, 다른 트랜잭션은 해당 자원에 대한 읽기 또는 쓰기 작업을 수행할 수 없습니다. X락은 데이터를 변경하는 작업에 사용됩니다. 트랜잭션이 X락을 획득하면, 다른 트랜잭션에서는 그 자원에 접근할 수 없게 됩니다. S락은 여러 트랜잭션이 동시에 읽기 작업을 수행할 수 있고, X락은 배타적인 접근을 요구하여 읽기 및 쓰기 작업을 독점합니다. 이러한 락들은 동시성 제어를 통해 데이터베이스의 데이터 무결성과 일관성을 유지하며, 여러 트랜잭션 간의 충돌을 방지합니다.

Record Lock, Gap Lock 아래 S Lock, X lock이 존재한다고 이해하면 되겠습니다.

원더월 서비스에서의 데드락 발생 원인

위 테이블은 설명을 위해 극히 일부만 예를 들어 나타낸 것이며 상품과 주문 테이블은 1:N 관계를 가지고 있습니다.
주문의 시작부터 완료까지는 많은 작업을 하게 되지만 데드락의 주 원인이 되었던 부분은 아래와 같습니다.

- 해당 쿼리는 TypeORM으로 구현되었습니다.

1. 주문 생성 api - order 테이블에 insert 합니다.
2. 주문 완료 api - product 테이블의 sold_count(재고)를 update 합니다.

주문 시작부터 주문 완료까지 어느정도 시간차가 존재할 수 밖에 없기에 트래픽이 잠잠할 때는 1번과 2번이 동시에 실행되는 경우가 거의 없습니다. 하지만 주문이 몰리면 위 두개의 api가 거의 동시에 여러개가 실행될 가능성이 존재합니다.
아래는 실제 원더월 서비스에서의 결제 시 발생한 데드락 로그를 예시에 맞춰 간단하게 수정한 것인데요, 어떤 원인에 의해 발생했는지 하나하나 분석해보도록 하겠습니다.

데드락 로그 분석

TRANSACTION 1

2022-xx-xx 0x:1x:3x 2b4eb987d700
**_ (1) TRANSACTION:
TRANSACTION 2346332882, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 13 lock struct(s), heap size 376, 10 row lock(s), undo log entries 5
MySQL thread id 23460, OS thread handle 0x2b4e34bcb700, query id 3040990 10.1.1.178 service_api update
INSERT INTO `order`(`id`, `product_id`) VALUES (DEFAULT, 3086)`
_** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 844 page no 28 n bits 144 index `PRIMARY` of table `wonderwall`.`product` trx id 2346332882 lock mode S locks rec but not gap waiting
Record lock, heap no 144 PHYSICAL RECORD: n_fields 18; compact format; info bits 0
...

먼저 1번 트랜잭션의 로그를 분석해 보겠습니다.

INSERT INTO `order`(`id`, `product_id`) VALUES (DEFAULT, 3086)`

order table에 product 테이블의 PK인 product_id를 포함하여 insert를 시도하고 있습니다.

_** (1) WAITING FOR THIS LOCK TO BE GRANTED:

하지만 insert를 시도하다가 데드락이 발생했습니다. 위 로그는 락을 획득하기 위해 대기하고 있다는 것을 의미합니다. 어떤 락을 획득하기 위해 대기하고 있는지 확인해 보겠습니다.

RECORD LOCKS space id 844 page no 28 n bits 144 index `PRIMARY` of table `wonderwall`.`product` trx id 2346332882 lock mode S locks rec but not gap waiting

product table의 primary 인덱스의 레코드에 락이 걸려있고, S락을 대기하고 있다고 보여집니다. 여기서 살펴봐야 할 부분은 두가지입니다.

1. 왜 레코드 락이 걸렸는가
2. insert를 하려면 X락이 필요한데 왜 S락을 대기하는가
   
   

여기서는 2번에 대한 내용만 설명하고 넘어가고, 1번에 대한 내용은 아래의 2번 트랜잭션을 분석하며 추가로 설명하도록 하겠습니다.
insert를 하려면 X락을 획득해야 한다고 위에서 설명해놨는데 로그를 확인해보니 S락을 대기하고 있습니다. 어떻게 된걸까요?
이는 데이터의 일관성과 동시성을 보장하기 위한 제어 메커니즘 때문인데요, 일반적으로 X락을 획득하기 위해서는 먼저 S락을 획득해야 합니다.
S락은 여러 트랜잭션에서 동시에 획득할 수 있는 공유 락이기 때문에 데이터의 일관성을 유지하면서 동시에 읽을 수 있습니다. 하지만 X락은 배타적인 접근을 요구하기 때문에 다른 트랜잭션이 S락을 보유하고 있는 경우 X락을 획득하기 위해서는 다른 트랜잭션이 보유하고 있는 S락이 모두 커밋되거나 롤백될 때까지 대기해야만 합니다.
이러한 이유로 위 로그에서는 S락을 대기하고 있다고 나오는 것이며, 실제 동작은 S락 획득 -> X락 획득 -> insert 순서로 진행됩니다.

---

TRANSACTION 2

**_ (2) TRANSACTION:
TRANSACTION 2346332859, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 22 lock struct(s), heap size 376, 25 row lock(s), undo log entries 10
MySQL thread id 23391, OS thread handle 0x2b4e34a45700, query id 3040994 10.1.2.132 service_api updating
UPDATE `product` SET `sold_count` = sold_count + 1  WHERE `id`=3086`
_** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 844 page no 28 n bits 144 index `PRIMARY` of table `wonderwall`.`product` trx id 2346332859 lock_mode X locks rec but not gap
Record lock, heap no 144 PHYSICAL RECORD: n_fields 18; compact format; info bits 0
...

이번에는 2번 트랜잭션을 분석해 보겠습니다.

UPDATE `product` SET `sold_count` = sold_count + 1  WHERE `id`=3086`

product 테이블의 sold_count 컬럼을 update 하려고 시도합니다.

HOLDS THE LOCK(S)

이 로그는 해당 트랜잭션이 보유하고 있는 락의 종류를 의미합니다. S락을 보유하고 있는 것으로 보이는데요, X락을 보유하고 있어야 할 것 같은데 뭔가 이상합니다. 좀 더 살펴보겠습니다.

RECORD LOCKS space id 844 page no 28 n bits 144 index `PRIMARY` of table `wonderwall`.`product` trx id 2346332859 lock_mode X locks rec but not gap Record lock

1번 트랜잭션에서 설명하다 말았던 레코드 락이 걸려있던 이유가 이곳에 있습니다.
2번 트랜잭션에서 product 테이블의 sold_count를 를 업데이트 하기 위해 레코드 락을 걸어놓은 상태이며, update를 실행해야 하기 때문에 X락을 획득한 상태입니다.
위에서 설명했듯이 X락을 획득하려면 S락을 획득해야 하니, S락도 보유하고 있을 것입니다.
그러면 방금 전에 HOLDS THE LOCK(S) 이부분에서 왜 X락이 아닌 S락을 보유하고 있다고 나오는지에 대한 의문이 풀릴 것 같습니다.
1번 트랜잭션 입장에서 보면 궁극적으로는 X락의 획득이 목표이나, X락보다 S락을 먼저 획득해야 하기 때문에 로그상으로는 2번 트랜잭션이 S락을 보유하고 있는 것으로 보이는 것입니다.

정리를 해보자면 2번 트랜잭션이 보유하고 있는 X락을 획득하기 위해 1번 트랜잭션이 대기하는 과정에서 데드락이 발생하고 있었던 것으로 보여집니다.

마치며

이번 포스트에서는 데드락의 발생 원인과 로그를 분석해 보았습니다.
최근에 오픈한 프롬 스토어에서는 새로운 방법을 사용하여 재고 처리를 진행하고 데드락을 회피하고자 했는데요, 다음 포스트인 데드락 예방과 SQS 도입 다뤄보도록 하겠습니다.