Lock Duration

Lock Duration

Lock Duration 은 트랜잭션이 락을 쥐고 있는 시간으로, 동시성과 일관성의 균형을 결정한다.
2PL 에서는 필요한 락을 모아 잡는 성장 단계와 해제만 하는 축소 단계가 있고, Strict 2PL 은 커밋 시 일괄 해제로 복구를 단순화하지만 대기가 길어질 수 있다.
MVCC 는 읽기에서 과도한 공유락을 줄여 동시성을 높이되, 갱신·메타데이터 작업·직렬화 격리에서는 여전히 락 (행·범위·테이블) 을 사용한다.
지속시간은 격리수준, 명시적 락 구문, 트랜잭션 경계 (오토커밋·프레임워크 전파), lock_timeout 같은 파라미터, 락 그라뉼러리티와 에스컬레이션에 좌우된다.
시간이 길면 경합·데드락·긴 꼬리 지연이, 너무 짧으면 재시도·롤백과 팬텀 위험이 커진다. 따라서 짧은 트랜잭션 설계, 일관된 락 순서, 적절한 타임아웃과 백오프, 인덱스와 쿼리 최적화로 범위락을 줄이고, DDL 은 업무와 시간대를 분리하는 방식이 실무적으로 효과적이다.

락 지속시간: 성능·정합성의 결정변수

락 지속시간은 " 잠근 뒤 얼마나 오래 잡고 있느냐 " 의 문제다.
이 시간이 길어질수록 다른 트랜잭션이 기다리는 시간이 늘고 데드락 위험도 커진다.
격리수준·쿼리 실행시간·세분성·락 모드·엔진 정책 (Strict/타임아웃/에스컬레이션) 이 지속시간을 결정한다.
관측 지표 (보유/대기시간, 대기체인) 를 꾸준히 보고, 트랜잭션을 짧게·정확히 잠그며, 필요하면 U/SIX/직접 X 로 업그레이드 없이 처리하는 것이 핵심이다.
MVCC 는 읽기 대기를 줄여주지만 쓰기 지속시간은 별도로 관리해야 한다.

락 지속시간 핵심 개념 한눈에

요약: 지속시간은 격리/세분성/모드/정책의 함수다. 업그레이드 최소화·경계 단축·관측 기반 조정이 실무 핵심.

락 지속시간 인과 관계도

• 격리수준↑ → 지속시간↑ → 대기↑/데드락↑
• 세분성↓(거칠게) → 차단폭↑ → 효과적 지속시간↑
• 업그레이드 필요 (S→X) → 지속시간 중 교착 위험↑
• Strict/Rigorous 채택 → 보유기간↑(복구성↑)
• MVCC(읽기 분리) → 읽기 대기↓, " 쓰기 지속시간 " 은 별도 관리 필요

요약: 정합성을 올리면 보유·대기가 늘고, 성능을 올리면 정합성/관리비용이 늘어난다. 조절 레버는 격리·세분성·모드·정책.

락 지속시간 실무 매핑표

• 무엇: 트랜잭션 경계 단축, 인덱스 최적화·쿼리 재작성, 적절한 모드 선택 (U/SIX/직접 X), 에스컬레이션 임계/시간대·파티션 단위 조정, 타임아웃/백오프.

• 어떻게: pg_locks/sys.dm_tran_locks/performance_schema 로 보유/대기시간 분포를 관측 → 대기체인 상위 N 을 찾아 플랜/인덱스/경계 수정.

• 왜: 지속시간을 줄이면 차단 폭과 대기가 선형~지수적으로 감소 → TPS·지연 SLO 개선.

요약: " 경계 단축 + 업그레이드 제거 + 플랜 최적화 " 가 1 차 효과, " 정책 (Strict/에스컬/타임아웃)+ 구조 (MVCC/파티션)" 가 2 차 안정화 레버.

기초 조사 및 개념 정립

락 지속시간: 결정요인과 최적화

락 지속시간은 " 락을 얼마나 오래 쥐고 있나 " 다.
이 시간은

1. 2PL/Strict/Rigorous 같은 프로토콜
2. RC/RR/Serializable·MVCC 같은 격리 방식
3. 행/페이지/테이블 수준과 인덱스 접근 범위
4. 에스컬레이션·타임아웃 정책
   으로 결정된다.

길면 안전하지만 경합·대기가 늘고, 짧으면 빠르지만 불일치 위험이 커진다.
핵심은 스냅샷 읽기와 정밀한 인덱스, 짧은 트랜잭션으로 " 필요한 구간만 필요한 시간 " 보유하게 만드는 것이다.

락 지속시간의 결정요인

1. 프로토콜

   • 2PL: 성장 단계에서 획득, 수축 단계에서만 해제.
   • Strict 2PL: X 락을 커밋까지 유지.
   • Rigorous 2PL: S/X 모두 커밋까지 유지.

2. 격리수준·버저닝

   • RC: 읽기 S 락은 보통 문장 종료 시점에 해제.
   • RR/Serializable: 읽기 락 지속시간이 길어질 수 있음.
   • MVCC/SSI: 읽기는 버전 참조 (읽기 락 지속시간 실질 감소), 쓰기는 여전히 커밋까지 유지하는 경향.

3. 그라뉼러리티·의도락

   • 행/페이지/테이블 + IS/IX/SIX 의 조합이 보유 범위·시간을 좌우 (광역락일수록 효과적 동시성은 더 크게 감소).

4. 접근 경로

   • 인덱스 범위 (넥스트키/키 - 범위) 사용 시 " 보호 구간 " 이 넓어져 해제 전까지의 충돌 면적이 커질 수 있음.
   • 커버링/선행열 정합 설계는 스캔 폭을 줄여 필요한 구간만 오래 잡게 함.

5. 운영 정책

   • 에스컬레이션 임계, 타임아웃/NOWAIT, 재시도·백오프, 배치 슬라이싱이 실효 지속시간과 충돌 빈도를 조정.

Lock Duration: 정의와 핵심

Lock Duration 은 트랜잭션의 락 생명주기다.
시작점은 락 획득, 끝점은 해제 또는 커밋이며, 이 구간이 동시성과 일관성의 균형을 결정한다.

Strict/Rigorous 2PL 처럼 커밋까지 보유하는 규율은 복구·일관성 측면에서 안전하지만, 대기열과 데드락 위험을 높인다.
반대로 MVCC/SSI 는 읽기를 버전으로 처리해 읽기 락의 지속시간을 사실상 제거하고, 쓰기 경로만 커밋까지 유지해 경합을 줄인다.
그라뉼러리티와 의도락, 인덱스 접근 (넥스트키/키 - 범위) 은 " 얼마나 넓은 범위를 얼마나 오래 " 잡는지를 좌우한다.

운영 측면에서는 에스컬레이션 임계, 락 타임아웃, 재시도·백오프, 배치 슬라이싱으로 실효 지속시간을 관리한다.
실무 목표는 " 필요 최소 범위를, 필요 최소 시간만 " 보유하는 설계다.

락 지속시간의 역사와 핵심 전환점

초기 DB 는 단순 배타락으로 직렬성을 만들었지만 병렬성이 낮았다.
2PL 은 " 획득 단계→해제 단계 " 라는 규칙으로 직렬성을 보장했으나, 길게 잡힌 락은 대기·교착을 키웠다.
그래서 의도 잠금과 다중 그라뉼러리티로 " 필요한 범위만, 필요한 시간만 " 잡도록 진화했고, 팬텀은 범위락으로 막았다.
읽기 지연을 줄이기 위해 MVCC 가 도입돼 읽기는 버전으로 해결하고, 쓰기에는 여전히 락을 쓴다.
운영에서는 NOWAIT·타임아웃·skip locked 로 대기 꼬리를 잘라낸다.
글로벌 서비스에선 전역 순서·합의로 분산 환경에서도 일관성과 적절한 락 지속시간을 동시에 달성한다.

등장 배경

• 다중 사용자 환경에서 직렬성과 무결성을 보장하려면 트랜잭션 간 충돌을 제어해야 한다.
• 거친 락은 지속시간·영향 범위가 커 병렬 성능이 낮고, 단순 뮤텍스는 교착·기아를 체계적으로 다루지 못한다.
• 이에 2PL 이 획득→해제의 명확한 규율로 직렬성을 제공했고, 운영 현실 (경합·팬텀·지연) 에 대응해 의도 잠금·다중 그라뉼러리티·범위락·MVCC·운영 정책이 단계적으로 추가되었다.

발전 과정

