큐는 현대 컴퓨팅에서 매우 유용한 도구입니다. 웹 애플리케이션에서는 느릴 수 있는 계산을 나중에 수행하기 위해 자주 사용됩니다. 기본적으로 큐는 계산을 예약되는 시점과 실행되는 시점의 두 시점으로 나눌 수 있게 해 줍니다. "프로듀서"는 실행할 작업을 큐에 넣고, "컨슈머" 또는 "워커"는 큐에서 작업을 가져와 실행합니다. 예를 들어 웹 애플리케이션에서 새 사용자가 등록 절차를 마치면, 활성화 링크가 포함된 이메일을 보내기 위해 웹 애플리케이션은 새 작업을 큐에 추가합니다. 이메일을 실제로 보내는 과정은 일시적인 네트워크 실패나 다른 오류가 있을 때 재시도가 필요할 수 있으며, 이는 워커의 몫입니다.

기술적으로 말하자면, 큐는 프로세스 간 메시징 프리미티브의 한 형태로 생각할 수 있습니다. 여기서 수신 프로세스는 메시지의 수신을 확인해야 합니다. 큐는 메시지를 큐에서 제거해도 되는지 알아야 하므로, 메시지를 보내고 잊는(fire-and-forget) 방식은 불가능하며, 어떤 형태로든 수신 확인이 반드시 필요합니다.

우리가 이야기하는 종류의 큐에서는 메시지를 수신하는 것이 작업 실행을 촉발합니다. 이때 메시지 수신이 확인되는 시점에 따라 큐의 의미가 달라집니다. 워커 프로세스가 메시지를 처리하기 전에 수신을 확인하면, 워커가 실패할 경우 메시지는 작업이 전혀 수행되기 전에 손실될 수 있습니다. 메시지를 처리한 후에만 확인을 보내면, 워커가 실패하거나 네트워크 분할로 인해 큐가 메시지를 다시 전달할 수 있습니다. 이는 큐의 일관성 속성과 관계없이 발생하므로, 큐가 강한 일관성을 제공하는 시스템으로 모델링되더라도 불확정성은 여전히 유효합니다:

• 메시지가 처리 전에 확인되면, 큐는 최대 한 번 전달(at-most-once delivery) 속성을 가집니다. 즉, 메시지는 0번 또는 1번 처리될 수 있습니다.
• 메시지가 처리 후에 확인되면, 큐는 최소 한 번 전달(at-least-once delivery) 속성을 가집니다. 즉, 메시지는 1번에서 무한 번까지 처리될 수 있습니다.

이 두 경우 모두 완벽하지는 않지만, 실제 세상에서는 두 번째 동작이 선호되는 경우가 많습니다. 메시지가 여러 번 전달되어 작업이 여러 번 실행되는 상황을 처리하는 것이, 때때로 특정 작업을 전혀 실행하지 않는 시스템을 처리하는 것보다 훨씬 간단하기 때문입니다. 최소 한 번 전달 시스템의 예로는 Amazon SQS(Simple Queue Service)가 있습니다.

최소 한 번 전달 시스템이 선호되어야 하는 근본적인 이유도 있습니다. 분산 시스템과 관련된 이유로, 다른 의미론인 최대 한 번 전달(at-most-once delivery)은 큐가 강한 일관성을 요구합니다. 메시지가 한 번 확인되면 다른 어떤 워커도 같은 메시지를 확인할 수 없어야 하는데, 이는 강력한 속성입니다.

최소 한 번 전달 시스템으로 초점을 옮기면, 큐를 CP 시스템으로 모델링하는 것이 낭비이자 불리함이라는 사실을 알 수 있습니다:

• 어차피 최소 한 번 전달 이상을 보장할 수 없습니다.
• 큐가 네트워크 분할의 소수 측에서 작동할 수 있는 능력을 잃습니다.
• 일관성 요구 때문에 큐는 합의가 필요하므로, 합당한 이유 없이 성능을 소모하고 지연 시간을 추가합니다.

메시지가 여러 번 전달될 수 있으므로, 개념적으로 우리가 원하는 것은 교환 법칙이 성립하는 데이터 구조와 최종 일관성 시스템입니다. 메시지는 N개의 노드에 복제된 집합 데이터 구조에 저장될 수 있으며, 병합 함수는 집합들의 합집합입니다. 워커가 메시지를 실행한 후 보내는 확인 응답도 개념적으로 집합의 원소이며, 특정 원소가 처리되었음을 표시합니다. 이는 실제 시스템에 특히 실용적이지 않은 사소한 예이지만, 특정 종류의 큐가 분산 시스템의 특정 속성 집합으로 잘 모델링될 수 있음을 보여줍니다.

실용적으로 보면, 큐가 제공하려 할 수 있는 다른 유용한 기능들이 있습니다:

• 적어도 일정 시간 동안 단일 워커에게 전달을 보장합니다. 다중 전달은 허용되지만, 가능한 한 피하고 싶습니다.
• 이미 처리된 메시지가 타임아웃 후 다시 전달되는 것을 피하기 위한 최선 노력(best-effort) 검사를 제공합니다. 다시 말하지만, 이 속성을 보장할 수는 없지만, 실제로 이미 처리된 메시지를 다시 발행하는 것을 줄이기 위해 노력할 수는 있습니다.
• 정상 운영 중 메시지를 FIFO로 처리할 수 있는 충분한 내부 상태를 유지합니다. 그래야 먼저 도착한 메시지가 먼저 처리됩니다.
• 내부 데이터 구조를 자동으로 정리합니다.

이에 더해 네트워크 분할 중에도 메시지를 보존해야 합니다. 그래야 개념적으로(실제로는 다른 데이터 구조를 사용할 수 있겠지만) 전달할 메시지 집합이 모든 노드의 모든 메시지의 합집합이 됩니다.

안타깝게도 Redis 기반 큐 구현은 많이 존재하지만, 아무도 N개의 독립적인 Redis 노드와 제공되는 프리미티브를 이러한 특성을 가진 분산 시스템의 구성 요소로 사용하려고 시도하지 않습니다. Redis의 데이터 구조와 성능, 그리고 특정 유용한 보장을 제공하는 알고리즘을 사용하면, 사용하기에 매우 실용적이고 관리와 확장이 쉬우며 노드당 뛰어난 성능(초당 메시지 수)을 제공하는 큐 시스템을 만들 수 있을 것입니다.

이 주제가 흥미롭고 Redis의 훌륭한 사용 사례라고 생각하기 때문에, 저는 그러한 Redis 기반 큐 시스템에 대한 설계를 아주 천천히 진행하고 있습니다. 시간이 허락된다면 다음 몇 주 안에 무언가를 보여드릴 수 있기를 바랍니다.