🚥 Concurrency Control 동시성 제어

• 트랜잭션들이 동시에 수행될 때 일관성을 해치지 않도록 데이터 접근을 제어하는 DBMS 기능
• 같은 데이터에 다른 Read / Write 가 있다면 예상치 못한 동작 가능성
• DB에서 활용 가능한 동시성 제어 기술 = Lock
• NonSerializable
  • 같은 데이터에 대한 여러 트랜잭션의 동시 접근으로 원래의 결과와 다른 결과가 나오는 것
  • 우리는 Serializable한 DB환경을 만들기 위해서 Lock 을 사용함

🔒 Lock

😚 Optimistic Lock 낙관적 잠금

전제

• 데이터 갱신 시 경합이 발생하지 않을 것이라고 봄

Lock 방식

• 한 트랜잭션에서 업데이트 완료 시, 동시에 업데이트 확약을 시도하는 다른 사용자들에게 충돌 알림
• 버전 읽기로 충돌 감지 → 동시성 제어
  • Read, Write 시점에 버전 읽기
  • Read Version = Write Version → Version Update
  • Read Version ≠ Write Version → Conflict

적용

• 동시 업데이트 거의 없는 경우

🧐 Pessimistic Lock 비관적 잠금

전제

• 동일한 데이터를 동시에 수정할 가능성이 높다고 봄

Lock 방식

• 각 트랜잭션 선행 트랜잭션이 업데이트 확약 후 레코드 잠금을 해제할 때까지 대기해야 함.
• 잠금 / 해제 -> 동시성 제어
  • Lock
    • 트랜잭션 동안 필요한 레코드에 잠금 설정
    • 다른 트랜잭션의 접근 거부
  • Unlock
    • 트랜잭션 종료하여 필요치 않으면 해제 설정
    • 기다리고 있던 다른 트랜잭션 접근 및 잠금 허용

적용

• 동시 업데이트 빈번한 경우
• 외부 시스템과 연동한 경우

종류

• 공유 Lock
• 배타 Lock
• 업데이트 Lock
• 내재 Lock

공용(Shared) Lock : S-Lock / Read-Lock

• Read 할 때 사용하는 락
• 다른 트랜잭션이 같은 데이터를 read 하는 것은 허용
  • 데이터 사용권을 여러 트랜잭션이 함께 가질 수 있음
  • 여러 트랜잭션이 읽기만 가능

배타(Exclusive) Lock : X-Lock / Write-Lock

• Read, Write 할 때 사용하는 락
• 배타 Lock을 건 트랜잭션만 해당 데이터에 대한 독점권을 가짐
  • 다른 트랜잭션이 같은 데이터를 read/write 하는 것을 허용하지 않음

업데이트(Update) Lock : U-Lock / Update-Lock

• Update 쿼리의 where 필터할 때 사용하는 락
• 배타 락 실행 전 데드락 방지를 위해 사용

내재(Intent) Lock : I-Lock

• 사용자가 요청한 범위에 대한 락을 걸 수 있는지 여부를 빠르게 판단하기 위해 사용하는 락

💰 lock 의 단위

💳 Lock Escalation

• 데이터베이스 락 관련 메모리 최적화 기법
• Lock 이 걸리면, 락이 걸린 대상과 그 상위 락 단위에 대해서 내재 락이 함께 생성됨.
  • Lock 자체에 많은 메모리 자원 소모됨.
  • 테이블 내 일정 비율 이상 락 생성 시 레코드 단위가 아닌, 테이블에 락 설정
  • 메모리 사용 최적화

🪫 Lock을 써도 발생하는 문제 해결법

• 락 걸리는 시점에 따른 차이

• 이렇게 락을 거는 시점을 바꾸기만 해도 동시성 문제를 해결할 수 있음

2PL(2-Phase Locking) Protocol

• 트랜잭션에서 모든 Locking Operation이 최초의 Unlocking Operation 보다 먼저 수행되도록 하는 것
• 데드락 발생 가능

Conservative 2PL

• 모든 Lock 취득한 뒤 트랜잭션 시작
• 데드락 발생하지 않음
• 실용적이지 않음

-- 모든 락 취득
read_lock(x)
write_lock(y)
write_lock(z)
-- 트랜잭션 시작
read(x)
unlock(x)
read(y)
read(z)
write(y = x+y+z)
unlock(y)
write(z = 2 * x)
unlock(z)

Strict 2PL (S2PL)

• Strict Schedule 보장하는 2PL
• Recoverability 보장
• 배타 락을 commit / rollback 할 때 반환

-- 모든 락 취득
read_lock(x)
write_lock(y)
write_lock(z)
-- 트랜잭션 시작
read(x)
unlock(x)
read(y)
read(z)
write(y = x+y+z)
write(z = 2 * x)
-- 커밋
commit
-- 커밋 후 배타 락을 반환
unlock(y)
unlock(z)

Strong Strict 2PL (SS2PL / Rigorous 2PL)

• S2PL 확장판
• 공유 락 (read-lock), 배타 락 (write-lock) 모두 commit / rollback 시 반환
• S2PL 보다 쉬운 구현
• 락 시점이 길어지므로, 성능 악화

🔪 Lock을 사용해서 발생하는 문제

• 결론
  • 락 시간 제한, 락 크기 제한, 트랜잭션 범위 축소 등 락에 의한 의도치 않은 상황을 줄일 수 있는 설계를 고려할 것

Blocking

• Lock 간 경합 발생해 특정 세션이 작업 진행하지 못하고 멈춘 상태
  • 배타 락 걸리면 다른 트랜잭션은 어떠한 lock 도 못 걸고 대기하기 때문
• 트랜잭션 commit 혹은 rollback 시점에 블로킹 해제
• 해결방안
  • 트랜잭션을 짧게 정의
  • 같은 데이터를 갱신하는 트랜잭션이 동시에 수행되지 않도록 설계
  • lock timeout을 이용하여 잠금해제 시간 조절

Deadlock 교착상태

• 해결방안
  • 트랜잭션 진행방향을 같은 방향으로 처리
    • 블로킹은 발생할 수 있지만 데드락 발생 가능성은 없어짐
  • 트랜잭션 처리속도를 최소화
  • lock timeout을 이용하여 잠금해제 시간을 조절