Redis 보편적인 동시성 해결 방법

Question

토이 프로젝트에 Redis를 적용하기 위해 스터디 중이며, 아직은 초반 부분만 이해한 상태입니다.지금까지 강의에서 이해한 내용은 다음과 같습니다:Redis는 완전한 싱글 스레드 방식은 아니지만, 클라이언트 명령어(command)는 싱글 스레드로 처리됩니다.하지만 Spring과 같은 클라이언트에서 Redis의 값을 읽어와 계산하는 과정에서 동시 요청이 발생할 수 있고, 이때 Spring 애플리케이션 내부에서 동시성 문제가 발생할 수 있습니다.예시 시나리오:1. 클라이언트 A: GET counter → 102. 클라이언트 B: GET counter → 103. 클라이언트 A: counter + 1 → 11 → SET counter 114. 클라이언트 B: counter + 1 → 11 → SET counter 11 → 동시성 이슈 발생위와 같이 로직이 수행되면 4번 과정에서 counter의 값이 덮어쓰기되어 잘못 갱신되는 문제가 발생합니다.전통적인 RDBMS에서는 트랜잭션 락을 통해 값이 갱신되거나 사용 중일 경우 다른 트랜잭션이 잠시 대기하도록(lock) 처리됩니다.하지만 Redis는 기본적으로 이러한 락 기능을 제공하지 않기 때문에, 동시성 제어를 사용자가 직접 구현해줘야 합니다.현재까지는 여기까지 이해한 상태입니다.여기서 궁금한 점Redis는 고속 처리를 위해 전통적인 DB의 기능(예: 트랜잭션 락 등)을 의도적으로 제외한 것으로 알고 있습니다.그런데 강의에서 말한 것처럼 락(lock)을 직접 구현해서 문제를 해결해야 한다는 부분이 직관적으로 이해되지 않습니다."속도를 위해 락을 제외했는데, 결국 락을 구현해서 다시 느려지는 것 아닌가?" 라는 생각이 들었고,단순한 로직은INCRBY, DECRBY 명령어를 사용하여 해결해도 되겠지만 복잡한 로직이 들어가는 경우이처럼 사용자가 락을 구현해서 처리하는 방식이 실제로 보편적으로 많이 사용되는지 궁금합니다.

mylife · Answer

다르말인데 혹시 강의 어떤거 들으시나여?? 레디스 강의 찾고 있습니다 ㅠㅜ

Paimon · Answer

일반적으로 레디스는 캐싱처럼 그정도의 불일치는 허용하는 대신 빠른 속도가 필요한 경우에 사용됩니다.보통은 락을 구현할 정도로 값이 정확해야한다면 RDB나 그런 트랙잭션을 지원하는 다른 NoSQL 기술을 쓰는 경우가 대부분입니다.

ㅇㅈㅇ · Answer

학습을 위한 예시로 쓴 거 겠지만일단 위와 같은 문제는 incr 로 해결됩니다.

zoony · Answer

조금 다른 이야기지만 redis를 이용해서 분산락 처리에 사용하기도 합니다. spring이라면 redisson이 유명합니다.

엡실론 · Answer

특수한 상황을 제외한다면 일반적인 동시성 제어에는 락이나 락 비슷한 요소가 반드시 필요합니다. 그런면에서 락이 반드시 성능상 나쁜건 아닙니다.레디스 자체에서도 watch를 통해서 낙관적 락을 지원하긴 한데, 낙관적 락은 트래픽이 몰리는 상황에서는 불리합니다.락을 서버에서 단순히 synchronized로 구현할 수는 없습니다. 서버가 한대라면 몰라도 여러대가 있는 경우 사용할 수는 없으니까요. 대신 레디스를 사용한 redlock이라는 분산락 알고리즘이 있습니다. 이를 구현한 redisson 같은 라이브러리를 사용하는게 편하겠죠.

전뚱이인데요 · Answer

분산락 사용하지 않나요?그리고 분산락 알고리즘은 cas 알고리즘 사용할껄요 cas 이름이 맞는지 헷갈리네요 싱글스레드지만 메모리로 돌아가서 빠르게 처리하는걸로 압니다그리고 정말 대용량 일 때 redis 다중화 해서 사용할껄요..?

