Pessimistic vs. Optimistic Locking

Pessimistic vs. Optimistic Locking

Pessimistic Locking은 충돌을 우려해 먼저 락을 거는 방식으로, 데이터 무결성이 중요한 환경에서 적합하다. Optimistic Locking은 충돌 가능성이 낮다고 보고 사후 검증을 통해 일관성을 보장한다. 시스템 요구사항과 성능 특성에 따라 선택된다.

등장 배경 및 발전 과정

Pessimistic Locking은 초기 RDBMS + ACID 보장 요구에서 발전했으며, 충돌 회피를 위한 보수적 접근 방식이 정립되었으며, Optimistic Locking은 낮은 충돌 환경을 가정한 성능 중심 전략으로, 분산 시스템, 웹/모바일 기반 환경에서 발전해왔다.

Pessimistic Locking

• 등장 배경:
  1970 년대 초반, IBM System R 등의 RDBMS 에서 ACID 보장과 동시성 제어를 위해 등장.
  특히 Lost Update, Dirty Read 같은 문제 해결이 핵심 과제였음.

• 발전 과정:

  • 1976 년 Jim Gray의 트랜잭션 및 2PL 이론 등장
  • 1980 년대 주요 상용 DB (Oracle, DB2 등) 에 비관적 락 기본 내장
  • ERP, 금융, 제조 등 고정합성 업무에서 지금까지도 널리 사용됨
  • 분산 환경에서는 분산 락 (ZooKeeper, etcd) 기반으로 확장됨

Optimistic Locking

• 등장 배경:
  1979 년 H.T. Kung과 John T. Robinson의 논문에서 낮은 충돌 환경 가정 하에 효율적인 동시성 제어로 제안.
  트랜잭션 간 충돌이 드물고 읽기 위주의 처리량 증가가 필요한 환경을 타깃으로 하였다.

• 발전 과정:

  • 1990 년대 이후 웹 애플리케이션, 분산 시스템 확산과 함께 주목
  • @Version 기반 낙관적 락이 JPA, Hibernate 등에서 표준화
  • NoSQL DB (MongoDB, DynamoDB 등) 에서 충돌 검증 알고리즘으로 응용
  • 최근에는 CQRS, 이벤트 소싱, API 기반 마이크로서비스에 핵심 요소로 사용됨

목적 및 필요성

공통적인 목적 및 필요성

• 데이터 정합성 유지: 여러 사용자가 동시에 공유 자원에 접근하는 상황에서 일관성과 무결성을 보장함.
• 충돌 관리 전략: 동시 접근 시 발생할 수 있는 충돌을 예방하거나 감지하고 복구하여 시스템 오류나 데이터 손실을 방지함.
• 시스템 성능 - 신뢰성 균형: 높은 처리량을 유지하면서도 신뢰성 있는 트랜잭션 처리를 도모함.

방식별 목적 및 필요성

핵심 개념

Pessimistic 과 Optimistic Locking 은 데이터 정합성과 성능 균형을 위한 핵심 동시성 제어 전략이다.
전자는 충돌 회피 중심의 락 기반 방식, 후자는 충돌 검증 기반의 비 - 락 방식이며, 충돌 빈도와 시스템 특성에 따라 선택된다.

공통 핵심 개념

Pessimistic Locking

Optimistic Locking

전략 선택 가이드라인 요약

주요 기능 및 역할

공통 기능 및 역할

• 공통 기능: 동시 접근 시 자원 상태를 통제하여 경쟁 조건을 제어
• 공통 역할: 데이터 정합성 유지와 트랜잭션 충돌 대응을 통해 시스템 신뢰성을 확보

방식별 기능 및 역할

• Pessimistic Locking은 충돌이 치명적인 환경에서의 사전 방어형 전략이며, 데이터 정합성 보장을 우선시함.
• Optimistic Locking은 충돌이 드물고 빠른 처리가 중요한 환경에서의 사후 복구형 전략으로, 성능과 확장성 확보에 적합함.
• 둘 모두 트랜잭션 제어 및 일관성 유지에 필수적인 전략이며, 사용 환경에 따라 병행 적용 가능.

락 정책 선택 가이드라인 매트릭스

판단 흐름

flowchart TD
    A[충돌 가능성 높음?] -->|Yes| B[Pessimistic Locking]
    A -->|No| C[낙관적 접근 가능성 검토]
    C --> D[트랜잭션 길고 성능 중요?]
    D -->|Yes| E[Optimistic Locking]
    D -->|No| F[복구 비용 고려]
    F -->|복구 비용 큼| B
    F -->|복구 용이| E

적용 예시

특징

공통 특징

• 동시성 환경에서의 정합성 보장 메커니즘
• 트랜잭션 기반 처리와 밀접한 관련
• 충돌 발생 가능성에 대한 대응 전략 존재

Pessimistic vs. Optimistic Locking 특징

• 접근 방식: 충돌 대응 시점의 차이. Pessimistic 은 사전 차단, Optimistic 은 사후 검증 중심으로 설계됨.
• 락 사용: 락 지속 점유 여부가 전략을 가르는 핵심. Pessimistic 은 명시적 락, Optimistic 은 논리적 버전 기반.
• 충돌 처리: 즉시 블로킹 vs. 충돌 발생 후 롤백 및 재시도 방식으로 처리 방식이 다름.
• 동시성: 락 사용 유무에 따라 블로킹 발생 여부가 달라지고, 이는 동시성 수준에 큰 영향.
• 성능: 환경에 따라 상반된 성능 특성. 충돌 빈도/경합 강도가 전략 선택에 핵심 기준.
• 장애 대응: Pessimistic 은 Deadlock 대비, Optimistic 은 재시도/백오프 등의 보완 로직 필요.
• 프로그래밍 난이도: Pessimistic 은 단순, Optimistic 은 로직 설계 복잡도가 있음.
• 적용 사례: 강한 정합성 필요시 Pessimistic, 사용자 경험/속도 우선 환경은 Optimistic 이 적합.

핵심 원칙

