동시성 문제

9 min read

사용자님이 걱정하시는 부분은 **“Redis가 1번 요청을 처리하는 아주 짧은 순간에 2번 요청이 들어오면, 문전박대(Connection Refused) 당하고 에러가 터지지 않을까?”**라는 것이군요.

결론부터 말씀드리면 “전혀 걱정하지 않으셔도 됩니다. 튕기지 않고 알아서 줄을 섭니다.”

사용자님이 별도의 Queue(RabbitMQ, Kafka 등)를 만들지 않아도 되는 이유는 이미 보이지 않는 곳에서 2단계로 줄을 세워주고 있기 때문입니다.

1. “누가 줄을 세워주나요?” (Hidden Queues)

Spring이나 Redis 코드가 아니라, 운영체제(OS)와 네트워크 계층이 이 역할을 해줍니다.

1단계: OS의 소켓 버퍼 (The Waiting Room)

Redis 서버(컴퓨터)의 운영체제에는 **‘네트워크 소켓 버퍼(Socket Buffer)‘**라는 공간이 있습니다.

  • A가 SETNX를 처리하고 있는 0.00001초 동안 B, C, D의 요청이 도착하면?

  • 운영체제가 이 요청들을 **메모리 버퍼(대기실)**에 차곡차곡 쌓아둡니다. (튕겨내지 않습니다!)

  • Redis가 A 처리를 끝내자마자, 대기실에서 B를 데려와서 처리합니다.

2단계: Spring의 Connection Pool (Client Side)

Spring Boot(Lettuce 또는 Jedis 라이브러리)도 그냥 막 요청을 던지는 게 아닙니다.

  • 커넥션 풀(Connection Pool): 미리 연결된 선들을 관리합니다.

  • 모든 선이 바쁘면? 잠시 **대기(Wait)**했다가 선이 비면 요청을 보냅니다. 즉, 클라이언트(Spring)단에서도 에러를 내뿜는 게 아니라 아주 잠깐 기다립니다.

2. Redis의 속도 vs 인간의 속도

사용자님이 걱정하는 “처리하는 동안”이라는 시간이 인간의 감각과는 차원이 다릅니다.

  • Redis의 SETNX 처리 속도: 약 0.000005초 (5마이크로초) 내외.

  • 1초에 처리 가능한 양: 기본 사양에서도 5만~10만 건 이상.

상황 예시: 배틀 게임에 1,000명이 동시에 접속해서 정답 버튼을 눌렀습니다.

  • Redis 입장에서는 1,000건 처리는 0.01초도 안 걸리는 일입니다.

  • 줄을 서긴 서는데, 그 대기 시간이 사람 눈에는 **“동시”**처럼 보일 정도로 짧습니다.

3. 언제 튕기나요? (Extreme Case)

물론 무한대로 받아주는 건 아닙니다. “소켓 버퍼가 꽉 찰 정도로” 요청이 폭주하면 그때는 튕길 수 있습니다. (Packet Drop)

하지만 그 정도가 되려면:

  1. 네이버 메인에 광고가 걸려서 전 국민이 동시에 클릭하거나,

  2. DDoS 공격 수준으로 초당 수십만 건이 들어와야 합니다.

사용자님이 기획하신 **“소규모 인원의 배틀”**이나 **“수백 명 단위의 서비스”**에서는 Redis가 숨도 안 차고 다 처리합니다.

💡 요약 및 결론

  1. 튕기나요? ❌ 아니요. OS(소켓)와 Spring(라이브러리)이 알아서 잠깐 대기시켰다가 순서대로 처리합니다.

  2. Spring이 줄 세우나요? ✅ 정확히는 Spring의 **Redis 클라이언트(Lettuce)**와 OS의 네트워크 스택이 줄을 세워서 Redis에게 하나씩 떠먹여 줍니다.

  3. 결론: SETNX 로직 하나면 충분합니다. Queue를 따로 구현하실 필요 없습니다.

마음 편하게 SETNX로 구현하시면 됩니다! 🚀

네, 정확합니다! 그게 바로 현업에서 Redis를 사용하는 가장 큰 이유입니다.

서버가 1대일 때는 그냥 자바 메모리(HashMap)에 저장해도 되지만, 서버가 2대 이상(Scale-out)이 되는 순간 Redis 같은 “공용 저장소”가 필수가 됩니다.

이 개념을 “각자의 수첩” vs “중앙 칠판” 비유로 설명해 드릴게요.

1. Redis가 없을 때 (각자의 수첩)

서버 A와 서버 B가 각각 HashMap을 쓴다고 가정해 봅시다.

  • 상황:

    1. 사용자가 로그인 요청을 보냄 → 서버 A가 받음.

    2. 서버 A: “OK, 로그인 성공! 내 수첩(메모리)에 적어놔야지.”

    3. 잠시 후, 사용자가 ‘내 정보 조회’ 요청을 보냄 → 로드밸런서가 이번엔 서버 B로 보냄.

    4. 서버 B: (자기 수첩을 뒤적거리며) “어? 넌 로그인 기록이 없는데? 다시 로그인해!”

  • 결과: 사용자는 분명 로그인을 했는데 계속 튕깁니다. (동기화 불가)

2. Redis를 쓸 때 (중앙 칠판)

모든 서버가 Redis라는 하나의 거대한 외부 칠판을 바라봅니다.

  • 상황:

    1. 사용자 로그인 → 서버 A가 받음.

    2. 서버 A: “로그인 성공! **저기 중앙 칠판(Redis)**에 적어놔야지.” (SET user:1:login true)

    3. 사용자 조회 요청 → 서버 B가 받음.

    4. 서버 B: (Redis를 쳐다보며) “아, 아까 A가 적어놨네? 로그인된 사람이구나. 통과!”

  • 결과: 사용자가 어느 서버에 접속하든 똑같은 데이터를 볼 수 있습니다. 이것을 “세션 공유(Session Clustering)” 또는 **“전역 상태 관리”**라고 합니다.

3. 사용자님 프로젝트(배틀)에서의 결정적 역할

아까 우리가 이야기했던 **동시성 제어(SETNX)**도 Redis가 공유되기 때문에 가능한 것입니다.

만약 Redis 없이 각 서버 메모리에서 처리한다면?

  • 서버 A: “내 메모리엔 아무도 정답 처리 안 했네? 철수가 1등!”

  • 서버 B: “내 메모리에도 아무도 없네? 영희가 1등!”

  • 결과: 1등이 두 명이 나오는 대참사가 벌어집니다.

하지만 **Redis는 모든 서버가 공유하는 “유일한 심판”**이기 때문에, 서버 A와 B가 동시에 물어봐도 Redis가 딱 한 명만 손을 들어줄 수 있는 것입니다.

💡 요약

  1. 공유되나요? 네! Spring Boot 서버가 100대가 되어도, Redis 설정(application.yml)에 적힌 주소(host: my-redis) 하나를 다 같이 바라봅니다.

  2. 역할: “서버들끼리 데이터를 공유하는 만남의 광장”입니다.

  3. 필수: 서버를 여러 대로 늘리는 스케일 아웃(Scale-out) 환경에서는 선택이 아니라 필수입니다.

이제 왜 Redis가 백엔드 아키텍처의 핵심인지 완벽하게 이해되셨죠? 🚀

Files