[Redis] Redis는 언제 활용할 수 있을까? 1편 - 분산락 구현하기 (2)

🌱 들어가기 전

지난 포스팅에서는 레디스를 활용해 분산락을 구현하는 다양한 방법들을 살펴보았다.

이번 포스팅에서는 조금 더 색다른 방법으로 레디스를 활용하여 분산락을 구현해보고자 한다.

 

---

 

✔ Case 4 - Lua Script 활용하기

Redis 2.6 버전에서 루아 스크립트 엔진이 추가되면서, 레디스 서버에서 루아 스크립트를 실행할 수 있게 되었다.

레디스 내부에서는 EVAL (혹은 EVALSHA)이라는 명령어를 통해 사용할 수 있다.

EVAL script numkeys [key [key ...]] [arg [arg ...]]

만약 스크립트가 길어지게 된다면 스크립트 전체를 EVAL로 전송하기에는 네트워크 대역의 비용이 발생할 수 있기 때문에, 레디스에서는 SCRIPT LOAD 명령어를 통해 스크립트를 서버 측에 캐싱한 다음에, 캐싱 후 반환된 키를 활용해 EVALSHA로 스크립트를 관리할 수 있다.

(물론 이것도 마냥 좋은 건 아니고, 레디스 노드가 많아진다면 캐싱도 전체 노드에서 해야 하기 때문에 문제가 있을 수 있다.)

 

루아(Lua)는 일종의 프로그래밍 언어로, 절차지향적 언어이다. 사실 C, C++와 사용하는 경우가 많지만, 레디스에서 사용하게 되면 사용자가 레디스 명령어를 직접 작성할 수 있으며, 해당 스크립트가 실행되는 동안에는 원자성을 보장하게 된다.

이는 마냥 좋은 점은 아닌 게, 스크립트에 대한 실행 요청이 들어왔을 때 다른 레디스 명령어들은 실행이 불가능하기 때문에 스크립트의 실행 시간이 반드시 고려되어야 한다. 하나의 스크립트에 여러 레디스 명령어를 사용하면서 원자성을 보장하고 싶을 때 주로 사용한다.

 

override fun executeScript(key: String, value: String, duration: String, script: RedisScript<Boolean>): Boolean {
    return redisTemplate.execute(script, listOf(key), value, duration)
}

redisTemplate는 스크립트를 실행할 수 있는 execute() 메서드를 제공하고 있으며, 실제로 내부 구현체를 살펴보면 eval()을 사용하는 것을 볼 수 있었다. 아래의 코드를 이해할 필요는 없고, 그냥 eval을 사용하고 있구나... 정도로만 넘어가자!

또한, key의 리스트와 내부 스크립트에서 사용할 변수들을 가변 인자로 (args) 받을 수 있는 것을 확인할 수 있다.

 

아무튼, 이에 맞춰서 한 번 비즈니스 로직을 생성해보자.

@PostMapping("/withdraw-lua")
fun withdrawUsingLuaScript(@RequestBody request: WithdrawRequest): ResponseEntity<BalanceResponse> {
    val result = accountService.withdrawUsingLuaScript(request)
    return ResponseEntity.ok(result)
}

@Transactional
fun withdrawUsingLuaScript(request: WithdrawRequest): BalanceResponse {
    val accountId = request.accountId
    val accountKey = keyGenerator.generateAccountKey(accountId)
    // 파일로 로드해도 되지만 직관적으로 여기에 넣었다.
    val script = """
        local key = KEYS[1]
        local value = ARGV[1]
        local expiration = tonumber(ARGV[2])

        local existingValue = redis.call('GET', key)
        if not existingValue then
            redis.call('SET', key, value, 'EX', expiration)
            return true
        else
            return false
        end
    """.trimIndent()
    val redisScript = RedisScript<Boolean>(script)

    while (!cacheService.executeScript(accountKey, "account-withdraw", "5", redisScript)) {
        Thread.sleep(1000)
    }

    val account = accountRepository.getAccountById(accountId)
    account.subtractBalance(request.amount)

    // 캐시 제거
    cacheService.delete(accountKey)
    return BalanceResponse(account.id, account.balance)
}

