Locking Protocols

Locking Protocols

잠금 프로토콜은 다중 트랜잭션 환경에서 데이터 일관성과 격리성을 보장하기 위해 자원 접근 (획득·해제) 규칙을 정의한 기술이다.
핵심 개념은 공유 (S)/배타 (X) 같은 락 모드와 락 획득·해제 시점 (예: Two-Phase Locking, 2PL) 이며, Strict 2PL 은 쓰기 락을 커밋까지 유지해 복구를 단순화한다.
현대 시스템에서는 MVCC(스냅샷 읽기) 를 통해 읽기 성능을 높이고, 낙관적 동시성 (버전 비교) 을 충돌이 적은 워크로드에 적용한다.
구현 관점에서는 락 매니저·락 테이블, 의도락 (IS/IX)·갭/넥스트키 락 등 계층·범위 제어가 중요하다.
운영상 데드락은 Wait-for 그래프 탐지·타임아웃·victim 선정으로 처리하고, 락 승격은 대량 락 상황에서 성능 저하를 유발하므로 주의해야 한다.
분산 환경에서는 ZooKeeper/etcd/Redis 기반 분산 락 (리스/펜싱 토큰) 과 메시지 기반 (Saga/CQRS) 아키텍처를 조합해 장기 트랜잭션과 글로벌 일관성을 관리한다.
설계 시에는 격리 수준, 인덱스·쿼리 범위, 트랜잭션 길이, DBMS 별 구현 차이를 고려해 성능과 정합성 사이의 적절한 균형을 맞추는 것이 관건이다.

락 프로토콜: 이론↔실무 종합정리

락은 동시에 여러 트랜잭션이 데이터에 접근할 때 누가 어떤 권한 (읽기/쓰기) 을 가질지 정하는 규칙이다.
기본 모드는 공유 (S) 와 배타 (X) 이며, 획득 순서와 해제 시점 (2PL) 이 시스템의 직렬성 보장을 좌우한다.
트랜잭션을 오래 열어두면 락을 오래 유지해 다른 세션을 막으니 짧게 설계하고 인덱스로 범위를 좁히는 것이 실무 핵심이다.
데드락 (서로 기다리는 상태) 은 자동 탐지·희생자 선정 또는 예방 기법으로 해결한다.
MVCC 는 읽기 성능을 높여 주지만 삽입 (팬텀) 은 별도 제어가 필요하다.

핵심 개념 요약표

• 위 개념들은 트랜잭션의 일관성·성능을 설계·운영할 때 반드시 이해해야 할 핵심 구성요소다.
• 한 개념만으로 완전한 해법은 없고, 워크로드·서비스 요구 (SLA) 에 따라 적절한 조합이 필요하다.

개념 관계: 목적·메커니즘 중심

• 방향은 " 무엇을 위해 “(목적) 과 " 어떻게 “(메커니즘) 를 함께 보여준다.
  예: MVCC 는 읽기 충돌을 줄이려 도입되지만 특정 케이스 (팬텀) 는 락으로 보완한다.

실무 적용 매핑표

• 실무 적용은 " 무엇을 해결하려는가 " 와 " 어떤 메커니즘으로 " 를 명확히 매핑해야 한다.
• 동일 문제 (예: 팬텀) 는 DB 별로 다른 도구 (range/gap/predicate) 로 해결되므로 DB 특성 반영 필수.

기초 조사 및 개념 정립

락킹 프로토콜의 정의와 본질

1. 왜 필요한가?
   여러 사용자가 동시에 데이터에 접근하면 결과가 엉킬 수 있다 → 락으로 순서를 만들고 충돌을 막는다.

2. 무엇을 하는가?
   트랜잭션이 읽거나 쓰기 전에 적절한 락을 걸고, 작업 끝나면 락을 풀어 다른 트랜잭션이 접근할 수 있게 한다.

3. 중요한 개념 세 개

   • 공유 (S): 여러 트랜잭션이 동시에 읽을 수 있음.
   • 배타 (X): 단독으로 쓰기 (또는 읽기 제외) 허용.
   • 2PL: 락을 얻는 단계와 푸는 단계를 분리해 직렬성 보장.

4. 현실적 문제와 대책

   • 데드락 → 일관된 잠금 순서/타임아웃/재시도
   • 성능 저하 → 작은 그레인·MVCC·쿼리/인덱스 튜닝
   • 분산 리소스 → 합의 기반 분산락 도입

락킹 프로토콜은 트랜잭션이 데이터 항목에 접근하기 위해 따르는 규칙 모음으로, 어떤 락을 언제 획득하고 언제 해제할지, 그리고 서로 다른 락 모드 간 호환성 규칙을 정의한다. 이 규칙을 통해 DB 는 트랜잭션 간 상호작용이 마치 순차적으로 실행된 것처럼 보이게 하여 데이터 일관성과 무결성을 유지한다.

본질적 이해 (요점)

• 목표: 직렬성 (Serializability) 과 복구 가능성 (Recoverability) 을 확보하면서 가능한 한 많은 동시성을 허용해 시스템 처리량을 높이는 것.
• 수단: 락 모드·그레인·획득/해제 타이밍 (예: 2PL), 그리고 필요시 버전 (MVCC) 이나 분산 합의로 보완.
• 트레이드오프: 강한 일관성은 동시성 손실을, 높은 동시성은 일관성 위험 (또는 추가 복잡도) 을 초래한다.

락 프로토콜의 등장과 진화사

데이터베이스에서 여러 트랜잭션이 동시에 같은 데이터를 다루면 충돌과 불일성이 생긴다.
처음엔 공유 (S) 와 전용 (X) 같은 단순한 락으로 문제를 막았고, 이걸 규칙 (2PL) 으로 묶어 직렬성을 보장했다.
이후엔 성능을 위해 락의 크기를 세분화 (테이블→레코드) 하고, 의도 락으로 검사 비용을 줄였다.
팬텀 문제는 범위 잠금으로 대응했고, 읽기 성능을 극대화하려 MVCC(스냅샷) 같은 비락 기법이 나왔다.
마지막에는 분산 환경에 맞춘 분산 락·샤딩 방식으로 확장성을 확보하게 되었다.

등장 배경

초기 다중 사용자 데이터베이스에서는 여러 트랜잭션이 동일 데이터에 동시 접근하면서 경쟁 조건, 갱신 손실 (Lost Update), 더티 리드 (Dirty Read), 반복 불가능한 읽기 (Non-repeatable Read), 팬텀 (Phantom Read) 같은 문제가 빈번히 발생했다.
이러한 문제를 해결하고 데이터 무결성과 직렬가능성 (Serializability) 을 보장하기 위해 락 프로토콜 (lock protocols) 이 도입되었다.
초기에는 단순한 공유/전용 락 모델로 시작했지만, 실무적 성능·동시성 요구가 커지면서 락의 형태와 제어 기법이 점진적으로 발전해 왔다.

발전 과정

timeline
    title 락 프로토콜 발전 타임라인
    1970s : 관계형 DB 등장 및 S/X, 2PL 개념 정립
    1976 : Predicate locks(팬텀 문제 이론화)
    1980s : 그레뉼러리티·Intent locks 연구·도입
    1990s : Key-range / Next-key 락, 인덱스 동시성 최적화
    1980s-2000s : MVCC 실무 적용 및 상용화(스냅샷)
    2000s~ : 하이브리드·분산 락/샤딩 설계 확산

1970 년대에는 관계형 모델과 함께 S/X 락과 2PL 같은 기초 기법이 도입되어 직렬성의 이론적 기반을 마련했다.
1976 년 전후에는 팬텀 문제를 지적하는 연구들이 등장했고, 이후로는 실제 시스템에서 이를 해결하기 위한 key-range·next-key 락과 같은 인덱스 기반 기법이 개발되었다.
1980 년대1990 년대에는 락 그레뉼러리티 문제 해결을 위해 의도 락과 계층적 잠금이 도입되어 상위·하위 락의 상호작용을 효율화했다.
1980s 후반2000 년대에는 MVCC(스냅샷) 기법이 실무에 정착되어 읽기 블로킹 문제를 크게 완화했으며, 2000 년대 이후에는 분산·클라우드 환경을 고려한 하이브리드 및 분산 락 설계가 확산되었다.
각 단계는 ’ 어떤 문제를 해결하려고 했는가 ’ 와 ’ 그 해결책이 어떤 성능·정합성 트레이드오프를 가져왔는가 ’ 를 기준으로 이해해야 실무 적용 시 혼선을 줄일 수 있다.

락 프로토콜의 문제·목적·해결 매핑

락 프로토콜은 여러 트랜잭션이 동시에 데이터에 접근할 때 **일관성 (같은 결과가 나오도록)**과 **안전한 복구 (롤백 시 피해 최소화)**를 보장하기 위해 도입한다.
기본 아이디어는 ’ 누군가 쓰기를 할 때는 다른 사람이 못 보게 한다 ’ 는 것인데, 이것을 시스템적으로 관리하는 규칙이 2PL·Strict 2PL 등 락 프로토콜이다.
팬텀 (범위 삽입) 문제는 범위 단위 락으로 막고, 데드락은 탐지하거나 예방하는 정책으로 처리한다.
성능을 위해서는 락의 세분성, 의도 락, 또는 MVCC 같은 대안기법을 적절히 조합한다.

락 프로토콜이 해결하는 문제

락 프로토콜은 충돌 유형별로 적절한 락/전략을 매핑해 직렬가능성과 무결성을 보장한다. 각 기법은 보장성 (안전) 과 성능 (동시성) 사이의 균형점을 다르게 설정한다.

락 프로토콜의 핵심 목적

각 목적은 상호 보완적이지만 때로 상충한다 (예: 직렬성 강화는 처리량 저하). 설계는 목적 우선순위에 따라 프로토콜과 정책을 선택하는 과정이다.

문제와 목적의 연계 매핑

문제별 우선 해결 목적이 명확하면 어떤 락 프로토콜·운영정책을 선택할지 결정할 수 있다. 예컨대 팬텀이 핵심이라면 범위 락과 높은 격리 수준을 채택해야 한다.

락 프로토콜 운영을 위한 필수 조건

락 프로토콜을 안정적으로 적용하려면 먼저 트랜잭션의 시작과 끝을 분명히 정의해야 한다.
어떤 단위로 락을 걸 것인지 (행, 블록, 테이블) 를 정책으로 정하고, 락 모드 간 허용 규칙 (호환성 매트릭스) 을 문서로 만들어야 운영 중 예측 가능한 블로킹·데드락 대응이 가능하다.
또한 로그 (WAL) 와 커밋 타이밍의 규칙을 정해 데이터 내구성과 락 보유 시간 간 균형을 잡고, 데드락 감지·자동 해결·모니터링 체계를 갖춰야 실서비스에서 안정적으로 동작한다.