• 정합성 보장: 트랜잭션 충돌을 방지하거나 검출해 데이터 일관성을 확보
• 충돌 대응 전략 필요: 사전 또는 사후 충돌을 처리하는 메커니즘이 반드시 존재해야 함
• 시스템 성능과 정합성 사이의 균형 설계가 중요

Pessimistic Locking 원칙

Optimistic Locking 원칙

핵심 원칙 비교

• 충돌 처리 시점: Pessimistic 은 사전 차단을 통해 안전성을 확보하고, Optimistic 은 사후 검출로 성능을 확보한다.
• 락 관리: Pessimistic 은 락을 명시적으로 소유하고 해제하며, 락 순서와 유지 시간이 중요하다. 반면 Optimistic 은 락을 사용하지 않고 버전 필드를 활용한다.
• 에러 대응 전략: Pessimistic 은 데드락을 피해야 하고, Optimistic 은 충돌 재시도에 대비한 정책을 마련해야 한다.
• 설계 철학: Pessimistic 은 데이터 정합성을 절대적으로 우선하며, Optimistic 은 시스템 병행성과 성능을 우선시한다.
• 확장성 및 성능: Pessimistic 은 고정밀 정합성 환경에 적합하고, Optimistic 은 사용자 수가 많은 웹 기반 시스템에 적합하다.

주요 원리 및 작동 방식

• 동시 접근 환경에서 데이터 정합성 및 충돌 제어를 구현
  • Pessimistic: 충돌 차단
  • Optimistic: 충돌 감지 및 복구

flowchart LR
  A[Pessimistic: Acquire → Operate → Release]
  B[Optimistic: Read → Operate → Validate → Commit/Rollback]

작동 원리 및 방식

Pessimistic Locking

sequenceDiagram
    participant T1
    participant DB
    participant T2

    T1->>DB: BEGIN
    T1->>DB: SELECT ... FOR UPDATE (Acquire Lock)
    DB-->>T1: Lock Acquired
    T2->>DB: SELECT ... FOR UPDATE (Block)
    T1->>DB: UPDATE
    T1->>DB: COMMIT (Release Lock)
    DB-->>T2: Lock Granted

1. 락 획득 단계

   1 2 3 4 5

   -- Shared Lock (읽기 락) SELECT * FROM products WHERE id = 1 FOR SHARE; -- Exclusive Lock (쓰기 락) SELECT * FROM products WHERE id = 1 FOR UPDATE;

2. 데이터 조작 단계

   1	UPDATE products SET quantity = quantity - 1 WHERE id = 1;

3. 락 해제 단계

   1	COMMIT; -- 또는 ROLLBACK

Optimistic Locking

sequenceDiagram
    participant T1
    participant DB
    participant T2

    T1->>DB: SELECT data, version → v=1
    T2->>DB: SELECT data, version → v=1
    T1->>DB: UPDATE WHERE version=1 → Success, version=2
    T2->>DB: UPDATE WHERE version=1 → Fail (version mismatch)
    T2->>DB: Retry SELECT → v=2
    T2->>DB: UPDATE WHERE version=2 → Success

1. 초기 읽기 단계

   1 2	SELECT id, name, quantity, version FROM products WHERE id = 1; -- 결과: id=1, name='Product A', quantity=100, version=5

2. 조건부 업데이트 단계

   1 2 3 4

   UPDATE products SET quantity = 99, version = version + 1 WHERE id = 1 AND version = 5; -- 영향받은 행 수를 확인하여 충돌 감지

3. 충돌 처리 단계

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

   # Pseudocode def update_product_optimistic(product_id, new_quantity): max_retries = 3 for attempt in range(max_retries): # 1. 현재 데이터 조회 product = select_product(product_id) # 2. 비즈니스 로직 수행 if product.quantity >= new_quantity: # 3. 조건부 업데이트 시도 affected_rows = update_product_with_version( product_id, new_quantity, product.version ) if affected_rows == 1: return "Success" # 성공 else: continue # 충돌 발생, 재시도 else: return "Insufficient quantity" return "Max retries exceeded"

Pessimistic vs. Optimistic Locking: 실전 구현 전략

• 실전 구현 전략에서는 시스템의 특성 (읽기/쓰기 비율, 충돌 가능성 등) 에 따라 적절한 락 전략과 기술이 결정된다. 비관적 락은 안정성을, 낙관적 락은 성능과 확장성을 우선시한다.

구조 및 아키텍처

공통적인 구조·역할

• 두 방식 모두 트랜잭션 단위의 동시성 제어 구조를 갖추며, 정합성 보장 목적을 공유.
• 다만 락 기반 관리 vs. 버전 기반 검증이라는 구조 차이 존재.

방식별 구조 및 비교

Pessimistic Locking

• 필수 요소: Lock Manager, Lock Table, Wait Queue
• 선택 요소: Deadlock Detector, Lock Escalation 등
• 작동 기반: DB 내부 Lock Manager, Two-Phase Locking Protocol 사용됨

graph TD
    subgraph DB Layer
        TM[Transaction Manager]
        LM[Lock Manager]
        LT[Lock Table]
        WQ[Wait Queue]
        DD[Deadlock Detector]
    end
    TM --> LM
    LM --> LT
    LM --> WQ
    LM -. optional .-> DD
    WQ --> LM

Optimistic Locking

• 필수 요소: Version Control (버전 필드), Conflict Detection, Retry Mechanism
• 선택 요소: Adaptive Retry Controller, Performance Monitor 등
• 작동 기반: 주로 애플리케이션 레이어에서 동작하며 DB 검증 로직 포함

graph TD
    subgraph App Layer
        TX[Transaction Start]
        OP["Operation (no lock)"]
        VD[Version Validate]
        RL[Retry Logic]
    end
    subgraph Data Layer
        DC[Conflict Detection Engine]
        VM[Version Control Store]
    end
    TX --> OP
    OP --> VD
    VD -->|no conflict| DC
    DC -->|validate| VM
    VD -->|conflict| RL
    RL --> TX

구성 요소

구현 기법 및 방법

