안녕하세요. 코딩하는 기술사입니다. 어제 그 대규모 선착순 예매 시스템 설계 영상에 달린 질문들에 답변하는 영상을 올렸는데요.

오늘은 그 질문들 중에서 하나를 뽑아왔습니다.

어 이 다른 구독자분들께도 도움이 될 만한 내용이라서 한번 말씀드려 보겠습니다.

자, 이런 질문이었습니다. 어 대기열을 소티드 셋이 아닌 MQ를 사용하면 정렬 연산 없이 선착순 구현이 가능한데 왜 소티드 셋을 사용했나요?

예. 즉 MQ로 선착순 하면 되는데 왜 Redis Sorted Set을 사용하냐는 질문인데요.

이 질문이 좋은 이유가 기능만 보면 MQ가 맞거든요.

근데 왜 MQ를 안 쓰고 Redis의 솔티드 셋을 사용했는지 말씀드리겠습니다.

자, Redis, MQ 둘 다 선입선출이죠. 줄 세우기 처리가 가능한데 왜 Redis일까요?

자, 핵심은 보여줘야 하기 때문입니다.

무엇을? 사용자에게 자신의 이 대기 순서가 얼마나 남았는지를 보여주는 이 UX, 이게 대기열의 필수 기능이기 때문이죠.

즉 선착순 처리도 중요하지만 사용자에게 지속적으로 이 피드백을 주는 게 필요하기 때문입니다.

여기서부터 MQ와 레디스의 길이 갈리는 겁니다.

현재 이 요구 사항에서 MQ의 문제점을 보겠습니다. 먼저 순번 확인이 불가합니다.

MQ는 본질적으로 이렇게 파이프에 흘려 보내는 구조입니다.

이 메시지는 기본적으로 앞에서부터 컨슘, 이렇게 꺼내가는 구조고요.

이 Q 내부를 랜덤하게 조회하는 게 어렵습니다. 이런 특징을 이 터널로 비유할 수 있겠는데요.

터널에는 그 차가 분명히 줄 서서 들어가지만 내가 터널 안에서 몇 번째인지 바로 확인하기 어렵죠.

많이 사용하는 MQ 카프카 같은 Q는 이 로그는 남기지만 거기서도 핵심은 내가 어디까지 읽었냐 그 오프셋의 개념이지 특정 사용자의 위치를 즉시 찾는 대기열 기능은 아닙니다.

다시 말해 MQ는 대기열의 상태 조회가 아니라는 거죠.

어, 반면 레디스의 ZSET, 레디스의 ZSET은 큐라기보다는 랭킹 명단에 가깝습니다.

대기열 자체를 데이터 구조로 이렇게 들고 있고, 어 특정 유저가 몇 번째 있는지 바로 알 수 있어요.

이때 ZRANK 명령어를 사용합니다.

이게 왜 좋냐면 사용자가 새로고침을 눌러도 처음부터 다시 뒤쪽에 줄을 세우는 게 아니라 줄 자체가 서버에 남아 있는 거죠.

이렇게 대기열에서는 상태 관리가 중요한데 ZSET은 이것을 아주 쉽게 해결해 줍니다.

자, 레디스의 이 Sorted Set이 어 대기열 운영 기능을 위해서 제공하는 것들을 보겠습니다.

어 그 대기열 안에 특정 유저의 순번 조회 인원 이걸 사용하면 내 뒤에 얼마나 남았는지 알 수 있죠.

그리고 재접속에도 유저 아이디가 남아 있으면 똑같은 순번을 유지해 주고 어 중간에 대기열에서 특정 유저를 빼낼 수도 있어요.

어 그리고 당연히 처음부터 뭐 몇 번째까지 이렇게 한꺼번에 뽑아올 수도 있고요.

자 이런 명령어들은 따로 한번 찾아보세요. 자 그리고 MQ의 어떤 두 번째 문제점입니다.

어 중복 클릭 뭐 F5 새로고침 연타를 할 경우 어 대기열에서 진짜 흔한 장애의 원인은 이겁니다.

