Redis에 대해 설명해주세요

[Libienz]

레디스는 인메모리 기반의 NoSQL 저장소입니다. 레디스는 캐시, 메시지 큐, 분산 락 구현체로 사용될 수 있습니다.

[ay-eonii]

자바의 대표적인 Redis 클라이언트로 Jedis와 Lettuce가 있습니다. 두 클라이언트를 비교해주세요.

[Libienz]

Jedis는 Lettuce와 Redisson보다 간결하게 구현되어 빠르게 동작합니다. Redis 명령어를 직접 사용하는 저수준 클라이언트입니다. 동기 방식이기 떄문에 간단한 구조의 애플리케이션에 적합합니다. 다만 멀티스레드 환경에서는 커넥션 풀을 사용해야 함으로 관리 포인트가 생깁니다.

Lettuce는 비동기, 논블로킹을 지원해서 고성능 시스템이나 멀티스레드 환경에 적합합니다. Lettuce는 자체적으로 스레드 세이프함으로 커넥션 풀이 필요 없습니다.

[ay-eonii]

락을 활용해야 한다면 어떤 클라이언트를 사용하실 건가요? 그 이유에 대해서도 설명해주세요

[Libienz]

Redis 기반의 분산 락을 구현해야 한다면 저는 Redisson 클라이언트를 선택하겠습니다. Redisson이 분산 락 기능을 기본적으로 제공하기 떄문입니다. Redisson은 Redis를 단순한 캐시나 데이터 저장소로만 사용하지 않고 분산 환경에서 활용할 수 있는 다양한 고급 기능을 제공합니다. 다른 클라이언트들은 기본적으로 분산 락을 위한 고수준 API를 제공하지 않습니다. 물론 Lua 스크립트나 다른 명령어 조합으로 직접 락을 구현할 수 있지만 불필요한 오버헤드가 될 것 같다는 생각입니다.

하지만 만약에 Redisson이 너무 무겁다고 판단되는 경우에는 Lettuce를 활용하여 가벼운 spinning 방식의 lock을 구현하겠습니다. 그렇지만 락은 시스템 전체의 데이터 무결성과 동시성 제어에 관여하기 때문에 기본적으로는 안정성 있는 Redisson을 사용하겠습니다.

[ay-eonii]

Lettuce가 spinning 방식의 Lock이라고 말씀해주셨는데, Redisson은 어떤 방식으로 Lock을 지원한는지 설명해주세요

[Libienz]

pub/sub 방식의 락을 활용합니다. spinning lock과는 다르게 잠금을 얻을 수 있는지 여부를 알려주는 채널을 구독하고 잠금이 해제되는 경우 이를 알 수 있도록 하는 방식인데요 잠금 시간이 길어지는 경우의 spinning lock의 리소스 낭비 문제를 pub/sub 방식으로 보완할 수 있습니다.

[ehtjsv2]

레디스도 저장소이니까 race condition문제가 발생할까요?

[Libienz]

레디스는 싱글 스레드 기반으로 동작함으로 하나의 자원에 여러 트랜잭션이 붙는 경합 상태는 존재하지 않습니다. 다만 레디스를 운용하면서도 여러 명령이 원자적으로 실행되어야 하는 경우가 있는데요 이 경우 MULTI/EXEC 명령을 활용하거나 루아 스크립트를 활용할 수 있습니다.

[ehtjsv2]

여러 명령이 원자적으로 실행되어야 하는 경우는 어떤 경우가 있나요? 그리고 MULTI/EXEC 명령에 대해 설명해주세요

[Libienz]

여러개의 키를 한번에 변경해야 하는 경우가 있습니다. 또 유량제어를 위한 카운터 값을 레디스에서 보관할 경우 이를 증가시키는 경우 역시 여러 명령어가 원자적으로 실행되어야 합니다.

MULTI/EXEC 명령어는 MULTI 명령어로 트랜잭션을 시작하고 EXEC 명령어를 호출하여 큐에 저장된 모든 명령어가 순서대로 실행됩니다. 트랜잭션 내의 명령어들은 중간에 다른 클라이언트가 개입할 수 없기 때문에 원자성이 보장됩니다.

MULTI
SET key1 "Hello"
SET key2 "World"
EXEC

[ehtjsv2]

레디스를 활용해서 유량제어를 하고 있을 때, 원자적으로 처리하지 않고 있다면 어떤 경우에 문제가 될 수 있을까요? 예를 들어 설명해주세요
그리고 혹시 레디스를 활용한 유량제어 경험이 있나요?

[Libienz]

특정 기능이 초당 100회 요청 제한을 두는 유량제어를 Redis로 구현하는 경우를 설명드리겠습니다.
이때 클라이언트는 레디스에 현재 요청 수를 조회하고 요청 수가 제한 이하인지 확인해야합니다.
만약 99개의 요청이 쌓인 상태에서 두 클라이언트가 동시에 요청이 99개인 것을 확인했다면 두 스레드 모두 자신의 요청이 유효할것이라고 생각하고 INCR 명령으로 요청 수를 증가시키게될 수 있습니다. 이 경우 101건의 요청이 처리되게 되어 처리율 제한을 넘어가는데요 이를 위해서 연산을 원자적으로 수행할 수 있는 방법을 사용해야 합니다.

---

레디스를 활용해 유량 제어를 직접 구현한 경험은 없습니다. 다만 유량제어를 구현하게 된다면 유량제어에도 여러가지 알고리즘이 있는 것으로 알고 있는데요 각 알고리즘의 장단점을 기반으로 트레이드오프지점을 계측하고 적절한 알고리즘을 선택하여 구현하겠습니다.

[helenason]

레디스를 캐시로 사용할 때 주의해야할 점은 무엇이 있나요?

[Libienz]

캐시는 데이터의 사본을 배치하는 작업으로 항상 복제되는 데이터와 원본 데이터사이의 정합성을 고려해야합니다. 정합성을 강하게 달성할 것이냐 약하게 달성할 것이냐 여부에 따라 강한 일관성 전략을 채택할수도 있고 궁극적 일관성 전략을 채택할 수 있습니다.

또 Redis는 싱글 스레드 기반으로 동작하기때문에 O(N) 명령어에 유의해야 합니다. 대표적인 O(N) 명령어는 KEYS가 있는데요, 이러한 명령어 대신 Redis의 공식문서에서 추천하는 SCAN 명령어등을 대신 활용해볼 수 있습니다.

추가적으로 캐시는 자주 무효화되고 변경되는 경우 오히려 오버헤드가 되고 메모리 파편화로 이어질 수 있습니다. 잘 변하지 않고 자주 조회되는 데이터들이 캐시를 적용하기에 적합함을 인지하고 메모리 파편화를 관찰하는 것도 중요합니다.

[helenason]

레디스는 왜 싱글 스레드 기반으로 동작하도록 구현했을까요? 멀티 스레드가 아닌 싱글 스레드를 사용했을 때의 이점이 무엇이었을까요?