백엔드 개발자를 위한 상위 6개 대기열 시스템

대기열 시스템에 대한 정보를 찾고 계신가요? 혹은 기존 시스템보다 더 나은 대안을 찾고 계신가요? 여러분에게 필요한 모든 정보를 여기에 모았습니다.

백엔드 개발에서 대기열 시스템은 마치 비밀과 같이 잘 알려지지 않은 영역입니다.

대기열 시스템을 찬양하는 시를 쓸 필요는 없지만, 백엔드 개발자가 대기열을 시스템에 성공적으로 통합하는 법을 배우게 되면 중급 개발자로 발돋움하게 된다고 생각합니다. 대기열은 고객 경험을 개선하고(이 부분은 더 자세히 살펴보겠습니다), 시스템의 복잡성을 줄이며 안정성을 향상시키는 데 기여합니다.

물론 트래픽이 거의 없는 간단한 웹 앱이나 브로셔 웹사이트에서는 대기열 시스템이 그다지 필요하지 않을 수 있습니다(일반적인 공유 호스팅 환경에서는 설치조차 불가능할 수도 있습니다). 그러나 규모가 작은 앱도 대기열 시스템의 이점을 누릴 수 있으며, 대규모 앱의 경우 대기열 시스템은 필수 불가결한 요소입니다.

시작하기 전에 한 가지 말씀드리자면, 대기열 시스템에 이미 익숙하고 다양한 옵션을 비교하고 싶으신 분들에게는 이어지는 소개 섹션이 다소 지루하게 느껴질 수 있습니다. 🙂 부담 없이 다음 섹션으로 바로 넘어가셔도 괜찮습니다. 소개 섹션은 대기열 시스템에 대한 막연한 개념만 있거나, 단지 이름만 들어본 분들을 위한 것입니다.

대기열 시스템이란 무엇일까요?

먼저 대기열이 무엇인지부터 알아보겠습니다.

대기열은 우리가 일상생활에서 흔히 볼 수 있는 실제 대기열을 모방한 컴퓨터 과학의 데이터 구조입니다. 예를 들어 매표소에 가면 사람들은 대기열의 맨 끝에 서게 되며, 맨 앞에 서 있는 사람이 먼저 표를 받게 됩니다. 이것을 "선입선출(FIFO)"이라고 부르기도 합니다. 컴퓨터 과학에서는 이러한 작업을 대기열에 저장하는 프로그램을 만들어 동일한 선입선출 방식으로 처리할 수 있습니다.

대기열은 그 자체로 실제 처리를 수행하지 않습니다. 작업이 처리될 때까지 기다리는 일종의 임시 저장소 역할만 합니다. 이 모든 내용이 다소 추상적으로 들릴 수 있지만, 너무 걱정하지 마세요. 다음 섹션에서 명확한 예시를 통해 설명해 드리겠습니다. 🙂

왜 대기열 시스템이 필요할까요?

장황한 설명 없이, 대기열 시스템이 필요한 주된 이유는 백그라운드 처리, 병렬 실행, 그리고 장애 복구 때문이라고 말씀드리고 싶습니다. 예시를 통해 더 자세히 살펴보겠습니다.

백그라운드 처리

만약 여러분이 시간이 중요한 전자상거래 마케팅 캠페인을 진행 중이고, 고객이 결제를 완료한 직후 "감사합니다" 페이지가 표시되기 전에 확인 이메일을 발송하도록 애플리케이션을 구축했다고 가정해 봅시다. 그런데 만약 연결하려는 메일 서버에 문제가 생겨 다운된다면, 웹페이지 로딩이 중단되어 사용자 경험에 심각한 문제가 발생할 것입니다.

수많은 고객 지원 요청을 받게 될 상황을 상상해보세요! 이 경우 이메일 발송 작업을 작업 대기열에 넣고, 고객에게는 성공 페이지를 보여주는 것이 훨씬 나은 해결책입니다.

병렬 실행

