[Database] 동시성 제어(Concurrency Control) - Locking

앞선 글을 읽고 온 당신, 동시성 제어에 대해서 조금은 배워보았을 것이다. 이제 다음 제어 방법인 Locking에 대해서 같이 알아봅시다~!

Locking

Locking은 하나의 트랜잭션이 데이터에 접근하는 동안, 다른 트랜잭션이 그 데이터를 동시에 변경하거나 읽지 못하도록 제한하는 메커니즘을 의미합니다! 그럼 이렇게 제한하는 대상은 어떻게 될까요?!

1. Locking의 대상

① Row-Level Lock (행 단위 잠금)

• 정밀함: 단 한 개의 레코드(행)에만 잠금을 거는 방식.
• 동시성 매우 높음: 다른 트랜잭션은 같은 테이블 내 다른 행에 대해서는 작업 가능.
• 사용 예시: MySQL InnoDB의 기본 잠금 방식.
• 단점: 잠금 수가 많아지면 관리 비용(오버헤드) 증가, 복잡한 데드락 가능성 증가.

// ex
UPDATE employees SET salary = 5000 WHERE id = 101;

→ id = 101 행만 생긴다.

② Table-Level Lock (테이블 전체 잠금)

• 단순함: 테이블 전체를 한 번에 잠그는 방식
• 동시성 낮음: 하나의 트랜잭션이 테이블을 사용 중이면, 나머지 트랜잭션은 모두 대기
• 사용 예시: MyISAM 엔진에서 주로 사용
• 장점: 구현 및 관리가 단순, 데드락 가능성 거의 없음
• 단점: 대규모 다중 사용자 환경에선 병목(Bottleneck)

// ex
LOCK TABLE employees WRITE;

→ employees 테이블 전체가 배타 잠금

③ Page-Level Lock (페이지 단위 잠금)

• 절충안: 하나의 페이지(일반적으로 4KB ~ 8KB)에 포함된 여러 행을 잠그는 방식
• 사용 예시: 일부 DBMS의 내부 구현에서 사용
• 장점: Table-level보단 동시성 높고, Row-level보다 관리비용 적음
• 단점: 하나의 페이지 안에 잠금 충돌 가능성이 존재

---

2. Lock의 종류 (Lock Type)

① 공유 잠금 (shared lock / s-lock): 데이터를 읽을 때 사용하는 락.

• 공유 잠금을 설정한 트랜잭션에서 데이터 항목에 대해 읽기(SELECCT) 연산만 가능합니다.
  1. T1이 id=101을 읽기 위해 S-lock
  2. T2도 같은 id=101을 읽는 경우 → 가능
  3. 하지만 T2가 UPDATE 시도 → 대기
• 하나의 데이터 항목에 대해서 여러 개의 공유잠금 (s-lock)이 가능합니다.
  1. T1이 id=101을 읽기 위해 S-lock
  2. T2도 같은 id=101를 s-lock → 가능
• 다른 트랜젝션도 읽기 연산만 실행 할 수 있습니다.

⇒ 이를 실생활로 생각해본다면

→ 1개의 발권된 책을 읽는 우리 모두는, 출판사가 수정할려고 할때 우리 모두 멈춰야 한다는 것!

② 배타 잠금 (exclusive lock / x-lock): 데이터를 변경할 때 사용하는 락

• 배타잠금을 설정한 트랜잭션은 데이터 항목에 대해서 읽기 연산(read)과 쓰기 연산(write) 모두 가능합니다.
  1. T1이 id=101에 대해 UPDATE 실행
  2. → id=101에 대해 X-lock 획득
  3. T2가 SELECT 시도해도 대기
• 하나의 데이터 항목에 대해서는 하나의 배타잠금(X-lock)만 가능합니다.
• 동시에 여러 개의 배타잠금은 불가능합니다.
• 다른 트랜잭션은 읽기 연산(read)와 쓰기 연산(write) 모두 불가능합니다.

