← 질문 목록
#11깊이 0
DB 락은 분산 환경에서 무엇이 한계인가?
서버가 여러 대여도 DB가 하나면 DB 락으로 막힌다. 문제는 DB 밖이다. 캐시나 외부 API처럼 그 DB가 모르는 자원은 DB 락이 지켜 주지 않는다. DB 밖 자원은 모든 서버가 공유하는 외부 저장소에서 락을 관리한다.
- 1. 클라이언트에서 외부 저장소로: 락 획득 요청
- 2. 외부 저장소에서 클라이언트로: 락 획득 성공/실패 응답
- 3. 클라이언트에서 DB로: 데이터 수정
- 4. 클라이언트에서 외부 저장소로: 락 해제
DB 락은 그 DB가 관리하는 자원에만 유효하다. 서로 다른 DB를 쓰거나 DB 밖 자원을 다투는 환경은 지켜 주지 못한다.
분산 락은 Redis나 ZooKeeper 같은 별도의 저장소를 사용한다. 모든 서버가 같은 저장소를 바라보고 누가 락을 쥐었는지를 한 자리에서 정한다. 다만 그 보장은 저장소의 일관성 모델과 락 알고리즘만큼만 강하다.
실무적으로는 락 획득 대기 시간과 만료 시간(lease)을 설정한다. 소유자가 장애로 락을 풀지 못해 남는 stale lock과 무기한 대기를 막기 위해서다.
만료된 소유자의 뒤늦은 쓰기는 fencing token으로 막는다 — 보호 대상이 토큰을 검증해 오래된 쓰기를 거부해야 완성된다.
추천 꼬리질문
관련 질문
- 분산 트랜잭션에서 Saga 패턴이 필요한 이유는?아키텍처 · 분산시스템분산 환경에서 단일 DB 수준 보장(락·트랜잭션)이 깨진다는 같은 밑바탕을 다룬다
- Redis 분산 락의 스핀과 Pub/Sub 방식 차이는?데이터베이스Redis 스핀락/Pub-Sub 구현은 분산 락 일반론의 구체 사례다
- 서버마다 시계가 다르면 무엇이 깨지는가?아키텍처 · 분산시스템분산 락의 만료 판단은 서버 시계에 기댄다 — 시계가 어긋나면 락의 안전성이 무너진다.
- 데이터베이스 격리 수준을 높이면 전체 처리량은 어떻게 변화하는가?데이터베이스
- 낙관적 락 충돌은 어떻게 재시도하는가?데이터베이스