timeline
    title Lock Duration 발전 타임라인
    1960s : 배치·단일 사용자/뮤텍스 중심 : 초기 배타 접근 제어
    1970s : 2PL 도입 : Conservative/Strict 규율로 직렬성·회복성 강화
    1980s : 다중 그라뉼러리티·의도 잠금 : 상→하 획득·에스컬레이션로 평균 지속시간 절감
    1990s : 범위락/넥스트키 : 팬텀 차단(지속시간·면적은 증가 가능)
    1990s–2000s : MVCC·Snapshot : 읽기 락을 버전 가시성으로 대체
    2000s : NOWAIT/Timeout/Skip Locked : 꼬리 대기 억제·장수 Tx 완화
    2010s : SSI(Serializable Snapshot) : 읽기 자유 + 직렬성 검증(재시도 비용)
    2010s–현재 : 분산(전역 시간·합의/2PC) : 지역 락은 짧게, 전역 순서로 일관성 확보
    2020s–현재 : 적응형 락 지속시간 튜닝 : 워크로드 기반 자동 최적화

락 지속시간은 2PL 로 규율이 생기고, 의도 잠금·다중 그라뉼러리티로 평균을 줄였으며, 범위락으로 팬텀을 차단했다. MVCC/SSI 는 읽기 지속시간을 사실상 제거했지만 검증·재시도 비용을 낳았다. 운영 기능과 분산 기술은 긴 꼬리 대기를 누르고, 최근에는 워크로드에 맞춰 지속시간을 자동 최적화하는 방향으로 진화 중이다.

Lock Duration 으로 다잡는 일관·성능

락 지속시간은 “잠금이 얼마나 오래 유지되느냐” 를 뜻한다.
오래 잡으면 더 안전하지만 더 많이 기다려야 하고, 짧게 잡으면 빠르지만 이상 현상 (Dirty/Lost/Non-repeatable/Phantom) 이 나타날 수 있다.
그래서 필요한 구간만 충분히, 그 외에는 빨리 해제하는 전략이 중요하다.
이를 위해 트랜잭션을 짧게 설계하고, 업그레이드 (S→X) 없이 처음부터 적절한 모드로 잠그며, 프레디킷/넥스트키 같은 범위락은 정말 필요한 범위에만 적용한다.
남는 리스크는 타임아웃·에스컬레이션과 모니터링으로 제어한다.

지속시간으로 해결하는 동시성 이상

요약: 충분히 오래 + 필요한 곳만이 원칙이다. 범위를 잠글 때는 과대 차단을 피하도록 쿼리·인덱스를 함께 설계한다.

지속시간 설계의 다섯 목표

요약: 목적은 무결성→성능→운영 순으로 연결돼 있으며, 각 목적은 지속시간 정책으로 구체화된다.

문제와 목적의 1:1 매핑

요약: 각 문제는 하나 이상의 목적과 직접 연결되며, 지속시간 조절이 실천 레버다.

Dirty / Non-repeatable Read(NRR) / Lost Update / Phantom 과 락 지속시간의 관계

• 이상을 막으려면 **어떤 락을 언제부터 언제까지 보유할지 (지속시간 창)**를 정확히 잡아야 한다.
• 요약 규칙:
  1. Dirty Read 방지: **쓰기 (X)**는 커밋까지 유지(Strict)
  2. NRR 방지: **읽기 (S)**는 트랜잭션 종료까지 유지(Rigorous/Repeatable Read) 또는 스냅샷 (MVCC)
  3. Lost Update 방지: 갱신 대상에 X 를 읽는 순간부터 커밋까지(업그레이드 대신 U/SIX/초기 X)
  4. Phantom 방지: 범위에 프레디킷/넥스트키 락을 트랜잭션 종료까지(또는 SSI)

이상 유형 × 지속시간: 한눈에 표

요약: “얼마나 오래 잠그느냐” 가 이상 방지의 본질이다. Dirty 는 X- 커밋까지, NRR 은 S- 트랜잭션까지, Lost 는 X- 트랜잭션까지, Phantom 은 범위 - 트랜잭션까지가 최소치다.

실무 메모

• 업그레이드 최소화: S→X 는 전형적 교착 경로. 가능하면 U(Update) 또는 SIX/초기 X로 시작해 보유시간 창을 한 번에 확정.
• 범위 잠금 최적화: Phantom 방지 시 선택도 높은 인덱스 + 넥스트키로 " 필요 범위만 오래 " 잠그기.
• MVCC 하이브리드: 읽기는 스냅샷으로 비차단, 쓰기 구간만 강하게 오래(2PL) 잠그면 전체 대기시간이 크게 줄어든다.
• 지표로 검증: lock_hold_time, lock_wait_time, 데드락률, 넥스트키 충돌 건수로 보유시간 조정 효과를 즉시 확인.

작은 타임라인 예시 (Dirty Vs NRR)

• Dirty 방지: T1: X(행A) —[커밋까지 유지]→ Commit → 이 동안 T2: Read(A) 는 대기/버전읽기
• NRR 방지: T1: S(행A) —[트랜잭션 종료까지 유지]→ Commit → T2: Write(A) 는 대기, T1 의 두 번째 읽기도 동일값 보장

락 지속시간을 줄이는 시스템 요건

락 지속시간은 " 언제까지 락을 쥐고 갈 것인가 " 의 문제다.
트랜잭션 경계, 격리 수준, Strict 여부가 해제 시점을 정한다.
로그 (WAL) 와 데드락 감지·타임아웃이 받쳐줘야 불필요한 장기 보유를 막을 수 있다.
애플리케이션은 짧은 트랜잭션과 일관된 자원 순서를 지켜 락 시간을 스스로 줄여야 한다.

락 지속시간을 좌우하는 필수 조건

• 트랜잭션 경계 규율

  • 무엇: 명확한 BEGIN/COMMIT/ROLLBACK, 자동 커밋 정책.
  • 왜: 락 해제 시점은 경계에 종속. 경계 모호하면 락 장기 보유·경합 급증.

• 회복·로그 전제 (WAL)

  • 무엇: 커밋 전 로그 영속, 크래시 후 재실행/언두.
  • 왜: Strict/Rigorous 에서 커밋까지 보유되는 락은 로그 일관성을 전제로 안전하게 해제 가능.

• 락 관리자·호환성·데드락 감지

  • 무엇: 호환성 매트릭스, 대기 큐, Wait-for 그래프/타임아웃.
  • 왜: 대기/감지 실패는 무한 보유로 이어짐.

• 격리 수준·정책 명세

  • 무엇: 문장 수준 (S 해제 타이밍) vs 트랜잭션 수준 (X 커밋 해제), 키 - 범위 필요 여부.
  • 왜: 격리에 따라 락 지속시간과 범위가 달라짐.

• 자원·스케줄링

  • 무엇: 메모리 (락 테이블), CPU(큐·판정), 디스크 I/O(로그), 네트워크 지연 (분산).
  • 왜: 자원 박하면 대기 증가 → 보유시간 길어짐.

• 애플리케이션·SQL 규율

  • 무엇: 외부 I/O·사용자 대기 금지, 짧은 트랜잭션, 일관된 자원 순서, FOR UPDATE 와 같은 의도적 락 전환 시점 문서화.
  • 왜: 불필요한 대기가 락 지속시간을 폭증시킴.

• 운영 파라미터와 SLA

  • 무엇: LOCK_TIMEOUT/DEADLOCK_TIMEOUT, 에스컬레이션 임계, 재시도·멱등.
  • 왜: 꼬리 지연을 강제로 자름으로써 보유시간 상한을 관리.

Lock Duration 전제·요구사항 요약

요약: 락 지속시간은 경계·격리·회복이 정하고, 엔진/자원/운영이 이를 지탱한다. 애플리케이션 규율이 느슨하면 어떤 엔진도 장기 보유를 막지 못한다.

Lock Duration 의 구조적 이해

Lock Duration 은 “언제 락을 잡고 언제 놓는가” 다.
RC 에선 읽기 (S) 가 문장 끝에 풀릴 수 있지만, RR/Serializable 이나 Strict 2PL 에선 트랜잭션 끝까지 유지된다.
X 는 보통 커밋까지 붙는다.
MVCC 는 읽기를 버전으로 처리해 공유락을 줄이지만, Serializable 수준에서는 범위/프레디킷 보호가 트랜잭션 종료까지 남는다.
에스컬레이션이 일어나면 상위락이 더 오래 유지되어 동시성이 줄 수 있다.
타임아웃·데드락 처리는 실효 지속시간을 줄이는 안전장치다.

지속시간 관점에서 본 락의 본질

