분산 락의 안전성 한계를 극복하는 펜싱 토큰(Fencing Token) 아키텍처와 스토리지 검증 설계

1. 분산 락(Distributed Lock)의 안전성 착시와 TTL 만료의 함정

마이크로서비스 및 분산 데이터베이스 환경에서 동일한 공유 자원(재고 차감, 계좌 이체, 쿠폰 발급 등)에 대한 동시 접근을 제어하기 위해 Redis 기반 분산 락(Redlock 또는 SET NX EX)이 널리 활용되고 있습니다. 개발자들은 분산 락을 획득하면 크리티컬 섹션(Critical Section) 내부의 연산이 안전하게 보호될 것이라고 신뢰합니다.

그러나 분산 시스템에서는 비동기 네트워크 단절, 긴 가비지 컬렉션 일시중지(Stop-the-World GC Pause), 클라우드 하이퍼바이저 가상머신(VM) 스케줄링 지연과 같은 통제 불가능한 시간 왜곡이 발생합니다. 프로세스가 락을 획득한 후 DB에 쓰기 직전 10초간 GC로 멈춰 있는 동안 락의 TTL(Time-to-Live)이 만료되면, 분산 락 관리자는 락을 해제하고 제3의 클라이언트에게 락을 부여합니다.

뒤늦게 깨어난 첫 번째 프로세스는 자신이 여전히 유효한 락을 쥐고 있다고 착각한 채 데이터베이스에 쓰기를 감행하여, 공유 자원을 덮어쓰고 데이터 정합성을 영구 파괴하는 치명적인 상호 배제(Mutual Exclusion) 붕괴가 발생합니다.

2. Martin Kleppmann의 비판과 펜싱 토큰(Fencing Token) 아키텍처 원리

Martin Kleppmann의 명논문(How to do distributed locking)에 입각하여, 락 서비스 자체만으로는 클라이언트의 지연을 감지할 수 없으므로 스토리지 계층(Database)에서의 최종 검증이 반드시 결합되어야 합니다.

이 문제를 해결하는 수학적 해법이 바로 펜싱 토큰(Fencing Token) 아키텍처입니다.

• 단조 증가 번호(Monotonically Increasing Number) 발급: 분산 락 서비스(ZooKeeper, etcd, Redis)는 클라이언트에게 락을 승인할 때마다 1씩 증가하는 정수 토큰(예: zxid, raft term, atomic counter)을 함께 반환합니다.
• 스토리지 단독 검증(Storage-Level Validation): 스토리지 서버(RDBMS, 오브젝트 스토리지)는 각 리소스별로 마지막으로 쓰기를 승인한 최고 펜싱 토큰 번호(last_token)를 보관합니다.
• 오래된 토큰 즉각 거부: 클라이언트가 쓰기 요청 시 자신의 토큰을 함께 전달하며, 스토리지 엔진은 IF client_token > last_token 조건이 참일 때만 트랜잭션을 승인하고 그렇지 않으면 즉시 HTTP 412 Precondition Failed로 거부합니다.

3. 펜싱 토큰 vs Redlock의 구조적 차이와 시간 동기화 한계

Redis 공식 Redlock 명세는 복수의 독립 Redis 노드 간 과반수(Quorum) 합의를 통해 락을 획득하지만, 시스템 시계(Physical Clock Drift, NTP 점프)가 어긋나거나 프로세스 지연이 발생할 경우 안전성(Safety)을 증명하지 못합니다.

• 물리 시계 불신뢰 원칙: Leslie Lamport의 논문(Logical Clocks)에 명시된 바와 같이, 분산 시스템에서 서버 간 물리 시계는 절대 신뢰할 수 없으며 단조 증가하는 논리 시계(Logical Counter)만이 인과율을 보장합니다.
• 이중 방어선 구축: 락 획득 단계는 단순한 트래픽 유입 완화(Efficiency) 목적으로 사용하고, 실제 데이터 무결성 보장(Correctness)은 스토리지의 펜싱 토큰 원자적 검증이 전담하도록 역할을 분리해야 합니다.

4. 실전 파이프라인 구현: 펜싱 토큰 발행기 및 스토리지 검증 시뮬레이터

