SQS vs RabbitMQ

88

Muszę utworzyć kolejkę do przetwarzania. Sama kolejka jest stosunkowo niewielka. Może być około 1000 zapisów na godzinę. Wykonanie każdego zadania może zająć około minuty i jest przetwarzane niemal natychmiast po dodaniu elementu do kolejki.

Czy jest jakiś powód, dla którego mógłbym chcieć wdrożyć RabbitMQ zamiast czegoś gotowego, takiego jak Amazon SQS? Z jakich powodów aplikacja potrzebuje własnego systemu kolejkowania zamiast czegoś w rodzaju SQS?

David542
źródło
1000 zapisów na godzinę jest w porządku. Jeśli masz czas i wystarczającą wiedzę, uruchom samodzielnie instancję RabbitMq, co również oszczędza pieniądze w porównaniu z usługą Amazon SQS. W przypadku SQS po prostu tam był. Było to wygodne, proste i dość szybkie w programowaniu.
BMW
Dzięki SQS uzyskujesz rozszerzalność i skalowalność wyzwalaczy Lambda.
Donato

Odpowiedzi:

98

Na początek Amazon SQS jest pseudo-kolejką, co oznacza, że ​​dostarczenie każdej wiadomości (jeśli dotrze do kolejki) jest gwarantowane, ale nie w sposób FIFO, który zwykle ma miejsce w kolejce.

Jeśli kolejność wiadomości jest dla Ciebie ważna i chcesz, aby kolejka działała w sposób FIFO, dokumentacja Amazon SQS stwierdza, że ​​należy to załatwić w logice aplikacji, ponieważ wiadomości z Amazon SQS będą docierać do Ciebie poza kolejnością.

W porównaniu z tym, o ile wiem, możesz zaimplementować kolejki robocze w RabbitMQ. Jeśli to pozbawia Cię implementacji sekwencjonowania komunikatów w kolejce na poziomie aplikacji, byłaby to bardziej preferowana opcja.

Oto kilka czynników, które pomogą Ci zdecydować, który z nich wybrać:

  1. Kolejka wiadomości, jak wspomniano powyżej.

  2. Możesz skonfigurować swój własny serwer z RabbitMQ, ale nie w przypadku Amazon SQS, więc koszty są tutaj zaangażowane.

  3. Skonfigurowanie własnego serwera będzie wymagało dobrej znajomości tematu, aby nie pozostawić żadnego zakątka nietkniętego. Tak nie jest w przypadku Amazon SQS, ponieważ można zacząć z nim dość szybko.

  4. Twój własny serwer RabbitMQ oznacza niższe koszty utrzymania, co nie ma miejsca w przypadku Amazon SQS.

Aktualizacje:

  1. Amazon SQS obsługuje teraz kolejki FIFO.
Noman Ur Rehman
źródło
5
Co masz na myśli, mówiąc „Amazon SQS ma dużą przenośność na prawie wszystkich głównych platformach, nie jestem pewien, czy tak jest w przypadku RabbitMQ”. RabbitMQ działa na wszystkich głównych platformach (Windows, Linux i Mac) oraz we wszystkich głównych językach (Java, .Net, PHP, Python, Ruby itp.)
old_sound
6
@old_sound Różnica polega na tym, że uruchamiając SQS płacisz tylko za użytkowanie (wysyłanie i odbieranie wiadomości), podczas gdy RabbitMQ ma ukryte koszty (powyżej użycia EC2) związane z upewnieniem się, że usługa działa, jest monitorowana i łatana, w tym zarówno aplikacja, jak i jej podstawa system operacyjny. Dzięki SQS AWS zajmie się całym tym „niezróżnicowanym podnoszeniem ciężarów”, dzięki czemu możesz po prostu skupić się na swojej aplikacji.
JaredHatfield,
27
Amazon SQS obsługuje teraz FIFO
rocketspacer
6
Zaktualizuj górę postu, aby pokazać, że teraz obsługuje kolejki FIFO, prawie przestałem czytać, kiedy to przeczytałem
andy mccullough
11
-1 Ta odpowiedź naprawdę wymaga uwagi, aby była użyteczna. Sugestie: Całkowicie usuń ograniczenie FIFO, skoncentruj się na IaaS - skalowaniu, konfiguracji itp. - i różnicach w dostarczaniu wiadomości (np. Odpytywanie).
Brett
69

