해설 — 분산 락의 TTL 미갱신으로 인한 배치 중복 실행 (C++)

난이도: 상

요약

runIfDue 는 (A) 에서 분산 락(TryAcquire)을 도입해 "다른 노드가 이미 담당 중이면 스킵"하려는 시도는 했지만, 락 TTL(5초)이 실제 배치 실행 시간(수 분)보다 훨씬 짧고, 락을 유지하기 위한 갱신(하트비트) 절차가 전혀 없다. (B) 에서 배치를 실행하는 동안 락은 TTL 이 지나면 자동 만료되어, 그동안 배치가 끝나기를 기다리던(혹은 뒤늦게 재시도하던) 다른 노드가 같은 날짜 키로 새로 락을 획득할 수 있게 된다. 그 결과 원래 노드가 배치를 절반쯤 진행 중인데 다른 노드가 처음부터 같은 배치를 시작해, 온라인 플레이어들이 접속 보상을 중복 수령한다.

문제점

(A)(B) 락 TTL 이 작업 시간보다 짧고 하트비트 갱신 부재 — 실행 중 락 만료로 중복 시작

• 증상: 노드 1 이 배치를 시작해 3분째 진행 중인데(수만 명 순회), 5초 뒤 락이 자동 만료되어 노드 2 가 같은 todayKey 로 새 락을 획득하고 배치를 처음부터 다시 실행한다. 두 노드 모두 온라인 플레이어에게 보상을 지급하므로 전체적으로 이중 지급이 발생한다.
• 재현 조건: 배치 실행 시간(수 분) > 락 TTL(5초), 그리고 락 획득 후 별도 갱신 로직 부재.
  1. 노드 1 이 (A) 에서 TTL 5초로 락 획득 성공, (B) 에서 배치 시작.
  2. 5초 경과, 락 자동 만료(노드 1 은 여전히 배치 진행 중).
  3. 노드 2 가 같은 키로 (A) 를 재시도해 락 획득 성공, (B) 에서 배치를 새로 시작.
  4. 결과: 두 노드가 동시에 같은 플레이어들에게 보상을 지급 — 중복.
• 근본 원인: 락의 "유효 기간"과 "보호해야 할 작업의 실제 소요 시간"이 맞물려 있지 않다. TTL 을 짧게 잡아 죽은 노드가 락을 영원히 들고 있는 상황(데드락)은 방지했지만, 그 대가로 살아있는 노드가 작업 중인데도 락이 만료되는 정반대의 위험을 만들었다. 배치 진행 중 락을 갱신하는 절차가 없어 이 위험이 그대로 드러난다.

수정안 (정확한 코드)

락 획득 시 소유자 토큰을 함께 저장하고, 배치 실행 중 별도 스레드(또는 주기 콜백)로 하트비트를 보내 락을 갱신한다. 배치가 끝나면(또는 소유권을 잃으면) 안전하게 종료한다.

#include <string>
#include <vector>
#include <atomic>
#include <thread>
#include <chrono>

class IDistributedLockClient {
public:
    virtual ~IDistributedLockClient() = default;
    // 소유자 토큰과 함께 원자적으로 락 획득. 성공 시 true.
    virtual bool TryAcquire(const std::string& key, const std::string& ownerToken, int ttlMs) = 0;
    // 소유자 토큰이 일치할 때만 TTL 연장(하트비트). 이미 다른 소유자로 넘어갔으면 false.
    virtual bool TryExtend(const std::string& key, const std::string& ownerToken, int ttlMs) = 0;
    virtual void Release(const std::string& key, const std::string& ownerToken) = 0;
};

class DailyRewardScheduler {
    IDistributedLockClient& lockClient_;
    std::string nodeId_;          // 이 노드를 식별하는 소유자 토큰(프로세스 시작 시 생성)
    std::string lastRunDate_;

public:
    DailyRewardScheduler(IDistributedLockClient& lockClient, std::string nodeId)
        : lockClient_(lockClient), nodeId_(std::move(nodeId)) {}