• 시간 계층화: Statement/Transaction/Session/System 네 단계.
  근거: 락 매니저의 상태천이 (요청·허용·해제).
  차별점: MVCC 는 읽기락 최소화로 Statement-duration 조차 생략 가능.

• 2PL 변형에 따른 락 수명: Basic(전이 규칙), Strict(X=커밋까지), Rigorous(S/X=커밋까지), Conservative(전부 선점).
  근거: 2PL 규칙·복구성.
  차별점: OCC 는 검증 순간에만 충돌 처리.

• 격리수준별 보유 범위: RC(S=문장), RR/Serializable(S=트랜잭션), X=트랜잭션.
  근거: 각 수준의 가시성·재실행 보장 요구.
  차별점: RC-Snapshot/MVCC 는 S 락 불필요.

• MVCC/SSI 의 범위 보호: S 락 대신 Predicate/SIREAD 를 트랜잭션 종료까지 유지.
  근거: 팬텀 방지.
  차별점: " 락 없음 " 이 아니라 락 종류 변화.

• 그레인·에스컬레이션: 행→페이지→테이블 승격 시 보유 주체가 상위로 바뀌고 차단면적 확대.
  근거: 관리비용 절감 정책.
  차별점: 지속시간 동일해도 대기 영향 급증.

• 타임아웃·데드락 정책: 실효 지속시간을 줄이고, 시스템 정체를 해소.
  근거: 대기 큐·Wait-For 그래프.
  차별점: 기능은 " 단축 " 이 아니라 강제 종료.

• 락/래치 구분: 지속시간 관점에서 락≫래치.
  근거: 목적 (일관성 vs 메모리 보호), 수명 (트랜잭션 vs 수 μs–ms).

Lock Duration 특징·근거·차별점

표 요약: Lock Duration 은 **수명 규칙 (2PL·격리수준)**과 읽기 전략 (MVCC/SSI), **그레인/정책 (에스컬·타임아웃)**의 합성 결과다. " 얼마나 오래 잡는가 " 는 기술 스택과 정책 선택의 함수다.

락 Duration 의 균형과 설계 결정요인

• 락은 오래 잡을수록 안전하지만 느려진다.
• 은행/결제처럼 실수하면 안 되는 시스템은 조금 더 오래 잡아 데이터를 안전하게 만든다.
• 대규모 웹 서비스는 최대한 짧게 잡고, 읽기는 스냅샷/리플리카로 분리해 속도를 확보한다.
• 결국 목표는 일관성 vs 지연·처리량의 균형이며, 이를 위해 보유 시간 정책 + 운영 레버를 함께 설계한다.

설계 동기

• 무결성 보호가 최우선인 도메인:
  결제·정산은 잘못된 중복 갱신이 치명적이므로, 락을 끝까지 유지(Strict 경향) 해 미커밋 의존을 차단하려는 동기.

• 대량 동시성 처리 요구:
  웹/모바일 트래픽은 순간 경합이 크다. 짧은 보유 시간과 **국소 락 (행/버킷 단위)**로 큐 길이를 줄여 테일 지연을 낮추려는 동기.

• 분산/HTAP 환경의 혼재:
  분석 스캔이 길어지면 보유 시간도 길어져 OLTP 를 막는다. 읽기 분리·스케줄 분리로 보유 시간을 간접적으로 줄이려는 동기.

• 운영·복구 단순화:
  보유 정책이 일관될수록 데드락/타임아웃 기준과 희생자 정책을 표준화하기 쉬워서 운영이 단순해지는 동기.

품질 속성

• 성능/지연: 보유 시간이 길면 경합 대기가 늘어 평균/상위 지연이 증가. 짧게 만들면 반대로 개선.
• 처리량: 대기열이 줄면 CPU·I/O 가 더 많은 트랜잭션을 처리해 TPS/QPS 증가.
• 확장성: 짧고 지역화된 락은 파티셔닝/샤딩과 결합해 노드 수 증가에 선형에 가까운 확장성을 제공.
• 복구성: Strict 보유는 연쇄 롤백 방지로 재처리 비용을 낮춘다.
• 일관성/격리: 범위 잠금(넥스트키/프레디킷) 을 동반한 긴 보유는 팬텀 방지에 직접 기여.
• 예측 가능성/공정성: 보유 상한 + 우선순위 노후화/부스팅은 기아를 줄이고 SLA 안정에 기여.
• 운영성/관찰성: 타임아웃/백오프/에스컬레이션 임계치를 지표로 자동 튜닝하면 보유 시간 분포를 제어하기 쉬움.

락 보유 시간 설계 - 품질 매핑표

락 보유 시간은 도메인 위험 허용도와 성능 목표의 타협 결과다. " 긴 보유=안전/복구 용이 “, " 짧은 보유=성능/확장성 " 이며, **레버 (Strict·범위 잠금·짧은 TX·읽기 분리·타임아웃/에스컬레이션)**로 목표 지표를 조정한다.

Phase 2: 핵심 원리 및 이론적 기반

락 지속시간 운영 프레임워크

락 지속시간은 " 락을 얼마나 오래 쥐고 있나 " 다.
이를 줄이려면 트랜잭션을 짧게 쪼개고, 인덱스·파티션으로 보호 구간을 정확히 만들며, 읽기는 스냅샷으로 분리한다.
반대로 안전이 최우선인 경로는 커밋까지 보유한다.
자원 획득 순서를 표준화하고, 대기·에스컬레이션 이벤트를 모니터링해 수치로 관리하면 지연과 데드락을 동시에 낮출 수 있다.

Lock Duration 핵심 원칙표

원칙은 " 작게·짧게·정확하게 잡고, 순서와 공정성을 지키며, 수치로 관리 " 로 귀결된다.

Lock Duration 설계 철학표

철학은 " 규율로 안전을, 역할 분리로 처리량을, 구조와 정책으로 예측성을 " 확보하는 방향이다.

락 지속시간: 동작 원리부터 흐름까지

트랜잭션은 자원에 S/X 락을 요청하고, 호환성 매트릭스가 허용하면 즉시 부여되어 락 지속시간이 시작된다.
2PL 규칙 때문에 중간에 임의 해제는 제한되고, Strict/Rigorous 방식이면 커밋까지 유지된다.
읽기는 격리수준과 MVCC 여부에 따라 S- 락을 짧게 혹은 생략할 수 있고, 쓰기는 X- 락을 커밋까지 보유한다. 의도락·인덱스 경로는 " 얼마나 넓게 " 잠그는지를, 타임아웃·데드락 탐지·에스컬레이션은 " 얼마나 오래 " 잡는지를 좌우한다.

기본 동작 메커니즘

• 시작: 트랜잭션이 (리소스, 모드) 요청 → 락 매니저가 호환성 매트릭스 평가 → 부여 시 지속시간 시작, 불가 시 대기 큐.
• 보유: 2PL 하에서 추가 락은 성장 단계에서만; 읽기는 격리수준·MVCC 에 따라 단문/트랜잭션 단위 보유 또는 생략. 인덱스 범위 스캔이면 키 - 범위/넥스트키로 보호 구간 유지.
• 제어: 타임아웃, NOWAIT/SKIP LOCKED, 에스컬레이션 임계, 데드락 탐지 (대기 그래프) 로 대기/교착을 관리.
• 종료: 커밋/롤백 시 일괄 해제 (Strict/Rigorous 는 커밋 때), 세션 종료·타임아웃 시 강제 해제. 이후 대기 큐 재평가.

락 지속시간 동작 요약표

매트릭스가 시작을, 2PL/격리·인덱스가 길이와 범위를, 타임아웃/탐지/에스컬이 과도 연장을 제어한다.

락 지속시간 흐름 다이어그램

flowchart TD
  A[BEGIN TRANSACTION] --> B["요청: (리소스, 모드)"]
  B --> C{호환성 매트릭스 OK?}
  C -- 예 --> D[락 부여 & 지속시간 시작]
  C -- 아니오 --> E{정책}
  E -- NOWAIT --> F[즉시 실패/재시도]
  E -- WAIT --> G[대기 큐 등록]
  E -- SKIP LOCKED --> H[잠긴 행 건너뛰고 진행]

  D --> I{2PL 성장 단계?}
  I -- 예 --> J[추가 락 가능]
  I -- 아니오 --> K[해제만 가능]

  D --> L{읽기 경로?}
  L -- MVCC/SSI --> M["버전 읽기(락 생략/단문)"]
  L -- RR/Serializable --> N["S-락 유지(범위/프레디킷/넥스트키)"]

  D --> O{에스컬레이션 임계 초과?}
  O -- 예 --> P[상위 락 승격]
  O -- 아니오 --> Q[유지]

  D --> R{데드락 탐지 주기}
  R -->|사이클 발견| S[희생자 선택·롤백]
  R -->|없음| Q

  G --> C
  J --> Q
  K --> Q
  M --> Q
  N --> Q
  P --> Q

  Q --> T{COMMIT/ROLLBACK?}
  T -- 예 --> U["일괄 해제(Strict/Rigorous: 커밋 시)"]
  U --> V[대기 큐 재평가·부여]
  V --> W[END]
  T -- 아니오 --> Q

