대기열 시스템을 찾고 있습니까? 아니면 더 나은 것을 찾고 있습니까? 여기에 필요한 모든 정보가 있습니다!
대기열 시스템은 백엔드 개발에서 가장 잘 지켜지는 비밀입니다.
큐잉 시스템을 찬양하는 시를 쓰지 않고, 나는 후배 백엔드 개발자가 큐를 시스템에 통합하는 법을 배운 후에 중급 백엔드 개발자가 된다고 말하고 싶습니다. 대기열은 고객 경험을 개선하고(방법을 살펴보겠습니다), 복잡성을 줄이며 시스템의 안정성을 개선합니다.
물론 트래픽이 거의 없는 매우 단순한 웹 앱과 브로셔 웹 사이트의 경우 대기열이 전체적으로 있을 수 있지만(일반적인 공유 호스팅 환경에서는 설치가 불가능할 수도 있음) 사소한 앱은 모두 대기열에서 이익을 얻습니다. 시스템 및 대형 앱은 대기열 없이는 불가능합니다.
시작하기 전에 면책 조항: 대기열 시스템에 이미 익숙하고 다양한 옵션을 비교하려는 경우 다음 몇 가지 소개 섹션에서 숙면을 유도할 것입니다. 🙂 그러니 부담 없이 바로 앞으로 가십시오. 소개 섹션은 대기열 시스템에 대해 막연한 개념이 있거나 그냥 지나가다가 이름을 들은 사람들을 위한 것입니다.
목차
대기열 시스템이란 무엇입니까?
대기열이 무엇인지 이해하는 것으로 시작하겠습니다.
대기열은 우리 주변에서 볼 수 있는 실제 대기열을 모방하는 컴퓨터 과학의 데이터 구조입니다. 예를 들어 매표소에 가면 여러분은 대기열의 맨 끝에 서야 하고 대기열의 맨 처음에 있는 사람이 먼저 표를 받는 것을 알 수 있습니다. 이것을 우리는 또한 “선착순” 현상이라고 부릅니다. 컴퓨터 과학에서는 이와 같은 작업을 대기열에 저장하는 프로그램을 작성하여 동일한 선착순으로 처리하는 것이 가능합니다.
대기열은 실제 처리 자체를 수행하지 않습니다. 작업이 무언가에 의해 선택될 때까지 기다리는 일종의 임시 저장소일 뿐입니다. 이 모든 것이 너무 추상적으로 들리더라도 걱정하지 마십시오. 이것은 추상적인 개념이지만 다음 섹션에서 명확한 예를 볼 것입니다. 🙂
대기열 시스템이 필요한 이유는 무엇입니까?
아주 긴 설명으로 들어가지 않고 대기열 시스템의 주요 필요성은 백그라운드 처리, 병렬 실행 및 장애 복구 때문이라고 말하고 싶습니다. 예제를 통해 다음을 살펴보겠습니다.
백그라운드 처리
시간이 중요한 전자 상거래 마케팅 캠페인을 실행 중이고 고객이 결제를 완료하고 “감사합니다” 페이지가 표시되기 직전에 확인 이메일을 실행하도록 애플리케이션을 구축했다고 가정합니다. 연결하려는 메일 서버가 다운되면 웹 페이지가 중단되어 사용자 경험이 중단됩니다.
귀하가 받게 될 많은 지원 요청을 상상해 보십시오! 이 경우 이 이메일 전송 작업을 작업 대기열로 푸시하고 고객에게 성공 페이지를 표시하는 것이 좋습니다.
병렬 실행
많은 개발자, 특히 더 단순하고 트래픽이 적은 앱을 주로 코딩하는 개발자는 백그라운드 처리를 위해 cron 작업을 사용하는 습관이 있습니다. 입력 크기가 너무 커서 지울 수 없을 때까지는 괜찮습니다. 예를 들어 분석 보고서를 컴파일하여 사용자에게 이메일로 보내는 크론 작업이 있고 시스템에서 분당 100개의 보고서를 처리할 수 있다고 가정합니다.
앱이 성장하고 분당 평균 100개 이상의 요청을 받기 시작하면 점점 더 뒤처지기 시작하고 모든 작업을 완료할 수 없을 것입니다.
대기열 시스템에서 이러한 상황은 여러 작업자를 설정하여 방지할 수 있습니다. 작업자는 각각 작업을 선택하고(각각 수행할 보고서 100개 포함) 병렬로 작업하여 훨씬 더 빨리 작업을 완료할 수 있습니다.
장애 복구
우리는 일반적으로 웹 개발자로서 실패를 생각하지 않습니다. 우리는 우리가 사용하는 서버와 API가 항상 온라인 상태라는 것을 당연하게 여깁니다. 그러나 현실은 다릅니다. 네트워크 중단은 모두 너무 일반적이며 인프라 문제로 인해 의존하는 우수한 API가 다운될 수 있습니다(“나 말고!”라고 말하기 전에 잊지 마세요. 대규모 Amazon S3 중단). 따라서 보고 예제로 돌아가서 보고서 생성의 일부가 결제 API에 연결해야 하고 해당 연결이 2분 동안 중단된 경우 실패한 보고서 200개는 어떻게 됩니까?
대기열 시스템은 상당한 오버헤드를 수반합니다. 완전히 새로운 영역으로 들어서면서 학습 곡선이 상당히 가파르고 애플리케이션 및 배포의 복잡성이 증가하고 대기 중인 작업을 항상 100% 정밀하게 제어할 수는 없습니다. 즉, 대기열 없이 애플리케이션을 구축하는 것이 불가능한 상황이 있습니다.
그런 점을 제외하고 오늘날 대기열에 있는 백엔드/시스템 사이의 몇 가지 일반적인 옵션을 살펴보겠습니다.
레디스
레디스 데이터 구조에 대한 지식 없이 데이터 문자열을 저장, 업데이트 및 검색하는 키-값 저장소로 알려져 있습니다. 이전에는 그랬을 수도 있지만 오늘날 Redis는 목록, 정렬된 집합, Pub-Sub 시스템과 같은 효율적이고 매우 유용한 데이터 구조를 가지고 있어 대기열 구현에 매우 바람직합니다.
Redis의 장점은 다음과 같습니다.
- 완전한 인메모리 데이터베이스로 더 빠른 읽기/쓰기가 가능합니다.
- 고효율: 초당 100,000개 이상의 읽기/쓰기 작업을 쉽게 지원할 수 있습니다.
- 매우 유연한 지속성 체계. 실패 시 데이터 손실 가능성을 희생하면서 최대 성능을 달성하거나 일관성을 위해 성능을 희생하도록 완전히 보수적인 모드로 설정할 수 있습니다.
- 즉시 지원되는 클러스터
Redis에는 메시징/대기열/복구 추상화가 없으므로 패키지를 사용하거나 직접 경량 시스템을 구축해야 합니다. 예를 들어 Redis는 프레임워크 작성자가 스케줄러를 구현한 Laravel PHP 프레임워크의 기본 큐 백엔드입니다.
Redis 배우기 쉽습니다.
토끼MQ
Redis와 Redis 사이에는 약간의 미묘한 차이가 있습니다. 토끼MQ그래서 먼저 그들을 제거합시다.
우선, RabbitMQ는 보다 전문화되고 잘 정의된 역할을 가지고 있으므로 이를 반영하도록 구축되었습니다. 즉, 메시징입니다. 다시 말해, 두 시스템 간의 중개자 역할을 하는 것이 가장 좋은 점입니다. 이는 데이터베이스 역할을 하는 Redis의 경우가 아닙니다. 결과적으로 RabbitMQ는 메시지 라우팅, 재시도, 부하 분산 등 Redis에 없는 몇 가지 기능을 더 제공합니다.
생각해 보면 작업 대기열은 메시징 시스템으로 생각할 수도 있습니다. 여기서 스케줄러, 작업자 및 작업 “제출자”는 메시지 전달에 참여하는 엔터티로 생각할 수 있습니다.
RabbitMQ에는 다음과 같은 장점이 있습니다.
- 메시지 전달을 위한 더 나은 추상화, 메시지 전달이 필요한 경우 애플리케이션 수준 작업 감소.
- 정전 및 정전에 대해 더 탄력적입니다(적어도 기본적으로 Redis보다).
- 분산 배포를 위한 클러스터 및 연합 지원.
- 배포를 관리하고 모니터링하는 데 유용한 도구입니다.
- 거의 모든 중요하지 않은 프로그래밍 언어를 지원합니다.
- 선택한 도구(Docker, Chef, Puppet 등)를 사용한 배포.
RabbitMQ는 언제 사용합니까? 비동기 메시지 전달을 사용해야 한다는 것을 알고 있지만 이 목록에 있는 다른 대기열 옵션 중 일부의 엄청난 복잡성을 해결할 준비가 되지 않은 경우 훌륭한 선택이라고 말하고 싶습니다(아래 참조).
액티브MQ
엔터프라이즈 영역에 있고(또는 고도로 분산된 대규모 앱을 구축하는 경우) 항상 바퀴를 재발명하고 싶지 않은 경우(그리고 그 과정에서 실수를 범할 필요가 없습니다), 액티브MQ 볼 가치가 있습니다.
ActiveMQ가 탁월한 위치는 다음과 같습니다.
- Java로 구현되어 정말 깔끔한 Java 통합이 가능합니다(JMS 표준 준수).
- 다중 프로토콜 지원: AMQP, MQTT, STOMP, OpenWire 등
- 보안, 라우팅, 메시지 만료, 분석 등을 즉시 처리합니다.
- 널리 사용되는 분산 메시징 패턴에 대한 기본 지원으로 시간과 비용이 많이 드는 실수를 절약할 수 있습니다.
ActiveMQ가 Java에서만 사용 가능하다는 것은 아닙니다. Python, C/C++, Node, .Net 및 기타 생태계에 대한 클라이언트가 있으므로 향후 붕괴 가능성에 대한 우려가 없어야 합니다. 게다가 ActiveMQ는 완전히 공개된 표준을 기반으로 하므로 경량 클라이언트를 쉽게 구축할 수 있습니다.
ActiveMQ는 단지 중개자일 뿐이며 백엔드는 포함되어 있지 않습니다. 여전히 지원되는 백엔드 중 하나를 사용하여 메시지를 저장해야 합니다. 특정 프로그래밍 언어(Celery, Sidekiq 등과 같은 다른 인기 있는 솔루션)와 관련이 없기 때문에 여기에 포함했습니다.
아마존 MQ
아마존 MQ 여기에서 빠르고 중요한 언급이 필요합니다. ActiveMQ가 요구 사항에 이상적인 솔루션이라고 생각하지만 인프라 구축 및 유지 관리를 직접 처리하고 싶지 않은 경우 Amazon MQ는 이를 위한 관리형 서비스를 제공합니다. ActiveMQ가 지원하는 모든 프로토콜을 지원합니다(기능에는 전혀 차이가 없습니다). 표면 아래에서 ActiveMQ 자체를 사용하기 때문입니다.
관리형 서비스라는 장점이 있어 사용 외에는 걱정할 필요가 없습니다. 배포 내에서 직접 다른 서비스 및 제품을 활용할 수 있으므로(예: 더 빠른 데이터 전송) AWS에 있는 배포에 더 적합합니다.
아마존 SQS
Amazon이 중요한 인프라 부분과 관련하여 조용히 있을 것이라고 기대할 수는 없습니까? 🙂
그래서 우리는 아마존 SQS, 잘 알려진 거대한 AWS에서 완전히 호스팅되고 간단한 대기열 서비스(말 그대로)입니다. 다시 한 번, 미묘한 차이가 중요하므로 SQS에는 메시지 전달 개념이 없습니다. Redis와 마찬가지로 대기열에서 작업을 수락하고 배포하기 위한 간단한 백엔드입니다.
그렇다면 언제 Amazon SQS를 사용하고 싶습니까? 다음은 몇 가지 이유입니다.
- 당신은 AWS 팬이고 다른 건 만지지 않을 것입니다.
- 실패율이 0이고 작업이 손실되지 않도록 하려면 호스팅된 솔루션이 필요합니다.
- 클러스터를 구축하고 싶지 않고 직접 모니터링해야 합니다. 또는 그 시간을 생산적인 개발에 사용할 수 있을 때 모니터링 도구를 구축해야 합니다.
- 귀하는 이미 AWS 플랫폼에 상당한 투자를 하고 있으며 이에 종속된 상태를 유지하는 것이 비즈니스 의미가 있습니다.
- 메시지 전달, 프로토콜 및 기타 등등과 관련된 보풀이 없는 집중적이고 단순한 대기열 시스템을 원합니다.
대체로 Amazon SQS는 작업 대기열을 시스템에 통합하고 스스로 설치/모니터링하는 것에 대해 걱정할 필요가 없는 사람에게 확실한 선택입니다.
콩나무
콩나무 오랫동안 사용되어 왔으며 전투 테스트를 거친 빠르고 쉬운 작업 대기열 백엔드입니다. Beanstalkd에는 Redis와 상당히 다른 몇 가지 특징이 있습니다.
- 그것은 엄격하게 작업 대기열 시스템이며 다른 것은 아닙니다. 작업을 푸시하면 나중에 작업자가 가져옵니다. 따라서 애플리케이션에 메시지 전달이 조금이라도 필요하다면 Beanstalkd를 피하고 싶을 것입니다.
- 집합, 우선 순위 대기열 등과 같은 고급 데이터 구조가 없습니다.
- Beanstalkd는 FIFO(선입선출) 대기열이라고 합니다. 우선 순위에 따라 작업을 정렬하는 방법은 없습니다.
- 클러스터링 옵션이 없습니다.
이 모든 것이 Beanstalkd가 단일 서버에 있는 간단한 프로젝트를 위한 매끄럽고 빠른 대기열 시스템을 만든다고 말했습니다. 많은 경우 Redis보다 빠르고 안정적입니다. 그래서 당신이 가지고있는 경우 문제 Redis를 사용하면 무슨 일이 있어도 해결할 수 없고 요구 사항도 간단합니다. Beanstalkd는 시도해 볼 가치가 있습니다.
결론
여기까지 읽었다면(또는 여기에서 skim-reading 😉에 도달했습니다) 대기열 시스템에 관심이 있거나 시스템이 필요할 가능성이 매우 높습니다. 그렇다면 언어/프레임워크별 대기열 시스템을 찾고 있지 않는 한 이 페이지의 목록이 도움이 될 것입니다.
큐잉이 간단하고 100% 신뢰할 수 있다고 말하고 싶지만 그렇지 않습니다. 그것은 지저분하고 모든 것이 배경에 있고 매우 빠르게 발생하기 때문에 (실수는 눈에 띄지 않고 매우 비용이 많이 들 수 있습니다). 그래도 대기열은 특정 지점을 넘어서는 매우 필요하며, 대기열이 당신의 무기고에서 강력한 무기(아마도 가장 강력한 무기일 수도 있음)임을 알게 될 것입니다. 행운을 빕니다! 🙂