    void runIfDue(const std::string& todayKey) {
        if (lastRunDate_ == todayKey)
            return;

        constexpr int kTtlMs = 30000;      // 하트비트 주기보다 넉넉한 TTL
        constexpr int kHeartbeatMs = 10000; // TTL 의 1/3 주기로 갱신

        if (!lockClient_.TryAcquire(todayKey, nodeId_, kTtlMs))
            return; // 다른 노드가 이미 담당 중이거나 오늘 이미 처리됨

        lastRunDate_ = todayKey;

        // 배치 실행 중 락을 주기적으로 갱신하는 하트비트 스레드.
        std::atomic<bool> stopHeartbeat{false};
        std::thread heartbeatThread([&] {
            while (!stopHeartbeat.load(std::memory_order_relaxed)) {
                std::this_thread::sleep_for(std::chrono::milliseconds(kHeartbeatMs));
                if (stopHeartbeat.load(std::memory_order_relaxed)) break;
                if (!lockClient_.TryExtend(todayKey, nodeId_, kTtlMs)) {
                    // 소유권을 잃었다(다른 노드가 가져갔거나 이미 만료됨) — 더 이상
                    // 이 프로세스가 배치를 계속할 권한이 없다는 신호.
                    break;
                }
            }
        });

        runDailyRewardBatch();

        stopHeartbeat.store(true, std::memory_order_relaxed);
        heartbeatThread.join();
        lockClient_.Release(todayKey, nodeId_);
    }

private:
    void runDailyRewardBatch() {
        for (int playerId : getOnlinePlayers()) {
            // 플레이어별 멱등 마커(player, date)를 함께 남겨, 하트비트 실패로 두 노드가
            // 겹쳐 실행되더라도 개별 지급 단위에서 중복을 한 번 더 차단한다.
            grantLoginRewardIdempotent(playerId);
        }
    }

    std::vector<int> getOnlinePlayers() { return {}; }
    void grantLoginRewardIdempotent(int /*playerId*/) { /* 멱등 지급 */ }
};

핵심: ① TTL 을 넉넉히 잡고 그 1/3 수준의 주기로 하트비트를 보내 배치 실행 중 락이 만료되지 않게 한다. ② 하트비트 갱신이 실패하면(소유권을 잃었다는 뜻) 배치를 계속하지 않고 중단해야 한다(위 스니펫은 단순화를 위해 갱신 실패 시 루프만 빠져나오지만, 실무에서는 배치 본체도 협조적으로 중단 신호를 확인해야 한다). ③ 플레이어별 멱등 마커로, 드물게 두 노드가 겹치더라도 개별 지급 단위에서 중복을 막는 이중 방어선을 둔다.

더 나은 설계 (+ 트레이드오프)

• 리더 선출: 매 배치마다 짧게 락을 얻고 놓는 대신 클러스터의 리더 노드를 장기간 선출해두면, 스케줄 작업 자체를 "리더만 실행"으로 단순화할 수 있다. 리더 장애 감지·failover 로직이 추가로 필요하다.
• 펜싱 토큰: 하트비트 갱신 실패를 감지하더라도 이미 진행 중인 DB 쓰기가 롤백되지 않을 수 있다 — 락 획득 시 단조 증가 토큰을 받아 모든 지급 쓰기에 그 토큰을 검증하면, 소유권을 잃은 뒤의 늦은 쓰기를 거부할 수 있다(concurrency_memory/problem12 참고).
• 작업을 작은 청크로 분할: 배치를 "플레이어 1000명 단위" 로 쪼개 각 청크마다 락을 짧게 재획득하면 하트비트 없이도 TTL 을 짧게 유지할 수 있다. 대신 청크 경계에서 진행 상태를 영속화해야 재개가 가능하다.
• 트레이드오프: 하트비트 방식은 기존 분산 락 인프라를 그대로 재사용할 수 있어 도입이 쉽지만, 갱신 스레드 관리·갱신 실패 시 작업 중단 로직 등 구현 복잡도가 늘어난다. 리더 선출은 초기 구축 비용이 크지만 장기적으로 스케줄러 로직이 단순해진다.

면접 포인트

1. 분산 락의 TTL 은 "죽은 소유자를 얼마나 빨리 회수할 것인가"와 "살아있는 소유자가 작업을 마칠 때까지 얼마나 오래 보호할 것인가" 사이의 트레이드오프다 — 작업 시간이 가변적이거나 길면 반드시 하트비트 갱신이 필요하다.
2. 하트비트 갱신 실패는 "소유권을 잃었다"는 신호이므로, 그 이후에도 부수효과(DB 쓰기 등)를 계속하면 펜싱 토큰 없이는 안전하지 않다.
3. 분산 락만으로 exactly-once 를 완벽히 보장하기 어려운 엣지 케이스에 대비해 멱등 마커 등 애플리케이션 레벨 이중 방어선을 두는 것이 실무적으로 안전하다.