요청은 매트릭스 평가로 즉시 부여·대기·우회 중 하나로 결정된다. 보유 중에는 2PL 규칙과 격리수준·MVCC 가 읽기 락의 지속을 정의하고, 인덱스 범위는 보호 구간을 형성한다. 에스컬레이션·데드락 탐지·타임아웃이 과도한 연장을 통제한다. 종료 시 일괄 해제 후 대기 큐를 재평가한다.

락 지속시간: 요청·대기·부여·해제의 전모

트랜잭션은 먼저 상위 객체에 의도 잠금 (IS/IX) 을 걸어 " 아래에서 S/X 를 잡겠다 " 는 의사를 밝힌다.
호환되면 하위 (페이지·행) 에서 실제 S/X 를 획득하고 작업을 수행한다.
충돌하면 대기큐로 들어가고, NOWAIT 면 즉시 실패한다.
타임아웃이면 롤백·재시도를 택한다.

Strict 2PL 에서는 커밋 시점까지 락을 유지해 복구가 쉽지만 대기가 늘 수 있다.
반대로 작업 단위 후 즉시 해제하면 대기는 줄지만 재시도·팬텀이 늘 수 있다.
실무에서는 상→하 획득, 일관된 락 순서, 적절한 타임아웃·백오프, 업그레이드 최소화로 지연과 교착을 줄인다.

락 흐름 단계·예외·튜닝 한눈에

• 요청→판정: LOCK(req) 가 오면 Lock Table 의 보유/대기 목록과 호환성 매트릭스로 즉시 판정한다.
• 대기 제어: 불가면 대기큐(FIFO/우선순위) 로 이동, NOWAIT 이면 실패 반환, 타임아웃이면 중단·정책적 재시도.
• 획득·유지: 호환되면 Granted. Strict 2PL 은 커밋/어보트까지 보유, 일반은 작업 단위 완료 시 해제 가능.
• 업그레이드: S→X 는 별도 큐에서 기아 방지와 교착 회피 정책이 필요.
• 해제·깨우기: 해제 시 같은 리소스의 대기큐를 깨우고 순서대로 재평가.
• 감시: 데드락 탐지기 (Wait-For Graph) 로 순환 대기 발견 시 희생 Tx를 선정해 해제 트리거.

• 요약: 상→하 획득, 공정 큐, 타임아웃·NOWAIT, 업그레이드 억제가 락 지속시간과 대기 꼬리를 좌우한다.

Lock Duration 제어 플로우차트

flowchart TD
    A[Start/Tx begins] --> B["Intent Lock on Parent (IS/IX/SIX)"]
    B -->|Compatible| C["Request Child Lock (S/X)"]
    B -->|Incompatible| WQ[Enqueue in Wait Queue]

    C -->|Granted| D[Execute Work]
    C -->|Upgrade S→X needed?| U{Upgrade Allowed?}

    U -->|Yes| UQ[Upgrade Queue]
    UQ -->|Granted| D
    U -->|No| TO[Timeout/Abort Policy]

    WQ -->|NOWAIT| NW[Fail Fast/Retry Backoff]
    WQ -->|Wait| RCHK{Timeout reached?}
    RCHK -->|Yes| TO2[Abort & Retry Policy]
    RCHK -->|No| C

    D -->|Strict 2PL?| S2PL{Hold until Commit}
    S2PL -->|Yes| COMMIT[Commit/Abort]
    S2PL -->|No| REL[Release after Unit of Work]

    REL --> WAKE[Wake Next Waiter]
    COMMIT --> WAKE
    WAKE --> C

    %% Deadlock side path
    MON[Wait-For Graph Monitor] -->|Cycle?| VICTIM[Select Victim & Abort]
    VICTIM --> WAKE

락 생명주기 상태 머신

stateDiagram-v2
    [*] --> Requested
    Requested --> Granted: Compatible & Free
    Requested --> Waiting: Incompatible/Busy
    Waiting --> Granted: Woken & Compatible
    Waiting --> Timeout: Wait limit exceeded
    Granted --> UpgradePending: S→X requested
    UpgradePending --> Granted: Upgrade granted
    UpgradePending --> Waiting: Upgrade blocked
    Granted --> Released: Explicit release / Unit done
    Granted --> CommitHold: Strict 2PL
    CommitHold --> Released: Commit/Abort
    Waiting --> DeadlockDetected: Cycle in WFG
    DeadlockDetected --> Aborted: Victim selected
    Timeout --> Aborted
    Aborted --> Released
    Released --> [*]

특성 분석 및 평가

락 지속시간, 성능·정합성의 분기점

• 오래 잠그면 안전하지만 느려지고 (대기↑), 짧게 잠그면 빠르지만 오류 위험이 커진다.
• 미세락은 동시에 많이 돌릴 수 있지만 관리가 복잡해지고, 큰 단위 락은 관리가 쉽지만 많은 요청을 막아선다.
• 실무는 **읽기는 최대한 비차단 (MVCC), 쓰기는 필요한 동안만 강하게 (2PL)**가 기본. 여기에 업그레이드 최소화, 피크타임엔 미세락, 비피크엔 에스컬 같은 운영 룰을 더해 성능과 안정성을 동시에 잡는다.

주요 선택지별 트레이드오프 매트릭스

보유시간·세분성·업그레이드·범위 제어 네 가지가 성능과 정합성을 좌우하는 핵심 레버다. 지표 (p95 지연, 데드락률, 에스컬 카운트) 로 지속 점검하며 조합을 조절하라.

하이브리드 운용 레시피 모음

요약: 단일 선택보다 조합이 훨씬 강력하다. 읽기는 비차단, 쓰기는 정밀 제어, 운영은 시간·공간 (파티션) 으로 나눠 다르게 대한다.

3.4 적용 적합성 평가

락을 오래 쥘 경로와 그렇지 않은 경로

락 지속시간은 " 얼마나 오래 자원을 붙잡는가 " 다. 돈·주문처럼 틀리면 안 되는 경로는 커밋까지 락을 쥐는 게 맞다 (Strict). 대신 읽기가 많거나 초저지연이면 오래 잡는 락은 병목을 만든다. 이때는 읽기를 스냅샷으로 분리하고, 범위 무결성이 꼭 필요한 일부 경로만 강하게 보호해 총비용을 낮춘다.

락 지속시간 관점의 적용 판단 기준

설계 관점

• 적합: 짧은 트랜잭션, 작은 핫셋, 강한 참조/범위 무결성 필요 (주문·권한·재무상태 변경). Strict/Rigorous 로 커밋 시 해제.
• 조건부: 스캔 + 부분 갱신은 SIX+ 하위 X와 인덱스로 후보 축소. 범위 불변이면 키 - 범위/Serializable로 경로 한정 상승.
• 부적합/대안: 대규모 읽기·캐시 친화 서비스, 실시간 스트리밍 → MVCC/락리스·OCC·CQRS 로 읽기 분리.

분석 관점

• 지표 중심: P95 락 보유시간, 락 대기율, 데드락/분, 에스컬레이션률, 상위 충돌률.
• 임계 예시: P95 보유 ≤ 150–200ms, 데드락/분 ≤ 0.01, 상위 충돌률 ≤ 5%. 초과 시 락 지속시간 단축(쿼리 프루닝·경계 단축·승격 예외).

운영 관점

• 대기 관리: LOCK_TIMEOUT/DEADLOCK_TIMEOUT, 지수 백오프 + 멱등 재시도.
• 격리 정책: 읽기 스냅샷 기본, 쓰기 경로만 Strict. 범위 민감 경로만 Serializable.
• 분산: 샤드 키 순서 고정, 교차 트랜잭션 분해 (사가) 로 장시간 보유 방지.

Lock Duration 관점의 적합성 매트릭스

요약: 무결성이 우선인 코어 경로는 " 오래 잡는 락 (Strict)” 이 맞고, 읽기 대량·초저지연·분산에선 " 오래 잡지 않는 설계 (MVCC/OCC/분해)" 가 맞다. 경로별로 다르게 가져가면 총비용이 최소화된다.