• 공통점:

  • 동시성 제어 목적
  • 트랜잭션 충돌 방지/처리
  • 고유한 충돌 감지 및 회피 메커니즘 존재

• 차이점:

  • 락 시점과 방식 (사전 vs 사후)
  • 충돌 발생 시 대응 방식 (대기 vs 재시도)
  • 구현 위치 (DB, App Layer 등)

• Database-Level Locking은 가장 고전적이고 안정적인 방식으로 강한 일관성을 보장하나, 동시성은 낮음. 주로 OLTP 시스템에서 사용.

• Application-Level Locking은 분산 환경에서 자원을 보호할 때 유용하며, Redis/Zookeeper 등 외부 도구 필요.

• Version-Based Locking은 높은 동시성을 제공하지만 충돌 발생 시 재시도가 필요하므로, 충돌이 빈번한 환경에는 부적절.

• Timestamp-Based Locking은 구현이 단순하지만 시간 동기화 문제가 존재하며, IoT/이벤트 시스템에 적합.

Database-Level Locking

1
2
3
4
5

-- PostgreSQL 예시
BEGIN;
SELECT * FROM inventory WHERE product_id = 1 FOR UPDATE;
UPDATE inventory SET quantity = quantity - 1 WHERE product_id = 1;
COMMIT;

Application-Level Locking (Python, Redis)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

import redis
import time

class RedisLock:
    def __init__(self, redis_client, key, expire=5):
        self.redis = redis_client
        self.key = key
        self.expire = expire

    def acquire(self):
        while not self.redis.set(self.key, "lock", nx=True, ex=self.expire):
            time.sleep(0.05)

    def release(self):
        self.redis.delete(self.key)

# 사용 예
lock = RedisLock(redis.StrictRedis(), "resource:lock")
lock.acquire()
try:
    # 작업 수행
    …
finally:
    lock.release()

Version-Based Locking (Node.js + PostgreSQL)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

async function updateWithVersion(db, id, newName) {
    const data = await db.query('SELECT name, version FROM items WHERE id = $1', [id]);
    const { name, version } = data.rows[0];

    const updated = await db.query(`
        UPDATE items SET name = $1, version = $2 WHERE id = $3 AND version = $4
    `, [newName, version + 1, id, version]);

    if (updated.rowCount === 0) {
        throw new Error("Version conflict detected");
    }
}

Timestamp-Based Locking (Python + SQLAlchemy)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

def update_with_timestamp(session, model, item_id, new_data):
    for _ in range(3):
        entity = session.query(model).filter_by(id=item_id).first()
        original_ts = entity.updated_at

        for key, value in new_data.items():
            setattr(entity, key, value)
        entity.updated_at = datetime.utcnow()

        updated = session.query(model).filter_by(id=item_id, updated_at=original_ts).update(new_data)
        if updated:
            session.commit()
            return
        else:
            session.rollback()
            time.sleep(0.05)
    raise Exception("Timestamp conflict detected")

Pessimistic vs. Optimistic Locking 비교

비관적 락은 락을 통한 선제 보호에 무게, 낙관적 락은 병행성과 성능에 무게를 둔다.
데이터 충돌 가능성 예측과 도메인 특성을 토대로 선택·조합.

공통점과 차이점

• 공통점: 두 방식 모두 데이터 정합성과 동시성 제어를 목적으로 하며, 트랜잭션 기반 시스템에서 충돌을 방지하거나 감지하는 구조이다.

• 차이점:

  • Pessimistic 은 선점 기반의 충돌 회피로 강한 일관성과 예측 가능한 동작을 제공하지만, 락 경합과 데드락 관리 이슈가 있다.
  • Optimistic 은 후처리 기반 충돌 감지로 처리량과 확장성은 뛰어나지만, 충돌 복구 로직과 재시도 정책이 중요하다.

• 적용 가이드라인:

  • 충돌이 자주 발생하고 결과가 치명적인 경우에는 Pessimistic Locking.
  • 충돌 빈도가 낮고 고성능을 요구하는 경우에는 Optimistic Locking이 적합하다.

목적 및 적용 대상

두 방식 모두 데이터 무결성과 동시성 보장을 목적으로 하지만, Pessimistic 은 " 충돌 회피 " 에, Optimistic 은 " 성능 최적화와 사후 회복 " 에 초점이 맞춰져 있음.

동작 원리 및 트랜잭션 처리

Pessimistic 은 사전 락 확보로 충돌 가능성을 원천 차단하는 반면, Optimistic 은 커밋 단계의 충돌 감지를 통해 처리량을 높이고 유연한 트랜잭션 구성을 가능하게 한다.

구현 복잡성 및 예외 처리

Optimistic 은 구현이 유연하지만 충돌 복구 로직이 필요하며, Pessimistic 은 안정적이나 데드락 예방 및 락 해제 정책 관리가 핵심 과제가 된다.

성능 및 확장성 관점

장점과 단점

• Pessimistic Locking 은 강력한 데이터 정합성과 충돌 회피가 강점이며, 데이터 중심 트랜잭션에 적합하다. 그러나 성능 저하와 데드락 리스크, 확장성 한계가 단점이다.
• Optimistic Locking 은 충돌 가능성이 낮고 병렬성 높은 환경에 유리하며, 웹 API 나 분산 시스템에서 적합하다. 다만, 충돌 발생 시 높은 재시도 비용과 복잡한 오류 처리가 필요하다.
• 실무에서는 사용 환경, 충돌 빈도, DB/프레임워크 지원 등을 고려하여 두 접근법을 선택하거나 혼용하는 것이 효과적이다.

공통 장점

• 데이터 무결성을 보장하고 트랜잭션 충돌 방지 혹은 감지 능력을 제공함
• 환경에 따라 선택적으로 도입하여 트랜잭션 오류를 줄일 수 있음

Pessimistic Locking

• 장점: 충돌을 사전 방지하여 정합성 보장, 구현 단순, 예측 가능한 동작
• 단점: 데드락 위험, 커넥션 점유, 확장성 낮음

Optimistic Locking

