대규모 처리 시 Redis 연산의 Atomic을 보장하기

F-Lab : 상위 1% 개발자들의 멘토링

2023-11-19

안녕하세요. 중급 개발자를 양성하는 상위 1% 개발자들의 멘토링 F-Lab의 대표 멘토 Fitz 입니다.

Redis는 여러 규모있는 회사에서 사용하는 인메모리 데이터베이스입니다.

인메모리 데이터베이스인만큼 스케일 아웃을 적용했을 때 공통으로 쓰는 값들을 저장하기도 하고, 이러한 특성을 이용하여 분산 락을 적용하기도 하는 등 꽤 쓸모가 많은 툴입니다.

하지만 공유하는 값에 동시 연산을 하게 되면 동시성 문제가 발생하여 의도치 못한 값을 얻게 되어 버그를 유발할 수 있는데요, 물론 트래픽이 적을 경우도 문제가 발생하지만 특히 동시에 여러 연산이 자주 일어나는 대규모 시스템에선 문제가 발생할 가능성이 더 커집니다.

이 글에서는 레디스로 Atomic한 연산을 보장할 수 있게하여 안전한 어플리케이션을 구현하는 법을 공유합니다.

[목차]

  1. Atomic한 연산이란?
  2. 레디스의 연산은 기본적으로 Atomic
  3. 레디스에서 Atomic이 깨지는 경우
  4. 레디스에서 Atomic을 보장하기 위해 제공하는 기능
  5. 어디서 쓰고 있을까?
  6. 마무리

Atomic한 연산이란?

먼저 Atomic한 연산이란 무엇일까요?

연산이 Atomic하다는 것은 말 그대로 더 이상 쪼개질 수 없는 연산이라는 말입니다.

평소에 자주 쓰는 연산자인 i++ 를 예로 들어보겠습니다. 이는 Atomic한 연산일까요?

정답은 “아니다” 입니다. i++ 는 아래와 같은 단위로 이루어집니다.

메모리에서 i 라는 변수에 들어있는 값을 읽는다.
읽은 값에 1을 더한다.
i 라는 변수에 결과값을 덮어씌운다.

갑자기 떠오르는 의문이 있습니다. 결국 쪼개지는 것은 맞는데 어떨 때, 왜 문제가 되는걸까요? 🤔

i라는 변수에 0이 들어있는 상황을 가정해보겠습니다. 그리고 2개의 스레드가 동시에 i++ 연산을 수행했습니다. 그럼 아래와 같은 상황이 벌어집니다.

이렇게 했을 때 우리가 예상하기론 i에는 2가 들어가야 합니다. 하지만 정말 2가 들어갈까요?

이에 대한 답 또한 “아니다” 입니다. 정답은 “아무도 모른다” 입니다.

많은 경우의 수 중 하나를 예시로 들어드리자면, 스레드들의 동작이 동시에 진행된다는 상황을 가정하여 아래의 그림처럼 표현할 수 있습니다.

이처럼 우리는 i++ 가 2번 일어나므로 2가 될 것을 기대했지만, 결과로 돌려받는 값은 1이 되었습니다.

이렇게 여러 스레드가 접근하는 상황에서 우리가 예상하는 답과 실제 답이 일치하지 않을 때 “스레드 세이프하지 않다” 라고 표현합니다.

만약 저 값을 우리가 의도한대로 2가 나오게 하려면 synchronized 블록으로 감싸야합니다. 하지만 이는 성능을 크게 저하시키기에 다른 방법을 사용해야 합니다. 이를 다루기엔 너무 길어지니 이러한 내용은 다른 글에서 다루도록 하겠습니다.

위와 같은 상황은 서버가 1대일 때에도 공유 변수가 있다면 가능한 시나리오이며, 여러 서버가 참조하고 있는 전역 변수인 레디스의 값에도 적용되는 내용입니다.

레디스의 연산은 기본적으로 Atomic이 보장됩니다.

만약 위의 i++ 연산을 레디스에서 하려면 어떻게 해야할까요? 기본적으로 아래와 같이 할 수 있을 것 같습니다.

get 명령어로 레디스에 저장된 값을 읽어온다.
1을 더한다.
set 명령어로 값을 덮어쓴다.

하지만 마찬가지로 연산이 이렇게 진행된다면 여러 서버에서 동시에 레디스에 요청을 날리게 되었을 때 똑같이 잘못된 값이 보여지는 문제가 발생할겁니다.

이러한 문제를 대비해서 레디스는 연산의 Atomic을 보장하는 명령어를 제공하고 있습니다.

예를 들자면 위와 같은 목적으로 데이터를 변경하기 위해서 INCR 명령어를 제공합니다.