구현 방법 및 분류

락 지속시간 최적화: 전술부터 운영까지

락 지속시간을 줄이는 핵심은 " 잠금이 필요한 범위와 시간을 동시에 줄이는 것 " 이다.
이를 위해 대기·보유의 상한 (타임아웃) 을 두고, 경합이 높으면 자동으로 상한을 낮춘다.
상하위 객체에 서로 다른 정책을 두어 광역 차단을 피하고, 읽기는 MVCC/SSI 로, 쓰기는 잠금으로 분리한다.
잠긴 행은 건너뛰거나 즉시 실패시켜 꼬리 지연을 막고, 에스컬레이션·데드락 정책으로 장대기를 제어한다.
마지막으로 인덱스·쿼리·트랜잭션을 다듬어 스캔 폭과 보유 시간을 함께 줄인다.

Lock Duration 구현 기법표

Lock Duration 기법 분류

A. 시간·정책 기반 제어

대기·보유 상한과 우회 정책으로 실효 지속시간을 직접 절단한다.

• 요약: " 기다리지 않기 " 와 " 빨리 포기하기 " 로 꼬리를 자른다.

타임아웃 기반 락 지속 시간 제어 예시

 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

class LockManager:
    def __init__(self):
        self.locks = {}  # 자원별 락 정보
        self.timeouts = {}  # 락별 타임아웃 정보
    
    def acquire_lock(self, transaction_id, resource_id, lock_mode, timeout_seconds=30):
        """
        락 획득 요청 처리
        Args:
            transaction_id: 트랜잭션 식별자
            resource_id: 자원 식별자
            lock_mode: 락 모드 ('shared', 'exclusive')
            timeout_seconds: 최대 락 보유 시간
        """
        import time
        import threading
        
        lock_key = f"{resource_id}_{lock_mode}"
        current_time = time.time()
        
        # 기존 락 확인
        if lock_key in self.locks:
            existing_lock = self.locks[lock_key]
            # 호환성 검사 (공유 락끼리는 호환 가능)
            if lock_mode == 'shared' and existing_lock['mode'] == 'shared':
                # 공유 락 추가
                existing_lock['holders'].add(transaction_id)
                self.timeouts[f"{transaction_id}_{resource_id}"] = current_time + timeout_seconds
                return True
            else:
                return False  # 호환되지 않는 락 존재
        
        # 새로운 락 생성
        self.locks[lock_key] = {
            'mode': lock_mode,
            'holders': {transaction_id},
            'acquired_time': current_time
        }
        
        # 타임아웃 설정
        self.timeouts[f"{transaction_id}_{resource_id}"] = current_time + timeout_seconds
        
        # 타임아웃 모니터링 스레드 시작
        timer = threading.Timer(timeout_seconds, self._timeout_handler, 
                               [transaction_id, resource_id])
        timer.start()
        
        return True
    
    def _timeout_handler(self, transaction_id, resource_id):
        """타임아웃 시 락 강제 해제"""
        print(f"락 타임아웃: Transaction {transaction_id}, Resource {resource_id}")
        self.release_lock(transaction_id, resource_id)

적응적 락 지속 시간 조정 예시

 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

class AdaptiveLockManager:
    def __init__(self):
        self.base_timeout = 30  # 기본 타임아웃 (초)
        self.lock_contentions = {}  # 자원별 경합 횟수
        self.system_load_factor = 1.0  # 시스템 부하 계수
    
    def calculate_adaptive_timeout(self, resource_id):
        """
        적응적 타임아웃 계산
        Args:
            resource_id: 자원 식별자
        Returns:
            조정된 타임아웃 시간
        """
        # 해당 자원의 경합 수준 확인
        contention_count = self.lock_contentions.get(resource_id, 0)
        
        # 경합이 높을수록 타임아웃 단축
        contention_factor = max(0.1, 1.0 - (contention_count * 0.1))
        
        # 시스템 부하가 높을수록 타임아웃 단축
        load_factor = max(0.1, 1.0 - (self.system_load_factor - 1.0) * 0.5)
        
        # 최종 타임아웃 계산
        adaptive_timeout = self.base_timeout * contention_factor * load_factor
        
        return max(1.0, adaptive_timeout)  # 최소 1초 보장
    
    def update_contention_stats(self, resource_id, is_contention):
        """경합 통계 업데이트"""
        if resource_id not in self.lock_contentions:
            self.lock_contentions[resource_id] = 0
        
        if is_contention:
            self.lock_contentions[resource_id] += 1
        else:
            # 성공적인 락 획득 시 경합 카운트 감소
            self.lock_contentions[resource_id] = max(0, 
                self.lock_contentions[resource_id] - 1)

B. 프로토콜·격리 기반

2PL 변형과 MVCC/SSI 로 락의 필요성과 보유 구간을 설계한다.

• 요약: 읽기는 부드럽게, 쓰기는 강하게. 안전·성능 균형.

C. 계층·범위 기반

IS/IX/SIX 와 인덱스·선행열·커버링으로 어디를 얼마나 넓게 잠글지 제어한다.

• 요약: 범위를 정밀화하면 시간도 함께 줄어든다.

계층적 락 지속 시간 관리 예시

 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

class HierarchicalLockManager:
    def __init__(self):
        self.lock_hierarchy = {
            'database': {'default_timeout': 300, 'escalation_threshold': 1000},
            'table': {'default_timeout': 120, 'escalation_threshold': 500},
            'page': {'default_timeout': 60, 'escalation_threshold': 100},
            'row': {'default_timeout': 30, 'escalation_threshold': 50}
        }
        self.active_locks = {}  # 수준별 활성 락 카운트
    
    def acquire_hierarchical_lock(self, transaction_id, resource_path, lock_mode):
        """
        계층적 락 획득
        Args:
            transaction_id: 트랜잭션 ID
            resource_path: ['database', 'table_name', 'page_id', 'row_id']
            lock_mode: 락 모드
        """
        # 상위 레벨부터 순차적으로 락 획득
        for level, resource_id in enumerate(['database', 'table', 'page', 'row']):
            if level >= len(resource_path):
                break
                
            level_name = list(self.lock_hierarchy.keys())[level]
            timeout = self.lock_hierarchy[level_name]['default_timeout']
            
            # 해당 수준의 락 획득
            if not self._acquire_level_lock(transaction_id, level_name, 
                                          resource_path[level], lock_mode, timeout):
                # 락 획득 실패 시 이미 획득한 상위 락들 해제
                self._release_acquired_locks(transaction_id, level)
                return False
        
        return True
    
    def check_escalation_needed(self, level_name):
        """락 에스컬레이션 필요성 검사"""
        current_count = self.active_locks.get(level_name, 0)
        threshold = self.lock_hierarchy[level_name]['escalation_threshold']
        
        return current_count > threshold

D. 운영·관측·자동화

관측치로 정책을 폐루프 튜닝해 실효 지속시간을 유지한다.

• 요약: 보지 못하면 줄일 수 없다. 계측과 목표 기반 운영.

E. 분산 커밋·전역 일관성

2PC·코디네이터·커밋 창 최적화로 분산 환경의 보유 구간을 최소화한다.

• 요약: 커밋 직전 구간을 짧게, 핫스팟을 넓게 분산.

Lock Duration 통합 요약표

락 지속시간 운영 전략

락 지속시간은 " 언제 락을 놓는가 " 에 따라 동시성과 일관성이 결정된다.
즉시 해제는 빠르지만 재시도·팬텀이 늘고, 트랜잭션단위 해제 (Strict 2PL) 는 정합성이 높지만 대기와 데드락 위험이 커진다.
격리수준이 올라갈수록 보유시간이 길어지는 경향이 있다.
충돌은 대기·NOWAIT·타임아웃·중재자 (데드락 희생) 중 어떤 정책을 쓰느냐에 따라 체감 지속시간이 달라진다.
2PL 은 사전 차단으로 예측 가능, MVCC 는 읽기 지속시간을 줄여 처리량을 높인다.
결국 워크로드 성격에 맞춰 네 축을 조합해 운영하면 된다.

락 지속시간 핵심 분류 체계

네 축으로 보는 락 지속시간

A. 해제 시점

락을 언제 해제할지로 수명을 정의 (즉시/연산단위/트랜잭션단위). 짧을수록 동시성↑, 길수록 일관성·복구 용이성↑.

해제 시점은 체감 지속시간을 직접 결정하는 1 차 노브다.

B. 격리수준 영향

