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

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

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

자, 이런 질문이었습니다. 어 대기열을 소티드 셋이 아닌 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를 사용하는 이유

Scripts