이 명령어는 여러 서버가 동시에 명령을 날려도 synchronized 키워드를 쓴 것처럼 명령어가 묶여서 실행되기에 Atomic이 보장됩니다.

아래는 레디스 공식 문서의 INCR 설명입니다.

시간 복잡도가 O(1)이기 때문에 성능이 빠릅니다. (대규모 데이터를 다룰 땐 잘못된 명령어 한 번에 레디스가 뻗을 수 있기 때문에 시간 복잡도는 잘 보고 연산하셔야 합니다.)

이렇게 공식 문서를 검색해보면 우리가 의도하는 연산을 제공하고 있을 가능성이 높습니다.

또한 레디스에서 제공하는 명령어를 쓰면 이렇게 묶여서 연산되기에 필요한 연산이 있다면 레디스 공식문서를 뒤져보는 습관을 기르는 것이 좋습니다.

(레디스 공식 문서 링크 : https://redis.io/commands/)

레디스에서 Atomic이 깨지는 경우

위에서 얘기드린 바와 같이 레디스의 명령어들은 Atomic이 보장됩니다. 하지만 그럼에도 Atomic이 깨지는 경우가 있습니다.

아마 눈치채셨을 수도 있지만 아까 INCR 명령어를 쓰지 않고 i++ 연산을 구현했던 것과 같이 여러 명령어를 조합해서 쓸 때 Atomic이 깨지게 됩니다. 그래서 여러 명령어를 조합해서 쓸 때에는 꼭 Atomic이 깨지지 않는지 유의해야 합니다.

아까 본 “공유 변수와 스레드” 그림에서 각각 “레디스와 서버”로만 바뀌었을 뿐 연산에 대한 것은 똑같습니다.

레디스에서 Atomic을 보장하기 위해 제공하는 기능

그렇다면 레디스는 이 문제를 해결하기 위해 어떤 도구들을 제공할까요?

Lua Script

레디스는 Lua 언어를 통해 명령어 조합을 스크립트로 사용할 수 있습니다.

EVAL 명령어를 통해 사용할 수 있으며, 이 스크립트는 레디스 레벨에서 연산의 Atomic이 보장되기에 안전하게 사용할 수 있습니다.

예시로 i++ 와 같은 동작을 하는 스크립트는 이렇게 작성해볼 수 있습니다.

(가독성을 높이기 위해 줄바꿈을 했으며, \를 생략했습니다.)

EVAL "
	local i = redis.call('get', 'i'); 
	i = i + 1;
	redis.call('set', 'i', i);
"

자세한 내용과 응용은 공식 문서를 읽고 적용해보시면 됩니다

(공식문서 링크 : https://redis.io/docs/interact/programmability/eval-intro/)

Transaction

레디스에서는 트랜잭션 기능 또한 제공합니다. (DB를 쓰면서 많이 보신 그 개념이 맞습니다.)

스크립트를 쓰는 방식과 다르게 명령어 형태로 트랜잭션의 범위를 지정할 수 있습니다. 예시를 들자면 아래와 같이 사용해볼 수 있습니다.

MULTI
... 조합할 명령어들
EXEC

마찬가지로 자세한 내용은 아래의 공식문서 링크를 참고해보실 수 있습니다.

(공식문서 링크 : https://redis.io/docs/interact/transactions/)

[퀴즈]
  공식 문서에 따르면 레디스의 트랜잭션이 실행될 땐
  "다른 클라이언트"의 요청을 처리하지 않는다고 합니다.
  
  레디스는 "다른 클라이언트"를 어떤 방식으로 식별할까요?

어디서 쓰고 있을까?

예전 2019년 하이퍼커넥트 재직 당시 분산 락에 대한 블로그 글을 하이퍼커넥트 테크블로그에 기고한 적이 있습니다.

(링크 : https://hyperconnect.github.io/2019/11/15/redis-distributed-lock-1.html)

이때 첨부했던 RedissonLock 을 예시로 보여드릴 수 있습니다.

이렇게 오픈소스에서도 여러 명령어 조합을 Atomic하게 만들어 버그를 방지하면서 성능을 높일 수 있도록 하고 있습니다.

❗️ 분산 락은 꼭 필요할 때만 써야 합니다.

최근 취준생분들의 포트폴리오에 분산락이 많이 보입니다.
학습용으로 사용해 본건 좋지만 문제 해결 관점에서
분산락을 어필하기란 쉽지 않을겁니다.

락을 건다는 것은 병목 지점을 만드는 것입니다.

물론 손 쉽게 동시성 문제를 해결할 수 있지만,
락을 걸지 않을 방법이 있다면 쓰지 않는게 낫습니다.

개인적으론 난이도와 성능의 트레이드오프라 생각합니다.