SQS byłby moim lepszym rozwiązaniem niż RabbitMQ, oto dlaczego.

  1. SQS to usługa zarządzana. Nie musisz więc martwić się o operacyjne aspekty prowadzenia systemu przesyłania wiadomości, w tym administrację, bezpieczeństwo, monitorowanie itp. Amazon zrobi to za Ciebie i zapewni wsparcie, jeśli coś pójdzie nie tak.
  2. SQS jest elastyczny i może skalować się do bardzo dużych szybkości / objętości (nieograniczony według AWS;))
  3. Dostępność SQS zawiera wiele dziewiątek i jest wspierana przez Amazon, co jest jedną rzeczą mniej, o którą należy się martwić w Twojej aplikacji.

Jednak RabbitMQ może zapewnić szybsze czasy odpowiedzi dla operacji typu put and get, zazwyczaj w ciągu 10 tysięcy TPS z moich testów. Aby SQS mógł zapewnić taką przepustowość, będziesz musiał skalować w górę w poziomie z wieloma instancjami. Więc jeśli szukasz opcji put poniżej 5 ms, RabbitMQ może być opcją do rozważenia, ponieważ widziałem czas spędzony w moich testach SQS na 1000 s TPS, który jest nieco wyższy niż RabbitMQ.

Właśnie przenieśliśmy naszą infrastrukturę obsługi wiadomości z ActiveMQ do SQS i nie możemy być szczęśliwsi. Okazało się, że jest to tańsze niż utrzymywanie własnego klastra ActiveMQ w chmurze.

Mam nadzieję że to pomoże! Daj nam znać, jak leci ...

ssekhar
źródło
@ssekhar Planujemy również migrację activemq do SES. Jak duże są zmiany po stronie klienta? Pracujemy na Javie i najnowszej wersji activemq.
Deepak Singhal
Od lat używam aplikacji opartych na SQS z medianą opóźnień około 7 ms na wprowadzenie - jeśli otrzymujesz 20-30 ms, coś jest strasznie nie tak, czy to w pomiarze, czy w teście. Czy biegasz z tego samego regionu AWS / AZ? Jak mierzysz?
Krease
1
@DeepakSinghal - jestem pewien, że prawdopodobnie znalazłeś już odpowiedź na swoje pytanie. Przepraszam, że spóźniłem się kilka lat, aby złapać to pytanie :). Przejście od ActiveMQ do SQS - oto kilka wyzwań, z którymi musieliśmy się zmierzyć. 1) SQS zapewnia co najmniej jednokrotną gwarancję dostawy w porównaniu z raz i tylko raz, jak JMS, więc musieliśmy rozwiązać problem zduplikowanej dostawy (nasze podejście pokazane tutaj -> angularthinking.blogspot.com ) 2) SQS używa wzorca ściągania vs. push do klientów jak w JMS, co ułatwia konsumpcję. Wdrożyliśmy własny odbiornik i procesor dostarczania asynchronicznego, aby uprościć programowanie.
ssekhar
27

Właściwie użyłem obu w środowisku komercyjnym z rozsądnym.

Krótka odpowiedź brzmi: jeśli nie ma konkretnych przypadków narożnych, lepiej wybrać AWS SQS. (Możesz przejść do dołu, aby uzyskać proste podsumowanie)

Kodowanie (Tie): RabbitMQ i AWS SQS mają ustanowione biblioteki i mnóstwo przykładów.

Limit czasu widoczności (SQS): Jedną z rzeczy, które SQS oferuje w porównaniu z RabbitMQ, jest szersze pojęcie limitu czasu widoczności. W RabbitMQ, jeśli konsument umiera przed zniszczeniem, komunikaty są umieszczane z powrotem w kolejce. Ale SQS ma szersze pojęcie limitu czasu widoczności, który nie jest powiązany z konkretnym dzwoniącym. Możesz więc rozpocząć jednostkę pracy, ustawić widoczność z dużym limitem czasu (do 12 godzin), rozłączyć się, zlecić innemu pracownikowi zakończenie i potwierdzenie. W moim projekcie wykorzystujemy to w dużym stopniu i wyeliminowaliśmy dodatkową usługę / pamięć masową, aby zarządzać potencjalnie dużymi ładunkami „w toku”.