이 사람들이 어 빨리 하려고 클릭을 막 연타를 하거나 또는 새로 고침을 막 합니다.

어 MQ 같은 경우에는 그냥 막 넣으면 중복으로 메시지가 막 들어가요.

이렇게 막 누르면 그게 순서대로 다 들어가요.

결국 MQ에서 이 중복 제거를 하려면 컨슘 단계에서 별도로 중복 제거 로직을 가져가야 합니다.

반면에 레디스 셋 지셋은 멤버를 유저식 별값으로 잡고 스코어 값이 같으면 그 유저는 그냥 하나로 계속 유지가 됩니다.

아무리 새로운 새롭게 막 들어오더라도 이런 특성을 우리가 멱등성이라고 합니다.

멱등성 같은 요청을 여러 번 수행해도 결과가 항상 동일한 성질 지셋의 동일한 멤버에 대해서 동일한 스코어로 추가하면 이 지셋 애드 연산은 멱등적입니다.

이 대기열에서 멱등성이 보장되면 트래픽이 훨씬 안정됩니다.

어 그리고 이 MQ의 어 세 번째 문제점입니다. 어제 그 KTX 예약에서는 뭐 이런 기능은 없었지만요.

어 만일에 이 대기열을 기다리다가 사용자가 지쳐서 이 취소를 할 수 있게 한다면 그 유저는 대기열에서 빼야 되죠.

근데 MQ는 기본적으로 앞에서부터 순서대로 꺼내기 때문에 중간에 있는 유저만 콕 집어서 삭제하기가 어렵습니다.

이걸 또 구현하려면 보통 그 별도의 인덱스나 저장소를 붙여서 그 취소 목록을 따로 만들어야 해요.

그리고 컨슘 단계에서 그 취소된 사용자들을 걸러내는 식으로 만들어야 한다는 거죠.

반면 이 레디스의 ZSet은 그냥 ZREM 명령어만 사용하면 중간에 있는 대기열 중간에 있는 유저를 바로 삭제할 수 있습니다.

대기열은 이런 운영 기능이 들어가야 한다면 Redis가 압도적으로 편한 거죠.

어, 그래서 실무에서 아키텍처가 대충 이렇습니다.

어, 유저가 이 대기열에 줄 서고요. 그다음에 그 Redis에 `ZPOPMIN`이라는 그 ZSET 연산으로 처음부터 N번까지 어 일정 수를 통과시켜서 API를 보냅니다.

그럼 API가 그다음 영구적인 저장을 위해서 어 MQ에 이렇게 저장하고 MQ 백단에 뭐 DB가 있든 뭐 알림 처리를 하든 뭐 로그를 쌓든 후 처리를 하는 거죠.

어, 이때 이 비동기를 위해서 이 MQ 사용하면 좋습니다.

앞단은 대기열 조회 관리가 중요하니까 Redis, 뒷단은 처리량 비동기가 중요하니까 MQ.

자, 결론입니다. MQ는 비동기 처리와 버퍼링에 최적화가 되어 있고요.

Redis의 Sorted Set은 실시간 랭킹과 어 대기열의 상태 관리, 즉 대기열의 운영에 최적화되어 있습니다.

어, 나머지는 한번 읽어 보시고요.

질문 주신 구독자님 감사합니다. 자, 오늘도 파이팅입니다.

대규모 예매 시스템에서 대기열에 Kafka가 아닌 Redis를 사용하는 이유

코딩하는기술사

대기열 시스템에서 Redis Sorted Set을 사용하는 주된 이유는 사용자에게 실시간으로 대기 순서를 보여주는 UX 기능과 대기열 상태 관리가 필수적이기 때문입니다.

MQ는 순번 확인 및 특정 사용자 위치 조회가 어렵고, 중복 클릭 시 메시지가 중복으로 들어가며, 대기열 중간의 특정 사용자를 삭제하기 어렵다는 문제점이 있습니다.

Redis Sorted Set은 ZRANK로 순번 조회가 가능하고, 멱등성 보장으로 중복 요청 처리가 안정적이며, ZREM 명령어로 대기열 중간 사용자 삭제가 용이하여 대기열 운영에 효율적입니다.