다음은 분산 락 획득 시 단조 증가 토큰을 발행하고, 프로세스 지연으로 인해 뒤늦게 인입된 무효 락의 스토리지 쓰기를 완벽히 차단하는 파이썬 엔지니어링 구현체입니다.

import time
import threading
import logging
from typing import Dict, Any, Optional, Tuple

logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s [%(levelname)s] (%(name)s) %(message)s',
    datefmt='%Y-%m-%d %H:%M:%S'
)
logger = logging.getLogger('FencingTokenEngine')

class FencingLockService:
    def __init__(self):
        self.lock = threading.Lock()
        self.current_holder: Optional[str] = None
        self.global_token_counter = 0

    def acquire_lock(self, client_id: str) -> Optional[int]:
        with self.lock:
            # 락 획득 시 단조 증가(Monotonically Increasing) 토큰 발행
            self.global_token_counter += 1
            self.current_holder = client_id
            token = self.global_token_counter
            logger.info(f'[LockService] 클라이언트 {client_id} 락 획득 성공 (발급 토큰: {token})')
            return token

    def release_lock(self, client_id: str):
        with self.lock:
            if self.current_holder == client_id:
                self.current_holder = None
                logger.info(f'[LockService] 클라이언트 {client_id} 락 반납 완료')

class ValidatedStorageServer:
    def __init__(self):
        self.storage_data: Dict[str, Any] = {}
        # 각 리소스별 마지막으로 승인된 최고 펜싱 토큰 기록
        self.last_fencing_tokens: Dict[str, int] = {}
        self.lock = threading.Lock()

    def write_resource(self, resource_id: str, payload: Any, client_fencing_token: int) -> bool:
        with self.lock:
            last_token = self.last_fencing_tokens.get(resource_id, 0)

            # 스토리지 계층 펜싱 토큰 유효성 검증: Token > LastToken
            if client_fencing_token <= last_token:
                logger.error(
                    f'[Storage 거부] 무효화된 펜싱 토큰 감지! '
                    f'제시된 토큰={client_fencing_token} <= 최신 승인 토큰={last_token} (GC 지연 클라이언트 차단)'
                )
                return False

            # 검증 통과: 스토리지 갱신 및 토큰 업데이트
            self.storage_data[resource_id] = payload
            self.last_fencing_tokens[resource_id] = client_fencing_token
            logger.info(f'[Storage 승인] 리소스={resource_id} 갱신 완료 (새 토큰={client_fencing_token})')

            return True

if __name__ == '__main__':
    lock_svc = FencingLockService()
    storage = ValidatedStorageServer()

    # 1. 정상 클라이언트 1 락 획득 (토큰 1)
    token_1 = lock_svc.acquire_lock('client_1')

    # 2. 클라이언트 1이 긴 GC Pause(일시중지)에 빠져 락이 만료되었다고 가정
    # 클라이언트 2가 새롭게 락 획득 (토큰 2)
    token_2 = lock_svc.acquire_lock('client_2')
    storage.write_resource('account_99', {'balance': 50000}, token_2)

    # 3. 뒤늦게 깨어난 클라이언트 1이 오래된 토큰(1)으로 쓰기 시도 -> 스토리지에서 즉각 거부 차단
    success = storage.write_resource('account_99', {'balance': 10000}, token_1)
    print('오래된 락 쓰기 시도 결과 (성공 여부):', success)

5. 성능 분석 벤치마크 및 프로덕션 RDBMS 적용 가이드

1,000건의 동시 경쟁 트랜잭션 환경에서 무작위 GC 일시중지(1~5초)를 주입했을 때 단순 분산 락과 펜싱 토큰 아키텍처의 데이터 정합성 보장 지표는 다음과 같습니다.

프로덕션 관계형 데이터베이스(MySQL, PostgreSQL)에 펜싱 토큰을 적용할 때는 다음과 같은 원자적 조건절 갱신을 사용해야 합니다.

UPDATE accounts SET balance = :new_balance, fencing_token = :token WHERE id = :id AND fencing_token < :token;

영향받은 행의 수(Affected Rows)가 0이면 다른 트랜잭션이 이미 선행 커밋되었음을 의미하므로 즉각 롤백(Rollback)하고 재시도하여 데이터 유실을 완벽히 방어할 수 있습니다.