Obsługa utraconych wiadomości (RabbitMQ - przez „zająca”) Usługa SQS zapewnia podstawowe przekazywanie utraconych wiadomości w ramach tego, co nazywają „polityką ponownego napędu”, która zrzuca wiadomości do kolejki utraconych wiadomości (po prostu kolejki). Jest podstawowy i ma tylko pojęcie liczby wiadomości. RabbitMQ ma możliwość wymiany utraconych wiadomości, która zapewnia komunikaty wypychane w DLE po ich wygaśnięciu. Ale jest to trochę dyskusyjne, ponieważ pomysł „Jeśli nie oglądasz, wygasają Twoje usługi i wiadomości, wylądują w DLE”. To niewielka wygrana dla RabbitMQ, ponieważ uważam, że ten argument jest sprzeczny z intuicją. Dlaczego miałbyś monitorować swoją kolejkę, a nie swoje usługi? (Jeśli już, to na odwrót)

Administracja (SQS): SQS nie podlega administracji. Po prostu płacisz za wywołania API. Wszystkie typowe bóle głowy, takie jak poprawki bezpieczeństwa systemu operacyjnego / aplikacji, skalowanie (dodawanie więcej węzłów), dysk są obsługiwane przez zespoły AWS. Jest również zgodny z FedRamp (do użytku rządowego). To naprawdę system typu „skonfiguruj i zapomnij”. Gdzie RabbitMQ wymaga zwykłych poprawek systemu operacyjnego / usług, AMI, klastrowania, wzmacniania zabezpieczeń itp. Chociaż jest to niezwykle rzadkie, AMI może ulec awarii lub czasami wymagać przeniesienia, więc klastrowanie jest potrzebne po wyjęciu z pudełka. SQS eliminuje wszystkie te bóle głowy.

KOSZT (SQS): pojedyncze wywołanie interfejsu API SQS może obejmować „pakiet do 10 wiadomości / rozmiar 256 KB”, a „długie odpytywanie” może drastycznie obniżyć koszty. Co więcej, istnieją strategie, takie jak kompresja wiadomości w celu umieszczenia dziesiątek (niektórzy twierdzą, że setki lub więcej) wiadomości mogą być wysyłane w jednym ładunku, aby jeszcze bardziej obniżyć koszty. I to zanim rozważymy czas, który ludzie spędzają na monitorowaniu / poprawianiu / naprawianiu problemów. SQS świetnie nadaje się również do „projektów poc”, jakby bezczynnie, bez żadnych kosztów.

FIFO (TIE): W 2016 roku AWS wprowadziło obsługę FIFO za dodatkowym kosztem ~ 0,01 USD / milion wywołań API (0,05 USD w porównaniu z 0,04 USD za milion wszystkich interfejsów API - bez rabatów). Możesz wybrać FIFO lub nie. W przypadku innych niż FIFO rzadko widzimy zduplikowane wiadomości.

Przechowywanie (SQS): AWS nie pobiera opłat za przechowywanie, ale masz limit 14 dni. W RabbitMQ będziesz musiał przydzielić, rozszerzyć i zarządzać przestrzenią dyskową, która wymaga szczytowej pojemności pamięci plus dodatkowe bufory. To tylko więcej bólów głowy.

Metryki (SQS): SQS zapewnia metryki gotowe. I chociaż możesz dodać je do AWS, to po prostu więcej pracy.

Lokalny deweloper (krawat): Większość nowoczesnych sklepów lubi mieć lokalne środowisko. Istnieje kilka opcji, które pozwalają teraz na dokowanie RabbitMQ i SQS.

