Database Lock 전체 지도

Overview

“DB Lock 종류”는 한 줄 목록이 아니라 서로 다른 분류 축이다. 낙관/비관은 충돌을 언제 다루는가, S/X는 어떤 작업과 공존하는가, Record/Gap은 어디를 보호하는가, Named/Distributed는 무엇을 소유권 Key로 삼는가를 말한다.

핵심 용어

왜 필요한가

“락을 걸었다”만으로는 대기 이유와 보호 범위를 설명할 수 없다. 같은 FOR UPDATE도 Index와 Isolation Level에 따라 다른 범위를 막고, JPA @Version은 DB Lock을 오래 보유하지 않는다. 축을 섞으면 과도한 Lock이나 빈 보호가 생긴다.

핵심 원리와 내부 동작

MVCC의 일반 SELECT는 보통 Snapshot을 읽고, Locking Read와 변경은 현재 Version과 Lock을 사용한다. Lock Manager는 요청 모드의 호환성을 검사해 즉시 부여하거나 Wait Queue에 둔다. 여러 Transaction 대기가 Cycle이면 하나를 Victim으로 Rollback한다.

flowchart TD; A[동시성 문제] --> B{단일 Row 불변식?}; B -->|Yes| C[Atomic Update / Constraint]; B -->|No| D{충돌 빈도}; D -->|낮음| E[Optimistic Version]; D -->|높음| F[Pessimistic Lock]; F --> G{Row가 존재?}; G -->|No| H[Range/Named/Distributed 검토]

Example

재고 감소는 UPDATE stock SET qty=qty-1 WHERE id=? AND qty>0와 영향 Row 수 확인이 가장 단순할 수 있다. 읽고 복잡한 판단이 필요하면 FOR UPDATE, 충돌이 드물고 재시도가 가능하면 Version을 검토한다.

실무에서 발생하는 문제와 Trade-off

Lock을 넓게 잡으면 정합성은 설명하기 쉬워도 Throughput과 Tail Latency가 나빠진다. 너무 약하면 Lost Update가 생긴다. 외부 API 호출 중 Lock 보유, 다른 순서의 자원 획득, Index 없는 범위 조회는 대표적인 장애 원인이다.

흔한 오해

• 일반 SELECT가 언제나 S Lock을 잡는 것은 아니다.
• JVM synchronized는 여러 Instance의 DB 경쟁을 보호하지 않는다.
• Redis Lock을 추가해도 DB Constraint가 불필요해지는 것은 아니다.
• Deadlock은 버그가 없어도 발생 가능한 동시성 결과다.

Production Considerations

Lock Wait, Deadlock, Transaction Age, 실행 계획과 영향 Row 수를 함께 관찰한다. Timeout과 제한 Retry를 정하고 자원 획득 순서를 통일한다. MySQL InnoDB, Oracle, PostgreSQL의 구현 차이를 제품 문서와 실제 대기 View로 확인한다.

다른 사람에게 설명한다면

30초: “DB Lock은 낙관·비관, S/X, Record·Gap 같은 서로 다른 분류 축이 있습니다. 먼저 Atomic Update와 Constraint를 보고, 충돌 빈도와 보호 범위에 따라 Version이나 Locking Read를 선택합니다.”

2분: 분류표를 그린 뒤 재고 예제로 Atomic Update→Optimistic→Pessimistic 선택을 설명하고 Index·Isolation Level·Deadlock 운영까지 연결한다.

Interview Questions

1. 낙관/비관과 S/X가 같은 분류가 아닌 이유는?
2. 일반 SELECT와 Locking Read의 차이는?
3. Index가 Lock 범위를 바꾸는 이유는?
4. 어떤 경우 Lock보다 Constraint가 나은가?

Related Topics

낙관적·비관적 락, Locking Read, Deadlock을 본다.