⇒ 이를 실생활로 생각해본다면

→ 문서 수정 중일 때, 다른 사람은 열람조차 못 하게 막는 것!

---

3. Locking 을 활용한 동시성 제어 기법.

① 낙관적 락 (optimistic lock)

“충돌은 잘 안 날 거야”라는 낙천적인 가정에서 출발한 방식입니다.

1. 개념
   • 낙관적 락은 충돌이 거의 발생하지 않을 것이라 가정하고, 처음에는 Lock을 걸지 않습니다. 대신, 데이터를 수정하려는 시점에 버전 정보(예: version 필드)를 비교하여 동시성 충돌이 발생했는지 확인합니다.
2. 작동 방식
   1. 데이터를 읽는다 (예: version = 3)
   2. 수정 작업을 준비한다
   3. 업데이트할 때 version = 3인지 확인
   4. 맞으면 업데이트 & version 증가
   5. 아니라면 충돌로 간주, 재시도하거나 사용자에게 알림
3. 특징!
   • 충돌이 발생하면 재시도 또는 병합을 통해서 충돌을 해결합니다.
   • Lock을 직접 걸지 않고 내가 읽은 version이 맞는지 확인 함으로써 정합성을 맞추는 방법입니다.
   • 경합이 적은 환경에서 성능이 우수합니다. (ex.게시판, 쇼핑몰, 조회 위주의 서비스 등 읽기가 많은 시스템)

② 비관적 락 (Pessimistic Lock)

“충돌이 날 가능성이 높다”는 비관적인 관점에서 시작합니다.

1. 개념
   • 비관적 락은 데이터를 읽거나 수정하기 전에 먼저 Lock을 획득하여 다른 트랜잭션의 접근을 차단합니다. 실제 데이터에 S-lock 또는 X-lock을 걸어, 현재 트랜잭션만 자원에 접근 가능하도록 합니다.
2. 작동 방식
   1. 데이터를 SELECT하면서 Lock을 함께 획득 (SELECT ... FOR UPDATE)
   2. Lock을 가진 트랜잭션만 해당 데이터에 접근 가능
   3. 수정 완료 후 COMMIT → Lock 해제
3. 특징!
   • 실제로 데이터에 lock을 걸어서 정합성을 맞추는 방법으로, 자원 요청에 따른 동시성 문제가 발생할 것이라고 예상하고 lock을 걸어버리는 방법입니다. → 그러나 Lock 획득으로 성능 저하 or 데드락 가능성이 있습니다.
   • 데이터에 대한 배타적인 액세스 권한을 보장하여 충돌 자체를 사전에 방지한다.
   • 데이터를 읽거나 수정하기 전에 lock을 획득하여 다른 사용자의 액세스를 차단하고, lock을 가진 스레드만 접근하도록 제어한다. (ex. 금융, 예약, 재고 시스템처럼 경쟁이 빈번한 환경 )

마무리.

낙관적 락과 비관적 락은 서로 반대되는 성격을 가진 동시성 제어 전략입니다.

어떤 방식을 선택해야 하는지는 시스템의 특성에 따라 달라집니다.

• 읽기 위주 & 충돌 적음 → 낙관적 락
• 경쟁 심하고 정합성 중요 → 비관적 락

여러분의 서비스 환경에 맞는 동시성 제어 전략을 잘 선택하셔서, 안정적이고 일관된 시스템을 유지하시길 바랍니다!

 

이전글을 읽어보고 싶다면?

2025.07.14 - [BackEnd🍃/DB & SQL] - [Database] 동시성 제어(Concurrency Control) - MVCC

[Database] 동시성 제어(Concurrency Control) - MVCC

 

 

*인용*

https://dev.mysql.com/doc/refman/8.4/en/innodb-locking.html?utm_source=chatgpt.com

https://velog.io/@c1madang/Concurrency-Control