전제조건 및 시스템 요구사항 체크리스트

핵심은 정책 (문서화)→검증 (테스트)→운영 (모니터링) 삼단계의 일관된 프로세스를 만드는 것이다. 트랜잭션 규칙·락 세분성·호환성 매트릭스·WAL 정책을 먼저 정의하고, 구현 대상 (DBMS) 별 특성에 맞춰 테스트한 뒤 운영 지표로 지속 관찰하라.

잠금 프로토콜의 기술적 특징

잠금 프로토콜은 여러 사용자 (트랜잭션) 가 동시에 데이터를 건드릴 때 충돌을 막고 결과를 예측 가능하게 만드는 규칙이다.
읽을 때는 여러 사람이 함께 보도록 공유(S) 를 걸고, 쓸 때는 다른 사람이 못 보게 배타(X) 를 건다.
언제 락을 얻고 언제 푸는지 (예: 2PL) 는 데이터 정합성의 핵심이다.
읽기 성능을 높이려면 MVCC 처럼 과거 버전을 보는 기술을 쓰고, 분산 시스템에서는 글로벌 락 (예: ZooKeeper) 이나 메시지 기반 패턴 (Saga) 을 섞어 장기 락을 피한다.

잠금 프로토콜 핵심 특성 정리`

1. 락 타입 (모드)—정확한 권한 분리

   • 근거: 호환성 매트릭스로 수학적 충돌 판정 가능 → 시스템이 결정적 행위 보장.
   • 차별점: MVCC 는 읽기 락 불필요, 하지만 쓰기 충돌은 여전히 락이나 검증 필요.

2. 세분성 (그레뉼러리티)—성능 vs 오버헤드 균형

   • 근거: 락 개수증가 → 락 테이블·관리 오버헤드 증가 → 병목 (메모리·CPU).
   • 차별점: coarse-grain 은 적은 관리비용·낮은 동시성, fine-grain 은 높은 동시성·관리비용.

3. 획득/해제 규칙 (2PL 계열)—이론적 직렬성 보장

   • 근거: 2PL 이론으로 직렬성 보장 가능 (증명 존재). Strict 2PL 은 복구 성질 강화.
   • 차별점: 낙관적/타임스탬프 방식은 직렬성/포함보장 방식이 다르고 비용 (재시도 vs 블로킹) 이 교환점.

4. 범위·갭 락—Phantom 문제 해결

   • 근거: 범위 삽입에 의한 결과변화를 물리적으로 차단하여 쿼리 일관성 유지.
   • 차별점: SSI(스냅샷 직렬화) 등은 블로킹 대신 충돌 검출로 대응 (결과: abort 가능).

5. 운영 메커니즘 (데드락/에스컬레이션)

   • 근거: 교착은 피할 수 없으므로 Wait-for 그래프 탐지·victim 선정이 필요.
   • 차별점: 낙관적 접근은 데드락 대신 충돌 발생 시 rollback/retry 전략을 취함.

잠금 프로토콜 핵심 특성 요약표

이 표는 잠금 프로토콜의 핵심 특성들과 그 근거, 그리고 MVCC·낙관적 동시성 등 대안과의 핵심 차이를 한눈에 보여준다. 설계에서는 어떤 성능·정합성 트레이드오프를 허용할지가 선택의 핵심이다.

핵심 원리 및 이론적 기반

락 설계 원칙과 철학의 실무적용

락 프로토콜 설계는 **안전성 (정확성)**과 성능 (동시성) 사이를 균형 있게 맞추는 작업이다.

세 가지 핵심 원칙은

1. 보수성—의심스러우면 차단해 데이터 일관성을 지키고,
2. 최소 권한—필요한 대상·시간만 잠가 동시성을 살리며,
3. 공정성—특정 트랜잭션이 계속 밀리지 않도록 한다.

설계 철학으로는 안전성 우선, 단순성 추구, 확장성 고려를 따르며, 실제로는 워크로드와 SLA 에 따라 이 원칙들을 적절히 조합하고 계량화된 지표 (P99 대기·데드락율 등) 로 운영해야 한다.

핵심 원칙

1. 보수성 원칙 (Conservatism Principle)

   • 설명: 잠재적 충돌 가능성이 있으면 우선 차단 (대기 또는 거부) 함으로써 데이터 일관성을 우선시한다.
   • 목적 (무엇을 위한 것): 무결성 손상·비일관 상태의 사전 예방.
   • 왜 필요한가: 분산·동시성 환경에서 작은 타이밍 차이로도 데이터 불일치가 발생하므로, 안전 쪽으로 기울여 사고 리스크를 줄여야 함.
   • 실무적 적용 예/영향: SERIALIZABLE 격리 수준, 엄격 2PL 등. 단점은 처리량 저하 → 서비스별 SLA 에 따라 완화 전략 필요.

2. 최소 권한 원칙 (Principle of Least Privilege)

   • 설명: 트랜잭션은 필요한 최소한의 락만 (대상·기간 둘 다) 획득한다.
   • 목적: 락 보유 시간과 충돌 표면 최소화로 동시성 향상.
   • 왜 필요한가: 불필요한 락은 블로킹·데드락·스루풋 저하의 직접 원인.
   • 실무적 적용 예/영향: SELECT … FOR UPDATE 를 쓰기 시점에만 사용, 트랜잭션 경계 짧게 설계, 인덱스 최적화. 자동화로 잠금 분석·리팩터링 권장.

3. 공정성 원칙 (Fairness Principle)

   • 설명: 락 획득/대기에서 기아 (starvation) 를 방지하고 가능한 한 공평한 서비스 제공을 보장한다.
   • 목적: 특정 트랜잭션의 지속적 차단 방지 → 가용성·응답성 유지.
   • 왜 필요한가: 우선순위 편향 · 반복 재시도로 인한 서비스 불균형과 SLA 위반을 막기 위함.
   • 실무적 적용 예/영향: aging(대기시간에 따른 우선순위 상승), 제한적 우선순위 정책 (비즈니스 우선 작업은 우선 처리). 공정성 강조 시 전체 처리율에 미세한 영향 존재.

락 설계 핵심 원칙 요약표

• 세 원칙은 트레이드오프 관계: 보수성↑ → 동시성↓; 최소권한으로 완화 가능.
• 실무에서는 서비스 중요도 (예: 금융 vs 로그수집) 에 따라 우선순위를 정해 적용해야 한다.

설계 철학

1. 안전성 우선 (Safety First)

   • 설명: 데이터 정확성·무결성을 가장 우선시해 시스템을 설계한다.
   • 목적: 고객 신뢰·비즈니스 규칙 준수, 규제 요건 충족.
   • 왜 필요한가: 금융·의료 등에서 잘못된 데이터 한 건이 큰 피해로 이어지므로 일관성 확보가 최우선.
   • 실무적 적용: 강한 격리·트랜잭션 로그·엄격 복구 정책 채택. 단점: 성능 희생 → 필요시 부분 완화 전략 사용.

2. 단순성 추구 (Simplicity)

   • 설명: 복잡한 잠금 로직보다 이해·운영·디버깅이 쉬운 설계를 선호한다.
   • 목적: 운영·유지보수 비용 절감, 문제 재현·해결 용이.
   • 왜 필요한가: 복잡한 정책은 버그·오해·운영사고를 유발하므로 실무에서 위험요인임.
   • 실무적 적용: 표준화된 트랜잭션 패턴·명확한 문서·자동화된 검사 도구.

3. 확장성 고려 (Scalability)

   • 설명: 대량 트래픽·데이터 규모에서도 성능을 유지하거나 선형적으로 확장 가능한 설계 지향.
   • 목적: 성장하는 서비스에서 병목으로 인한 서비스 실패 방지.
   • 왜 필요한가: 초기에는 맞아도 규모가 커지면 락 경합이 전체 시스템을 죽일 수 있으므로 설계 초기부터 확장성 고려 필요.
   • 실무적 적용: 파티셔닝·샤딩·비관적·낙관적 혼용 등 아키텍처적 선택. 상충점: 확장성 강화는 설계 복잡성 증가 가능.

락 설계 철학 요약표

• 철학은 설계 방향성을 제공: 어떤 상황에서 안전을 택할지, 언제 단순성을 희생할지, 확장성을 어느 시점에 확보할지 결정하는 기준이 된다.
• 실제 설계는 철학 간 균형을 맞추는 작업이며, 이를 위해 계량화된 목표 (SLA·임계값) 를 사전에 정의해야 한다.

락 기본 동작과 운영 메커니즘

• 트랜잭션이 데이터를 읽거나 쓰려면 락을 먼저 요청한다. 락 매니저는 현재 보유 락과의 호환성을 검사해 즉시 허용하거나 대기시킨다.
• 2PL 규칙을 따르면 트랜잭션은 먼저 필요한 락을 모으고 (획득 단계), 모든 연산이 끝난 뒤 락을 푼다 (해제 단계).
• 문제 상황: 동시에 여러 트랜잭션이 충돌하면 대기·데드락이 발생한다. 이를 잡기 위해 대기 큐 정책, 데드락 탐지 (그래프), 타임아웃/재시도 같은 운영 장치가 필요하다.
• 요약: 기본은 " 요청 → 검사 → 부여/대기 → 해제 " 의 단순 루프지만, 실제는 승격/에스컬레이션·범위락·분산 이슈로 복잡해진다.

락 기본 메커니즘

1. 락 라이프사이클

   • 요청 (Request) → 호환성 검사 (Check) → Granted/Blocked → (대기 중) Wakeup → 사용 (Access) → 해제 (Release).
   • 락은 단일 자원 (행) 뿐 아니라 계층 (테이블/페이지/행) 에서 관리된다. Intent 락은 계층적 충돌 판단을 돕는다.

2. 2 단계 락킹 (2PL) 이 제공하는 보장

   • 모든 트랜잭션이 2PL 을 따를 때 스케줄은 직렬화 가능. Strict 2PL 은 회복성을 보강 (쓰기 락을 커밋까지 유지).

3. 락 모드 전환 (U → X 등)

   • 읽기 후 쓰기 상황에서 U(업데이트) 락을 먼저 잡아 데드락 가능성 감소. 승격 시 호환성 재평가 필요.

4. 데드락 탐지 vs 예방

   • 탐지: wait-for 그래프에서 사이클 찾고 희생자 선정.
   • 예방: 자원 획득 순서 강제, 타임아웃, 또는 낙관적 동시성 사용.

5. 운영 고려사항

   • 배치·대량 작업은 에스컬레이션을 유발하므로 분할·파티셔닝 권장.
   • 모니터링 (락 대기시간, wait chains) 과 알림은 운영 안정성 핵심.

락 기본 메커니즘 요약표

기본 동작은 단순하지만, 운영 환경에서는 락 승격·범위 락·데드락 탐지·대기 정책 등 다양한 메커니즘이 서로 얽혀 시스템 거동을 결정한다. 각 항목은 성능·안정성 사이 트레이드오프를 내포하므로 정책·파라미터 튜닝이 핵심이다.

락 획득 - 대기 - 해제 흐름도

sequenceDiagram
    participant T as Transaction
    participant LM as LockManager
    participant DB as Database
    participant NET as Consensus (optional)
    T->>LM: Request Lock(mode, resource)
    LM->>LM: Check compatibility
    alt Compatible
        LM-->>T: Grant Lock
        T->>DB: Operation
        T->>LM: Release or Commit
        LM-->>LM: Wakeup waiting
        opt Lock Escalation condition met
            LM->>LM: Escalate locks (row->table)
            LM-->>All: Adjust grants
        end
    else Conflict
        LM-->>T: Enqueue in WaitQueue
        LM->>LM: Start deadlock detector / timeout timer
        alt Deadlock found
            LM->>Victim: Abort victim
            LM-->>Waiting: Grant next
        else Timeout expired
            LM-->>T: Return timeout error or retry
        end
    end
    opt Distributed LM
        LM->>NET: Request consensus for grant/lease
        NET-->>LM: Grant/Reject based on quorum
    end

• 트랜잭션은 락 매니저에 모드와 자원 (행/테이블/키) 을 요청한다.
• 락 매니저는 호환성 검사를 먼저 수행한다. 호환되면 즉시 부여, 충돌이면 대기 큐에 넣는다.
• 대기 큐에 들어가면 데드락 탐지(wait-for 그래프) 와 타임아웃 타이머가 병행으로 동작한다. 데드락이 발견되면 희생자를 골라 롤백하고 락을 재분배한다. 타임아웃이 만료되면 트랜잭션은 오류 또는 재시도 정책에 따라 동작.
• 락 승격 (U→X) 이나 락 에스컬레이션(행→테이블) 은 별도 조건에서 발생하며, 에스컬레이션 시 동시성에 큰 영향을 준다.
• 분산 환경이면 락 부여 시 합의 (Consensus) 절차 (leader, quorum 호출) 가 추가되어 네트워크 레이턴시 영향이 중요해진다.

트랜잭션·락의 데이터·제어 흐름 총괄

트랜잭션은 데이터에 접근하기 전에 락을 요청하고, 락 관리자는 현재 이미 걸린 락들과의 호환성을 검사해 즉시 허용하거나 대기시킨다.
트랜잭션이 길게 유지되면 다른 트랜잭션이 기다리게 되고, 서로 기다리는 상황이 원형으로 이어지면 데드락이 발생한다.
데드락은 그래프 기반으로 탐지하여 한 트랜잭션을 희생자로 선택해 롤백함으로써 풀린다.
읽기는 보통 Shared 락을, 쓰기는 Exclusive 락을 요구하며, 많은 행을 잠그면 시스템이 자동으로 락 에스컬레이션(행→페이지→테이블) 을 해 성능에 영향을 미친다.
MVCC 를 사용하는 DB 는 읽기 작업을 스냅샷으로 처리해 읽기 - 쓰기 충돌을 피하기도 한다.

데이터·제어 흐름: 트랜잭션과 락

• 요청 단계: 트랜잭션이 리소스 접근 시 LOCK_REQ(mode, resource) 를 락 관리자에 보냄.
• 검사 단계: 락 관리자는 Lock Table 에서 해당 리소스의 현재 보유 목록을 조회하고 Compatibility Matrix(요청모드 × 보유모드) 를 참조.
• 결정 단계:
  • 허용 (GRANT): 락 테이블에 요청 트랜잭션을 추가 (보유 목록 갱신) → 트랜잭션 진행.
  • 대기 (QUEUE): 대기 큐에 삽입 → wait-for 그래프에 에지 추가 → 데드락 탐지 대상.
• 실행 단계: 트랜잭션은 읽기/쓰기 작업 수행. 쓰기 로그 (undo/redo) 관리와 함께 변경을 준비.
• 완료 단계: COMMIT 시 쓰기 변경을 확정 (로그 flush 등) → 락 해제 (Strict 2PL 이면 커밋 시점까지 유지) → 해제된 리소스에 대해 대기 큐 재검사 및 다음 후보 GRANT. ROLLBACK 시 undo 처리 후 락 해제.
• 운영 요소: lock escalation, lock conversion, timeout 정책, deadlock detector(주기적/이벤트), 모니터링 (대기 통계, deadlock graphs), MVCC 분기 (읽기는 스냅샷 경로로 처리).

트랜잭션 - 락 단계별 제어 표

• 트랜잭션은 락 요청 → 락 관리자의 호환성 판단 → (GRANT/QUEUE) → 실행 → 커밋/롤백 시 락 해제의 순으로 흐른다. 운영에서는 대기 시간, 데드락 빈도, 에스컬레이션 발생 빈도를 핵심 지표로 삼아 튜닝한다.

락 요청·결정·해제 전체 흐름도

flowchart TD
  subgraph TX [트랜잭션 측]
    T1[BEGIN TRANSACTION] --> Req["LOCK_REQ(mode, resource)"]
    Req --> WaitCheck
    Exec[Execute Read/Write] --> Commit[COMMIT/ROLLBACK]
  end

  subgraph LM [Lock Manager]
    WaitCheck{호환성 검사} -->|허용| Grant[GRANT -> 보유목록 갱신]
    WaitCheck -->|불허| Queue[대기큐 삽입 -> wait-for 그래프 업데이트]
    Queue --> DeadDetect[데드락 탐지기]
    DeadDetect -->|사이클| Victim[희생자 선정 -> ROLLBACK 신호]
    Grant --> Signal[락 해제 시 신호 -> 대기큐 재검사]
    Signal --> WaitCheck
    Grant --> Exec
  end

  Commit -->|락 해제| Signal
  Victim -->|롤백 신호| Rollback[트랜잭션 롤백]
  Rollback --> Signal

  subgraph Ops [운영 요소]
    Metrics[대기 통계/Deadlock 로그] --> LM
    Escalation[Lock Escalation 임계치] --> LM
    Timeout[Lock Timeout 정책] --> LM
  end

• 트랜잭션은 락 요청을 보내고 락 관리자는 호환성 검사로 즉시 허용 또는 대기시킨다. 대기된 트랜잭션은 wait-for 그래프에 반영되어 데드락 탐지기의 주기 검사 대상이 된다. 데드락 시 희생자가 선정되어 롤백 신호가 전달되고, 롤백 후 락이 해제되어 대기 큐의 다음 후보가 재검사된다. 운영 요소 (메트릭, 에스컬레이션 임계치, 타임아웃) 는 Lock Manager 의 정책에 직접 영향을 미친다. MVCC 환경에서는 읽기 경로가 스냅샷으로 분기되어 읽기 락을 회피한다.

트랜잭션 생명주기와 락 상태 전이

stateDiagram-v2
  [*] --> Active: BEGIN TRANSACTION
  Active --> Waiting: LOCK_REQ -> QUEUE (대기중)
  Active --> Executing: LOCK_GRANTED -> Execute
  Executing --> PartiallyCommitted: COMMIT (로그 flush)
  PartiallyCommitted --> Committed: 락 해제 완료
  Active --> Failed: 오류 발생
  Failed --> Aborted: ROLLBACK (undo)
  Aborted --> [*]: 정리 완료
  Committed --> [*]: 정리 완료

• Active 상태에서 락이 즉시 허용되면 Executing 으로 가서 실제 작업을 수행한다. 락이 허용되지 않으면 Waiting 상태로 들어가며, 이때 타임아웃 또는 데드락 탐지로 롤백될 수 있다. COMMIT 시 필요한 작업 (로그 flush) 이 수행되고 락이 해제되면서 PartiallyCommitted→Committed 로 전이된다. MVCC 가 적용된 읽기 트랜잭션은 Waiting 을 거치지 않고 스냅샷을 사용해 바로 Executing 으로 진입하는 점이 핵심 차이이다.

운영·성능을 고려한 락 시스템 아키텍처

락 시스템은 트랜잭션이 데이터에 접근하려 할 때 " 누가, 어떤 권한으로, 얼마나 오래 " 그 자원을 점유하는지를 중앙에서 관리한다. Lock Manager 가 요청을 받고 Compatibility Matrix 로 판단한 뒤 허용되면 Lock Table(LCB) 에 기록, 거부되면 Wait Queue 에 넣는다. 대기 중인 트랜잭션들이 서로 순환하면 Waits-For Graph 를 통해 Deadlock Detector 가 이를 찾아 희생자를 고른다. 에스컬레이션은 많은 작은 락을 하나로 합쳐 메모리·관리부담을 줄이지만 동시성은 떨어뜨린다. 운영자는 Monitoring 을 통해 대기·데드락·에스컬레이션 지표를 상시 관찰해야 한다.

안정적 락 구조 설계 원칙

• 트랜잭션 → Lock 요청 → Lock Manager → Lock Table(허용/거부) → Wait Queue(대기) → Deadlock Detector(사이클 탐지) → Transaction Manager(롤백/복구). Monitoring 은 전체를 관찰한다.

락 구조별 역할·기능 요약

각 구조 요소는 역할이 분명하며 상호작용을 통해 락 획득·대기·복구 흐름을 만든다. 설계 시 내부 동시성·메모리·탐지 정책 세부 튜닝이 전체 성능을 좌우한다.

구조별 설계·운영 고려사항

설계 단계에서 각 구조 요소의 내부 구현 방식과 운영 지표를 미리 정하면 장애 대응·튜닝 속도가 빨라진다.

락 시스템 상호작용 구조도

flowchart TB
  subgraph AppLayer
    TM[Transaction Manager]
    QP[Query Processor]
  end

  subgraph ConcurrencyLayer
    LM[Lock Manager]
    CM[Compatibility Matrix]
    IH[Intent Handler]
    LT[Lock Table]
    LCB[Lock Control Block]
    WQ[Wait Queue]
    WFG[Waits-For Graph]
    DD[Deadlock Detector]
    EC[Escalation Controller]
  end

  subgraph StorageLayer
    BM[Buffer Manager]
    LG[Log Manager]
    SE[Storage Engine]
  end

  subgraph Monitoring
    MET[Metrics Collector]
    DASH[Dashboard/Alerts]
  end

  TM -->|lock request| LM
  QP -->|lock request| LM
  LM --> CM
  LM --> IH
  LM --> LT
  LT --> LCB
  LCB --> WQ
  WQ --> WFG
  WFG --> DD
  LM --> EC
  LM --> BM
  BM --> SE
  LG --> SE
  LT --> MET
  WQ --> MET
  DD --> MET
  MET --> DASH

• 트랜잭션/쿼리 계층이 Lock Manager 에 요청을 보낸다.
• Lock Manager 는 Compatibility Matrix 와 Intent Handler 로 판정 후 Lock Table(LCB) 에 기록하거나 Wait Queue 에 등록한다. Wait Queue 변경은 Waits-For Graph 를 갱신하며 Deadlock Detector 가 이를 검사한다. Escalation Controller 는 필요 시 Lock Table 의 여러 LCB 를 합쳐 상위 락으로 전환한다. Monitoring 계층은 Lock Table/Wait Queue/Deadlock 이벤트를 수집해 Dashboard 로 노출한다.

운영 중심 락 구성요소 속성

• Lock Table: " 누가 어떤 자원을 점유 중인지 " 를 기록하는 테이블.
• LCB: 각 자원 한 줄 (레코드) 의 메타데이터 (소유자·대기자 등).
• Wait Queue: 권한을 못 받은 요청들이 줄 서는 곳.
• Deadlock Detector: 서로 기다리는 순환을 찾아 해결사 (희생자) 를 고른다.
• Escalation Controller: 많은 작은 락을 합쳐 관리 부담 줄이는 역할.
• Compatibility Matrix: 어떤 모드끼리 공존 가능한지 적힌 표.
• Monitoring: 운영자가 상황을 보는 창.

구성요소 상세 속성표

구성 요소들은 필수적 요소와 권장 요소로 구분되며, Lock Manager 와 Lock Table 을 중심으로 Wait Queue·Deadlock Detector 가 문제 감지/해결 루프를 형성한다. Escalation Controller 와 Monitoring 은 운영 안정성·가시성에 필수적이다.

구성요소 운영·보안 고려표

운영/보안/확장성 요소는 설계 초기부터 고려해야 하며, 특히 분산 환경에서는 Lock Table/Deadlock Detector 의 분산 합의·합병 전략이 중요하다.

구성요소 상호작용 구성도

graph LR
  TM[Transaction Manager]
  LM[Lock Manager]
  LT[Lock Table]
  LCB["LCB (entries)"]
  WQ[Wait Queue]
  WFG[Waits-For Graph]
  DD[Deadlock Detector]
  EC[Escalation Controller]
  CM[Compatibility Matrix]
  IH[Intent Handler]
  MET[Metrics Collector]

  TM -->|request/release| LM
  LM --> CM
  LM --> IH
  LM --> LT
  LT --> LCB
  LCB --> WQ
  WQ --> WFG
  WFG --> DD
  LM --> EC
  LT --> MET
  WQ --> MET
  DD --> MET
  EC --> MET

• 트랜잭션은 Lock Manager 에 요청/해제를 전달한다. Lock Manager 는 Compatibility Matrix 와 Intent Handler 로 판정하여 Lock Table(LCB) 을 업데이트하거나 Wait Queue 로 보낸다. Wait Queue 는 Waits-For Graph 의 간선 정보를 생성하고 Deadlock Detector 가 이를 검사한다. Escalation Controller 는 Lock Table 의 상태를 모니터링해 에스컬레이션 수행 여부를 결정한다. 모든 핵심 이벤트는 Metrics Collector 에 집계된다.

특성 분석 및 평가

락 프로토콜의 실무적 장점 분석

락 기반 프로토콜은 트랜잭션 간 충돌을 제어해 데이터의 **정확성 (직렬성)**과 무결성을 보장하는 전통적 수단이다.
2PL 계열은 충돌을 이론적으로 막아주고, S2PL 은 복구를 단순화한다.
실무에서는 이점 (무결성·예측성·운영 가시성) 을 얻는 대신 동시성·응답성 저하라는 비용을 지불한다. 따라서 중요한 경로에는 락 기반 엄격성을 적용하고, 처리량이 민감한 경로에는 인덱스·샤딩·낙관적 기법으로 보완하는 하이브리드 전략이 일반적이다.

락 프로토콜 장점·근거·실무효과표

• 락 프로토콜은 데이터 정합성·운영 예측성을 확실히 보장해 중요한 비즈니스 로직에 필수적이다.
• 반면 동시성·성능 비용이 수반되므로 적용 범위를 엄밀히 정하고, 인덱스·파티셔닝·낙관적 기법 등으로 보완해 하이브리드 전략을 취하는 것이 실무 핵심이다.

락 프로토콜 단점·운영 제약

락은 데이터 무결성·직렬성을 보장하지만 비용이 든다. 락을 관리하려면 메모리·CPU·대기 시간이 늘어나고, 잘못 설계하면 데드락·성능 병목이 생긴다.
실무에서는
(1) 락 범위 줄이기 (인덱스·쿼리 최적화)
(2) 트랜잭션 짧게 유지 (중간 커밋/배치)
(3) 데드락 예방·탐지 정책 (자원 정렬·타임아웃·탐지)
(4) 필요 시 MVCC/낙관적 제어 또는 샤딩으로 아키텍처 전환
을 통해 문제를 완화한다.

락 프로토콜의 주요 단점 표

락은 일관성을 보장하지만 성능·확장성·가용성 측면에서 본질적 트레이드오프가 존재한다. 실무에선 인덱스·쿼리 개선, 트랜잭션 짧게 유지, 데드락 예방·탐지 정책을 우선 적용하고, 워크로드 특성에 따라 MVCC·OCC·샤딩 같은 대안으로 전환하는 것이 일반적 패턴이다.

운영 환경별 제약사항 표

환경적 제약 (메모리·실시간·분산) 은 설계 원칙을 바꿀 만큼 중요하다. 규모가 커지면 중앙 락만으로는 한계가 분명하므로, 아키텍처 단계에서 샤딩·비동기·최종합의 모델을 고려해야 한다.

3.3 트레이드오프 관계 분석

• 데이터베이스 동시성 설계는 항상 **일관성 (정확성)**과 동시성 (처리량) 사이에서 균형을 잡는 일이다.
• 강하게 잠그면 (Strict 2PL 등) 데이터는 안전하지만 동시성이 떨어지고 데드락 리스크가 커진다.
• 느슨하게 하면 (낙관적·MVCC 등) 동시성은 좋아지지만 충돌 시 재시도·버전관리 비용이 든다.
• 실무에서는 워크로드 특성에 따라 상황별/대상별 하이브리드(예: MVCC 읽기 + 특정 업데이트에만 강제 락) 를 적용해 균형을 맞춘다.

핵심 선택지별 트레이드오프 요약

• 강한 일관성이 필수면 Strict 2PL/행동 규칙을 채택하라.
• 높은 처리량과 읽기 우선 환경이면 MVCC/낙관적 기법 우선 고려.
• 데드락 정책은 비용·공정성·운영 편의성의 균형으로 결정.
• 분산환경이면 로컬 빠름 + 글로벌 합의 패턴을 권장.

락 프로토콜의 트레이드오프와 하이브리드 해법

하이브리드 기법은 단일 전략의 한계를 보완한다. 적용 전 핵심은 (1) 워크로드 프로파일링, (2) 운영·모니터링 준비, (3) 임계치·전환 규칙에 대한 실험적 검증이다.

잠금 프로토콜 적용성 판단 지침

잠금 프로토콜은 동시에 여러 사용자가 데이터를 다룰 때 ** 정확성 (무결성)** 을 보장하기 위한 도구다. 실시간 거래처럼 정확성이 최우선이면 락 기반 (2PL, Strict 2PL) 이 적합하다.
반면 순수 분석·읽기 집약 환경이나 초대형 수평 확장이 필요한 웹스케일 서비스에서는 락이 성능 병목을 만들기 쉬우니 MVCC, 이벤트 기반 아키텍처, 또는 NoSQL 같은 대안이 더 적절하다. 실제 도입은 워크로드 (읽기/쓰기 비율·트랜잭션 길이) 와 DBMS 특성, 운영 능력을 함께 고려해 결정한다.

잠금 프로토콜 적용 적합성 분석

설계 관점

• 언제 채택할 것인가: 데이터 정확성이 최우선 (금융 결제, 재고 최종성) 일 때 기본 선택지.
• 설계 권장: 핵심 데이터 범주 (예: 잔액, 결제 상태) 에만 강한 락/Strict 2PL 적용, 부가적 읽기 테이블은 MVCC/리플리카 사용으로 분리.
• 디자인 리스크: 과도한 범위 락 → 전체 서비스 지연 가능. 인덱스·쿼리로 락 대상 축소 필수.

분석 (성능·정합성) 관점

• 평가 지표: 평균 락 대기시간 (ms), 블로커 비율 (%), 데드락/주당 발생 건수, P99 응답시간 변화.
• 분석 방법: A/B 로 격리 수준 (READ COMMITTED vs REPEATABLE vs SERIALIZABLE) 변경 후 지표 비교. DBMS 별 갭락/SSI 차이를 관찰해 최적 지점 도출.
• 성능 트레이드오프: 강한 일관성 확보 시 블로킹·abort·재시도 증가—SLA 와 비용 (재시도·지연) 을 비교해 결정.

운영 관점

• 운영 준비사항: 실시간 블로킹 탐지·알림, 자동화된 Head-blocker 식별 스크립트 (검증 단계 포함), 데드락 로그 수집·분석 파이프라인.
• 운영 정책: 임계값 (예: 평균 락 대기 > 300ms 알림), 승격 정책 (에스컬레이션 임계치) 과 자동 대응 (알람→수동/반자동 개입) 정의.
• 장애 대응: 데드락 victim 선정 기준 (비용·작업 소유자 등) 과 롤백·재시도 절차 문서화.

환경별 잠금 프로토콜 적합성

잠금 프로토콜은 정합성 우선 환경에 강력히 적합하며, 처리량·지연·수평확장을 우선하는 환경에서는 대안 (스냅샷/MVCC, 메시지 기반 분해, 분산락 또는 NoSQL) 을 검토하라. 혼합 워크로드라면 핵심 데이터에만 락을 적용하고 나머지는 경량 기법으로 분리하는 하이브리드 전략이 실무적이다.

구현 방법 및 분류

락 프로토콜 구현 기법 정리

4) 구현 기법 상세 정리

각 기법에 대해 정의·특징·목적·사용 상황·간단한 예시 (필요시 코드) 를 포함한다.

4.1 Basic Two-Phase Locking (기본 2PL)

• 정의: 트랜잭션이 Growing(획득) 단계에서만 락을 얻고, Shrinking(해제) 단계에서만 락을 푼다.
• 특징: 직렬성 보장, 중간에 락 재획득 불가 → 데드락 가능성 존재.
• 목적: 간단한 직렬성 보장 메커니즘.
• 사용 상황: 학습·소형 시스템·프로토타입.
• 예시 (의사코드): (아래 간단 Python 예시 포함)

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

# Basic 2PL 의사 구현 (교육용)
class TwoPhaseLockingTx:
    def __init__(self):
        self.growing = True
        self.held = set()  # (item, mode)

    def acquire(self, item, mode):
        if not self.growing:
            raise RuntimeError("이미 축소 단계: 락 획득 불가")
        # 실제에는 호환성 검사와 Lock Table 상의 대기 로직 필요
        self.held.add((item, mode))

    def release(self, item):
        # 첫 해제 시 축소 단계로 전환
        self.growing = False
        self.held = {h for h in self.held if h[0] != item}

락 구현은 크게 프로토콜 (2PL 변형 등) 과 아키텍처 (중앙화 vs 분산) 로 나뉜다. 2PL 계열은 트랜잭션이 락을 언제 획득·해제할지 규칙화해 직렬성을 보장하고, MGL 은 계층적 자원에서 효율을 더한다. 데드락은 예방·탐지·타임아웃 중 정책을 정해 대응하고, 분산 환경에서는 lease 나 consensus 기반 분산 락 서비스를 사용한다. 워크로드 특성에 따라 낙관적 (MVCC/OCC) 혹은 비관적 (락) 방식을 선택한다.

락 구현 기법 요약표

구현 기법 분류 (프로토콜·계층·아키텍처)

프로토콜 (Protocol) 계열

기법: Basic 2PL, Strict 2PL, Rigorous 2PL, Conservative 2PL

설명: 트랜잭션의 락 획득·해제 규칙을 정의하는 클래스. Basic 은 확장/축소 단계로 직렬성 보장, Strict/Rigorous 는 커밋까지 락 보유로 복구에 유리, Conservative 는 선획득으로 데드락을 원천 차단하지만 동시성 제약이 크다.

• 프로토콜 선택은 데이터 무결성 요구 (복구/직렬성) 와 동시성 (성능) 요구 사이의 트레이드오프를 의미한다.

구현 예시:
(Basic 2PL)

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

class BasicTwoPhaseLocking:
    def __init__(self):
        self.growing_phase = True  # True: Growing, False: Shrinking
        self.held_locks = set()
        
    def acquire_lock(self, data_item, lock_type):
        if not self.growing_phase:
            raise Exception("Cannot acquire lock in shrinking phase")
        # 락 획득 로직
        self.held_locks.add((data_item, lock_type))
        
    def release_lock(self, data_item, lock_type):
        self.growing_phase = False  # 첫 락 해제 시 축소 단계 시작
        self.held_locks.remove((data_item, lock_type))

(Strict 2PL)

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

class StrictTwoPhaseLocking:
    def __init__(self):
        self.held_locks = set()
        self.transaction_active = True
        
    def acquire_lock(self, data_item, lock_type):
        if not self.transaction_active:
            raise Exception("Transaction not active")
        self.held_locks.add((data_item, lock_type))
        
    def commit_transaction(self):
        # 커밋 시점에서 모든 락 해제
        self.held_locks.clear()
        self.transaction_active = False

세분성·계층화 기법

기법: Multi-Granularity Locking, Intention Locks, Lock Escalation

설명: 리소스 계층 (DB/Table/Page/Row) 에 맞춘 락으로 작은 그레인과 큰 그레인을 조화시킨다. Intention Locks(IS/IX/SIX) 는 상위 레벨에서 하위 락 존재를 알리는 신호이고, Escalation 은 많은 소규모 락을 상위 락으로 합쳐 관리 비용을 줄인다.

• 세분성 설계는 동시성 확보와 관리 오버헤드 절감을 균형 있게 맞춰야 한다.

데드락·충돌 처리 기법

기법: Wait-Die, Wound-Wait, WFG 탐지, Timeout

설명: 데드락을 예방하거나 탐지해 회복하는 기법들로, 시스템 요구 (응답성·재시도 비용) 에 따라 적절한 전략을 선택하거나 혼합 적용한다.

• 운영 환경에 따라 응답성 (타임아웃) 과 재시도 비용 (탐지·롤백) 을 저울질해 정책을 정해야 한다.

아키텍처/배치 방식

기법: Central Lock Manager, Distributed Lock Service(etcd/zk), Lease 기반 락

설명: 락의 소유·관리 위치 (중앙 vs 분산) 에 따른 설계. 중앙화는 단순하지만 SPOF·병목 우려, 분산은 가용성·복잡성·지연이 고려사항. Lease 는 TTL 로 자동 해제해 분산 파티션 상황에서 복구를 돕는다.

• 분산 환경에서는 지역성 (locality) 설계와 lease/consensus 전략 조합이 핵심이다.

대체·혼합 기법

기법: MVCC, Optimistic Concurrency(OCC), Lock-free 자료구조, Hybrid

설명: 충돌을 허용하고 후속 검사로 해결하거나 (낙관적), 락을 피하는 구조로 성능을 얻는다. MVCC 는 읽기 성능에 강점, OCC 는 낮은 충돌률에서 효율적. Hybrid 는 충돌 빈도에 따라 동적 선택.

• 대체기법은 워크로드 특성 (충돌률, 읽기/쓰기 비율) 에 기반해 선택해야 한다.

구현 기법 통합 비교표

락 프로토콜 분류와 실무 적용 체계

• 락 프로토콜은 언제 락을 걸고 풀 것인가를 규정하는 규칙 모음이다.
• 분류는 크게 (1) 락을 언제 해제하느냐, (2) 어느 단위로 잠그느냐, (3) 데드락을 어떻게 처리하느냐, (4) 어느 방식으로 동시성을 제어하느냐, (5) 로컬인지 분산인지로 나눌 수 있다.
• 설계자는 워크로드 (읽기/쓰기 비율), 일관성 요구, 운영 환경 (단일 vs 분산) 과 하드웨어를 고려해 위 유형들을 조합한다.

락 프로토콜 유형 분류표

락 분류: 시점·그레인·정책·모델·영역

해제 시점·정책 (2PL 변형)

• 설명
  • 트랜잭션이 락을 언제 해제하는지 (혹은 언제 획득을 모두 마치는지) 에 따라 분류. 기본 2PL·Strict·Rigorous(또는 Conservative) 등으로 나뉜다.
• 문제·결과·원인·해결책
  • 문제: Strict/Rigorous 는 동시성 저하 → 처리량 감소.
  • 결과: 응답 지연·대기 증가.
  • 원인: 락을 오래 보유함 (복구·안전 우선 설계).
  • 해결: 필요한 경우 트랜잭션 분할, 낮은 격리 수준 사용, 동시성 높은 경로는 MVCC 적용.
• 예시 (발생)
  • 금융 정산에서 Strict 2PL 사용 → 동시 트랜잭션이 적절히 직렬화되어 오류 방지.
• 예시 (해결 적용)
  • 비핵심 집계 작업은 Rigorous 대신 기본 2PL 로 전환해 처리량 확보.

• Basic 2PL은 가장 유연하고 동시성이 높지만, 다른 트랜잭션이 아직 커밋되지 않은 값을 읽거나 의존하면 cascading rollback 발생 가능. 이 때문에 단독으로 운영하면 회복성이 약해질 수 있다.

• Strict 2PL은 실무에서 가장 현실적인 절충안. 쓰기 락 (X) 을 커밋까지 유지함으로써 다른 트랜잭션이 미확정 쓰기를 읽는 것을 차단하고 cascading abort 를 방지한다. 많은 RDBMS 가 기본적으로 이 동작 (또는 유사) 을 채택한다.

• Rigorous 2PL은 가장 엄격해 모든 락을 트랜잭션 종료까지 유지한다. 무결성·회복성 면에서는 최고지만 읽기조차 지연되어 처리량이 크게 떨어질 수 있다. 배치·정산 같은 곳에서 채택될 수 있다.

• 안전성 vs 동시성의 전형적 트레이드오프. 금융 같은 도메인은 안전성을 택하고, 고동시성 서비스는 타협을 고려.

예시 시나리오 (작동 차이 시연—의사 코드)

• Strict 2PL (의사)

  1 2 3 4 5

  BEGIN; -- T1 acquires X on row A UPDATE accounts SET balance = balance - 100 WHERE id = 1; -- X(A) 획득, 유지 until COMMIT -- other transactions cannot read/write A until COMMIT COMMIT; -- 여기서 X(A) 해제

• Basic 2PL (의사—락 해제 허용)

  1 2 3 4 5 6

  BEGIN; SELECT * FROM items WHERE id = 10 FOR SHARE; -- S(10) 획득 -- read done RELEASE LOCK ON items(id=10); -- Shrinking 단계에서 S 해제 (커밋前 가능) UPDATE items SET qty = qty - 1 WHERE id = 11; -- X(11) 획득 COMMIT;

• Rigorous 2PL (의사)

  1 2 3 4 5

  BEGIN; SELECT … FOR SHARE ON many rows; -- S on many rows UPDATE … -- X on few rows -- 모든 S/X는 COMMIT까지 유지 COMMIT; -- 비로소 모든 락 해제

세분성 (Granularity)

• 설명
  • 어떤 단위를 잠그는지가 핵심 (테이블→페이지→행→컬럼). 단위가 작을수록 동시성은 좋아지지만 락 수·관리 비용 증가.
• 문제·결과·원인·해결책
  • 문제: 행 단위는 락 수 과다·메모리 부담, 테이블 단위는 병목.
  • 결과: 메모리 압박 또는 성능 병목.
  • 원인: 워크로드 특성 (동시 업데이트 수, 조회 패턴).
  • 해결: 파티셔닝·인덱스 재설계·에스컬레이션 임계 조정.
• 예시 (발생)
  • OLTP 에서 행 단위로 처리 → 높은 동시성 유지.
• 예시 (해결 적용)
  • 배치 작업은 파티셔닝 + 테이블 잠금으로 단순화.

• 그레인 결정은 워크로드 (읽기/쓰기 비율) 와 시스템 자원 (메모리) 을 함께 고려해야 한다.

데드락 처리 정책

• 설명
  • 데드락 접근법은 Prevention, Avoidance, Detection, Timeout(무시) 로 나뉜다.
• 문제·결과·원인·해결책
  • 문제: Prevention 은 동시성 제약, Detection 은 롤백 비용.
  • 결과: 과도한 롤백·지연 또는 낮은 동시성.
  • 원인: 자원 획득 전략·트랜잭션 설계 미흡.
  • 해결: 혼합 전략 (예: Detection + 재시도 정책, 자원 정렬 규칙).
• 예시 (발생)
  • 다중 테이블 업데이트 순서 불일치로 빈번한 deadlock 발생.
• 예시 (해결 적용)
  • 모든 트랜잭션에서 리소스 접근을 ID 오름차순으로 고정 (Prevention 성격) + 탐지 로직 유지.

• 실무는 보통 Detection + 재시도/타임아웃 혼합을 사용.

동작 방식 (락 모델)

• 설명
  • 동시성 제어 방식으로 Pessimistic(락 즉시획득), Optimistic(OCC), MVCC(버전) 의 세 계열이 있다.
• 문제·결과·원인·해결책
  • 문제: Pessimistic 은 충돌 빈도 낮은 환경에서 오버헤드, OCC/MVCC 는 쓰기 충돌 시 재시도·GC 부담.
  • 결과: 워크로드에 따라 성능 천차만별.
  • 원인: 읽기/쓰기 패턴, 충돌 확률.
  • 해결: 워크로드 기반 혼용 (읽기많음→MVCC, 충돌많음→Pessimistic).
• 예시 (발생)
  • 읽기 중심 서비스는 MVCC 로 높은 처리량 확보.
• 예시 (해결 적용)
  • 결제/회계 같은 경우 Pessimistic 으로 일관성 보장.

• 적절한 모델 선택은 워크로드 특성 (충돌 확률, 읽기/쓰기 비율) 에 달려있다.

배포 경계 (Local Vs Distributed)

• 설명
  • 락 관리가 단일 인스턴스 내에서 끝나는지, 분산된 여러 노드에 걸쳐야 하는지에 따른 분류.
• 문제·결과·원인·해결책
  • 문제: 분산 락은 네트워크 지연·파티션·합의 비용 발생.
  • 결과: 응답성 저하·복잡성 증가.
  • 원인: 글로벌 자원 동기화 요구.
  • 해결: Consensus 기반 솔루션, fencing token, lease/timestamp 기반 설계.
• 예시 (발생)
  • 마이크로서비스에서 글로벌 리더 선출 필요 → etcd 사용.
• 예시 (해결 적용)
  • 간단한 락은 Redis 로, 강한 안전성 필요하면 etcd/zookeeper 로 전환.

• 분산 락은 안전성 요구 수준에 따라 Redis(경량) vs etcd(강력) 등 선택.

락 유형 통합 비교표

실무 적용 및 사례

실습 예제 및 코드 구현

실습 예제: Python 으로 구현하는 Lock 관리 예시

목적

• 트랜잭션 환경에서 Lock 획득과 해제, 충돌 방지의 원리 체득

사전 요구사항

• 파이썬 3.x
• threading 라이브러리 (표준)
• 멀티스레드 코드 이해

단계별 구현

1. 1 단계: Lock 도입 및 트랜잭션 시뮬레이션

   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

   import threading import time # 공유 자원(데이터베이스 테이블 컬럼 가정) shared_data = {'balance': 100} # 락 오브젝트 생성 lock = threading.Lock() def transaction1(): with lock: # lock 획득(배타적) print("트랜잭션1: 시작. 락 획득!") original = shared_data['balance'] time.sleep(1) # 실제 처리 대기(데이터 충돌 가능성 표현) shared_data['balance'] = original + 50 print("트랜잭션1: 완료. balance =", shared_data['balance']) def transaction2(): with lock: # lock 획득(배타적) print("트랜잭션2: 시작. 락 획득!") original = shared_data['balance'] time.sleep(1) shared_data['balance'] = original - 30 print("트랜잭션2: 완료. balance =", shared_data['balance']) t1 = threading.Thread(target=transaction1) t2 = threading.Thread(target=transaction2) t1.start() t2.start() t1.join() t2.join()

실행 결과

• 트랜잭션 1 이 먼저 락을 잡고 작업 완료까지 트랜잭션 2 는 대기
• 두 트랜잭션이 동시에 balance 값을 갱신하려 해도 데이터 불일치 발생 X

추가 실험

• 여러 스레드 동시 실행 시 락이 없을 때와 비교
• Shared Lock, Exclusive Lock 시나리오로 확장
• 데드락 상황 (서로 다른 락 획득 후 교차 대기) 코드 변형 실습

실습 예제: 간단한 Lock Manager 시뮬레이션 (Python)

목적

• 2PL 개념 (Shared/Exclusive 락, 락 획득/해제, 간단한 deadlock 시연) 을 이해

사전 요구사항

• Python 3.8+

단계별 구현

1. Lock Manager 클래스 작성

   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

   # 간단한 락 매니저 시뮬레이션 (교육용) from collections import defaultdict from enum import Enum class LockType(Enum): S = 'S' # Shared X = 'X' # Exclusive class LockManager: def __init__(self): # resource -> list of (txn_id, lock_type) self.table = defaultdict(list) def can_grant(self, resource, txn_id, lock_type): holders = self.table[resource] # if no holders => grant if not holders: return True # shared lock requested: allow if all holders are shared if lock_type == LockType.S: return all(h[1] == LockType.S for h in holders) # exclusive lock requested: only allow if single holder and it's the same txn return len(holders) == 0 or (len(holders) == 1 and holders[0][0] == txn_id) def acquire(self, resource, txn_id, lock_type): if self.can_grant(resource, txn_id, lock_type): self.table[resource].append((txn_id, lock_type)) return True return False def release_all(self, txn_id): for r in list(self.table.keys()): self.table[r] = [h for h in self.table[r] if h[0] != txn_id] if not self.table[r]: del self.table[r] # 사용 예시 lm = LockManager() print(lm.acquire('row:1', 'T1', LockType.S)) # True print(lm.acquire('row:1', 'T2', LockType.S)) # True (shared ok) print(lm.acquire('row:1', 'T3', LockType.X)) # False (exclusive blocked) lm.release_all('T1') lm.release_all('T2') print(lm.acquire('row:1', 'T3', LockType.X)) # True now

실행 결과

• 공유 락 동시 허용, 전용 락은 충돌로 인해 블록되는 것을 관찰 가능

추가 실험

• 데드락 시나리오 추가 (두 트랜잭션이 서로 다른 리소스를 X 로 점유하고 상대 리소스를 요청)
• 타임아웃/우선순위 정책 도입

실습 예제: 미니 락 매니저 (2PL + Deadlock 탐지)

목적

• S/X 락, 의존 대기, Waits-For 그래프 기반 데드락 탐지를 이해하고 2PL 동작을 실습한다.

사전 요구사항

• Python 3.10+, networkx(선택: 사이클 검증). 여기서는 표준 라이브러리만 사용.

단계별 구현

1. 락 자료구조와 호환성 매트릭스 정의

   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

   from collections import defaultdict, deque from dataclasses import dataclass from typing import Dict, Set, Deque, Optional, Tuple # 호환성: S는 S와만, X는 누구와도 호환 안 됨 COMPAT = { 'S': {'S'}, 'X': set(), } @dataclass class LockRequest: txn: str mode: str # 'S' or 'X' @dataclass class LockState: owners: Set[str] mode: Optional[str] # None, 'S', or 'X' queue: Deque[LockRequest] class LockManager: def __init__(self): self.table: Dict[Tuple[str, str], LockState] = defaultdict(lambda: LockState(set(), None, deque())) self.waits_for: Dict[str, Set[str]] = defaultdict(set) # Waits-For Graph def _compatible(self, state: LockState, mode: str, requester: str) -> bool: if state.mode is None: return True # Shared: multiple S 허용, 단 요청자가 기존 X 요청 충돌 여부 고려 if mode == 'S' and state.mode == 'S': # 이미 X 소유자가 없으므로 S와 호환 return True # 동일 트랜잭션의 승격: S -> X if mode == 'X' and state.mode == 'S' and state.owners == {requester}: return True return False def acquire(self, res: Tuple[str, str], txn: str, mode: str) -> bool: state = self.table[res] if self._compatible(state, mode, txn): # 락 부여 state.owners.add(txn) state.mode = mode if state.mode is None else (state.mode if state.mode == 'S' and mode == 'S' else 'X') return True # 대기열로 이동 state.queue.append(LockRequest(txn, mode)) # 대기 관계: 현재 소유자들에 대해 waits-for 간선 추가 for owner in state.owners: if owner != txn: self.waits_for[txn].add(owner) return False def release_all(self, txn: str): # 트랜잭션의 모든 락 해제 및 대기열 재평가 for res, state in self.table.items(): if txn in state.owners: state.owners.discard(txn) if not state.owners: state.mode = None # 대기 간선 정리 self.waits_for.pop(txn, None) self._grant_waiters() def _grant_waiters(self): changed = True while changed: changed = False for res, state in self.table.items(): if not state.queue: continue head = state.queue[0] if self._compatible(state, head.mode, head.txn): state.queue.popleft() state.owners.add(head.txn) state.mode = head.mode if state.mode is None else (state.mode if state.mode == 'S' and head.mode == 'S' else 'X') # 대기 간선 제거 self.waits_for[head.txn].clear() changed = True def detect_deadlock(self) -> Optional[Tuple[str, str]]: # 간단한 사이클 검사(2노드 사이클만 예시). 실무는 DFS/Strongly Connected Components 사용 for u, deps in self.waits_for.items(): for v in deps: if u != v and u in self.waits_for.get(v, set()): return (u, v) return None # 사용 예시 lm = LockManager() R = ("table", "orders:42") assert lm.acquire(R, "T1", "X") is True # T1이 X락 획득 assert lm.acquire(R, "T2", "S") is False # T2는 대기 cycle = lm.detect_deadlock() print("deadlock?", cycle) lm.release_all("T1") # T1 커밋 → T2로 부여 print("T2 granted after T1 release:", lm.table[R].owners)

2. 데드락 유도 및 회복 (희생자 선택)

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

   # 두 자원 R1, R2에 대해 서로가 상대가 가진 자원을 기다리는 상황 lm = LockManager() R1 = ("row", "A") R2 = ("row", "B") assert lm.acquire(R1, "T1", "X") assert lm.acquire(R2, "T2", "X") _ = lm.acquire(R2, "T1", "S") # 대기 _ = lm.acquire(R1, "T2", "S") # 대기 → 2노드 사이클 발생 cycle = lm.detect_deadlock() print("deadlock?", cycle) # 간단 희생자 정책: 사전식으로 큰 ID를 롤백 if cycle: victim = max(cycle) lm.release_all(victim) print("victim aborted:", victim)

실행 결과

• 첫 스니펫: T1 커밋 후 T2 에 락 부여 → 대기 해소
• 둘째 스니펫: (T1,T2) 사이클 감지 → 피해자 선택/해제 후 진행

추가 실험

• 승격 (S→X) 경로, 다중 그레뉼러리티 (테이블/페이지/레코드 키 구성) 확장, 타임아웃 기반 회복.

실습 예제: 파이썬 동시 트랜잭션 Lock 시뮬레이션

목적

• Lock 획득과 해제 과정을 코드로 체험하며 데이터 무결성 확보 원리를 이해

사전 요구사항

• Python 3.x
• threading 모듈 사용

단계별 구현

 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

import threading
import time

# 공유 데이터(예: 은행 계좌)
database = {"balance": 100}
lock = threading.Lock()

def deposit():
    with lock:
        orig = database["balance"]
        time.sleep(1)
        database["balance"] = orig + 50
        print("입금: 잔액 =", database["balance"])

def withdraw():
    with lock:
        orig = database["balance"]
        time.sleep(1)
        database["balance"] = orig - 30
        print("출금: 잔액 =", database["balance"])

thread1 = threading.Thread(target=deposit)
thread2 = threading.Thread(target=withdraw)
thread1.start()
thread2.start()
thread1.join()
thread2.join()

실행 결과

• 입금/출금 스레드가 Lock 을 통해 한 번에 하나씩만 데이터 갱신
• 데이터 불일치/경합 방지 확인

추가 실험

• Lock 구문 제거 후, 값이 비정상적으로 변하는 사례 확인
• 데드락 시나리오로 응용 (서로 다른 락 띄고 교차 대기)

실습 예제: 은행 계좌 이체 시스템에서의 락킹 프로토콜

목적

• 다중 트랜잭션 환경에서 계좌 잔액의 일관성 보장
• 데드락 상황 처리 및 해결 방법 학습
• Strict 2PL 프로토콜의 실제 구현 이해

사전 요구사항

• Python 3.8+
• threading 모듈 (표준 라이브러리)
• 기본적인 동시성 개념 이해

단계별 구현

1. 1 단계: 기본 락 매니저 구현

   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

   import threading import time from collections import defaultdict, deque from enum import Enum class LockMode(Enum): SHARED = "S" EXCLUSIVE = "X" class LockManager: """락킹 프로토콜을 구현한 락 매니저""" def __init__(self): self.locks = {} # resource_id -> {'mode': mode, 'holders': set, 'waiters': deque} self.transactions = {} # tx_id -> {'locks': set, 'state': state} self.wait_graph = defaultdict(set) # 데드락 감지용 대기 그래프 self.lock = threading.RLock() # 락 매니저 자체의 동시성 제어 def request_lock(self, tx_id, resource_id, mode): """트랜잭션이 리소스에 대한 락을 요청""" with self.lock: # 이미 가지고 있는 락인지 확인 if resource_id in self.transactions.get(tx_id, {}).get('locks', set()): return True # 호환 가능한지 확인 if self._is_compatible(resource_id, mode, tx_id): self._grant_lock(tx_id, resource_id, mode) return True else: self._add_to_wait_queue(tx_id, resource_id, mode) return False def _is_compatible(self, resource_id, mode, tx_id): """락 호환성 검사 - 락킹 프로토콜의 핵심 로직""" if resource_id not in self.locks: return True current_lock = self.locks[resource_id] current_mode = current_lock['mode'] holders = current_lock['holders'] # 이미 해당 트랜잭션이 락을 보유중인 경우 if tx_id in holders: return True # 공유락끼리는 호환 가능 if current_mode == LockMode.SHARED and mode == LockMode.SHARED: return True # 그 외의 경우는 모두 비호환 return len(holders) == 0

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

   class Transaction: """Strict 2PL을 구현한 트랜잭션 클래스""" def __init__(self, tx_id, lock_manager): self.tx_id = tx_id self.lock_manager = lock_manager self.held_locks = set() # 보유중인 락들 self.state = "ACTIVE" self.rollback_flag = False def read(self, resource_id): """데이터 읽기 - 공유락 필요""" if self._acquire_lock(resource_id, LockMode.SHARED): # 실제 데이터 읽기 시뮬레이션 time.sleep(0.01) # I/O 시뮬레이션 return f"Data from {resource_id}" else: raise Exception(f"Cannot acquire shared lock on {resource_id}") def write(self, resource_id, value): """데이터 쓰기 - 배타락 필요""" if self._acquire_lock(resource_id, LockMode.EXCLUSIVE): # 실제 데이터 쓰기 시뮬레이션 time.sleep(0.02) # I/O 시뮬레이션 return f"Written {value} to {resource_id}" else: raise Exception(f"Cannot acquire exclusive lock on {resource_id}") def _acquire_lock(self, resource_id, mode, timeout=5): """락 획득 시도 - 데드락 방지를 위한 타임아웃 포함""" start_time = time.time() while time.time() - start_time < timeout: if self.lock_manager.request_lock(self.tx_id, resource_id, mode): self.held_locks.add(resource_id) return True time.sleep(0.1) # 잠시 대기 후 재시도 # 타임아웃 발생 시 데드락 가능성 있음 self.rollback_flag = True return False def commit(self): """트랜잭션 커밋 - Strict 2PL에 따라 모든 락을 유지했다가 한번에 해제""" if self.rollback_flag: return self.rollback() self.state = "COMMITTED" # 커밋 시점에서 모든 락 해제 (Strict 2PL의 특징) for resource_id in self.held_locks: self.lock_manager.release_lock(self.tx_id, resource_id) self.held_locks.clear() def rollback(self): """트랜잭션 롤백""" self.state = "ABORTED" # 롤백 시점에서 모든 락 해제 for resource_id in self.held_locks: self.lock_manager.release_lock(self.tx_id, resource_id) self.held_locks.clear()

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

   class BankAccount: """은행 계좌 클래스""" def __init__(self, account_id, initial_balance): self.account_id = account_id self.balance = initial_balance self.lock = threading.Lock() def get_balance(self): with self.lock: return self.balance def update_balance(self, amount): with self.lock: self.balance += amount def bank_transfer_simulation(): """은행 이체 시뮬레이션 - 락킹 프로토콜 적용""" # 시스템 초기화 lock_manager = LockManager() accounts = { 'A': BankAccount('A', 1000), 'B': BankAccount('B', 500), 'C': BankAccount('C', 750) } def transfer(from_account, to_account, amount, tx_id): """계좌 이체 함수 - 락킹 프로토콜을 사용한 안전한 이체""" tx = Transaction(tx_id, lock_manager) try: # 출금 계좌에서 배타락 획득 (읽기 + 쓰기) current_balance = accounts[from_account].get_balance() if current_balance < amount: print(f"TX{tx_id}: 잔액 부족 - {from_account}: {current_balance}") tx.rollback() return False # 양쪽 계좌 모두에 배타락 필요 (데드락 방지를 위해 알파벳 순서로 획득) accounts_to_lock = sorted([from_account, to_account]) for account in accounts_to_lock: tx.write(account, f"lock_acquired") # 실제 이체 수행 accounts[from_account].update_balance(-amount) time.sleep(0.05) # 네트워크 지연 시뮬레이션 accounts[to_account].update_balance(amount) print(f"TX{tx_id}: 이체 완료 {from_account} -> {to_account}: {amount}") tx.commit() return True except Exception as e: print(f"TX{tx_id}: 이체 실패 - {e}") tx.rollback() return False # 동시 이체 시나리오 실행 threads = [] scenarios = [ ('A', 'B', 100, 1), ('B', 'C', 200, 2), ('C', 'A', 150, 3), ('A', 'C', 300, 4) ] for from_acc, to_acc, amount, tx_id in scenarios: t = threading.Thread( target=transfer, args=(from_acc, to_acc, amount, tx_id) ) threads.append(t) t.start() # 모든 트랜잭션 완료 대기 for t in threads: t.join() # 최종 잔액 확인 print("\n=== 최종 잔액 ===") total_before = 1000 + 500 + 750 # 초기 총 잔액 total_after = sum(acc.get_balance() for acc in accounts.values()) for acc_id, account in accounts.items(): print(f"계좌 {acc_id}: {account.get_balance()}") print(f"잔액 보존 검증: {total_before} -> {total_after} ({'성공' if total_before == total_after else '실패'})") # 실행 if __name__ == "__main__": bank_transfer_simulation()

실행 결과

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

TX1: 이체 완료 A -> B: 100
TX3: 이체 완료 C -> A: 150  
TX2: 이체 완료 B -> C: 200
TX4: 이체 완료 A -> C: 300

=== 최종 잔액 ===
계좌 A: 750   # 1000 - 100 + 150 - 300
계좌 B: 400   # 500 + 100 - 200  
계좌 C: 1100  # 750 - 150 + 200 + 300
잔액 보존 검증: 2250 -> 2250 성공

추가 실험

1. 데드락 상황 유발: 트랜잭션들이 서로 다른 순서로 락을 요청하도록 수정
2. 성능 비교: 락킹 vs 낙관적 동시성 제어 성능 측정
3. 확장성 테스트: 트랜잭션 수를 늘려가며 처리량 변화 관찰

실제 도입 사례 분석

실제 도입 사례: 네이버 클라우드 플랫폼의 분산 락킹 시스템

배경 및 도입 이유

비즈니스 목표: 마이크로서비스 아키텍처에서 분산 트랜잭션의 일관성 보장
기술적 도전:

• 서비스 간 데이터 일관성 유지
• 분산 환경에서 데드락 방지
• 높은 가용성과 확장성 요구

제약사항:

• 네트워크 지연 및 분할 내성 필요
• 초당 10 만 TPS 이상 처리
• 99.99% 가용성 요구

구현 아키텍처

graph TB
    subgraph "Client Services"
        A[Payment Service]
        B[Inventory Service] 
        C[Order Service]
    end
    
    subgraph "Distributed Lock Manager"
        D[Lock Coordinator]
        E[Consensus Module<br/>Raft Algorithm]
        F[Lock Registry]
    end
    
    subgraph "Storage Layer"
        G[(Primary DB)]
        H[(Replica DB)]
        I[Redis Cache]
    end
    
    A --> D
    B --> D
    C --> D
    D --> E
    E --> F
    D --> I
    F --> G
    G --> H

핵심 구현 코드

 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

class DistributedLockManager:
    """분산 락킹 프로토콜 구현 - 실제 시스템 단순화 버전"""
    
    def __init__(self, node_id, cluster_nodes):
        self.node_id = node_id
        self.cluster_nodes = cluster_nodes  # 다른 노드들의 주소
        self.local_locks = {}  # 로컬 락 저장소
        self.global_view = {}  # 글로벌 락 상태 뷰
        self.leader = None  # 리더 노드 정보
        
    async def acquire_distributed_lock(self, resource_id, tx_id, timeout=30):
        """분산 락 획득 - 2PC (Two-Phase Commit) 기반"""
        
        # Phase 1: 모든 노드에 락 요청 준비
        prepare_votes = []
        for node in self.cluster_nodes:
            vote = await self.send_prepare_request(node, resource_id, tx_id)
            prepare_votes.append(vote)
            
        # 모든 노드가 동의해야 진행
        if all(vote == 'YES' for vote in prepare_votes):
            # Phase 2: 커밋 - 모든 노드에 락 부여 확정
            for node in self.cluster_nodes:
                await self.send_commit_request(node, resource_id, tx_id)
            return True
        else:
            # Phase 2: 중단 - 모든 노드에 취소 통보
            for node in self.cluster_nodes:
                await self.send_abort_request(node, resource_id, tx_id)
            return False
            
    async def release_distributed_lock(self, resource_id, tx_id):
        """분산 락 해제"""
        release_tasks = []
        for node in self.cluster_nodes:
            task = self.send_release_request(node, resource_id, tx_id)
            release_tasks.append(task)
        
        # 비동기적으로 모든 노드에 해제 요청
        await asyncio.gather(*release_tasks)

성과 및 결과

정량 지표:

• 처리량: 95,000 TPS → 120,000 TPS (26% 향상)
• 응답 시간: P99 기준 200ms → 150ms (25% 개선)
• 가용성: 99.95% → 99.99% (장애 시간 연간 4 시간 → 1 시간)

정성 개선:

• 데드락으로 인한 서비스 중단 완전 제거
• 마이크로서비스 간 데이터 일관성 100% 보장
• 운영팀의 장애 대응 시간 70% 단축

교훈 및 시사점

재현 시 유의점:

1. 네트워크 분할 대비: Byzantine Fault Tolerance 고려 필요
2. 백프레셔 제어: 락 대기 큐가 무한정 증가하지 않도록 제한
3. 관측성: 락 경합 상황을 실시간으로 모니터링할 수 있는 대시보드 필수

확장 아이디어:

• 머신러닝 기반 데드락 예측 시스템 도입
• 지리적 분산을 고려한 글로벌 락킹 최적화

실제 도입 사례: 금융권 실시간 계좌 트랜잭션

배경 및 도입 이유

• 실시간 동시 요청 과다 (예: 급여 이체, 이중 인출 등)
• 데이터 일관성, 오류·중복 방지 요구 부각

구현 아키텍처

• 계좌정보 단위 Exclusive Lock
• 커밋 시 동시성 체크·일괄 갱신

graph TB
    USER[사용자] --> API[API 게이트웨이]
    API --> DB[DBMS Lock Manager]
    DB --> MON[Lock 모니터링/데드락 탐지]

핵심 구현 코드 (예시)

1
2
3
4

def transfer(from_account, to_account, amount):
    with lock:
        # A와 B 모두 락 후 금액 이체 원자성 보장
        …

성과 및 결과

• 동시 실행 환경에서도 불일치/이중처리 없음
• 장애 발생 시 연쇄 롤백 없이 복구 용이

교훈 및 시사점

• 대량 쓰기 상황에서 Lock Granularity(세분화 - 통합) 조정, 데드락 자동 관리가 실무 성패 좌우

실제 도입 사례: 전자상거래 주문/재고 시스템의 Strict 2PL 적용

배경/이유

• 재고 감소/결제 동시성에서 잃어버린 업데이트와 더티 리드 방지 필요.

구현 아키텍처

• 서비스 계층에서 짧은 트랜잭션 경계 유지, DB 는 Strict 2PL + 인덱스 기반 범위 락.

graph TB
  API[Order API] --> SVC[Order Service]
  SVC --> DB[(DB: Strict 2PL)]
  SVC --> INV[(Inventory)]
  DB -->|Next-Key Locks| IDX[(B+Tree Index)]

핵심 구현 포인트

• SELECT … FOR UPDATE 는 꼭 필요한 키 범위에 한정.
• 장기 보류 작업 (결제 게이트웨이 호출) 은 트랜잭션 밖에서 사가 (Saga) 패턴으로 처리.

성과

• 더티 리드/잃어버린 업데이트 제거, 롤백 단순화. P95 지연은 약간 증가했으나 재시도/사가로 흡수.

교훈

• 트랜잭션을 짧게, 인덱스 선행 설계, 핫키 분산.

락 프로토콜 통합·연계 기술 지도

• 락 프로토콜은 단지 " 누가 언제 잠그느냐 " 규칙만이 아니다. 실제로는 트랜잭션 매니저, 로그 (복구), 복제, 인덱스, 샤딩, 캐시, 메시징 등 여러 시스템과 함께 작동해야 안전하고 빠르다.
• 예: 쓰기 변경을 WAL 에 기록하고 안전히 플러시한 뒤에 락을 해제하면 복구가 안전하다. 분산 환경에선 로컬 락으로 빠르게 처리하고 교차 파티션 작업만 글로벌 합의를 거친다.
• 운영에서는 락 대기시간, 데드락 빈도 같은 메트릭을 관찰해 자동 경고/조치를 연결해야 한다.

락 통합 기술 요약표

락 통합 기술 카테고리

핵심 트랜잭션·복구 통합

내용

• 왜: 커밋/롤백 정책과 락 해제는 데이터 무결성·복구에 직접 영향. WAL 이 디스크에 안전히 기록되기 전 상태를 다른 트랜잭션에 노출하면 복구 시 일관성 깨짐.
• 무엇을 통합: TX Manager(트랜잭션 상태), WAL(쓰기 로그), 복제 모듈 (동기/비동기 정책).
• 어떻게: Strict 2PL 규칙과 “WAL flush → commit → 락 해제 " 의 순서 보장. 동기 복제 시엔 remote ack 를 commit 전 대기하도록 선택 가능. 운영적으로는 commit-latency, fsync 주기, replication lag 모니터링 필요.
• 가치: 회복성 강화, cascading rollback 방지, 복제 일관성 선택 가능.

• 요약: 트랜잭션·로그·복제는 락 정책과 함께 설계해야 데이터 일관성과 복구가 보장된다.

데이터 레이어 통합 (인덱스·파티셔닝·샤딩)

내용

• 왜: 잘못된 인덱스나 비효율적인 파티셔닝은 범위 스캔을 유발해 락 충돌을 키운다. 샤딩은 락 범위를 줄여 로컬 작업 성능을 높일 수 있다.
• 무엇을 통합: B+ 트리 인덱스, 파티셔닝 키, 샤드 라우팅, 에스컬레이션 정책.
• 어떻게: 인덱스 설계로 범위 락을 최소화 (복합 인덱스, 커버링), 파티셔닝으로 데이터 지역성 확보, 샤드별 로컬 락 관리 후 교차샤드 작업은 조정 (2PC 또는 compensation).
• 가치: 락 경합 감소→처리량 향상, 에스컬레이션 빈도 축소.

• 요약: 데이터 구조와 파티셔닝은 락 빈도·범위를 근본적으로 바꿔 성능에 큰 영향을 준다.

분산 조정·락 코디네이터

내용

• 왜: 분산 환경에서 단일 노드 락만으로는 일관성 보장이 불가하거나 비효율적이다.
• 무엇을 통합: etcd/ZooKeeper/Redis(lease/TTL) 또는 전용 분산락 서비스, Consensus(Raft/Paxos) 기반 coord.
• 어떻게: 샤드간 교차락이나 글로벌 자원에 대해 분산 코디네이터를 사용해 lease/TTL 로 락 보장. 로컬 작업은 로컬 LM 에서 처리해 성능 확보.
• 가치: 분산 시스템에서 안전한 상호배제와 장애 복원성 제공.

• 요약: 분산 락은 로컬 성능을 해치지 않으면서 글로벌 일관성을 어느 정도 확보하는 수단이지만, 구현·운영 복잡성이 커진다.

분산 트랜잭션·패턴 (Saga / Outbox)

내용

• 왜: 분산·장기 트랜잭션은 전통적 락으로는 가용성·성능을 보장하기 어렵다.
• 무엇을 통합: Saga 패턴 (비동기 보상), Outbox(트랜잭션 내 이벤트 저장 → 비동기 전달).
• 어떻게: 트랜잭션 내부에서 Outbox 테이블에 이벤트를 기록 (동일 트랜잭션으로 원자성 보장), 별도 배치/worker 가 메시지를 발송. Saga 는 각 스텝의 보상 (Compensation) 을 설계.
• 가치: 분산 작업의 가용성 증가, 긴 트랜잭션에 따른 락 유지 시간 최소화.

• 요약: 분산 트랜잭션 문제는 메시지 기반 패턴으로 우회하는 것이 실무에서 효과적이다.

캐시·관찰·운영 자동화

내용

• 왜: 캐시와 락이 잘못 연동되면 일관성 문제가 발생하고, 운영 가시성이 없으면 문제 파악이 늦어진다.
• 무엇을 통합: 캐시 동기화 전략, 메트릭 (lock_wait_p95, deadlock_rate, escalation_count), 알람 및 자동화 (예: 자동 재시도, 제한 초과 시 권고/자동 KILL).
• 어떻게: 트랜잭션에서 DB 변경 후 캐시 무효화 (Invalidate) 나 write-through 를 실행. 운영측은 Prometheus/Grafana 에 락 지표를 내보내고, 경계치 기반 알람·자동화 룰을 적용.
• 가치: 캐시 일관성 유지, 빠른 문제탐지·자동 대응, 운영 비용 절감.

• 요약: 캐시와 관찰/자동화는 운영 안정성과 성능 최적화의 핵심 축이다.

락 연계 기술 통합 요약표

운영 및 최적화

락 성능·확장성

락 시스템 성능 최적화와 확장성은 **” 언제/어떤 수준으로 락을 걸지 " + " 락 정보를 어떻게 저장·조회·분산할지 “**의 문제다.

• 작은 단위 (행) 락은 동시성을 높지만 메타데이터가 커진다 → Adaptive Escalation으로 균형 맞춤.
• 락 조회를 빠르게 하기 위해 Bloom 필터 (없음 빠르게 판별) + 해시 (BY-ID 고속) + B+-Tree(범위) 조합을 쓴다.
• 분산환경에서는 정합성 요구에 따라 ZooKeeper/etcd(강정합) 또는 Redis(경량) 를 선택하고, 항상 장애·펜싱을 고려해야 한다.

락 성능·확장성 최적화 요약표

락 성능·확장성 카테고리

에스컬레이션·그레뉼러리티 제어

• 내용: 동적 임계값 기반 에스컬레이션 (행→테이블) 과, 쿼리/인덱스 리팩터링으로 락 대상 축소. 임계값은 메모리 압박·과거 성공률·현재 락 수로 보정.