• 장점: 락 비용 없음, HTTP 및 분산 환경에 적합, 병행성 우수
• 단점: 충돌 시 재시도 비용 증가, 복잡한 오류 처리, 충돌 감지 시점 지연

카테고리별 비교

데이터 정합성

성능 및 확장성

충돌 및 오류 처리

환경 적합성

도전 과제

공통 도전 과제

락 전략과 무관하게 발생할 수 있는 시스템/운영 이슈로서, 확장성, 자원 한계, 복잡한 예외 흐름 등을 다룬다. 특히 멀티노드 환경에서는 스레드 풀 고갈, 트랜잭션 경계 불명확성으로 인해 예기치 않은 병목이 발생할 수 있다.

Pessimistic Locking 특화 도전 과제

락의 존재 자체가 시스템 리스크 로 작용하는 상황에 초점을 맞춘다. 데드락이나 타임아웃, 락 점유 누락은 실시간 서비스에서 치명적인 영향을 미치며, 락 정책의 정교함이 요구된다.

Optimistic Locking 특화 도전 과제

충돌 감지 및 재시도 처리 에 초점을 둔다. 충돌 빈도에 따라 재시도 폭발 (Replay Storm), 논리적 충돌 미감지 (ABA), 불필요한 충돌 감지 (False Conflict) 등이 발생하며, 이를 해결하기 위해 충돌 완화 설계와 히스토리 기반의 정합성 검증이 요구된다.

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

공통 고려사항

• 충돌 가능성 및 트래픽 패턴 분석 필요
• 모니터링과 지표 수집, 실시간 알림 연동 필수
• 테스트 환경에서의 사전 검증 및 시나리오 테스트 수행
• 성능/안정성/비즈니스 중요도를 고려한 전략적 선택 요구

비교

• Pessimistic Locking은 충돌 방지에 효과적이나, 락 보유 시간이 길고 데드락에 취약하며 응답 지연이 있을 수 있다. 락 순서를 명확히 정의하고 타임아웃 및 빠른 실패 처리를 설계해야 한다.

• Optimistic Locking은 높은 동시성과 낮은 락 비용을 제공하지만, 충돌 발생 시 재시도 로직과 백오프 전략이 필수이다. 트래픽이 많거나 클라우드 분산 환경에서 적합하다.

• 공통적으로 성능 지표, 충돌 로그, 트랜잭션 모니터링을 기반으로 사전 테스트 및 실시간 추적 체계를 갖추는 것이 중요하다.

실무 도입 가이드

도입 절차

1. 트랜잭션 경합 분석
   • 주요 테이블/기능의 쓰기 충돌 빈도, 동시성 수준 측정
2. 전략 선택
   • 충돌 빈도 높음: Pessimistic
   • 충돌 빈도 낮음: Optimistic
3. 프레임워크 지원 여부 확인
   • ORM, DBMS 기능 확인 (e.g., JPA, Sequelize, SQLAlchemy)
4. 락 정책 구현
   • 버전 관리, with_for_update 등 적용
5. 테스트 및 롤백 전략 수립
   • 낙관적 충돌 검출 및 재시도 전략 포함

적용 체크리스트

실무 검증/운영 팁

• 공통:
  • 스트레스 테스트 (동시성 테스트), 실제 사용자 트래픽 패턴 반영해 검증
  • 시스템 모니터링 도구 (예: Prometheus, Grafana) 와 연계
• 비관적 락:
  • 트랜잭션/쿼리 로그를 통해 락 대기, Deadlock, Timeout 빈도 모니터링
  • DBMS Lock Table 상태 주기적 점검, 락 그레뉼러리티 (행/테이블 등) 조정
• 낙관적 락:
  • 충돌률, 롤백률, 재시도 성공률 등 메트릭 수집
  • Version 관리 및 재시도 정책 (Backoff, 최대 재시도 횟수) 주기적 조정

락 전략의 테스트 및 검증 방법

비관적 락 (Pessimistic Locking)

• 테스트 포인트
  • 동시성 충돌 발생 시 트랜잭션이 적절히 대기하거나 차단되는지 확인
  • 데드락 (Deadlock) 발생 상황 시 시스템이 자동 감지 및 회복되는지 검증
• 검증 시나리오
  • 두 개 이상의 클라이언트가 동일 데이터를 동시에 쓰기 시도 → 한쪽만 성공, 다른 쪽은 대기 또는 실패
  • 트랜잭션이 오래 대기하면 타임아웃 후 적절히 롤백되는지 확인
• 테스트 예시 (Python, SQLite 사용)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

import sqlite3
import threading

def update_pessimistic():
    conn = sqlite3.connect('test.db', timeout=5, isolation_level='EXCLUSIVE')
    cur = conn.cursor()
    try:
        cur.execute("BEGIN EXCLUSIVE")
        # 테스트를 위해 긴 시간 작업 시뮬레이션
        cur.execute("UPDATE products SET stock = stock - 1 WHERE id = 1")
        conn.commit()
    except Exception as e:
        print("Lock Error:", e)
        conn.rollback()
    finally:
        conn.close()

설명: 두 명 이상이 동시에 실행하면 한 쪽만 진입, 나머지는 타임아웃 혹은 대기.

낙관적 락 (Optimistic Locking)

• 테스트 포인트
  • 동시 커밋 시 버전 불일치 (충돌) 가 감지되고, 트랜잭션이 적절히 롤백 및 재시도 되는지 확인
  • 재시도 정책 및 알림 로직 정상 동작 확인
• 검증 시나리오
  • 실제 버전 정보를 변경하지 않고 여러 쓰기 트랜잭션 동시 실행 → 일부만 업데이트, 나머지 롤백/재시도
  • 빈번한 충돌 환경에서 성능 및 충돌 발생률 관찰
• 테스트 예시 (Python, SQLAlchemy)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

def update_optimistic(session, product_id, order_qty, cur_version):
    product = session.query(Product).filter_by(id=product_id, version=cur_version).first()
    if product and product.stock >= order_qty:
        product.stock -= order_qty
        product.version += 1
        try:
            session.commit()
            return True
        except:
            session.rollback()  # 버전 충돌 발생 시 롤백
            return False
    return False