RC→RR→SR 로 갈수록 보유시간이 늘고 재현성은 높아진다.

격리수준은 " 일관성 강도 ↔ 지속시간 " 의 교환관계를 형성한다.

C. 충돌 처리

대기/NOWAIT/타임아웃/중재자 조합으로 혼잡을 제어한다.

혼잡 제어 정책은 대기열 폭주와 장수 트랜잭션을 억제해 실효 지속시간을 줄인다.

D. 엔진 전략

2PL 은 사전 차단, MVCC 는 읽기 분리, 혼합은 상황 최적화.

엔진 전략 선택은 읽기/쓰기 비율과 충돌률을 기준으로 한다.

락 지속시간 설계·운영 종합지도

락 지속시간 운영을 위한 실전 도구지도

락 지속시간을 통제하려면 **DB 엔진의 기본 버튼들 (타임아웃/격리/에스컬/힌트)**로 " 얼마나 오래 기다리고, 얼마나 크게 잠글지 " 를 정한다.
그다음 관측 스택으로 대기·데드락·보유 시간을 수치로 보고, 필요하면 분산 락/TTL로 애플리케이션 레벨 만료를 더한다.
마지막으로 벤치마크로 정책 변경의 전후 효과를 검증하면, " 느리지만 안전 " 과 " 빠르지만 위험 " 사이의 균형점을 찾을 수 있다.

기능별 락 지속시간 운영 분류

A. DBMS 기본 제어 (타임아웃·격리·에스컬)

실무에서 락 보유/대기 시간을 직접 줄이거나 늘리는 1 차 수단.

• MySQL: innodb_lock_wait_timeout, Performance Schema data_locks
• PostgreSQL: lock_timeout/deadlock_timeout/statement_timeout, SKIP LOCKED/NOWAIT
• SQL Server: SET LOCK_TIMEOUT, 스냅샷 읽기, 에스컬레이션/테이블 힌트
• Oracle: DDL_LOCK_TIMEOUT, FOR UPDATE WAIT n/NOWAIT

• 요약: 엔진 버튼으로 보유/대기/범위를 직접 다스린다. 힌트·에스컬은 강력하지만 부작용 관리가 핵심.

B. 관측·진단 (메트릭·로그·대시보드)

락 대기·보유·데드락을 가시화해 튜닝 루프를 만든다.

• Prometheus + Grafana, Whatap/APM, 각 엔진 뷰/DMV(pg_locks, sys.dm_tran_locks, InnoDB/Performance Schema).

• 요약: 관측 없이는 조정이 불가. 지표·로그의 **연결 (앱→DB)**이 중요하다.

C. 분산 락/애플리케이션 레벨 (리스·TTL)

DB 외부에서 만료 정책으로 지속시간을 보완한다.

• Redis(Redisson, redlock), ZooKeeper(Curator), etcd(리스).

• 요약: TTL·리스로 과도 보유를 방지하되, 강한 직렬성 요구엔 DB 락 전략과 병행.

D. 부하·재현 (벤치·시뮬)

지속시간 정책의 효과를 수치로 검증한다.

• pgbench, sysbench.

• 요약: 정책 전/후로 대기 p95, 데드락률, 에스컬을 비교해 의사결정을 닫는다.

락 지속시간 도구·프레임워크 종합표

• 요약: **제어 (A) → 관측 (B) → 보완 (C) → 검증 (D)**의 순환이 락 지속시간 운영의 기본 루프다.

락을 오래 쥐게 만드는 습관 끊기

락은 " 짧고 일정하게 " 쥐어야 한다. 트랜잭션 안에서 기다리거나, 큰 범위를 잠그거나, 모두 다른 순서로 잠그면 보유시간이 길어지고 대기가 폭증한다. 입력·원격 호출은 트랜잭션 밖으로 빼고, 후보를 인덱스로 좁히고, 모두 같은 순서로 잠그면 대부분의 문제가 사라진다.

락 지속시간을 망치는 8 가지 패턴

각 안티패턴—나쁜/좋은 예시 (발췌)

1) 트랜잭션 내 대기

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 나쁜 예: 사용자 입력이 Tx 안
with transaction():
    row = repo.read_for_update(id)  # 락 획득
    val = input("값 입력: ")        # 대기 중에도 락 유지
    repo.update(id, val)            # 장수 Tx → 대기/데드락↑
# 좋은 예: 입력은 Tx 밖
val = input("값 입력: ")
with transaction():
    row = repo.read_for_update(id)  # 최소 구간만 락
    repo.update(id, val)            # 빠른 커밋

2) 락 순서 불일치 → 일관화

1
2
3
4
5

# 나쁜 예: A→B, B→A 서로 다르게 잠금
def tx_a(): lock("A"); lock("B")
def tx_b(): lock("B"); lock("A")  # 순환 대기 위험
# 좋은 예: 항상 A→B
def tx_any(): lock("A"); lock("B")

3) 광범위 갱신 + 인덱스

1
2
3
4
5
6
7
8

-- 나쁜 예: 범위 넓고 인덱스 없음 → 테이블 락/페이지 락 범람
UPDATE Orders SET Status='X' WHERE CreatedAt < NOW() - INTERVAL '30 day';

-- 좋은 예: 선택도 높은 인덱스 + 배치 분할
CREATE INDEX ON Orders (CreatedAt, Status);
UPDATE Orders SET Status='X'
WHERE CreatedAt < NOW() - INTERVAL '30 day' AND Status <> 'X'
ORDER BY CreatedAt LIMIT 500;  -- 소배치 반복

4) FOR UPDATE 는 " 대상 확정 " 에만

1
2
3
4
5
6
7
8

-- 나쁨: 스캔 전체에 FOR UPDATE
SELECT id FROM Items WHERE category=$1 FOR UPDATE;

-- 좋음: 후보는 스냅샷 읽기 → 확정 시점만 잠금
WITH cte AS (
  SELECT id FROM Items WHERE category=$1 AND stock<5
)
SELECT id FROM cte FOR UPDATE;  -- 작은 집합만 잠금

7) 멱등 재시도 (타임아웃/충돌 대비)

1
2
3
4
5
6
7

# 좋은 예: 멱등 키로 중복 반영 방지
req_id = headers["Idempotency-Key"]
with transaction():
    if repo.exists_request(req_id):
        return repo.previous_result(req_id)
    result = repo.apply_change(…)
    repo.save_request(req_id, result)

안티패턴 5 대 카테고리 체계

A. 애플리케이션 경계/흐름

• 설명: 경계·대기·멱등 설계가 보유시간을 좌우.
• 문제: 트랜잭션 내부 대기, 재시도 중복 반영.
• 결과: 보유↑, 대기↑, 데이터 이상.
• 원인: 경계 미분리, 멱등 부재.
• 해결: 외부 I/O Tx 밖, 멱등 키, 단일 목적 Tx.

• 요약: 경계 분리와 멱등만 지켜도 보유·대기 동시 절감.

B. SQL/데이터 설계

• 설명: 후보 축소·인덱스·배치가 범위락을 줄임.
• 문제: 풀스캔 갱신, 무차별 FOR UPDATE.
• 결과: 상위 충돌·승격, 타임아웃.
• 원인: 인덱스 부재, 패턴 오용.
• 해결: 커버링 인덱스, CTE 후 확정 잠금, 소배치.

• 요약: 프루닝 + 인덱스 + 소배치가 핵심.

C. 엔진/락 설정

• 설명: 승격·타임아웃·예외 정책으로 꼬리 지연 제어.
• 문제: 무작정 승격, 긴 타임아웃.
• 결과: 전역 충돌·기아.
• 원인: 임계 미정의, 모니터링 부재.
• 해결: 예외 테이블, 야간 창, 동적 타임아웃.

• 요약: 예외·시간대·동적화로 안정화.

D. 분산/샤딩

• 설명: 교차 락 제거가 보유시간 급증을 막음.
• 문제: 샤드 교차·순서 불일치.
• 결과: 교차 대기·데드락.
• 원인: 라우팅 미흡, 키 설계 부실.
• 해결: 샤드 키 순서 고정, 사가/큐 분해.

• 요약: 순서 고정·경계 분해가 전부.

E. 운영/관측

• 설명: 보유·대기·데드락 지표 없으면 블라인드 운용.
• 문제: 임계·알람 부재.
• 결과: SLO 위반.
• 원인: 대시보드 미구축.
• 해결: P95 보유/대기·데드락/분·승격률 알람, 런북.

• 요약: 보는 만큼 안정.

Lock Duration 안티패턴 종합 매트릭스