많은 개발자, 특히 간단하고 트래픽이 적은 앱을 주로 개발하는 사람들은 백그라운드 처리를 위해 크론 작업을 사용하는 데 익숙합니다. 데이터 크기가 감당할 수 없을 정도로 커질 때까지는 괜찮습니다. 예를 들어, 분석 보고서를 컴파일하여 사용자에게 이메일로 보내는 크론 작업이 있고, 시스템에서 분당 100개의 보고서를 처리할 수 있다고 가정해 보겠습니다.

앱이 성장하면서 분당 평균 100개 이상의 요청이 들어오기 시작하면, 시스템은 점점 더 많은 작업이 밀리게 되어 결국 모든 작업을 처리하지 못하게 될 것입니다.

대기열 시스템을 사용하면 여러 작업자를 설정하여 이 문제를 해결할 수 있습니다. 각 작업자는 작업을 선택하고(각각 100개의 보고서 포함) 병렬로 작업을 수행함으로써 훨씬 더 빨리 작업을 완료할 수 있습니다.

장애 복구

일반적으로 웹 개발자들은 실패를 생각하지 않는 경향이 있습니다. 우리는 우리가 사용하는 서버와 API가 항상 온라인 상태라고 당연하게 생각합니다. 하지만 현실은 그렇지 않습니다. 네트워크 중단은 너무나 흔하게 발생하며, 인프라 문제로 인해 우리가 의존하는 API가 다운될 수도 있습니다(혹시 "나는 아닐 거야!"라고 생각하기 전에, 대규모 Amazon S3 중단 사태를 잊지 마세요). 보고서 생성 예시로 다시 돌아가서, 만약 보고서 생성 과정 중 일부가 결제 API에 연결해야 하는데, 그 연결이 2분 동안 중단된다면 실패한 200개의 보고서는 어떻게 될까요?

대기열 시스템은 상당한 오버헤드를 수반합니다. 새로운 영역으로 진입하는 것이므로 학습 곡선이 가파르고, 애플리케이션과 배포가 복잡해지며, 대기 중인 작업을 100% 정확하게 제어할 수 없는 경우도 있습니다. 하지만 대기열 없이는 애플리케이션을 구축하는 것이 불가능한 상황도 분명히 있습니다.

이러한 점들을 고려하여 오늘날 널리 사용되는 백엔드/시스템용 대기열 옵션을 살펴보겠습니다.

Redis

Redis는 데이터 구조에 대한 지식 없이 데이터 문자열을 저장, 업데이트 및 검색하는 키-값 저장소로 알려져 있습니다. 이전에는 그랬을 수 있지만, 오늘날 Redis는 목록, 정렬된 집합, Pub-Sub 시스템과 같은 효율적이고 매우 유용한 데이터 구조를 제공하여 대기열 구현에 매우 적합합니다.

Redis의 장점은 다음과 같습니다.

• 완전한 인메모리 데이터베이스로 빠른 읽기/쓰기가 가능합니다.
• 매우 효율적입니다. 초당 100,000건 이상의 읽기/쓰기 작업을 쉽게 처리할 수 있습니다.
• 매우 유연한 지속성 체계를 제공합니다. 데이터 손실 가능성을 감수하고 최대 성능을 추구하거나, 일관성을 위해 성능을 희생하는 보수적인 모드로 설정할 수 있습니다.
• 클러스터링을 즉시 지원합니다.

Redis는 메시징/대기열/복구 추상화 기능을 제공하지 않으므로, 패키지를 사용하거나 직접 경량 시스템을 구축해야 합니다. 예를 들어, Redis는 프레임워크 작성자가 스케줄러를 구현한 Laravel PHP 프레임워크의 기본 큐 백엔드입니다.

Redis를 배우는 것은 어렵지 않습니다.

RabbitMQ

Redis와 RabbitMQ 사이에는 몇 가지 미묘한 차이가 있습니다. 먼저 이 차이점들을 명확히 해보겠습니다.

