Lock 🔐 (Django 기준)

---

비관적 락(Pessimistic Lock) 🔒

• "충돌이 발생할 것이라고 비관적으로 가정"합니다.

  • 데이터를 읽는 시점에 즉시 락을 걸어 다른 사용자가 수정하지 못하도록 원천 차단하는 방식입니다.

---

select_for_update()

• 반드시 transaction.atomic() 블록 내에서 실행되어야 합니다.

---

코드

• select_for_update() 는 해당 로우가 트랜잭션 종료 시점까지 잠기도록
• SELECT ... FOR UPDATE SQL 문을 생성

from django.db import transaction
from .models import Product

def decrease_stock_pessimistic(product_id, quantity):
    # 1. atomic() 트랜잭션 블록이 반드시 필요합니다.
    with transaction.atomic():
        # 2. select_for_update()를 사용하여 DB 수준의 락을 획득합니다.
        # 이 시점에 다른 트랜잭션이 해당 로우를 수정하려고 하면 대기하게 됩니다.
        product = Product.objects.select_for_update().get(id=product_id)
        
        if product.stock >= quantity:
            product.stock -= quantity
            product.save() # save() 완료 후 트랜잭션이 끝날 때 락이 해제됩니다.
        else:
            raise ValueError("재고가 부족합니다.")

---

select_for_update(nowait=True)

• 사용하면 다른 곳에서 이미 락을 걸었을 때
• 기다리지 않고 바로 DatabaseError를 발생시켜 빠른 응답 처리가 가능합니다.

---

비관적 락의 치명적인 단점 ‼️

• 비관적 락은 강력하지만, 그만큼 대가가 큽니다.

  • 성능 저하 (Throughput 감소)

    • 특정 데이터에 락이 걸리면 다른 모든 요청은 해당 트랜잭션이 끝날 때까지
      • "줄을 서서 대기"해야 합니다.
    • 이는 웹 서비스의 응답 속도를 늦추는 주범이 됩니다.

  • 데드락(Deadlock) 위험

    • 여러 트랜잭션이 서로가 가진 락을 기다리는 교착 상태에 빠질 수 있습니다.
    • 시스템 전체가 멈출 위험이 있습니다.

  • DB 커넥션 점유

    • 락을 유지하는 동안 DB 커넥션을 계속 붙잡고 있어야 합니다.
    • 동시 접속자가 많아지면 커넥션 풀이 고갈되어 서비스 장애로 이어집니다.

---

낙관적 락(Optimistic Lock) 🔒

• "충돌이 거의 발생하지 않을 것이라고 낙관적으로 가정" 합니다.

  • 데이터를 읽을 때는 락을 걸지 않고, 수정 완료 시점에 내가 읽었던 데이터가
  • 그사이 변했는지 확인하여 충돌을 감지하는 방식입니다.

---

Race Condition (경쟁 상태)

• 두 개 이상의 프로세스가 공통 자원에 동시에 접근할 때 발생하는 문제 상황입니다.

---

Version / F

• Django는 별도의 @Version 같은 내장 필드가 없음
• 따라서 version 필드를 직접 정의하거나
  • F 객체를 이용한 원자적(Atomic) 업데이트 방식을 주로 사용

---

F 객체

• 일반적인 방식 (F 객체 미사용):

  • DB에서 데이터를 가져와 파이썬 메모리에 올립니다. (stock = 10)
  • 파이썬에서 계산합니다. (10 - 1 = 9)
  • 계산된 결과 9를 DB에 다시 저장합니다. (UPDATE ... SET stock = 9)
  • 위험성
    • 데이터를 가져오고 저장하는 찰나의 순간에 다른 사용자가 재고를 바꿔버리면 데이터가 꼬입니다.

• F 객체 방식:

  • 파이썬은 계산을 하지 않습니다.
  • 대신 "DB야, 네가 가진 stock 값에서 quantity만큼 빼줘"라는 SQL 명령어만 보냅니다.
  • 실제 계산은 데이터베이스 엔진 내부에서 일어납니다.