스크립트의 경우 파일로 관리해도 되지만, 그렇게 길지 않기 때문에 문자열을 사용하여 바로 로드하였다.

local key = KEYS[1]
local value = ARGV[1]
local expiration = tonumber(ARGV[2])

local existingValue = redis.call('GET', key)
if not existingValue then
    redis.call('SET', key, value, 'EX', expiration)
    return true
else
    return false
end

내부 스크립트를 한 번 살펴보자.

KEYS를 통해 listOf(key)로 넘겨준 키의 첫 번째 값을 받아오고, ARGV를 통해 각각 인자로 넘겨준 변수를 사용한다.

이때, 숫자값을 사용하기 위해서 tonumber()를 활용할 수 있다.

내부 로직의 경우 GET을 통해 받아오고, 만약 값이 존재하지 않으면 SET을 통해 값을 지정하고, 아니면 false를 반환하는 간단한 로직이다. 사실상 앞서 Case 2번의 애플리케이션 레벨에서 진행했던 행위를 루아 스크립트를 통해서 원자성을 보장하도록 만들어준 것이다. 

 

@Test
fun 루아스크립트를_통한_동시_출금요청() {
    // given
    val accountId = 계좌_생성()
    초기_잔액_설정(accountId, 100)
    val requestCount = 2

    // when
    // 동시에 20씩 출금을 요청함
    val executor = Executors.newFixedThreadPool(requestCount)
    val latch = CountDownLatch(requestCount)
    repeat(requestCount) {
        executor.submit {
            루아스크립트를_통한_출금_요청(accountId, 20)
            latch.countDown()
        }
    }

    latch.await()

    // then
    val balanceResponse = 잔액_조회(accountId)

    // 락으로 인해서 순차적으로 처리되기 때문에 정상적으로 60 반환
    assertThat(balanceResponse.balance)
        .isEqualTo(60)
}

 private fun 루아스크립트를_통한_출금_요청(accountId: Long, amount: Int): BalanceResponse {
    val withdrawRequest = WithdrawRequest(accountId, amount)

    return RestAssured.given()
        .log().all()
        .contentType(MediaType.APPLICATION_JSON_VALUE)
        .`when`()
        .body(withdrawRequest)
        .post("/accounts/withdraw-lua")
        .then()
        .log().all()
        .extract()
        .`as`(object : TypeRef<BalanceResponse>() {})
}

테스트 코드를 돌려보면 역시 잘 동작하는 것을 확인할 수 있었다.

 

---

 

✔ Case 5 - 스핀락 대신 pub-sub 구조 활용하기 (Redisson)

하지만, 앞선 방식들은 모두 스핀락을 사용하다 보니 락을 얻기 위해서 레디스 서버로 계속 요청을 보내야 한다는 부담이 있다.

또한, 앞선 예제들에서는 키에 대해 TTL도 걸어주고, 명시적으로 delete도 지정해주었기 때문에 크게 문제가 되지 않았지만, 개발자가 직접 스핀락을 구현하다 보니 만약 TTL을 빼먹거나, 키에 대한 삭제 처리를 진행하지 않으면 계속 락을 점유하는 문제가 발생할 수도 있다.

 

그래서, Lettuce 대신에 Redission에서 제공하는 분산락을 사용하여 이를 해결해보자.

Redisson의 경우 기본적으로 Pub-Sub 기반의 구조이기 때문에 계속 연결을 시도하지 않는다.

Publish-Subscribe (Pub-Sub) 구조는 Publisher와 Subscriber가 서로 알지 못해도 통신이 가능하도록 만들어진 패턴이다.
Publisher는 Subscriber에게 직접적으로 메시지를 보내지 않고, Channel에 publish를 진행하게 된다.
Subscriber는 관심이 있는 채널을 필요에 따라 Subscribe를 통해 메시지를 수신할 수 있다.

해당 채널을 Subscribe를 하고 있는 스레드들이 Publish된 메시지를 받아야 락 점유를 시도하기 때문에 비교적 부하가 덜하다.

레디스에서는 다음과 같이 명령어를 제공하고 있다.