우선, RabbitMQ는 메시징이라는 보다 전문화되고 명확한 역할을 가지고 있으며, 이에 맞춰 구축되었습니다. 즉, RabbitMQ는 두 시스템 간의 중개자 역할을 하는 데 최적화되어 있습니다. 이는 데이터베이스 역할을 하는 Redis와는 다른 점입니다. 따라서 RabbitMQ는 메시지 라우팅, 재시도, 부하 분산 등 Redis에는 없는 다양한 기능을 제공합니다.

작업 대기열은 메시징 시스템으로도 생각해볼 수 있습니다. 여기서 스케줄러, 작업자 및 작업 "제출자"는 메시지 전달에 참여하는 개체로 간주할 수 있습니다.

RabbitMQ의 장점은 다음과 같습니다.

• 메시지 전달을 위한 더 나은 추상화를 제공하여 메시지 전달이 필요한 경우 애플리케이션 수준의 작업을 줄여줍니다.
• 정전 및 중단에 대한 복원력이 더 뛰어납니다(적어도 기본적으로 Redis보다 뛰어납니다).
• 분산 배포를 위한 클러스터 및 연합 지원을 제공합니다.
• 배포를 관리하고 모니터링하는 데 유용한 도구를 제공합니다.
• 거의 모든 주요 프로그래밍 언어를 지원합니다.
• Docker, Chef, Puppet 등 원하는 도구를 사용하여 배포할 수 있습니다.

RabbitMQ는 언제 사용해야 할까요? 비동기 메시지 전달이 필요하지만, 이 목록에 있는 다른 대기열 옵션의 복잡성을 감당할 준비가 되어 있지 않다면 RabbitMQ가 좋은 선택이 될 수 있습니다(아래 내용 참고).

ActiveMQ

만약 엔터프라이즈 환경에 있거나, 대규모 분산 앱을 구축하고 있으며, 항상 바퀴를 재발명하고 싶지 않다면(실수를 반복하고 싶지 않다면), ActiveMQ를 고려해 볼 가치가 있습니다.

ActiveMQ의 뛰어난 기능은 다음과 같습니다.

• Java로 구현되어 있어 깔끔한 Java 통합을 제공합니다(JMS 표준 준수).
• AMQP, MQTT, STOMP, OpenWire 등 다양한 프로토콜을 지원합니다.
• 보안, 라우팅, 메시지 만료, 분석 등과 같은 기능을 즉시 제공합니다.
• 널리 사용되는 분산 메시징 패턴을 기본적으로 지원하여 시간과 비용이 많이 드는 실수를 예방할 수 있습니다.

ActiveMQ가 Java에서만 사용할 수 있는 것은 아닙니다. Python, C/C++, Node, .Net 및 기타 생태계를 위한 클라이언트를 제공하므로, 향후 사용에 대한 걱정은 하지 않아도 됩니다. 또한 ActiveMQ는 완전히 공개된 표준을 기반으로 하므로, 경량 클라이언트를 쉽게 구축할 수 있습니다.

ActiveMQ는 단순히 메시지 브로커일 뿐이며, 자체 백엔드를 포함하고 있지 않습니다. 메시지를 저장하기 위해 지원되는 백엔드 중 하나를 여전히 사용해야 합니다. 특정 프로그래밍 언어(Celery, Sidekiq 등과 같은 다른 인기 있는 솔루션)와 관련이 없기 때문에 이 목록에 포함했습니다.

Amazon MQ

Amazon MQ는 여기에서 간단히 언급하고 넘어갈 수 없는 중요한 부분입니다. 만약 ActiveMQ가 여러분의 요구 사항에 이상적인 솔루션이라고 생각하지만, 인프라 구축과 유지 관리를 직접 처리하고 싶지 않다면, Amazon MQ는 이를 위한 관리형 서비스를 제공합니다. ActiveMQ가 지원하는 모든 프로토콜을 지원하며, 기능적으로는 아무런 차이가 없습니다. 내부적으로 ActiveMQ 자체를 사용하기 때문입니다.

관리형 서비스라는 장점이 있으므로, 사용 외에는 다른 부분에 대해서는 걱정할 필요가 없습니다. 또한 배포 내에서 다른 서비스 및 제품을 직접 활용할 수 있기 때문에(예: 더 빠른 데이터 전송), AWS 환경에 더 적합합니다.