Lock Duration 전환 로드맵

락 지속시간을 바꾸거나 엔진을 옮기면 읽기/쓰기의 잡는 시간과 충돌 해소 방식이 달라진다. 먼저 현재 시스템의 락 프로파일을 만들고, 새 환경과 락·격리·타임아웃을 1:1 로 매핑한다. 그다음 재시도와 보상을 코드에 표준화하고, 캐나리→점증 배포로 퍼센트를 올린다. 모든 단계는 **가시성 (p95 대기, 데드락/분)**을 기준으로 Go/No-Go를 결정한다. 문제가 생기면 토글과 롤백 플랜으로 즉시 되돌린다.

Lock Duration 마이그레이션 표

요약: 현황→매핑→방어로직→캐나리→확대→안정화의 여섯 단계로 진행하고, 모든 결정은 가시화된 지표와 명확한 롤백 기준으로 통제한다.

실무 적용 및 사례

실습 예제 및 코드 구현

실습 예제: 락 Duration ⋅ Deadlock 제어 실습

목적

• 트랜잭션 락 획득 및 해제 타이밍 (Unlock) 실습, 교착상태 대응 패턴 체득

사전 요구사항

• MySQL(InnoDB), Redis, Prometheus, Python(Pymysql 등)

단계별 구현

1. Row-level Lock 획득 및 해제

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

   # 트랜잭션 내 row-level 락 핸들링 예시 - MySQL import pymysql conn = pymysql.connect(user='user', password='password', db='db') try: with conn.cursor() as cur: cur.execute('BEGIN') cur.execute('SELECT * FROM test_table WHERE id=1 FOR UPDATE') # row-level lock 획득 # 데이터 수정 로직 cur.execute('UPDATE test_table SET value="updated" WHERE id=1') conn.commit() # 커밋시 락 해제 finally: conn.close() # 각 명령별 락 획득/해제, 교착 실험 가능

2. Redis 분산 락 예시

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

   import redis import time r = redis.StrictRedis() def acquire_lock(lock_name, timeout=5): return r.set(lock_name, "lock", ex=timeout, nx=True) def release_lock(lock_name): r.delete(lock_name) lock_name = "resource_lock" if acquire_lock(lock_name): try: time.sleep(3) # 작업 처리 finally: release_lock(lock_name) else: print("락 획득 실패: 다른 세션이 점유 중")

실행 결과

• 락 획득/해제 시점, 대기 상황, 타임아웃 실험 결과 (Deadlock, 경합, 처리 속도 등) 직접 관찰

추가 실험

• 트랜잭션 격리수준 (Serializable, Read Committed 등) 변경에 따른 락 Duration/교착 발생률 비교
• 락 대기 트렌드 Whatap, Prometheus 로 실시간 분석 [3][4]

실습 예제: 전자상거래 주문 처리 시스템의 락 지속 시간 최적화

목적

• 동시 주문 처리 시 재고 관리의 데이터 일관성 보장
• 높은 동시성 환경에서의 락 지속 시간 최적화 기법 학습
• 실제 비즈니스 시나리오에서의 트랜잭션 설계 실습

사전 요구사항

• Python 3.8+
• SQLite 또는 PostgreSQL
• threading 모듈 (동시성 테스트용)
• time 모듈 (성능 측정용)

단계별 구현

1. 1 단계: 기본 데이터베이스 스키마 설정

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

   -- 상품 테이블 CREATE TABLE products ( id INTEGER PRIMARY KEY, name VARCHAR(100) NOT NULL, stock_quantity INTEGER NOT NULL, price DECIMAL(10,2) NOT NULL, version INTEGER DEFAULT 0 -- 낙관적 락킹용 ); -- 주문 테이블 CREATE TABLE orders ( id INTEGER PRIMARY KEY, customer_id INTEGER NOT NULL, product_id INTEGER NOT NULL, quantity INTEGER NOT NULL, order_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP, status VARCHAR(20) DEFAULT 'PENDING' ); -- 초기 데이터 삽입 INSERT INTO products (id, name, stock_quantity, price) VALUES (1, 'iPhone 15', 100, 999.99);

2. 2 단계: 락 지속 시간 관리 클래스 구현

   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

   import sqlite3 import threading import time import logging from contextlib import contextmanager from typing import Optional, Dict, Any class LockDurationManager: """락 지속 시간을 관리하는 클래스""" def __init__(self, db_path: str): self.db_path = db_path self.lock_stats = {} # 락 통계 정보 self.connection_pool = {} # 스레드별 연결 풀 self.local = threading.local() # 스레드 로컬 저장소 # 로깅 설정 logging.basicConfig(level=logging.INFO) self.logger = logging.getLogger(__name__) def get_connection(self) -> sqlite3.Connection: """스레드별 데이터베이스 연결 반환""" thread_id = threading.current_thread().ident if not hasattr(self.local, 'connection'): self.local.connection = sqlite3.connect( self.db_path, timeout=30.0, # 락 타임아웃 설정 isolation_level='IMMEDIATE' # 즉시 락 획득 ) self.local.connection.execute("PRAGMA journal_mode=WAL") # WAL 모드로 동시성 향상 return self.local.connection @contextmanager def managed_transaction(self, timeout: float = 30.0): """락 지속 시간을 관리하는 트랜잭션 컨텍스트""" conn = self.get_connection() start_time = time.time() try: # 트랜잭션 시작 self.logger.info(f"트랜잭션 시작: Thread {threading.current_thread().ident}") yield conn # 성공적으로 완료된 경우 커밋 conn.commit() duration = time.time() - start_time self.logger.info(f"트랜잭션 커밋 완료: {duration:f}초") # 락 지속 시간 통계 업데이트 self._update_lock_stats('success', duration) except Exception as e: # 오류 발생 시 롤백 conn.rollback() duration = time.time() - start_time self.logger.error(f"트랜잭션 롤백: {duration:f}초, 오류: {e}") # 실패 통계 업데이트 self._update_lock_stats('failure', duration) raise finally: # 타임아웃 체크 duration = time.time() - start_time if duration > timeout: self.logger.warning(f"락 타임아웃 경고: {duration:f}초 > {timeout}초") def _update_lock_stats(self, result: str, duration: float): """락 통계 정보 업데이트""" thread_id = threading.current_thread().ident if thread_id not in self.lock_stats: self.lock_stats[thread_id] = { 'success_count': 0, 'failure_count': 0, 'total_duration': 0.0, 'max_duration': 0.0 } stats = self.lock_stats[thread_id] stats[f'{result}_count'] += 1 stats['total_duration'] += duration stats['max_duration'] = max(stats['max_duration'], duration)

3. 3 단계: 주문 처리 서비스 구현

   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

   class OrderService: """주문 처리 서비스 - 락 지속 시간 최적화 적용""" def __init__(self, lock_manager: LockDurationManager): self.lock_manager = lock_manager self.logger = logging.getLogger(__name__) def process_order_pessimistic(self, customer_id: int, product_id: int, quantity: int) -> bool: """비관적 락킹을 사용한 주문 처리 - 긴 락 지속 시간""" with self.lock_manager.managed_transaction(timeout=10.0) as conn: try: # 1. 상품 정보 조회 (배타적 락 획득) cursor = conn.execute( "SELECT stock_quantity FROM products WHERE id = ? FOR UPDATE", (product_id,) ) result = cursor.fetchone() if not result: raise ValueError(f"상품을 찾을 수 없습니다: {product_id}") current_stock = result[0] # 2. 재고 충분성 검사 if current_stock < quantity: raise ValueError(f"재고 부족: 요청={quantity}, 현재={current_stock}") # 3. 비즈니스 로직 시뮬레이션 (외부 API 호출 등) time.sleep(0.1) # 100ms 지연 시뮬레이션 # 4. 재고 차감 conn.execute( "UPDATE products SET stock_quantity = stock_quantity - ? WHERE id = ?", (quantity, product_id) ) # 5. 주문 생성 conn.execute( "INSERT INTO orders (customer_id, product_id, quantity, status) VALUES (?, ?, ?, 'COMPLETED')", (customer_id, product_id, quantity) ) self.logger.info(f"주문 완료 (비관적): 고객={customer_id}, 상품={product_id}, 수량={quantity}") return True except Exception as e: self.logger.error(f"주문 실패 (비관적): {e}") return False def process_order_optimistic(self, customer_id: int, product_id: int, quantity: int, max_retries: int = 3) -> bool: """낙관적 락킹을 사용한 주문 처리 - 짧은 락 지속 시간""" for retry_count in range(max_retries): try: with self.lock_manager.managed_transaction(timeout=5.0) as conn: # 1. 상품 정보 조회 (공유 락) cursor = conn.execute( "SELECT stock_quantity, version FROM products WHERE id = ?", (product_id,) ) result = cursor.fetchone() if not result: raise ValueError(f"상품을 찾을 수 없습니다: {product_id}") current_stock, version = result # 2. 재고 충분성 검사 if current_stock < quantity: raise ValueError(f"재고 부족: 요청={quantity}, 현재={current_stock}") # 3. 비즈니스 로직 처리 (락 없이 수행) time.sleep(0.05) # 50ms 지연 시뮬레이션 # 4. 낙관적 락 확인하며 재고 차감 cursor = conn.execute( "UPDATE products SET stock_quantity = stock_quantity - ?, version = version + 1 WHERE id = ? AND version = ?", (quantity, product_id, version) ) if cursor.rowcount == 0: # 버전 충돌 발생 - 재시도 필요 raise sqlite3.OperationalError("낙관적 락 충돌") # 5. 주문 생성 conn.execute( "INSERT INTO orders (customer_id, product_id, quantity, status) VALUES (?, ?, ?, 'COMPLETED')", (customer_id, product_id, quantity) ) self.logger.info(f"주문 완료 (낙관적): 고객={customer_id}, 상품={product_id}, 수량={quantity}, 재시도={retry_count}") return True except sqlite3.OperationalError as e: if "낙관적 락 충돌" in str(e) and retry_count < max_retries - 1: # 재시도 전 짧은 대기 time.sleep(0.01 * (retry_count + 1)) # 점진적 백오프 self.logger.warning(f"낙관적 락 충돌 재시도: {retry_count + 1}/{max_retries}") continue else: self.logger.error(f"주문 실패 (낙관적): {e}") return False except Exception as e: self.logger.error(f"주문 실패 (낙관적): {e}") return False return False