// order라는 채널에 대해서 new-order라는 메시지 발행 예제
PUBLISH order new-order

// order, delivery라는 채널에 대해서 메시지 구독 예제
SUBSCRIBE order, delivery

publish 시 채널과 발행할 메시지를 입력하고, subscribe 시 구독하고 싶은 채널 이름을 나열하면 된다.

publish 후 성공적으로 메시지를 발행하면 1을 반환하고, 만약 아무도 구독하고 있지 않는 채널에 발행을 하면 0을 반환한다.

 

 

이를 코드로 구현하기 위해 다음과 같은 의존성을 추가해주도록 하자.

implementation("org.redisson:redisson-spring-boot-starter:3.23.5")

 

그리고, 비즈니스 로직을 작성해보자.

@PostMapping("withdraw-redisson")
fun withdrawUsingRedisson(@RequestBody request: WithdrawRequest): ResponseEntity<BalanceResponse> {
    val result = accountService.withdrawUsingRedisson(request)
    return ResponseEntity.ok(result)
}

@Service
class AccountService(
    // RedissonClient에 대해 의존성 주입 필요
    private val redissonClient: RedissonClient,
    private val accountRepository: AccountRepository,
    private val keyGenerator: KeyGenerator
) {

    @Transactional
    fun withdrawUsingRedisson(request: WithdrawRequest): BalanceResponse {
        val accountId = request.accountId
        val accountKey = keyGenerator.generateAccountKey(accountId)

        // 락 획득
        val lock = redissonClient.getLock(accountKey)
        try {
            val canLock = lock.tryLock(3, 5, TimeUnit.SECONDS)
            if (canLock.not()) {
                throw RuntimeException("락 획득에 실패하였습니다.")
            }
            val account = accountRepository.getAccountById(accountId)
            account.subtractBalance(request.amount)
            return BalanceResponse(account.id, account.balance)
            
        } finally {
            // 락 해제
            lock.unlock()
        }
    }
}

redissionClient에서는 getLock()이라는 메서드를 통해 인자로 넘겨준 이름을 가진 Lock instance를 생성한다.

이때, 스레드가 락을 획득하는 순서를 보장하지 않는다. (non-fair locking이라고 하는데, 조금 더 정확하게는 특정 스레드가 먼저 들어와서 오랫동안 락을 대기하고 있을 때, 새로운 스레드가 와서 요청을 보내면 옛날 스레드가 아니라 새로운 스레드가 락을 점유할 수 있다는 의미인 것 같다. 참고 링크)

 

이후, 가져온 인스턴스가 락을 획득할 수 있는 상황이라면 (tryLock) 점유하고, 아니라면 예외를 발생하도록 만들었다.

항상 락에 대한 해제 로직은 돌아야 하기 때문에 try-finally 구문을 통해 unlock을 꼭 해주도록 하자.

 

한 번 테스트 코드로 확인해보자.

@Test
fun 레디슨을_통한_동시_출금요청() {
    // given
    val accountId = 계좌_생성()
    초기_잔액_설정(accountId, 100)
    val requestCount = 2

    // when
    // 동시에 20씩 출금을 요청함
    val executor = Executors.newFixedThreadPool(requestCount)
    val latch = CountDownLatch(requestCount)
    repeat(requestCount) {
        executor.submit {
            레디슨을_통한_출금_요청(accountId, 20)
            latch.countDown()
        }
    }

    latch.await()

    // then
    val balanceResponse = 잔액_조회(accountId)

    // 락으로 인해서 순차적으로 처리되기 때문에 정상적으로 60 반환
    assertThat(balanceResponse.balance)
        .isEqualTo(60)
}

private fun 레디슨을_통한_출금_요청(accountId: Long, amount: Int): BalanceResponse {
    val withdrawRequest = WithdrawRequest(accountId, amount)

    return RestAssured.given()
        .log().all()
        .contentType(MediaType.APPLICATION_JSON_VALUE)
        .`when`()
        .body(withdrawRequest)
        .post("/accounts/withdraw-redisson")
        .then()
        .log().all()
        .extract()
        .`as`(object : TypeRef<BalanceResponse>() {})
}

아주 잘 돌아가는 것을 확인할 수 있다.

 

