MySQL Named Lock과 Redis Distributed Lock

Overview

Named/Distributed Lock은 존재하는 Row 하나가 아니라 user:1001:event-entry 같은 논리 작업을 직렬화한다. MySQL Named Lock은 DB Session, Redis Lock은 Key와 Lease를 기반으로 하므로 Transaction Row Lock과 생명주기·장애 모델이 다르다.

핵심 용어

왜 필요한가

“사용자당 동시 작업 하나”처럼 아직 Row가 없거나 여러 Row의 검증+삽입을 묶어야 할 수 있다. 그러나 Lock 서비스만 믿으면 Process Pause, Network Partition, Lease 만료 뒤 이전 소유자의 늦은 쓰기로 정합성이 깨진다.

핵심 원리와 내부 동작

Redis 기본 형태는 SET key token NX PX ttl이다. 해제는 GET과 DEL을 분리하지 않고 Lua로 Token 일치 시만 삭제한다. 작업이 TTL보다 길면 갱신이 필요하지만 갱신 실패를 고려한다. Fencing Token을 지원하는 최종 저장소는 더 큰 Token만 받아 늦은 소유자를 차단한다.

Example

SET lock:user:1001 random-owner-token NX PX 5000
-- 성공한 Client만 작업
-- Lua: 현재 값이 owner-token일 때만 DEL

MySQL은 GET_LOCK(name, timeout), RELEASE_LOCK(name)을 제공하지만 Connection Pool에서 획득·해제 Connection이 달라지지 않게 해야 한다. 업무 불변식은 최종적으로 Unique Constraint나 조건부 Update로도 방어한다.

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

Redis Failover, GC Stop-the-world, Network 지연으로 Lease 소유자가 둘처럼 행동할 수 있다. 긴 TTL은 장애 복구를 늦추고 짧은 TTL은 정상 작업 중 만료된다. Lock 집중은 Hot Key와 직렬화 병목을 만든다. Redlock은 요구하는 안전성·Failure Model을 검토 없이 만능으로 쓰지 않는다.

흔한 오해

• SETNX와 만료만으로 안전한 Unlock이 되지 않는다.
• Lock을 얻었다는 사실이 작업이 한 번만 실행됐음을 보장하지 않는다.
• Named Lock은 DB Transaction Commit과 자동으로 같은 경계가 아니다.
• 분산 Lock이 DB Constraint를 대체하지 않는다.

Production Considerations

Acquire 실패·대기·보유 시간, Lease 갱신 실패, Token mismatch, Hot Key를 측정한다. Timeout보다 작업 최악 시간을 검토하고 실패 시 중단 가능한지 설계한다. 금전·재고처럼 강한 안전성이 필요하면 Fencing과 DB 불변식을 함께 둔다.

다른 사람에게 설명한다면

30초: “Named/Redis Lock은 문자열 Key로 논리 작업을 직렬화합니다. Redis에서는 NX+TTL뿐 아니라 Owner Token을 비교해 해제해야 하고, Lease가 만료된 옛 소유자의 늦은 쓰기는 Fencing Token과 최종 저장소 검증으로 막습니다.”

2분: Row가 없는 검증+Insert 예, MySQL Session 수명, Redis Lease/Owner/Lua/Fencing, 마지막 DB Constraint를 순서대로 설명한다.

Interview Questions

1. Owner Token 없이 DEL하면 어떤 Race가 생기는가?
2. Lease 만료 후 옛 소유자의 쓰기는 어떻게 막는가?
3. Named Lock과 Row Lock의 수명 차이는?
4. Redlock을 선택할 때 어떤 Failure Model을 확인하는가?

Related Topics

DB Lock 지도, Redis 실패 패턴을 함께 본다.