설명: 데이터베이스 테이블에 version 필드 필수. 버전이 다르면 commit 실패 (충돌).

트랜잭션 격리 수준과의 연계 분석

• 트랜잭션 격리 수준은 Pessimistic Locking 과 더 밀접하게 연동되며, 높은 격리 수준일수록 낙관적 락의 재시도 및 충돌 가능성이 높아진다. 반면 비관적 락은 트랜잭션 격리 수준의 효과를 보강하거나 대체하는 역할도 가능하다.

최적화하기 위한 고려사항 및 주의할 점

1. Lock 범위 최적화
   락이 지나치게 넓거나 세밀할 경우 모두 성능 병목으로 이어질 수 있다. 락 단위 조정과 자동 에스컬레이션 정책은 DB 벤더별로 튜닝 필요.

2. 트랜잭션 최적화
   트랜잭션을 작게 유지하는 것이 락 유지 시간을 줄이고 교착상태를 방지하며, 전체 시스템 처리량을 향상시킨다.

3. 재시도/백오프 전략
   낙관적 락에서는 충돌 시 재시도가 핵심 전략이 되므로, 재시도 횟수 제한과 백오프 전략은 성능 유지에 필수적이다.

4. 읽기/쓰기 전략
   읽기와 쓰기 트래픽이 혼합된 경우에는 락 방식도 혼합 적용하는 것이 효과적이다. 읽기 복제본 활용은 Pessimistic 에서도 유효하다.

5. 버전 관리 최적화
   낙관적 락은 버전 필드가 핵심이므로, 캐싱, 인덱싱, TTL 관리로 성능 병목을 예방해야 한다.

6. 비동기/비차단 처리
   락 또는 충돌 이후의 후처리를 비동기로 분리하면 응답 지연을 줄이고 시스템 유연성을 높일 수 있다.

7. 분산 환경 최적화
   분산 락 및 글로벌 버전 정보는 네트워크 지연 및 장애 대응 능력이 중요한데, Redis/Zookeeper/etcd 각각의 특성을 고려해 설계해야 한다.

8. 모니터링 및 분석
   락 충돌, 대기 시간, 트랜잭션 충돌률을 정량적으로 측정하고 분석하는 것은 성능 최적화뿐 아니라 문제 조기 발견에 결정적이다.

공통적으로 고려해야 할 사항

• 락 범위와 트랜잭션 시간은 성능과 정합성의 균형을 결정짓는 핵심.
• 모니터링과 지표 기반 튜닝은 락 충돌, 재시도 비율, 대기 시간 등을 실시간으로 확인해 최적화에 반영해야 함.

Pessimistic Locking 특화 고려사항

• 락 에스컬레이션은 필요 이상으로 큰 범위에 락이 걸리지 않도록 튜닝해야 하며, 데이터 밀집도에 따라 조절해야 함.
• 데드락 방지를 위한 순서 보장, 타임아웃 설정, 우선순위 기반 정책도 고려 필요.

Optimistic Locking 특화 고려사항

• 버전 충돌 시 복구 전략이 명확해야 하고, 과도한 재시도를 방지하는 백오프 알고리즘이 필요함.
• 버전 필드 캐싱, 압축, 인덱싱 최적화를 통해 성능 병목 최소화.

실무 사용 예시

금융 및 트랜잭션 시스템

전자상거래 및 예약 시스템

🔹 협업 및 콘텐츠 편집

🔹 로그/통계/IoT/게임 등 실시간 데이터

✅ 6. 요약 정리 (카테고리별 핵심 내용)

• 금융/트랜잭션: 모든 상태 변경에 대해 정합성이 핵심이므로 Pessimistic Locking이 권장되며, 트랜잭션 중 데드락이나 락 타임아웃 대응이 필요함.

• 전자상거래/예약 시스템: 조회는 Optimistic, 결제나 확정 단계에서는 정확성이 중요해 혼합 전략이 일반적임.

• 협업 도구/콘텐츠 편집: 사용자 경험과 병합 편의성을 위해 Optimistic Locking 또는 CRDT 기반 처리로 전환됨.

• 로그/통계/IoT/게임 처리: 실시간성 우선 환경에서는 대부분 Optimistic Locking을 적용하며, 중요 트리거나 리소스에는 제한적으로 락을 적용함.

필요하다면 각 시나리오별로 실제 구현 코드 예시, 락 전략 전환 조건, 트랜잭션 경계 설정 방식 등도 추가 분석해줄 수 있어. 다음 단계로 확장하고 싶은 부분이 있다면 알려줘.

활용 사례

사례 1: 대형 온라인 쇼핑몰에서 재고 부족으로 인한 결제 실패 방지

시나리오: 대형 온라인 쇼핑몰에서 상품 재고 수량 관리 시 재고 부족으로 인한 결제 실패 방지

시스템 구성:

• 사용자 → 주문 시스템 → 재고 관리 서비스 → DB

graph TD
  User --> OrderSystem
  OrderSystem --> InventoryService
  InventoryService --> DB[Inventory DB]

Workflow:

• 주문 요청 → 재고 확인 → Pessimistic Lock → 재고 차감 → 주문 처리 → Lock 해제

역할:

• 재고 수량 정확성 보장
• 동시 결제 충돌 방지

유무에 따른 차이점:

• 적용 시: 주문 충돌 없음, 정확한 재고 유지
• 미적용 시: 동시에 결제 시 재고 초과 주문 가능

구현 예시 (Python + SQLAlchemy):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

from sqlalchemy import select, update, and_
from sqlalchemy.orm import Session
from models import Inventory

def reserve_stock(session: Session, product_id: int, quantity: int):
    with session.begin():
        item = session.execute(
            select(Inventory).where(Inventory.product_id == product_id).with_for_update()
        ).scalar_one()
        
        if item.stock < quantity:
            raise Exception("Out of stock")

        item.stock -= quantity
        session.commit()

사례 2: 전자상거래 플랫폼의 플래시 세일 이벤트 시스템