이대로 끝내면 아쉽기 때문에, 내부적으로 어떻게 pub-sub 구조를 통해 락을 획득하는지 확인해보자.

boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException;

먼저, tryLock의 경우 내부적으로 3개의 인자를 받는다.

waitTime은 락을 사용할 수 있을 때까지 대기하는 시간, leaseTime은 락을 점유하는 시간, unit은 시간에 대한 단위이다.

이는 즉, leaseTime이 지나게 되면 자동으로 락이 해제되며, 이미 락을 점유하고 있는 스레드가 존재할 때 다른 스레드가 요청을 보내면 waitTime까지 대기한다는 의미이다.

 

tryLock의 내부 로직을 살짝 살펴보면 한 가지 흥미로운 점을 발견할 수 있는데, 바로 루아 스크립트를 활용한다는 점이다.

위와 같이 키의 존재에 대한 여부 확인 및 해당 키의 값에 대한 증가는 루아스크립트를 통해 진행하고 있었다.

락이 존재하지 않는다면 락에 대한 키와 스레드 아이디를 기반으로 값을 1 증가시키고, TTL을 설정하는 로직이다.

 

그리고, tryLock 메서드의 하단으로 내려가보면 아래와 같이 락에 대해 대기하는 로직이 나온다.

이때, subscribe 내부 로직을 보면 세마포어를 활용하고 있다.

앞서 말했던 것처럼, 멀티 스레드 환경인 스프링부트가 싱글 스레드 기반인 레디스를 호출하게 되면 동시성 문제가 발생할 수 있기 때문에, 세마포어를 활용해서 항상 하나의 스레드만 접근이 가능하도록 만들고 있는 것을 확인할 수 있다.

subscribe를 실패하면 (예외가 발생하면) false를 반환하며 로직을 종료한다.

 

이후, while문을 돌면서 남아 있는 시간 동안 락을 획득하기 위해 재시도를 진행한다.

여기서 tryAcquire()에 의해 반환되는 ttl 값은 현재 스레드가 점유를 시도하고 있는 락이 다른 스레드에 의해 언제 해제될지 나타내는 값을 (= 락이 얼마나 더 유지될지) 의미하며, null이라면 락을 획득할 수 있는 상태이기 때문에 true를 반환하게 된다.

만약 락 획득에 실패했다면 time (waitTime을 나타내며, 대기 시간을 의미한다)의 값을 갱신해주고, 갱신된 값이 만료되었다면 락 획득에 실패했다고 간주하여 false를 반환하게 된다.

 

이후, 아직 대기 시간이 남아 있는 상태라면 현재 시간을 다시 갱신한다.

만약 ttl (락에 대해 남은 유효 시간)이 0보다 크거나 같으면서 time (남은 대기 시간)보다 작으면 ttl 시간 동안 다시 락 획득을 대기하며, 그게 아니라면 남은 대기 시간 동안 기다리게 된다. (= 그냥 획득을 ttl, time만큼 대기하며 시도한다고 생각하기)

최종적으로 대기 시간인 time을 갱신하고, 만료되었다면 락 획득에 실패했다고 간주하고 false를 반환하게 된다.

 

그리고 마지막으로 이러한 락 획득 시도가 종료되면 unsubscribe를 통해 구독을 해제한다.

마찬가지로 구독 해제 시에도 이렇게 세마포어를 활용하는 것을 볼 수 있다.

 

---

 

🌱 마무리

레디스 관련해서 계속 써야지, 써야지 했는데 어쩌다 보니 계속 미루다가 이제서야 작성하게 되었다.

10월에는 글 2개 정도는 올리도록 노력해봐야겠다... 🥲 나태해진 나 반성해... 

 

+ 무조건 레디스를 통해 분산락을 도입해야 한다고는 생각하지 않는다.

모든 기술의 도입에는 이유가 있어야 한다고 생각하기 때문에... 레디스를 활용하지 않더라도 얼마든지 동시성 제어는 가능하다.

앞으로 도입을 하게 된다면 무작정 도입하지 않고, 이러한 점들에 대해 trade-off를 잘 고민해봐야겠다 😶