코딩하는 기술사 채널에서 대규모 선착순 예매 시스템 설계 영상에 대한 질문 중 하나를 다룹니다. 질문은 **'대기열을 Redis Sorted Set이 아닌 MQ를 사용하면 정렬 연산 없이 선착순 구현이 가능한데 왜 Redis Sorted Set을 사용했는가?'**였습니다.

기능적인 측면만 본다면 MQ가 선착순 처리에는 적합해 보이지만, 실제 시스템에서는 Redis Sorted Set을 사용합니다. 그 이유는 **대기열의 핵심 기능이 단순히 선착순 처리가 아니라 사용자에게 자신의 대기 순서를 보여주는 UX(사용자 경험)를 제공하는 것**이기 때문입니다.

MQ는 본질적으로 파이프에 메시지를 흘려보내는 구조로, 앞에서부터 메시지를 꺼내가는 방식입니다. 따라서 **MQ 내부를 랜덤하게 조회하여 특정 사용자의 순번을 확인하는 것이 불가능**합니다. 이는 터널 안에서 자신의 차례를 바로 알기 어려운 것과 유사하며, 카프카와 같은 MQ도 특정 사용자의 위치를 즉시 찾는 대기열 기능은 제공하지 않습니다.

또한, MQ는 중복 클릭이나 새로고침 연타 시 메시지가 중복으로 들어갈 수 있습니다. **중복 제거를 위해서는 컨슘 단계에서 별도의 로직을 구현해야 하는 복잡성**이 따릅니다.

사용자가 대기열 중간에 취소하는 경우에도 MQ는 앞에서부터 순서대로 꺼내기 때문에 **중간 유저를 콕 집어 삭제하기 어렵습니다**. 이를 구현하려면 별도의 인덱스나 저장소를 만들고 컨슘 단계에서 취소된 사용자를 걸러내는 방식을 사용해야 합니다.

Redis ZSET(Sorted Set)은 큐라기보다는 랭킹 명단에 가깝습니다. **대기열 자체를 데이터 구조로 관리하며, `ZRANK` 명령어를 사용하여 특정 유저가 몇 번째 있는지 바로 알 수 있습니다.** 이는 사용자가 새로고침을 해도 순번이 유지되는 중요한 기능을 제공하며, 대기열의 상태 관리를 매우 쉽게 해결해 줍니다.

Redis Sorted Set은 대기열 운영을 위한 다양한 기능을 제공합니다. 특정 유저의 순번 조회, 잔여 인원 확인, 재접속 시 동일 순번 유지, 중간에 특정 유저 제거, 처음부터 일정 개수만큼 한꺼번에 뽑아오기 등이 가능하며, 특히 **멤버를 유저 식별값으로 사용하고 스코어 값이 같으면 중복으로 추가되지 않는 멱등성**을 보장하여 트래픽 안정화에 기여합니다.

대기열에서 유저를 취소해야 할 경우에도 **Redis ZSet은 `ZREM` 명령어 하나로 대기열 중간에 있는 유저를 즉시 삭제할 수 있어** 대기열 운영 기능이 필요한 경우 Redis가 압도적으로 편리합니다.

실무 아키텍처: Redis와 MQ의 조합

실무에서는 유저가 대기열에 줄을 서고, Redis의 `ZPOPMIN` 연산으로 일정 수의 사용자를 통과시켜 API로 보냅니다. 이 API는 영구 저장을 위해 MQ에 저장하고, MQ 백단에서 DB 저장, 알림 처리, 로그 적재 등의 후처리를 진행합니다. **앞단은 대기열 조회 관리가 중요하므로 Redis를 사용하고, 뒷단은 처리량과 비동기가 중요하므로 MQ를 사용**하여 각자의 장점을 활용하는 것이 일반적인 아키텍처입니다.

**MQ는 비동기 처리와 버퍼링에 최적화**되어 있으며, **Redis Sorted Set은 실시간 랭킹과 대기열의 상태 관리, 즉 대기열 운영에 최적화**되어 있습니다. 따라서 대규모 선착순 예매 시스템의 대기열에서는 사용자의 순번 확인과 효율적인 관리를 위해 Redis Sorted Set을 활용합니다.

