Redis로 분산 락은 어떻게 동작하나요?

Question

Accepted Answer

**분산 락**은 여러 프로세스/서버에 걸쳐 공유 리소스 접근을 조율하여 한 번에 하나만 락을 보유하게 합니다. Redis는 TTL이 있는 원자적 set-if-not-exists를 통해 이에 흔히 사용됩니다 — 다만 올바르게 하려면 주의(와 제한 이해)가 필요합니다.

## 기본 Redis 락 (SET NX with TTL)

```js
// 획득: 락 키가 존재하지 않을 때만 SET, TTL과 함께 (자동 해제 안전장치)
const token = randomUUID();   // 이 락 보유자를 식별하는 고유 토큰
const acquired = await redis.set("lock:resource", token, "NX", "EX", 30);
// NX = 존재하지 않을 때만 설정(원자적); EX 30 = 30초 후 자동 만료 (deadlock 회피)

if (acquired) {
  try {
    // ... 배타적 접근이 필요한 작업 수행 ...
  } finally {
    // 우리가 여전히 보유 중일 때만 해제 (토큰 확인) — 원자성을 위해 Lua 스크립트 사용
    await releaseLock("lock:resource", token);
  }
}
```

락은 **`SET key value NX EX`**를 사용합니다: 키가 없을 때만 원자적으로 설정(한 클라이언트만 성공)하고 **TTL**(보유자가 크래시되면 락이 자동 해제되어 deadlock 회피)과 함께입니다.

## 두 가지 결정적 정확성 세부사항

```text
1. 항상 TTL 설정 → 락 보유자가 크래시되면 락이 자동 만료
   (그렇지 않으면 리소스가 영원히 잠김 — deadlock)
2. 고유 토큰 사용 + 일치할 때만 해제 → 다른 사람의 락을 해제하지 않도록
   (예: 당신의 TTL이 만료되고 다른 클라이언트가 획득한 경우).
   해제는 원자적이어야 함 (Lua 스크립트로 check-token-then-delete).
```

```lua
-- 안전한 해제: 값이 우리 토큰과 일치할 때만 삭제 (Lua로 원자적)
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end
```

## 제한과 Redlock

```text
⚠️ 단일 Redis 락은 완벽히 안전하지 않음: 작업 중 TTL이 만료되거나, failover 시
   (락이 아직 복제되지 않음) 두 클라이언트가 모두 보유할 수 있음.
→ REDLOCK 알고리즘 → 더 강한 보장을 위해 여러 독립 Redis 노드에 걸쳐
   (과반수) 락 획득 (단 Redlock조차 논쟁이 있음).
→ 결정적 정확성을 위해서는 fencing token과 결합하거나 합의를 위해 설계된
   시스템(예: ZooKeeper/etcd)을 사용. 트레이드오프를 알 것.
```

## 왜 중요한가

Redis로 분산 락을 이해하는 것은 분산 시스템에 걸쳐 **공유 리소스 접근을 조율하는 데** 가치가 있으므로 유용한 지식이며 — 정확성 함정을 이해하는 것이 특히 중요합니다.

분산 락은 실제 요구를 해결합니다: 다중 서버 시스템에서 한 번에 하나의 프로세스/서버만 결정적 동작을 수행하도록 보장(중복 처리, 공유 리소스의 race condition, 충돌하는 연산 방지)하며, Redis가 이에 흔한 도구입니다.

**기본 메커니즘** — `SET key value NX EX`(TTL이 있는 원자적 set-if-not-exists)로 한 클라이언트만 락을 획득하고 크래시 시 자동 해제 — 을 이해하는 것이 기초 기법입니다.

결정적으로, **두 가지 정확성 세부사항**을 이해하는 것이 필수입니다: **항상 TTL 사용**(크래시된 보유자의 락이 자동 만료되어 영구 deadlock 회피)과 **고유 토큰과 일치 해제 사용**(당신의 TTL이 만료된 경우 다른 클라이언트의 락을 실수로 해제하지 않도록 — Lua 스크립트로 atomic check-then-delete).

이 세부사항이 순진한 구현이 미묘하고 위험한 버그를 갖는 지점입니다.

똑같이 중요한 것은 **제한**을 이해하는 것입니다: 단일 Redis 락은 완벽히 안전하지 않으며(작업 중 TTL 만료나 failover로 두 클라이언트가 락을 보유 가능), 이는 더 강한 보장을 위한 **Redlock** 알고리즘(여러 Redis 노드에 걸쳐 획득)으로 이어집니다 — 그리고 결정적 정확성을 위해서는 fencing token이나 합의 시스템(ZooKeeper/etcd)이 필요할 수 있음을 아는 것입니다.

트레이드오프와 제한에 대한 이 인식은 성숙한 이해를 반영합니다.

분산 시스템에서 공유 리소스 접근 조율은 실제 요구이고, Redis 분산 락이 흔하지만 신중한 올바른 구현(TTL, 고유 토큰, 원자적 해제)과 제한(Redlock, failover 위험) 인식을 요구하므로, Redis로 분산 락 — 메커니즘, 정확성 세부사항, 제한 — 을 이해하는 것은 분산 조율에 가치 있고 실무적으로 관련된 지식이며, 함정과 트레이드오프 이해가 기본 기법만큼 중요한 주제입니다.