🔒 DB Lock
여러 트랜잭션이 동시에 동일한 데이터를 엑세스할 때 데이터 무결성을 유지하고 충돌을 방지하는 매커니즘
백엔드 개발을 하면서 여러 트랜잭션이 동시에 처리되는 경우가 많습니다. 이러한 동시성은 시스템의 성능을 높이지만, 동시에 데이터 무결성을 위협하는 잠재적인 문제를 동반합니다. 이때 중요한 역할을 하는 것이 바로 DB Lock입니다.
- DB Lock의 종류는 다음과 같이 크게 두 가지로 나뉩니다.
-
LS-Shared Lock : 공유락
-
LX-Exclusive Lock: 배타락
-
공유 락(LS-Shared Lock)
- 여러 트랜잭션이 동시에 동일한 리소스를 읽을 수 있도록 허용합니다.
- 공유 락이 걸린 데이터는 읽기 전용이기 때문에 변경 불가합니다.
- 데이터 일관성을 유지하기 위해 주로 사용, SELECT 쿼리에서 사용합니다.
--Transaction 1: 공유 락 설정
SELECT * FROM member WHERE last_name = 'Kim' LOCK IN SHARE MODE;
--Transaction 2: 공유 락 설정
SELECT * FROM member WHERE last_name = 'Lee' LOCK IN SHARE MODE;- 두 트랜잭션에서 같은 리소스에 동시에 접근 가능합니다.
배타 락(LX-Exclusive Lock)
- 특정 리소스에 대해 한 트랜잭션이 배타적으로 액세스하고 변경할 수 있도록 허용합니다.
- 배타 락이 걸리 데이터는 다른 트랜잭션이 읽거나 쓸 수 없습니다.
- 데이터 수정시 무결성을 보장하기 위해 사용하며 주로 UPDATE, DELETE 쿼리에서 사용합니다.
-- Transaction 1: 배타 락 설정
START TRANSACTION;
UPDATE member SET first_name = 'Ga Eun' WHERE first_name = 'gagle';
-- Transaction 2: 동일 리소스에 대해 배타 락 시도(대기 상태)
START TRANSACTION;
UPDATE member SET first_name = '가은' WHERE first_name = 'gagle';Deadlock (교착 상태)
두 개 이상의 트랜잭션이 서로의 락을 기다리며 무한 대기 상태에 빠지는 상황,
이는 시스템의 성능을 저하시킬 뿐만 아니라 트랜잭션 처리에 치명적인 영향을 미칠 수 있음
1. 교착상태의 발생 조건
- 교착상태에 빠지려면 아래 발생조건 4가지를 모두 충족해야합니다.
- 상호 배제(Mutual Exclusion)
- 자원은 한 번에 하나의 트랜잭션만 사용할 수 있음
- 트랜잭션 A가 특정 자원을 락으로 점유하고 있는 동안, 트랜잭션 B는 그 자원을 사용할 수 없음
- 점유 및 대기(Hold and Wait)
- 트랜잭션이 적어도 하나의 자원을 점유하고 있으면서, 추가로 다른 자원의 사용을 요청하며 대기 상태에 있음.
- 예를 들어, 트랜잭션 A가 자원 X를 락하고 자원 Y를 요청할 때, 자원 Y가 트랜잭션 B에 의해 락되어 있으면 트랜잭션 A는 자원 Y를 기다림
- 비선점(Non-preemption)
- 트랜잭션이 점유한 자원을 강제로 빼앗을 수 없음
- 순환 대기(Circular Wait)
- 두 개 이상의 트랜잭션이 원형(사이클)으로 자원을 서로 점유하고 있으며, 각 트랜잭션은 다음 트랜잭션이 점유한 자원을 기다리고 있음.
- 예를 들어, 트랜잭션 A가 자원 X를 점유하고 자원 Y를 기다리며, 트랜잭션 B가 자원 Y를 점유하고 자원 X를 기다리는 경우
2. 예제
MySQL 로컬 db로 간단한 데드락 상황을 만들어봤습니다.
원래 테이블
첫번 째 세션에서 트랜잭션을 시작하고 1번 row에 update를 해줍니다.
(선점 시작, id = 1 인 행에 대한 배타 락 획득)
두번 째 세션에서 트랜잭션을 시작하고 2번 row에 update를 해줍니다(선점 시작, id = 12 인 행에 대한 배타 락을 획득)
첫번 째 트랜잭션에서 2번 row에 접근합니다(id = 2인 행에 대한 배타 락 요청, 대기 시작)
두 번째 트랜잭션에서 1번 행에 접근합니다 ( id = 1인 행에 대한 배타 락 요청, 대기 시작)
3. 데드락의 탐지
- 대부분의 데이터베이스 시스템은 주기적으로 데드락을 감지하기 위한 메커니즘을 가지고 있습니다.
- Wait-For 그래프(Wait-For Graph)
- 데이터베이스의 트랜잭션과 자원 간의 의존성을 그래프로 표현합니다.
- 각 트랜잭션을 노드로, 자원을 기다리는 상태를 간선으로 표시합니다.
- 그래프에 사이클(순환)이 존재하면 데드락이 발생한 것 입니다.
- 타임아웃 기반 탐지
- 트랜잭션이 특정 시간 동안 자원을 획득하지 못하면 데드락이 발생했다고 판단하고 해당 트랜잭션을 강제 종료합니다.
- 타임아웃 설정이 적절하지 않으면 정상적인 트랜잭션이 중단될 위험이 있습니다.
4. 데드락 해결 방법
- 트랜잭션 강제 종료
- 데드락이 감지되면, 관련된 트랜잭션 중 하나 또는 모두를 강제로 종료(rollback)하여 자원을 해제합니다.
- 가장 적게 작업한 트랜잭션을 종료하거나, 우선순위가 낮은 트랜잭션을 종료하는 방법이 일반적입니다.
- 재시도
- 강제 종료된 트랜잭션을 일정 시간 후 다시 시도하게 하여 데드락 상황을 해결합니다.
- 트랜잭션이 충돌하지 않을 가능성을 높이기 위해 적용됩니다.
3. 데드락 처리 전략
사실 이거는 GPT한테 물어봤습니다...데드락 발생 시 어떻게 처리하는게 좋을지가 궁금해서...
예방, 감지, 그리고 복구의 세 가지 접근 방식으로 나눌 수 있습니다
1. 예방 (Prevention)
-
데드락을 예방하는 방법은 문제 발생 자체를 줄이는 것입니다.
a. 트랜잭션 범위 최소화: 트랜잭션을 짧고 간단하게 유지하여 자원 점유 시간을 최소화합니다.
b. 일관된 잠금 순서(순서 규칙 설정): 여러 트랜잭션이 동일한 자원을 잠글 때, 모든 트랜잭션이 동일한 순서로 자원을 잠그도록 합니다.
c. 적절한 인덱스 사용: 인덱스를 사용하여 쿼리 성능을 향상시키고, 자원 점유 시간을 줄입니다.
d. 트랜잭션 격리 수준 조정: 적절한 격리 수준을 선택하여 데이터의 일관성을 유지하면서 데드락 가능성을 줄입니다.
2. 감지 (Detection)
-
데드락 감지는 시스템에서 데드락이 발생했는지 확인하는 것 입니다.
a. 데드락 감지 알고리즘: 일반적으로는 Wait-For 그래프(Wait-For Graph)(위에서 간단히 설명함)
b. 데드락 로그 분석: 데이터베이스 로그를 분석하여 데드락 발생 시점을 파악합니다.
3. 복구 (Recovery)
-
데드락이 발생한 경우, 이를 해결하기 위한 복구 방법은 다음과 같습니다.
a. 트랜잭션 롤백: MySQL의 InnoDB 스토리지 엔진은 내부적으로 데드락 탐지 기능을 포함하고 있으며, 자동으로 교착 상태를 감지하고 트랜잭션 중 하나를 롤백합니다. (위의 예제에서는 트랜잭션2가 자동 롤백됨)
b. 재시도 로직 구현: 애플리케이션에서 데드락이 발생했을 때 자동으로 트랜잭션을 롤백하고 재시도하는 로직을 구현해야 합니다.
+)
- 데이터베이스 모니터링 도구: MySQL Workbench, pgAdmin (PostgreSQL), SQL Server Management Studio 등에서 데드락 모니터링 및 분석 기능을 제공하고 있습니다.
- 트랜잭션 관리: 대규모 데이터베이스 애플리케이션에서는 트랜잭션 관리를 정교하게 설정하여 데드락 발생 가능성을 줄이고, 발생 시 적절히 처리할 수 있도록 설계해야 합니다.