시나리오: 대규모 전자상거래 플랫폼의 플래시 세일 이벤트 시스템

시스템 구성:

• 웹 서버: Load Balancer 뒤의 다중 인스턴스
• 데이터베이스: PostgreSQL 클러스터 (Master-Slave)
• 캐시: Redis 클러스터
• 메시지 큐: RabbitMQ
• 모니터링: Prometheus + Grafana

graph TB
    subgraph "사용자 요청"
        U1[User 1]
        U2[User 2]
        U3[User N]
    end
    
    subgraph "웹 계층"
        LB[Load Balancer]
        W1[Web Server 1]
        W2[Web Server 2]
        W3[Web Server N]
    end
    
    subgraph "서비스 계층"
        OS[Order Service]
        IS[Inventory Service]
        PS[Payment Service]
    end
    
    subgraph "데이터 계층"
        RC[Redis Cache]
        MQ[Message Queue]
        DB[(PostgreSQL)]
        DBR[(Read Replica)]
    end
    
    subgraph "모니터링"
        MON[Monitoring System]
    end
    
    U1 --> LB
    U2 --> LB
    U3 --> LB
    
    LB --> W1
    LB --> W2
    LB --> W3
    
    W1 --> OS
    W2 --> OS
    W3 --> OS
    
    OS --> IS
    OS --> PS
    OS --> MQ
    
    IS --> RC
    IS --> DB
    PS --> DB
    
    DB --> DBR
    
    OS --> MON
    IS --> MON
    PS --> MON

Workflow:

1. 상품 조회 단계: Redis 캐시에서 상품 정보 조회 (Optimistic)
2. 장바구니 담기: 버전 기반 Optimistic Locking 으로 장바구니 업데이트
3. 재고 확인: Read Replica 에서 재고 조회 (성능 최적화)
4. 주문 생성: Pessimistic Locking 으로 재고 차감 및 주문 생성
5. 결제 처리: 외부 PG 연동 시 타임아웃 고려한 락 관리
6. 주문 완료: 비동기 메시지로 후속 처리 (배송, 알림 등)

역할:

• Pessimistic Locking: 재고 차감, 결제 처리에서 데이터 정확성 보장
• Optimistic Locking: 장바구니, 사용자 프로필 업데이트에서 성능 최적화
• Redis Cache: 상품 정보 캐싱으로 DB 부하 감소
• Message Queue: 비동기 처리로 사용자 응답 시간 단축

유무에 따른 차이점:

• 락킹 메커니즘 없는 경우:
  • 재고 오버셀링 발생 (100 개 재고에 150 개 주문 접수)
  • 결제 중복 처리로 인한 고객 불만 및 환불 비용
  • 데이터 불일치로 인한 운영 복잡성 증가
• Pessimistic Locking 만 사용하는 경우:
  • 안전하지만 동시 접속자 증가 시 심각한 성능 저하
  • 평균 응답 시간 3-5 초 증가
  • 데드락 발생으로 인한 시스템 불안정
• Optimistic Locking 만 사용하는 경우:
  • 높은 성능이지만 플래시 세일 시 대량 충돌 발생
  • 재시도 스톰으로 인한 서버 부하 급증
  • 사용자 경험 저하 (반복적인 " 다시 시도 " 메시지)
• 하이브리드 접근법 (권장):
  • 상황별 최적 락킹 전략 적용
  • 평균 응답 시간 1 초 이내 유지
  • 99.9% 데이터 정확성 보장

구현 예시:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211

# Python Flask + SQLAlchemy 구현
from flask import Flask, request, jsonify
from sqlalchemy import create_engine, Column, Integer, String, DateTime
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker
from datetime import datetime
import redis
import json

app = Flask(__name__)

# Database 설정
engine = create_engine('postgresql://user:pass@localhost/ecommerce')
SessionLocal = sessionmaker(bind=engine)
Base = declarative_base()

# Redis 설정
redis_client = redis.Redis(host='localhost', port=6379, db=0)

class Product(Base):
    __tablename__ = 'products'
    
    id = Column(Integer, primary_key=True)
    name = Column(String)
    price = Column(Integer)
    stock_quantity = Column(Integer)
    version = Column(Integer, default=1)
    updated_at = Column(DateTime, default=datetime.utcnow)

class Order(Base):
    __tablename__ = 'orders'
    
    id = Column(Integer, primary_key=True)
    user_id = Column(Integer)
    product_id = Column(Integer)
    quantity = Column(Integer)
    total_amount = Column(Integer)
    status = Column(String, default='pending')
    created_at = Column(DateTime, default=datetime.utcnow)

@app.route('/api/products/<int:product_id>', methods=['GET'])
def get_product(product_id):
    """상품 정보 조회 - Redis 캐시 + Optimistic 접근"""
    
    # 1. Redis 캐시 확인
    cached_product = redis_client.get(f'product:{product_id}')
    if cached_product:
        return jsonify(json.loads(cached_product))
    
    # 2. DB에서 조회 (Read Replica 사용)
    session = SessionLocal()
    try:
        product = session.query(Product).filter_by(id=product_id).first()
        if not product:
            return jsonify({'error': 'Product not found'}), 404
        
        product_data = {
            'id': product.id,
            'name': product.name,
            'price': product.price,
            'stock_quantity': product.stock_quantity,
            'version': product.version
        }
        
        # 3. Redis에 캐시 저장 (5분 TTL)
        redis_client.setex(
            f'product:{product_id}', 
            300, 
            json.dumps(product_data)
        )
        
        return jsonify(product_data)
        
    finally:
        session.close()