Wysoka przepustowość / bardzo duża wiadomość (RabbitMQ - coś w rodzaju) Gdy przekażesz SQS> 1000 żądań / s, opóźnienie SQS wzrośnie. Istnieje kilka strategii obejścia tego problemu. Ale uważam, że te przypadki są niezwykle rzadkie, ponieważ większość pracy można podzielić na wiele kolejek. Ale dla tego typu przypadków, w których wymagane jest 100k / s, myślę, że Kafka jest lepszy. (W mojej pracy używamy również Kafki) Rzadko zdarza się, aby pojedyncza jednostka pracy wymagała ponad 1000 żądań / sekundę z małym opóźnieniem. * Więcej informacji znajdziesz poniżej

Podsumowanie: Jeśli zamierzasz być w AWS i chcesz poślubić SQS, to SQS jest nie do pomyślenia. Ale powinieneś czytać dalej, ponieważ należy wziąć pod uwagę ważne kwestie.

Klasyczna strategia RabbitMQ (i innych kolejek) polega na tworzeniu kilku typów kolejek zoptymalizowanych pod kątem określonych rodzajów pracy. Następnie dostrój każdą z tych kolejek i zgrupuj podobną pracę w niewielką liczbę tych (często bardzo dużych) kolejek. Ponieważ SQS nie ma narzutu administracyjnego, w rzeczywistości lepiej jest przydzielić dedykowaną kolejkę do każdej pracy. W ten sposób pozwala na skalowanie, ale także eliminuje nasycenie kolejki (obrażająca praca nasycająca kolejkę i zagłuszanie innych pracowników), lepszy wgląd w pracę (domyślne metryki) i tym podobne.

Nowa strategia umożliwiła moim zespołom lepszy wgląd w rozkład pracy. Dawno minęły czasy „ulepszania instancji w celu zwiększenia obciążenia”. W przeszłości widzielibyśmy duży niewyjaśniony wzrost, który powodowałby skutki uboczne w innych usługach lub po prostu przypuszczaliśmy, że skumulowane liczby wyglądają na prawidłowe ”. Teraz, gdy ruch jest oddzielony, w rzeczywistości odkryliśmy wiele problemów, które wcześniej pozostawały niezauważone i możemy jasno wyjaśnić, jaki ruch jest w jakim kierunku. I chociaż wdrożenie metryk i narzędzi jest bardzo możliwe, SQS zapewnia je wszystkie od razu.

Nadal istnieją duże przypadki, w których RabbitMQ należy poważnie rozważyć

- 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.
Leigh
źródło
4

Jeśli jesteś wrażliwy na koszty, Amazon SQS prawdopodobnie będzie droższy. Mówię, że prawdopodobnie dlatego, że nadal musisz gdzieś hostować swój serwer RabbitMQ. SQS bezpłatnie udostępnia pierwszy milion żądań, a następnie pobiera opłatę w wysokości 0,4 USD za milion żądań. Istnieje jednak sztuczka polegająca na zmniejszeniu kosztów za pomocą SQS poprzez włączenie długiego odpytywania, tj. Ustawienie czasu odbioru wiadomości na 20 sekund. Nie oznacza to, że Twoje wiadomości będą wysyłane tylko co 20 sekund, oznacza to raczej, że SQS nie obciąży Cię „żądaniem”, jeśli kolejka jest pusta (co 20 sekund).

Jeśli używasz 1000 żądań na godzinę, to 744000 miesięcznie. Bezpłatnie w ramach poziomu bezpłatnego i około 0,74 * 0,4 USD = 0,2976 USD poza poziomem. Który prawdopodobnie można by jeszcze bardziej skrócić, włączając czas oczekiwania. Więc w twoim przypadku SQS może faktycznie działać taniej, ponieważ większość hostingu zaczyna się od minimum 5 USD (chyba że masz darmowy poziom EC2 od AWS). Powinno być dobrze z najmniejszą opcją, ponieważ RMQ zaleca tylko około 128 MB pamięci RAM.

Uważam, że SQS jest dużo bardziej przyjazny dla użytkownika, a RabbitMQ bardziej techniczny, jeśli masz takie skłonności.

Aktualizacja:

Właściwie uważam, że AWS Simple Notification Service jest bardziej odpowiedni dla tego, czego potrzebowałem https://stackoverflow.com/a/13692720/5403449, głównie dlatego, że jest oparty na wypychaniu, czyli nie odpytywaniu

Josh
źródło