Redis Sorted Set 대신 MQ를 사용했을 때 선착순 대기열 시스템에서 발생할 수 있는 주요 문제점들은 무엇인가요?

Redis Sorted Set이 MQ와 비교하여 대기열의 UX(사용자 경험) 측면에서 어떤 장점을 제공하는지 설명해 주세요.

Redis Sorted Set의 멱등성(Idempotency)이 대기열 시스템의 안정성에 어떻게 기여하는지 구체적으로 설명해 주세요.

실무에서 Redis Sorted Set과 MQ를 함께 사용하여 대규모 선착순 예매 시스템을 구축하는 일반적인 아키텍처는 무엇이며, 각 기술이 담당하는 역할은 무엇인가요?

선착순 예매 시스템 대기열에 Redis Sorted Set을 사용하는 이유 설명

MQ 대신 Redis Sorted Set을 사용한 이유에 대한 질문을 다룸

기능상으로는 MQ가 적합해 보이지만, Redis Sorted Set을 사용하는 이유를 설명할 예정임을 밝힘

MQ의 대기열 기능 한계점: 순번 확인 불가

사용자에게 대기 순서를 보여주는 UX가 대기열의 필수 기능이기 때문에 Redis를 사용한다고 설명

MQ는 파이프처럼 메시지가 흘러가는 구조라 Q 내부를 랜덤하게 조회하기 어렵고, 특정 사용자의 위치를 즉시 찾는 대기열 기능이 아님

카프카 같은 MQ는 로그는 남기지만, 특정 사용자의 위치를 즉시 찾는 대기열 기능은 아님

Redis Sorted Set의 대기열 기능 장점: 상태 관리 및 랭킹 명단

Redis ZSET은 큐라기보다는 랭킹 명단에 가깝고, 특정 유저가 몇 번째 있는지 ZRANK 명령어로 바로 알 수 있음

사용자가 새로고침해도 줄이 서버에 남아 있어 처음부터 다시 줄 서지 않아도 됨

Redis Sorted Set은 특정 유저의 순번 조회, 재접속 시 순번 유지, 특정 유저 제거, 여러 명 한 번에 뽑아오기 등 대기열 운영 기능을 제공함

MQ의 대기열 기능 한계점: 중복 클릭 처리 및 멱등성 문제

중복 클릭이나 새로고침 연타 시 MQ는 메시지가 중복으로 들어가며, 중복 제거를 위해 별도 로직이 필요함

Redis ZSET은 멤버를 유저 식별값으로 사용하고 스코어 값이 같으면 하나로 유지되는 멱등성을 보장하여 트래픽 안정화에 기여함

MQ의 대기열 기능 한계점: 대기열 중간 유저 삭제 어려움

사용자가 대기열에서 취소할 경우 MQ는 기본적으로 앞에서부터 꺼내기 때문에 중간 유저를 삭제하기 어려움

MQ에서 중간 유저를 삭제하려면 별도 인덱스나 저장소를 붙여 취소 목록을 만들고 컨슘 단계에서 걸러내야 함

Redis ZSET은 ZREM 명령어로 대기열 중간에 있는 유저를 바로 삭제할 수 있어 대기열 운영이 편리함

유저가 Redis 대기열에 줄 서고, ZPOPMIN 연산으로 일정 수를 통과시켜 API로 보냄

API는 영구 저장을 위해 MQ에 저장하고, MQ 백단에서 DB 저장, 알림 처리 등 후처리함

앞단은 대기열 조회 관리가 중요한 Redis, 뒷단은 처리량 비동기가 중요한 MQ를 사용함

결론: MQ와 Redis Sorted Set의 최적화 영역

MQ는 비동기 처리와 버퍼링에 최적화되어 있고, Redis Sorted Set은 실시간 랭킹과 대기열 상태 관리(운영)에 최적화되어 있음

대규모 예매 시스템에서 대기열에 Kafka가 아닌 Redis를 사용하는 이유

스크립트