@app.route('/api/orders', methods=['POST'])
def create_order():
    """주문 생성 - Pessimistic Locking 적용"""
    
    data = request.get_json()
    user_id = data.get('user_id')
    product_id = data.get('product_id')
    quantity = data.get('quantity', 1)
    
    session = SessionLocal()
    try:
        session.begin()
        
        # 1. Pessimistic Lock으로 재고 확인 및 차감
        product = session.query(Product).filter_by(id=product_id).with_for_update().first()
        
        if not product:
            session.rollback()
            return jsonify({'error': 'Product not found'}), 404
        
        if product.stock_quantity < quantity:
            session.rollback()
            return jsonify({'error': 'Insufficient stock'}), 400
        
        # 2. 재고 차감
        product.stock_quantity -= quantity
        product.updated_at = datetime.utcnow()
        
        # 3. 주문 생성
        order = Order(
            user_id=user_id,
            product_id=product_id,
            quantity=quantity,
            total_amount=product.price * quantity
        )
        session.add(order)
        
        # 4. 트랜잭션 커밋
        session.commit()
        
        # 5. 캐시 무효화
        redis_client.delete(f'product:{product_id}')
        
        return jsonify({
            'order_id': order.id,
            'status': 'success',
            'remaining_stock': product.stock_quantity
        })
        
    except Exception as e:
        session.rollback()
        return jsonify({'error': str(e)}), 500
    finally:
        session.close()

@app.route('/api/cart', methods=['PUT'])
def update_cart():
    """장바구니 업데이트 - Optimistic Locking 적용"""
    
    data = request.get_json()
    user_id = data.get('user_id')
    items = data.get('items', [])
    
    max_retries = 3
    
    for attempt in range(max_retries):
        session = SessionLocal()
        try:
            # 1. 현재 사용자 카트 정보 조회
            cart_key = f'cart:{user_id}'
            current_cart = redis_client.get(cart_key)
            
            if current_cart:
                cart_data = json.loads(current_cart)
                original_version = cart_data.get('version', 1)
            else:
                cart_data = {'items': [], 'version': 1}
                original_version = 1
            
            # 2. 카트 데이터 업데이트
            new_cart_data = {
                'items': items,
                'version': original_version + 1,
                'updated_at': datetime.utcnow().isoformat()
            }
            
            # 3. Optimistic Update (Lua 스크립트 사용)
            lua_script = """
            local key = KEYS[1]
            local expected_version = tonumber(ARGV[1])
            local new_data = ARGV[2]
            
            local current_data = redis.call('GET', key)
            if current_data then
                local current_version = cjson.decode(current_data).version
                if current_version ~= expected_version then
                    return 0  -- 버전 충돌
                end
            end
            
            redis.call('SET', key, new_data)
            redis.call('EXPIRE', key, 3600)  -- 1시간 TTL
            return 1  -- 성공
            """
            
            result = redis_client.eval(
                lua_script, 
                1, 
                cart_key, 
                original_version, 
                json.dumps(new_cart_data)
            )
            
            if result == 1:
                return jsonify({
                    'status': 'success',
                    'cart': new_cart_data
                })
            else:
                # 충돌 발생, 재시도
                if attempt < max_retries - 1:
                    time.sleep(0.1 * (2 ** attempt))  # 지수 백오프
                    continue
                else:
                    return jsonify({'error': 'Cart update conflict'}), 409
                    
        except Exception as e:
            return jsonify({'error': str(e)}), 500
        finally:
            session.close()
    
    return jsonify({'error': 'Max retries exceeded'}), 503

if __name__ == '__main__':
    app.run(debug=True)

사례 3: 온라인 쇼핑몰에서 재고관리

시나리오: 온라인 쇼핑몰에서 재고관리 API 에 동시에 다수의 주문 요청이 들어올 때

시스템 구성:

• Web API 서버
• 데이터베이스 시스템 (DBMS)
• 클라이언트 (사용자 및 주문 API)

graph TD
    Client1(Client A) --> WebAPI(Web API 서버)
    Client2(Client B) --> WebAPI
    WebAPI --> DB[DB - 상품 테이블]

Workflow:

• 고객이 상품 주문 요청을 보내면 Web API 가 재고를 확인, 감산하여 DB 에 반영
• 비관적 락: 주문 처리 중 다른 처리 차단
• 낙관적 락: 처리 후 커밋 시점 충돌 검사, 충돌 시 롤백 후 재시도

역할:

• 비관적 락: 데이터 충돌 선제 차단
• 낙관적 락: 빠른 처리와 충돌 발생 시 롤백 대응

유무에 따른 차이점:

• 비관적 락 도입: 주문 동시 처리 불가, 대기 시간 증가. 데이터 충돌 완전 차단
• 낙관적 락 도입: 빠른 처리, 동시에 주문할 경우 일부에서는 실패 및 재시도 발생 가능

구현 예시: Python, SQLAlchemy ORM 기반

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

# 비관적 락
from sqlalchemy import select, update, and_, text
from sqlalchemy.orm import Session

def process_order_pessimistic(session: Session, product_id: int, order_qty: int):
    # 상품 행을 SELECT FOR UPDATE로 가져옴(락 선점)
    product = session.execute(
        select(Product).where(Product.id == product_id).with_for_update()
    ).scalar_one_or_none()

    if product and product.stock >= order_qty:
        product.stock -= order_qty
        # 변경사항 커밋
        session.commit()
        return True
    else:
        session.rollback()
        return False

# 낙관적 락
def process_order_optimistic(session: Session, product_id: int, order_qty: int, version: int):
    product = session.query(Product).filter(
        and_(Product.id == product_id, Product.version == version)
    ).with_for_update(nowait=False).first()
    
    # 버전이 일치하면 업데이트
    if product and product.stock >= order_qty:
        product.stock -= order_qty
        product.version += 1  # 버전 증가
        try:
            session.commit()
            return True
        except:
            session.rollback()
            return False
    else:
        session.rollback()
        return False

사례 4: 클라우드 기반 분산 처리 시스템

시나리오: 대형 온라인 상품 검색 시스템에서 수많은 사용자가 동시에 상품 정보를 조회 및 일부 수정

시스템 구성:

• 검색 API 서버 (분산)
• DBMS(예: PostgreSQL, MySQL: MVCC 지원)
• 캐시 레이어 (Redis 등)

Mermaid 다이어그램 (분산 낙관적 락/MVCC 기반)