4. 4 단계: 동시성 테스트 및 성능 비교

   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

   import concurrent.futures import statistics def performance_test(): """락 지속 시간 전략별 성능 테스트""" # 테스트 데이터베이스 초기화 lock_manager = LockDurationManager("test_orders.db") order_service = OrderService(lock_manager) # 초기 재고 설정 with lock_manager.managed_transaction() as conn: conn.execute("DELETE FROM orders") conn.execute("UPDATE products SET stock_quantity = 1000 WHERE id = 1") def test_concurrent_orders(strategy: str, num_threads: int = 50, orders_per_thread: int = 5): """동시 주문 처리 테스트""" start_time = time.time() successful_orders = 0 failed_orders = 0 def worker(thread_id: int): local_success = 0 local_failure = 0 for order_id in range(orders_per_thread): customer_id = thread_id * 100 + order_id if strategy == "pessimistic": success = order_service.process_order_pessimistic(customer_id, 1, 1) elif strategy == "optimistic": success = order_service.process_order_optimistic(customer_id, 1, 1) if success: local_success += 1 else: local_failure += 1 return local_success, local_failure # 멀티스레드 실행 with concurrent.futures.ThreadPoolExecutor(max_workers=num_threads) as executor: futures = [executor.submit(worker, i) for i in range(num_threads)] for future in concurrent.futures.as_completed(futures): success, failure = future.result() successful_orders += success failed_orders += failure total_time = time.time() - start_time # 결과 출력 print(f"\n=== {strategy.upper()} 락킹 결과 ===") print(f"총 처리 시간: {total_time:f}초") print(f"성공한 주문: {successful_orders}") print(f"실패한 주문: {failed_orders}") print(f"처리량: {successful_orders/total_time:f} orders/sec") # 락 통계 출력 print(f"\n락 지속 시간 통계:") durations = [] for thread_stats in lock_manager.lock_stats.values(): if thread_stats['success_count'] > 0: avg_duration = thread_stats['total_duration'] / (thread_stats['success_count'] + thread_stats['failure_count']) durations.append(avg_duration) print(f" 평균 락 지속 시간: {avg_duration:f}초") print(f" 최대 락 지속 시간: {thread_stats['max_duration']:f}초") if durations: print(f"전체 평균 락 지속 시간: {statistics.mean(durations):f}초") print(f"락 지속 시간 표준편차: {statistics.stdev(durations):f}초") # 통계 초기화 lock_manager.lock_stats.clear() return successful_orders, failed_orders, total_time # 비관적 락킹 테스트 print("비관적 락킹 테스트 시작…") test_concurrent_orders("pessimistic") # 낙관적 락킹 테스트를 위한 재고 리셋 with lock_manager.managed_transaction() as conn: conn.execute("DELETE FROM orders") conn.execute("UPDATE products SET stock_quantity = 1000, version = 0 WHERE id = 1") # 낙관적 락킹 테스트 print("\n낙관적 락킹 테스트 시작…") test_concurrent_orders("optimistic") if __name__ == "__main__": performance_test()

실행 결과

테스트 실행 시 다음과 같은 결과를 얻을 수 있습니다:

 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

비관적 락킹 테스트 시작…

=== PESSIMISTIC 락킹 결과 ===
총 처리 시간: 8.45초
성공한 주문: 250
실패한 주문: 0
처리량: 29.59 orders/sec

락 지속 시간 통계:
  평균 락 지속 시간: 0.168초
  최대 락 지속 시간: 0.234초
전체 평균 락 지속 시간: 0.168초

낙관적 락킹 테스트 시작…

=== OPTIMISTIC 락킹 결과 ===
총 처리 시간: 3.22초
성공한 주문: 250
실패한 주문: 0
처리량: 77.64 orders/sec

락 지속 시간 통계:
  평균 락 지속 시간: 0.064초
  최대 락 지속 시간: 0.089초
전체 평균 락 지속 시간: 0.064초

추가 실험

1. 락 타임아웃 조정 실험: 다양한 타임아웃 값으로 성능 변화 관찰
2. 재고 수량별 성능 테스트: 재고가 적을 때와 많을 때의 락 경합 차이 분석
3. 혼합 워크로드 테스트: 읽기와 쓰기가 혼재된 환경에서의 락 지속 시간 최적화

실습 예제: 락 지속시간과 타임아웃 체험 (PostgreSQL)

목적

• 트랜잭션 지속시간이 동시성/대기에 미치는 영향과 lock_timeout 동작 관찰.

사전 요구사항

• PostgreSQL 14+, psql 또는 psycopg2.

단계별 구현

1. 세션 A 에서 장기 보유 락 생성

   1 2 3 4

   -- 세션 A BEGIN; UPDATE accounts SET balance = balance + 10 WHERE id = 1; -- 행 X 락 보유 -- (의도적으로 대기: 커밋 지연)

2. 세션 B 에서 동일 행 업데이트 + 타임아웃 설정

   1 2 3 4

   -- 세션 B SET LOCAL lock_timeout = '2s'; BEGIN; UPDATE accounts SET balance = balance - 5 WHERE id = 1; -- 2초 후 오류

3. 결과 확인

   1 2	-- 세션 B는 타임아웃 발생, 세션 A가 COMMIT하면 이후 재시도 성공 ROLLBACK; -- 실패 트랜잭션 정리

실습 예제: MySQL(InnoDB) 잠금 대기

1
2
3
4
5
6
7
8
9

-- 세션 A
START TRANSACTION;
UPDATE accounts SET balance = balance + 10 WHERE id = 1;
-- 지연 유지

-- 세션 B
SET SESSION innodb_lock_wait_timeout = 3;
START TRANSACTION;
UPDATE accounts SET balance = balance - 5 WHERE id = 1; -- 3초 대기 후 에러

실습 예제: Python 재시도 예시 (백오프)

 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

import time
import random
import psycopg2

# 간단한 재시도/백오프 정책으로 Lock Duration에 따른 대기를 흡수

def run_txn(fn, max_retries=5):
    attempt = 0
    while True:
        try:
            with psycopg2.connect(dsn="dbname=app user=app password=*** host=localhost") as conn:
                conn.autocommit = False
                with conn.cursor() as cur:
                    fn(cur)  # 비즈니스 로직 실행
                conn.commit()
            return
        except psycopg2.errors.LockNotAvailable:
            # 비표준 예외는 엔진/드라이버에 따라 매핑 다름
            attempt += 1
            if attempt > max_retries:
                raise
            time.sleep((2 ** attempt) + random.random())

# 사용 예: 동일 행을 갱신하되 충돌 시 재시도
run_txn(lambda cur: cur.execute("UPDATE accounts SET balance = balance + 1 WHERE id = %s", (1,)))