Amazon SQS

Amazon이 주요 인프라 부분에 대해 가만히 있을 거라고 기대할 수는 없겠죠? 🙂

그래서 등장한 것이 Amazon SQS입니다. 잘 알려진 거대 AWS에서 완전히 호스팅되는 간단한 대기열 서비스입니다(말 그대로). 다시 한번 강조하지만, 미묘한 차이가 중요합니다. SQS는 메시지 전달 개념을 가지고 있지 않습니다. Redis와 마찬가지로 대기열에서 작업을 수락하고 배포하기 위한 간단한 백엔드입니다.

그렇다면 Amazon SQS는 언제 사용해야 할까요? 다음과 같은 몇 가지 이유가 있습니다.

• AWS의 열렬한 팬이며 다른 것은 사용하고 싶지 않을 때.
• 실패율이 0이고 작업이 손실되지 않도록 호스팅된 솔루션이 필요한 경우.
• 클러스터를 구축하고 직접 모니터링하고 싶지 않을 때. 또는 해당 시간을 생산적인 개발에 활용할 수 있을 때 모니터링 도구를 구축하고 싶지 않을 때.
• 이미 AWS 플랫폼에 상당한 투자를 하고 있으며, 이에 종속되는 것이 비즈니스적으로 합리적일 때.
• 메시지 전달, 프로토콜 등과 관련된 복잡한 요소 없이, 집중적이고 단순한 대기열 시스템을 원할 때.

전반적으로 Amazon SQS는 대기열을 시스템에 통합하고 직접 설치/모니터링하는 것에 대해 걱정하고 싶지 않은 사용자에게 확실한 선택입니다.

Beanstalkd

Beanstalkd는 오랫동안 사용되어 왔으며, 실제 환경에서 검증된 빠르고 쉬운 작업 대기열 백엔드입니다. Beanstalkd는 Redis와는 상당히 다른 몇 가지 특징을 가지고 있습니다.

• Beanstalkd는 엄격하게 작업 대기열 시스템이며, 다른 기능은 제공하지 않습니다. 작업을 푸시하면 나중에 작업자가 가져갑니다. 따라서 애플리케이션에 메시지 전달이 조금이라도 필요한 경우 Beanstalkd는 피해야 합니다.
• 집합, 우선순위 대기열과 같은 고급 데이터 구조를 제공하지 않습니다.
• Beanstalkd는 FIFO(선입선출) 대기열로 작동합니다. 우선순위에 따라 작업을 정렬하는 방법은 없습니다.
• 클러스터링 옵션을 제공하지 않습니다.

이러한 특징을 고려할 때, Beanstalkd는 단일 서버에 있는 간단한 프로젝트를 위한 매끄럽고 빠른 대기열 시스템을 제공합니다. 많은 경우 Redis보다 빠르고 안정적입니다. 따라서 문제가 발생하여 Redis를 사용하여 해결할 수 없거나, 단순한 요구 사항을 가지고 있다면 Beanstalkd를 시도해볼 가치가 있습니다.

결론

만약 여기까지 읽었거나 (혹은 대충 읽으면서 😉) 이 부분에 도달했다면, 대기열 시스템에 관심이 있거나 시스템이 필요할 가능성이 매우 높습니다. 그렇다면, 언어/프레임워크별 대기열 시스템을 찾고 있지 않다면, 이 페이지의 목록이 도움이 될 것입니다.

대기열 시스템이 간단하고 100% 신뢰할 수 있다고 말하고 싶지만, 현실은 그렇지 않습니다. 대기열 시스템은 복잡하며, 모든 것이 백그라운드에서 매우 빠르게 발생하기 때문에 (실수가 눈에 띄지 않고 비용이 많이 들 수 있습니다). 그럼에도 불구하고 대기열은 특정 수준을 넘어서면 필수적인 요소이며, 대기열이 여러분의 무기고에서 강력한 무기(아마도 가장 강력한 무기일 수도 있음)임을 알게 될 것입니다. 행운을 빕니다! 🙂