sequenceDiagram
    participant User
    participant APIServer
    participant DBMS as Database (MVCC)
    User->>APIServer: 상품 수정 요청
    APIServer->>DBMS: 최신 버전 조회
    DBMS->>APIServer: 버전 정보와 데이터 반환
    APIServer->>DBMS: 데이터 변경 요청 (버전 함께 전달)
    alt 충돌 없음
        DBMS->>APIServer: 변경 성공/커밋
    else 충돌 발생
        DBMS->>APIServer: 충돌, 롤백 알림
        APIServer->>User: 재시도 요청 또는 오류 반환
    end

Workflow:

1. API 서버가 최신 상품 정보 (버전 포함) 읽기
2. 사용자 정보로 수정 요청
3. DB 는 커밋 시점에 버전 비교하여 충돌 확인
4. 충돌 없으면 반영, 있으면 롤백 및 오류 알림

역할:

• DBMS(MVCC/낙관적 락): 동시성 보장/정합성 유지
• API 서버: 재시도/백오프 등 비즈니스 로직

유무에 따른 차이점:

• MVCC/낙관적 락 없을 때: 일관성 저하, 일시적 데이터 잘못된 접근 가능
• 있을 때: lock-free 읽기, 대규모 확장성 및 성능 확보

구현 예시 (Python, SQLAlchemy, MVCC 기반 PostgreSQL):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# MVCC 기반으로 Version 필드(예: xmin)을 사용
from sqlalchemy.orm import Session
from sqlalchemy.exc import StaleDataError

def update_product_mvcc(session: Session, product_id: int, new_price: float, expected_version: int):
    try:
        product = session.query(Product).filter_by(id=product_id, version=expected_version).first()
        if not product:
            return False  # 충돌 발생
        product.price = new_price
        product.version += 1
        session.commit()
        return True
    except StaleDataError:
        session.rollback()
        return False

• 설명: 트랜잭션 커밋 시도 전의 version 값이 일치하면 성공, 아니면 충돌 감지 후 롤백.

정리 및 학습 가이드

내용 정리

Pessimistic vs. Optimistic Locking 은 단순한 선택이 아니라, **시스템 요구사항 (정합성 vs 성능 vs 확장성)**에 따라 유연하게 구성되어야 할 전략이다. 특히 현대 분산 시스템에서는 조합 전략과 상황 기반 정책을 통해 충돌 회피와 성능 확보를 동시에 추구하는 방향이 명확히 드러나고 있다.
이제 단일 방식보다는 트래픽 특성, 비즈니스 도메인, 기술 인프라에 따라 동적이고 조합적인 락 전략이 핵심이 된다.

트렌드 및 최신 기술 동향 요약

• 분산 환경 확산: 락의 중앙 집중화는 병목이 될 수 있어, 분산 락 시스템 (Redis Redlock, etcd, Zookeeper 등) 이 부상
• CQRS + Event Sourcing:
  • CQRS: 커맨드 (Command) 와 쿼리 (Query) 를 분리해 동시성 충돌 가능성 최소화
  • Event Sourcing: 상태 변경을 이벤트 로그로 대체해 트랜잭션 충돌 문제를 완화
• Lock Granularity:
  • Row-level, Column-level, Attribute-level Locking 등으로 세분화 → 경쟁 최소화 + 성능 향상
• Adaptive Locking Strategy:
  • 동적 정책 기반 적용: 트래픽 분석 → 충돌 빈도에 따라 전략 자동 전환 (예: optimistic fallback to pessimistic)

학습 항목 정리

• 기본 항목에서는 락 전략의 선택을 위한 트랜잭션 이론과 기본 동작 이해가 중요하며, 격리 수준과 ACID 특성, 그리고 데이터베이스 락 동작 방식은 반드시 선행 학습이 필요함.

• 심화 항목에서는 충돌 해결 및 최적화 전략에 대한 이해가 중요하다. 특히 낙관적 락에서는 CAS, 재시도, 백오프가 실질적인 핵심이며, 분산 환경에서의 락 일관성은 고급 주제로 분류됨.

• 실무 항목에서는 CQRS 및 이벤트 소싱 등 아키텍처 차원의 해결 전략과 함께, 락으로 인한 병목을 감지하고 대응하기 위한 모니터링과 테스트 전략이 중요하다.

• 특히 Pessimistic은 데드락 방지와 락 유지 최소화 전략, Optimistic은 충돌 후 전략적 복구 설계가 실무의 핵심이다.

용어 정리

참고 및 출처

• Pessimistic vs. Optimistic Locking – Martin Fowler
• Pessimistic Locking in JPA – Baeldung
• Optimistic Locking in JPA – Baeldung
• Optimistic Concurrency Control – MongoDB Docs
• java.util.concurrent.locks – Oracle Java Docs
• Redlock Algorithm – Redis Docs
• Optimistic Locking vs Pessimistic Locking – Medium
• Optimistic vs. Pessimistic Locking – Stack Overflow
• How Databases Guarantee Isolation – FreeCodeCamp
• Optimistic vs. Pessimistic Locking – Vlad Mihalcea
• Optimistic and Pessimistic Locking in SQL – Learning Notes
• Concurrency Control and Optimistic Locking – SleekFlow
• Pessimistic vs. Optimistic Locking in MySQL – DEV Community
• Optimistic Concurrency Control – Wikipedia
• Pessimistic Locking – Wikipedia
• Multi-Version Concurrency Control (MVCC) – Wikipedia
• Optimistic Locking vs. Pessimistic: A Guide for System Designers – LinkedIn
• Pros and Cons of Locking in SQL Transactions – LinkedIn
• Lock-Free Programming – Wikipedia
• Optimistic Locking in SQLAlchemy Docs
• Pessimistic Locking Pattern – Martin Fowler
• Pessimistic vs. Optimistic Locking in PostgreSQL – Cybertec
• Transaction Concurrency Control – PostgreSQL Docs
• Pessimistic vs Optimistic Locking in Database Systems – Baeldung
• Optimistic and Pessimistic Concurrency Control in Distributed Databases – Stanford
• Distributed Lock with Redis: Redlock – Redis Docs