• F 객체 사용의 장점

  • 경쟁 상태(Race Condition) 방지
    • 여러 요청이 동시에 들어와도 DB가 순차적으로 연산을 처리하므로 데이터 무결성이 지켜집니다.
    • 이것이 바로 낙관적 락의 핵심 원리 중 하나입니다.
  • 성능 최적화
    • 데이터를 파이썬 메모리로 불러올(SELECT) 필요 없이 바로 UPDATE 명령을 내리므로
    • 데이터베이스 통신 횟수와 메모리 사용량이 줄어듭니다.
  • 원자성(Atomicity)
    • 조회와 수정을 하나의 쿼리로 처리하여 원자적인 작업을 보장합니다

---

코드

• F 객체를 이용한 원자적 업데이트

  • 별도의 버전 필드 없이도 Race Condition을 방지하는 가장 "파이썬스러운" 방식입니다.
  • DB 수준에서 현재 값을 기준으로 연산합니다

from django.db.models import F
from .models import Product

def decrease_stock_f_expression(product_id, quantity):
    # filter 조건에 재고 확인 로직을 포함하여 쿼리 한 번으로 처리합니다.
    # UPDATE product SET stock = stock - quantity WHERE id = ? AND stock >= quantity
    updated_count = Product.objects.filter(
        id=product_id, 
        stock__gte=quantity
    ).update(stock=F('stock') - quantity) ♦️

    if updated_count == 0:
        # 조건에 맞는 로우가 없거나(ID 부재), 그사이 재고가 줄어든 경우
        raise ValueError("재고가 부족하거나 데이터가 변경되었습니다.")

• 수동 버전 관리 (JPA 방식과 유사)

  • 엔티티에 version 필드를 추가하여 직접 검사합니다.

from .models import Product

def update_product_manual_version(product_id, new_name):
    product = Product.objects.get(id=product_id)
    current_version = product.version ♦️

    # 데이터 수정
    product.name = new_name
    product.version += 1

    # 업데이트 시점에 처음 읽었던 버전인지 확인
    updated = Product.objects.filter(
        id=product_id, 
        version=current_version
    ).update(name=new_name, version=F('version') + 1)

    if not updated:
        raise Exception("이미 다른 사용자에 의해 수정된 데이터입니다.")

---

낙관적 락이 빛을 발하는 상황 ✨

• 낙관적 락은 "충돌이 가끔 일어난다"는 전제하에 시스템의 전체적인 처리량을 극대화

  • 읽기 작업이 압도적으로 많을 때

    • 대부분의 웹 서비스는 데이터를 수정하는 요청보다 조회하는 요청이 훨씬 많습니다.
    • 조회할 때마다 락을 걸면(Shared Lock 포함) 성능이 심각하게 저하되는데,
    • 낙관적 락은 조회 시 아무런 제약을 주지 않으므로 매우 빠릅니다.

  • 트랜잭션이 길어질 때

    • 사용자가 글을 수정하기 위해 편집 창을 열어두고 10분 뒤에 '저장'을 누른다고 가정해 봅시다.
    • 비관적 락
      • 10분 동안 다른 누구도 그 글을 읽거나 수정하지 못하게 막습니다. (사실상 불가능)
    • 낙관적 락
      • 저장 버튼을 누르는 순간에만 버전이 바뀌었는지 체크합니다. 효율성이 압도적입니다.

---

실무 적용 가이드

비관적 락 권장

• 재고 차감, 포인트 결제
  • 데이터의 정확성이 생명이므로 select_for_update()를 권장합니다.

---

낙관적 락 권장

• 단순 게시글 수정, 사용자 프로필 변경
  • 충돌 가능성이 낮으므로 락 없이 처리하거나 F 객체를 이용한 낙관적 업데이트를 권장합니다.

---

성능 최적화

• select_for_update()는 DB의 커넥션 점유 시간을 늘리므로
  • 트래픽이 매우 높다면 Redis를 활용한 분산 락을 고려해야 합니다.

---

선택기준

• 비관적 락을 쓰는 경우 (특수 상황)

  • 재고가 1개 남은 초특가 세일 상품 (충돌이 100% 확실할 때)
  • 금융 시스템의 잔액 이체 (단 0.1%의 오차도 허용하지 않으며, 실패 시 재시도가 매우 복잡할 때)

