처리 할 대기열을 만들어야합니다. 대기열 자체는 상대적으로 적은 양입니다. 시간당 약 1,000 개의 쓰기가있을 수 있습니다. 각 작업의 실행에는 각각 약 1 분이 소요될 수 있으며 항목이 대기열에 추가되는 즉시 처리됩니다.
Amazon SQS와 같은 기성품 대신 RabbitMQ를 구현하고 싶은 이유가 있습니까? 응용 프로그램에 SQS와 같은 것 대신 자체 대기열 시스템이 필요한 이유는 무엇입니까?
처리 할 대기열을 만들어야합니다. 대기열 자체는 상대적으로 적은 양입니다. 시간당 약 1,000 개의 쓰기가있을 수 있습니다. 각 작업의 실행에는 각각 약 1 분이 소요될 수 있으며 항목이 대기열에 추가되는 즉시 처리됩니다.
Amazon SQS와 같은 기성품 대신 RabbitMQ를 구현하고 싶은 이유가 있습니까? 응용 프로그램에 SQS와 같은 것 대신 자체 대기열 시스템이 필요한 이유는 무엇입니까?
답변:
처음에 Amazon SQS는 의사 대기열입니다. 즉, 모든 메시지 (대기열에 도달 한 경우)의 전달이 보장되지만 일반적으로 대기열에서 발생하는 FIFO 방식이 아닙니다.
메시지 순서가 중요하고 대기열이 FIFO 방식으로 작동하기를 원하는 경우 Amazon SQS 문서에는 Amazon SQS의 메시지가 순서에 상관없이 도달하므로 애플리케이션 로직에서이를 처리하도록 명시되어 있습니다.
이것에 비해 내가 아는 한 RabbitMQ에서 작업자 큐를 구현할 수 있습니다. 애플리케이션 수준에서 큐 메시지 시퀀스를 구현하지 않아도된다면 이것이 더 바람직한 옵션이 될 것입니다.
다음은 어느 것을 선택할지 결정하는 데 도움이되는 몇 가지 요소입니다.
위에서 언급 한 큐 메시지 시퀀스.
RabbitMQ로 자체 서버를 설정할 수 있지만 Amazon SQS의 경우에는 비용이 여기에 포함됩니다.
자신의 서버를 설정하려면 주제에 대한 충분한 지식이 필요하므로 모서리를 그대로 두지 마십시오. Amazon SQS는 시작하는 것이 매우 빠르기 때문에 그렇지 않습니다.
자체 RabbitMQ 서버는 Amazon SQS의 경우가 아닌 유지 관리 비용을 의미합니다.
업데이트 :
SQS가 RabbitMQ보다 선호되는 이유는 다음과 같습니다.
그러나 RabbitMQ는 일반적으로 테스트에서 수만 TPS에서 풋 및 겟에 대해 더 빠른 응답 시간을 제공 할 수 있습니다. SQS가 이러한 종류의 처리량을 제공하려면 여러 인스턴스를 사용하여 수평 적으로 확장해야합니다. 따라서 5ms 미만의 풋을 찾고 있다면 RabbitMQ보다 약간 높은 1000s의 TPS에서 SQS 테스트에서 20ms-30ms에 가까운 시간을 보냈기 때문에 RabbitMQ를 고려할 수 있습니다.
우리는 메시징 인프라를 ActiveMQ에서 SQS로 방금 옮겼으며 더 이상 행복 할 수 없습니다. 클라우드에서 자체 ActiveMQ 클러스터를 유지하는 것보다 더 저렴하다는 사실을 알게되었습니다.
도움이 되었기를 바랍니다! 어떻게되는지 알려주세요 ..
실제로 상업적 환경에서 합리적으로 사용했습니다.
짧은 대답은 특정 코너 케이스가 없으면 AWS SQS를 사용하는 것이 좋습니다. (간단한 요약을 위해 아래로 건너 뛸 수 있습니다)
코딩 (Tie) : RabbitMQ와 AWS SQS 모두 라이브러리를 설정하고 많은 예제를 가지고 있습니다.
가시성 제한 시간 (SQS) : SQS가 RabbitMQ를 통해 제공하는 한 가지는 가시성 제한 시간에 대한 광범위한 개념입니다. RabbitMQ에서 소비자가 응답하기 전에 죽으면 메시지가 큐에 다시 들어갑니다. 그러나 SQS는 특정 발신자와 관련이없는보다 광범위한 가시성 제한 시간 개념을 가지고 있습니다. 따라서 작업 단위를 시작하고, 긴 시간 제한 (최대 12 시간)으로 가시성을 설정하고, 연결을 끊고, 다른 작업자가 완료하도록하고 승인 할 수 있습니다. 제 설계에서는이를 광범위하게 활용하고 잠재적으로 큰 '진행중인'페이로드를 관리하기 위해 추가 서비스 / 스토리지를 제거했습니다.
배달 못한 편지 처리 (RabbitMQ- '토끼'에 의해) SQS는 배달 못한 편지 대기열 (다른 큐)로 메시지를 덤프하는 "재 드라이브 정책"이라고 부르는 기본 배달 못한 편지 처리를 제공합니다. 기본이며 메시지 수의 개념 만 있습니다. RabbitMQ에는 만료 될 때 DLE에서 푸시되는 메시지를 제공하는 배달 못한 편지 교환이 있습니다. 그러나 이것은 "서비스와 메시지가 만료되는 것을 보지 않으면 DLE에 도착할 것입니다"라는 아이디어로 일종의 논쟁입니다. 내가 그 인수 카운터가 직관적이라는 것을 알기 때문에 RabbitMQ에게는 약간의 승리입니다. 서비스가 아닌 대기열을 모니터링하는 이유는 무엇입니까? (만약 있다면, 그 반대입니다)
관리 (SQS) : SQS에 대한 관리가 없습니다. API 호출 비용 만 지불하면됩니다. OS / 앱 보안 패치, 확장 (노드 추가), 디스크와 같은 모든 일반적인 골칫거리는 AWS 팀에서 처리합니다. 또한 FedRamp를 준수합니다 (정부 용). 진정한 '설정 후 잊어 버리기'시스템입니다. RabbitMQ에 일반적인 OS / 서비스 패치, AMI, 클러스터링, 보안 강화 등이 필요한 곳. 극히 드물지만 AMI가 다운되거나 때때로 이동해야하므로 클러스터링이 즉시 필요합니다. SQS는 이러한 모든 두통을 제거합니다.
비용 (SQS) : 단일 SQS API 호출에는 '최대 10 개의 메시지 / 256k 크기'일괄 처리가 포함될 수 있으며 '긴 폴링'은 비용을 대폭 절감 할 수 있습니다. 또한 비용을 추가로 줄이기 위해 단일 페이로드로 수십 개의 메시지를 전송할 수있는 메시지 압축과 같은 전략이 있습니다. 그리고 이것은 사람들이 문제를 모니터링 / 패칭 / 수정하는 데 소비하는 시간을 고려하기 전입니다. SQS는 유휴 상태에서 비용이 들지 않는 것처럼 'poc 프로젝트'에도 좋습니다.
FIFO (TIE) : 2016 년 AWS는 ~ 0.01 / 백만 API 호출의 추가 비용으로 FIFO 지원을 도입했습니다 (할인 전 API 호출 백만 개당 0.04 달러 대 0.04 달러). FIFO 사용 여부를 선택할 수 있습니다. 비 FIFO의 경우 중복 메시지가 거의 표시되지 않습니다.
스토리지 (SQS) : AWS는 스토리지 비용을 청구하지 않지만 14 일로 제한됩니다. RabbitMQ에서는 최대 스토리지 용량과 추가 버퍼가 필요한 디스크 공간을 할당, 확장 및 관리해야합니다. 그것은 더 많은 두통입니다.
지표 (SQS) : SQS는 즉시 사용 가능한 지표를 제공합니다. AWS에 추가 할 수는 있지만 더 많은 작업이 필요합니다.
지역 개발 (넥타이) : 대부분의 현대 상점은 지역 환경을 좋아합니다. 이제 RabbitMQ 및 SQS의 도커를 허용하는 몇 가지 옵션이 있습니다.
높은 처리량 / 매우 큰 메시지 (RabbitMQ-일종의) SQS> 1000 요청 / 초를 푸시하면 SQS의 지연 시간이 늘어납니다. 이를 해결하기위한 몇 가지 전략이 있습니다. 그러나 대부분의 작업이 여러 대기열로 분할 될 수 있으므로 이러한 경우는 매우 드뭅니다. 그러나 100k / sec가 필요한 이러한 유형의 경우에는 Kafka가 더 좋습니다. (저희 작업에서도 Kafka를 사용합니다.) 짧은 대기 시간으로 초당 1000 개 이상의 요청이 필요한 단일 작업 단위를 갖는 경우는 드뭅니다. *이 설명은 아래를 참조하십시오.
요약 : AWS에서 SQS와 기꺼이 결혼하려는 경우 SQS는 생각할 필요가 없습니다. 그러나 고려해야 할 중요한 사항이 있으므로 계속 읽어야합니다.
RabbitMQ (및 기타 대기열)의 고전적인 전략은 특정 유형의 작업에 최적화 된 여러 유형의 대기열을 만드는 것입니다. 그런 다음 각 대기열을 미세 조정하고 유사한 작업을 소수 (종종 매우 큰) 대기열로 그룹화합니다. SQS에는 관리 오버 헤드가 없기 때문에 실제로 각 작업에 전용 대기열을 할당하는 것이 좋습니다. 이렇게하면 확장이 가능할뿐 아니라 대기열 포화 (작업에 문제가 생기고 다른 작업자가 빠져 나가는 작업), 작업에 대한 더 나은보기 (기본 메트릭) 등이 제거됩니다.
새로운 전략을 통해 우리 팀은 작업이 어떻게 배포되는지 더 잘 볼 수 있습니다. '더 많은 부하를 위해 인스턴스를 업그레이드'하던 시대는 지났습니다. 과거에는 다른 서비스에 부작용을 일으킬 수있는 설명 할 수없는 큰 급증을 보거나 누적 수치가 맞아 보인다고 추측했습니다. ' 이제 트래픽이 분리되었으므로 이전에는 알지 못했던 많은 문제를 실제로 발견했으며 트래픽이 어디로 가고 있는지 명확하게 설명 할 수 있습니다. 메트릭 및 도구를 구현하는 것은 매우 가능하지만 SQS는 이러한 모든 것을 즉시 제공합니다.
RabbitMQ를 심각하게 고려해야하는 좋은 사례가 여전히 있습니다.
- Very large legacy code base that uses RabbitMQ with extensive tooling and knowledgeable support staff
- Messages that needs to be in the same work stream for > 14 days
- Very large messages that has very low latency requirements with it
- Cloud agnostic code base requirements. If you must run your code on other platforms (e.g. Azure/Google/bare metal), then SQS is not an option
- Large volume of data for a single pipeline that can't be broke up and other solutions (e.g. Kafka) are not viable. But at a super large volume, Kafka is a lot faster. While SQS will push large payloads to S3, you are now incurring additional cost.
비용에 민감한 경우 Amazon SQS가 더 비용이 많이들 수 있습니다. 나는 여전히 RabbitMQ 서버를 어딘가에 호스팅해야하기 때문에 아마도 말합니다. SQS는 처음 백만 건의 요청을 무료로 제공하고 그 이후에는 요청 백만 건당 0.4 달러를 청구합니다. 긴 폴링, 즉 receive_message_wait_time을 20 초로 설정하여 SQS로 비용을 줄이는 트릭이 있습니다. 이것은 메시지가 20 초마다 전송된다는 의미가 아니라, 쿼리가 비어있는 경우 (20 초마다) SQS가 '요청'을 청구하지 않음을 의미합니다.
시간당 1000 개의 요청을 사용하는 경우 한 달에 744,000 개가됩니다. 프리 티어 내에서는 무료이며 티어에서 약 0.74 * $ 0.4 = $ 0.2976입니다. 대기 시간을 활성화하여 더 줄일 수 있습니다. 따라서 귀하의 경우 SQS는 대부분의 호스팅이 최소 $ 5 이상부터 시작하므로 실제로 더 저렴하게 작동 할 수 있습니다 (AWS의 EC2 프리 티어가없는 경우). RMQ는 약 128MB 램 시작을 권장하므로 가장 작은 옵션으로도 문제가 없습니다.
나는 SQS가 훨씬 더 사용자 친화적이고 RabbitMQ가 더 기술적 인 경향이 있다고 생각합니다.
최신 정보:
실제로 AWS Simple Notification Service가 필요한 항목에 더 적합하다는 것을 발견 했습니다. https://stackoverflow.com/a/13692720/5403449는 주로 푸시 기반 즉 폴링 이 아니기 때문입니다.