초무쿤 · Answer

메시지큐(MQ)를 쓰시는게 맞지 않나 싶은데요.(kafka, rabbitmq activemq등)래디스는 그냥 키-벨류 인메모리 저장소입니다.MQ대용으로 사용하면 사고 나유~

스토리 · Answer

락을 구현하기 보다 Redis lua script 사용 하시면 됩니다.redis 명령어는 큐에 넣어서 처리되는데, lua script 자체가 하나의 세트로 원자적으로 처리됩니다.https://redis.io/docs/latest/develop/interact/programmability/eval-intro/

꼬끼꼬꼬개발자 · Answer

간만에 재밌는 질문이..일단 트랜잭션은 정말 복잡합니다!단순히 락 이라고 표현하기에는 내부 구조가 어마어마하게 복잡하고 각 범용 혹은 상용 dbms마다 구현 형태가 다릅니다.동시성으로 인한 경쟁상타를 배제하기 위해 redis를 사용한다는것은 트랜잭션을 사용하는것과는 살짝 다릅니다. 트랜잭션은 완벽한듯 하지만 완벽하지 않습니다. 교착상태가 얼마든지 생길 수 있습니다.하지만 redis를 통해 해결할 수 있는 부분이 생깁니다, 단순하게 생각해보자면, 1번 스레드와2번 스레드가 있다고 가정하고A라는 요소에 락을 건다고 했을때 1번 a가 있는가?2번 a가 있는가?둘다 없다면? 서로 락을 획득하기 위한 키를 생성할거고 이걸 단순히 set 이 아닌 set nx 를 통해 진행하면 경쟁상태 돌입시 둘중 하나의 스레드만 성공응답을 받게됩니다. 이런 방식을 통해 스핀락 형태로 구현된 기능이 lettuce에 있으며, redisson은 이걸넘어 redis의 pub/sub기능까지 활용하여 분산락 형태의 기능을 제공해 주는걸로 알고 있습니다.저도 예전에 공부한거라 정확히 기억은 안나지만 대충 이러합니다.데이터중심어플리케이션설계 라는 책을 보시면 각종 데이터 저장소에 대한 설명과 단순히 락이라는 범주를 벗어나 동시성에서 생기는 이런 경쟁을 해결하기 위해 어떤 방식을 어떻게 사용했는지 설명이 적당히 되어있으니 참고하시면 좋을거 같아요.

레벨1개발자 · Answer

서버가 1개라면 굳이 락을 이용하는 것보단 synchronized를 사용하고서버가 여러대이면 Radisson 사용할 것 같네요

skrevolve · Answer

동시성제어를 할일이 없도록 구성하는게 제일 현명합니다. 정확하게 제어가 되도록 복잡하게 짠다고 하더라도 나중에 유지보수하는것까지 생각해보세요. 트랜젝션이 중요한 기능이면 보수적으로 가야죠. Bullmq 같은 소스를 까보면 락전략을 어떻게 구성했는지 알수있습니다. 트랜젝션이 중요하면 락을 피할수없죠. 락키 구성, 키만료 조회 속도 개선할때 알고리즘 전략은 서비스유형에 따라 다양합니다.. 같은키를 쓰니 복잡해지는 문제는 각이벤트나 엔트리를 나눠서 zscore 나노초단위로 조회하면 빠르죠

shin7688 · Answer

3년 전 부터 Redis 를 사용하여 데이타 캐쉬를 저장하였습니다. 사용자가 많고 쉽게 사용할 수 있어서 사용하였죠.2년 전 부터는 Hazelcast 를 사용하였습니다. 성능 이슈와 데이타 일치성 문제가 있어 Hazelcast 사용 하였습니다.IMDG(In-Memory Data Grid) 관련 이슈 중에 하나가 데이타 일치성 문제일것 같습니다.Redis 는 문서에도 많이 나와 있지만 마스터에 쓰고 이후 슬레이브에 복제가 늦어져서 데이타가 일치하지 않을 확률이 높습니다.아무래도 IMDG 구조에 적합한 Hazelcast 또는 다른 IMDG 제품을 추천 합니다.

Redis 보편적인 동시성 해결 방법

12개의 답변

Q&A 목록