• 낙관적 락을 쓰는 경우 (일반 상황)

  • 대부분의 게시판, 프로필 수정, 설정 변경
  • 동시 수정 확률이 낮지만 데이터 정합성은 지켜야 할 때
  • 성능(응답 속도)이 매우 중요한 대규모 트래픽 서비스

---

추가 학습

• 분산 락 (Distributed Lock)

  • Redis의 Redlock 등을 이용해 DB 부하를 줄이면서 동시성을 제어하는 방법.

• 메시지 큐 (Message Queue)

  • 요청을 큐에 쌓아 순차적으로 처리함으로써 DB 락 없이 동시성을 해결하는 구조.

• 멱등성 (Idempotency)

  • 여러 번 요청해도 결과가 같은 API 설계 방식 (낙관적 락 실패 시 재시도와 연관).

---

레디스 락 🔒

• 여러 대의 서버가 공유 자원에 접근하는 환경에서 사용하는
  • '분산 락(Distributed Lock)'의 대표적인 구현 방식
• 일반적인 DB 락은 특정 데이터베이스의 레코드나 테이블에 락을 겁니다.
  • 하지만 서비스 규모가 커져서 서버가 여러 대(Distributed System)가 되면
  • 각 서버가 서로 다른 DB 커넥션을 가지기 때문에 DB 레벨의 락만으로는 한계가 발생할 수 있습니다.
• 이때 Redis라는 외부 저장소를 활용해 "현재 이 자원은 내가 사용 중이다"라는 표식(Ticket)을
  • 남김으로써 여러 서버 간의 동기화를 맞추는 것이 바로 레디스 락입니다.

---

핵심 명령어

• SET resource_name my_random_value NX PX 30000
  • NX (Not eXists): key가 없을 때만 저장합니다. (락 획득 시도)
  • PX 30000: 30,000 밀리초(30초) 후에 자동으로 삭제합니다. (데드락 방지)
  • my_random_value: 락을 해제할 때 본인이 잡은 락인지 확인하기 위한 고유 값입니다.

---

실무적인 구현 방법

• Redisson 라이브러리

  • 단순히 SETNX를 직접 구현하면 락 만료 시간 관리나 재시도(Retry) 로직을 직접 짜야 하므로 매우 복잡
  • 자바(Spring) 진영에서는 이를 추상화한 Redisson 라이브러리를 표준처럼 사용합니다.

• Redisson을 이용한 분산 락 예제 코드

  • Watchdog 기능
    • Redisson의 특징으로, 로직이 길어져 락 만료 시간이 다가오면 자동으로 시간을 연장해줍니다.
  • tryLock()
    • 락을 획득할 때까지 무한정 대기하지 않고
    • 지정된 시간(waitTime)만큼만 시도합니다. 이는 시스템 전체의 스레드 점유를 막아줍니다.
  • isHeldByCurrentThread()
    • 내가 잡지 않은 락을 억지로 해제하려고 하면 에러가 발생할 수 있으므로, 반드시 확인 후 해제합니다.

import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.springframework.stereotype.Service;
import java.util.concurrent.TimeUnit;

@Service
public class StockService {

    private final RedissonClient redissonClient;

    public StockService(RedissonClient redissonClient) {
        this.redissonClient = redissonClient;
    }

    public void decreaseStock(Long productId) {
        // 1. 해당 자원에 대한 락 객체를 가져옵니다.
        RLock lock = redissonClient.getLock("lock:product:" + productId);

        try {
            // 2. 락 획득 시도 (최대 10초 대기, 획득 후 1초간 유지)
            // waitTime: 락을 얻기 위해 기다리는 시간
            // leaseTime: 락을 획득한 후 점유하는 시간
            boolean available = lock.tryLock(10, 1, TimeUnit.SECONDS);

            if (!available) {
                System.out.println("락 획득에 실패했습니다.");
                return;
            }

            // 3. 비즈니스 로직 수행 (재고 감소 등)
            System.out.println("재고를 감소시킵니다.");

        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            // 4. 반드시 락을 해제합니다. (현재 쓰레드가 락을 가지고 있을 때만)
            if (lock.isHeldByCurrentThread()) {
                lock.unlock();
            }
        }
    }
}

---