Dlaczego powinienem używać Amazon Kinesis, a nie SNS-SQS?


164

Mam przypadek użycia, w którym nadchodzi strumień danych i nie mogę ich konsumować w tym samym tempie i potrzebuję bufora. Można to rozwiązać za pomocą kolejki SNS-SQS. Dowiedziałem się, że Kinesis ma ten sam cel, więc jaka jest różnica? Dlaczego powinienem (lub nie powinienem) preferować kinezę?

Odpowiedzi:


59

Z pozoru są one nieco podobne, ale Twój przypadek użycia określi, które narzędzie jest odpowiednie. IMO, jeśli możesz sobie poradzić z SQS, powinieneś - jeśli zrobi to, co chcesz, będzie prostsze i tańsze, ale tutaj jest lepsze wyjaśnienie z AWS FAQ, które podaje przykłady odpowiednich przypadków użycia obu narzędzi do pomóc ci zdecydować:

FAQ's



80

Pamiętaj, że ta odpowiedź była poprawna dla czerwca 2015 r

Po dłuższym przestudiowaniu problemu, mając na uwadze to samo pytanie, stwierdziłem, że SQS (z SNS) jest preferowany w większości przypadków użycia, chyba że kolejność komunikatów jest dla Ciebie ważna (SQS nie gwarantuje FIFO w wiadomościach).

Kinesis ma dwie główne zalety:

  1. możesz przeczytać tę samą wiadomość z kilku aplikacji
  2. w razie potrzeby możesz ponownie przeczytać wiadomości.

Obie zalety można osiągnąć, używając SNS jako wachlarza do SQS. Oznacza to, że producent wiadomości wysyła tylko jedną wiadomość do SNS, a następnie SNS rozsyła wiadomość do wielu SQS, po jednym dla każdej aplikacji konsumenckiej. W ten sposób możesz mieć tylu konsumentów, ilu chcesz, bez myślenia o shardingu.

Co więcej, dodaliśmy jeszcze jeden SQS, który jest subskrybowany do SNS, który będzie przechowywać wiadomości przez 14 dni. W normalnym przypadku nikt nie czyta z tego SQS, ale w przypadku błędu, który powoduje, że chcemy przewinąć dane, możemy łatwo odczytać wszystkie wiadomości z tego SQS i ponownie wysłać je do SNS. Podczas gdy Kinesis zapewnia tylko 7 dni retencji.

Podsumowując, SNS + SQS jest znacznie łatwiejsze i zapewnia większość możliwości. IMO potrzebujesz naprawdę mocnego etui, aby wybrać Kinesis zamiast niego.


2
Do Twojej wiadomości: Możesz zachować kinezę do 7 dni.
Didier A.

30
Niedawno AWS ogłosił SQS FIFO [ docs.aws.amazon.com/AWSSimpleQueueService/latest/…, który może służyć do porządkowania czasu wiadomości.
VijeshJain

4
Super drobny komentarz - prawdopodobnie nie używać słowa splitw SNS split the message to multiple SQSsponieważ nie rozbić wiadomości w kawałkach, ale kopiuje go do wielu miejsc docelowych.
Mobigital

2
Kinezy nie nadają się do zastosowań typu „fan-out” (pub-sub) ze względu na ograniczenia dotyczące liczby czytników na fragment / sekundę. Chociaż nie ma to związku z pierwotnym dochodzeniem, każdy polegający na skalowaniu kinezji do n-czytelników powinien wziąć ten fakt pod uwagę. forums.aws.amazon.com/message.jspa?messageID=760351
codeasone

2
Gwarancja zamówienia Kinesis dotyczy fragmentu, a nie strumienia. Gdy masz więcej niż jeden odłamek, cały strumień nie miałby gwarancji zamówienia. W przypadku kolejki SQS, gdy przepustowość jest stosunkowo niska, jest to prawie FIFO. Tylko wtedy, gdy twoja przepustowość rośnie, kolejność jest mniej przestrzegana. Dotyczy to klasycznych kolejek SQS, a nie kolejek FIFO.
yoroto

54

Kinesis obsługuje funkcje wielu konsumentów, co oznacza, że ​​te same rekordy danych mogą być przetwarzane w tym samym lub różnym czasie w ciągu 24 godzin u różnych konsumentów, podobne zachowanie w SQS można osiągnąć, zapisując w wielu kolejkach, a konsumenci mogą czytać z wielu kolejek. Jednak ponowne zapisywanie w wielu kolejkach spowoduje wydłużenie czasu oczekiwania o mniej niż kilka sekund {kilka milisekund} w systemie.

Po drugie, Kinesis zapewnia możliwość routingu w celu wybiórczego kierowania rekordów danych do różnych fragmentów przy użyciu klucza partycji, który może być przetwarzany przez poszczególne instancje EC2 i może umożliwić obliczenia mikro partii {Liczenie i agregacja}.

Praca na dowolnym oprogramowaniu AWS jest łatwa, ale z SQS jest najłatwiejsza. W przypadku Kinesis istnieje potrzeba dostarczenia wystarczającej liczby shardów z wyprzedzeniem, dynamicznie zwiększając liczbę shardów, aby zarządzać obciążeniem skokowym i zmniejszać, aby zaoszczędzić koszty również wymagane do zarządzania. to ból w kinezie, żadne takie rzeczy nie są wymagane w przypadku SQS. SQS jest nieskończenie skalowalne.


11
Jeśli chodzi o wyjaśnienie dotyczące SQS. Możesz uzyskać łatwy sposób wysyłania tej samej wiadomości do wielu SQS, mając przed sobą SNS.
Roee Gavirel

8
aplikacja -> temat sns ---> sqs1, sqs2, sqs3 ...?
kartik

4
Tak, miałem na myśli dokładnie to podejście.
Roee Gavirel

@RoeeGavirel A co z ograniczeniami żądań / sekund dla SNS API?
Barbaros Alp

@BarbarosAlp - znam tylko ograniczenie dotyczące SMS-ów (mobilnych wiadomości tekstowych), które jest tutaj nie na temat. to jest oficjalna dokumentacja: docs.aws.amazon.com/general/latest/gr/…
Roee Gavirel

43

Semantyka tych technologii jest inna, ponieważ zostały zaprojektowane do obsługi różnych scenariuszy:

  • SNS / SQS: elementy w strumieniu nie są ze sobą powiązane
  • Kineza: elementy w strumieniu ze sobą powiązane

Rozumiemy różnicę na przykładzie.

  1. Załóżmy, że mamy strumień zamówień, dla każdego zamówienia musimy zarezerwować część zapasów i zaplanować dostawę. Po zakończeniu możemy bezpiecznie usunąć przedmiot ze strumienia i rozpocząć przetwarzanie kolejnego zamówienia. Jesteśmy w pełni wykonane z poprzedniego rzędu przed rozpoczęciem następnego.
  2. Ponownie mamy ten sam strumień zamówień, ale teraz naszym celem jest grupowanie zamówień według miejsc docelowych. Gdy mamy powiedzmy 10 zamówień w to samo miejsce, chcemy je dostarczyć razem (optymalizacja dostaw). Teraz historia jest inna: kiedy otrzymamy nowy element ze strumienia, nie możemy zakończyć jego przetwarzania; raczej "czekamy" na więcej przedmiotów, aby osiągnąć nasz cel. Ponadto, jeśli proces procesora ulegnie awarii, musimy „przywrócić” stan (aby żadne zamówienie nie zostało utracone).

Gdy przetwarzanie jednego elementu nie może być oddzielone od przetwarzania innego, musimy mieć semantykę Kinesis, aby bezpiecznie obsłużyć wszystkie przypadki.


Dzięki kolejce SQS FIFO komunikaty byłyby uporządkowane w miarę ich wysyłania. Czy to sprawia, że ​​pod tym względem SQS jest podobny do kinezy?
Andy Dufresne

1
@AndyDufresne: to dobrze obejmuje scenariusz, w którym porządek jest ważny. W przypadku (1) powyżej, możesz chcieć obsługiwać zamówienia „w kolejności”. Jeśli więc zabraknie Ci zapasów, późniejsze zamówienia zostaną odrzucone lub opóźnione. Semantyka FIFO nie rozwiązuje podstawowego problemu względności (grupowania).
Konstantin Triger

35

Fragment dokumentacji AWS :

Zalecamy Amazon Kinesis Streams w przypadkach użycia z wymaganiami podobnymi do następujących:

  • Kierowanie rekordów powiązanych do tego samego procesora rekordów (jak w przypadku przesyłania strumieniowego MapReduce). Na przykład zliczanie i agregacja są prostsze, gdy wszystkie rekordy dla danego klucza są kierowane do tego samego procesora rekordów.

  • Zamawianie nagrań. Na przykład chcesz przesłać dane dziennika z hosta aplikacji do hosta przetwarzającego / archiwizującego, zachowując kolejność instrukcji dziennika.

  • Możliwość jednoczesnego korzystania z tego samego strumienia przez wiele aplikacji. Na przykład masz jedną aplikację, która aktualizuje pulpit nawigacyjny w czasie rzeczywistym, a drugą archiwizuje dane w Amazon Redshift. Chcesz, aby obie aplikacje korzystały z danych z tego samego strumienia jednocześnie i niezależnie.

  • Możliwość konsumowania płyt w tej samej kolejności kilka godzin później. Na przykład masz aplikację rozliczeniową i aplikację audytową, która działa kilka godzin za aplikacją rozliczeniową. Ponieważ Amazon Kinesis Streams przechowuje dane do 7 dni, możesz uruchomić aplikację audytową do 7 dni za aplikacją rozliczeniową.

Zalecamy Amazon SQS w przypadkach użycia z wymaganiami podobnymi do następujących:

  • Semantyka wiadomości (np. Potwierdzenie / niepowodzenie na poziomie wiadomości) i limit czasu widoczności. Na przykład masz kolejkę elementów pracy i chcesz niezależnie śledzić pomyślne zakończenie każdego elementu. Amazon SQS śledzi potwierdzenie / niepowodzenie, więc aplikacja nie musi utrzymywać stałego punktu kontrolnego / kursora. Amazon SQS usunie potwierdzone wiadomości i ponownie dostarczy nieudane wiadomości po skonfigurowanym limicie widoczności.

  • Indywidualne opóźnienie wiadomości. Na przykład masz kolejkę zadań i musisz zaplanować poszczególne zadania z opóźnieniem. Dzięki Amazon SQS możesz skonfigurować indywidualne wiadomości tak, aby miały opóźnienie do 15 minut.

  • Dynamicznie zwiększająca się współbieżność / przepływność w czasie odczytu. Na przykład masz kolejkę roboczą i chcesz dodać więcej czytelników do czasu wyczyszczenia zaległości. Dzięki strumieniom Amazon Kinesis możesz skalować w górę do wystarczającej liczby shardów (pamiętaj jednak, że będziesz musiał dostarczyć wystarczającą liczbę fragmentów z wyprzedzeniem).

  • Wykorzystanie zdolności Amazon SQS do przejrzystego skalowania. Na przykład buforujesz żądania, a obciążenie zmienia się w wyniku sporadycznych skoków obciążenia lub naturalnego rozwoju Twojej firmy. Ponieważ każde buforowane żądanie może być przetwarzane niezależnie, Amazon SQS może skalować się w sposób przejrzysty, aby obsłużyć obciążenie bez żadnych instrukcji dotyczących udostępniania.


34

Największą zaletą dla mnie jest to, że Kinesis to kolejka do wielokrotnego odtwarzania, a SQS nie. Możesz więc mieć wielu odbiorców tych samych wiadomości Kinesis (lub tego samego konsumenta w różnym czasie), podczas gdy SQS, gdy wiadomość zostanie potwierdzona, zniknie z tej kolejki. Z tego powodu SQS jest lepszy w przypadku kolejek roboczych.


Jak potwierdzasz wiadomość? Czy chodziło Ci o usunięcie?
NeverEndingQueue

Tak, zasadniczo. Mówiąc, że skończyłeś z tą wiadomością
Matthew Curry

15

Inna sprawa: kineza może wyzwolić Lambdę, podczas gdy SQS nie. Więc w przypadku SQS musisz albo dostarczyć instancję EC2 do przetwarzania wiadomości SQS (i radzić sobie z nią, jeśli się nie powiedzie), albo musisz mieć zaplanowaną Lambdę (która nie skaluje się w górę ani w dół - dostajesz tylko jedną na minutę) .

Edycja: ta odpowiedź nie jest już poprawna. SQS może bezpośrednio wyzwalać Lambdę od czerwca 2018 r

https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html


1
-1 Nie zgadzam się. Chociaż kineza może wyzwolić lambdę, nie ma to żadnej przewagi nad przewidywaną lambdą SQS. Ten ostatni będzie skalował się płynnie (tj. Jeśli zajmie to więcej niż minutę, druga lambda zostanie podkręcona). Cena dotyczy czasu obliczeniowego, więc nie ma też znaczącej różnicy. A jeśli potrzebujesz więcej niż 5 równoczesnych lambd, po prostu dodaj wiele wyzwalaczy zaplanowanych w odstępie kilku sekund (za pomocą crona). To nie jest powód, aby używać Kinesis zamiast SNS / SQS.
Steven de Salas

5
Nie jestem pewien, czy zgadzam się z tym sporem;] - można zaplanować jedną lambdę / minutę, co ograniczyłoby przetwarzanie wsadowe wiadomości, które dotarły w tym interwale. Kineza umożliwiłaby natychmiastowe przeczytanie wiadomości. A może coś, co źle zrozumiałem?
Moszi

Istnieje ogromna różnica między kilkoma wyzwalaczami w chmurze a setkami, gdy trzeba wywołać ciągnącą lambdę przeciwko SQS.
Coding Pig

14
Lambda obsługuje teraz SQS jako wyzwalacz!
sixty4bit

11

Modele cenowe są różne, więc w zależności od przypadku użycia jeden lub drugi może być tańszy. W najprostszym przypadku (bez SNS):

  • Opłaty SQS za wiadomość (każde 64 KB liczy się jako jedno żądanie).
  • Kinesis ładuje się na fragment na godzinę (1 fragment może obsłużyć do 1000 wiadomości lub 1 MB / sekundę), a także za ilość wprowadzonych danych (co 25 KB).

Podłączając aktualne ceny i nie biorąc pod uwagę poziomu darmowego, wysyłając 1 GB wiadomości dziennie przy maksymalnym rozmiarze wiadomości, Kinesis będzie kosztować znacznie więcej niż SQS (10,82 USD / miesiąc dla Kinesis vs. 0,20 USD / miesiąc dla SQS) . Ale jeśli wysyłasz 1 TB dziennie, Kinesis jest nieco tańsza (158 USD / miesiąc w porównaniu do 201 USD / miesiąc w przypadku SQS).

Szczegóły: SQS pobiera 0,40 USD za milion żądań (64 KB każde), więc 0,00655 USD za GB. Przy 1 GB dziennie to nieco poniżej 0,20 USD miesięcznie; przy 1 TB dziennie dochodzi do nieco ponad 201 USD miesięcznie.

Kinesis pobiera 0,014 USD za milion żądań (po 25 KB), czyli 0,00059 USD za GB. Przy 1 GB dziennie to mniej niż 0,02 USD miesięcznie; przy 1 TB dziennie to około 18 USD miesięcznie. Jednak Kinesis pobiera również 0,015 USD za godzinę fragmentu. Potrzebujesz co najmniej 1 fragmentu na 1 MB na sekundę. Przy 1 GB dziennie 1 fragment będzie wystarczający, co oznacza dodatkowe 0,36 USD dziennie, co daje łączny koszt 10,82 USD miesięcznie. Przy 1 TB dziennie będziesz potrzebować co najmniej 13 fragmentów, co oznacza dodatkowe 4,68 USD dziennie, co daje łączny koszt 158 ​​USD miesięcznie.


Nie do końca rozumiem, dlaczego wykładniczy wzrost rozmiaru ma tutaj znaczenie. Czy możesz zagłębić się trochę więcej? Wygląda na to, że masz wgląd, który chciałbym mieć. Edytuj Właściwie, patrząc na odpowiedź Euguene Feingolda, wygląda na to, że toczy się całkiem solidna debata na ten temat (?).
Thomas

Przepraszam, popełniłem błędy w moich obliczeniach (mam nadzieję, że teraz naprawiono).
John Velonis,

prawda, ale co się stanie, jeśli średni rozmiar wiadomości SQS jest mały, powiedzmy 1 kb lub mniej?
mcmillab

1
@mcmillab SQS będzie naliczać taką samą opłatę, niezależnie od tego, czy Twoja wiadomość ma rozmiar 1 KB, czy 64 KB - zobacz stronę cenową Amazon SQS . Więc jeśli twoje wiadomości mają tylko 1 KB, SQS będzie kosztować 64 razy więcej niż liczby, które podałem powyżej, jeśli wysyłasz tę samą całkowitą ilość danych. Jednak pojedyncze żądanie może zawierać do 10 wiadomości, więc jeśli możesz grupować wiadomości razem, może to być tylko 6x więcej (w zależności od tego, jak pełne są twoje partie).
John Velonis,

1
@JohnVelonis Powyżej wyliczenia cen SQS brakuje kluczowego elementu. Konieczna jest szczególna uwaga, aby zrozumieć, w jaki sposób są naliczane opłaty za żądania SQS. 1 żądanie = 1 akcja API. Aby przetworzyć pojedynczą „wiadomość” należy wykonać przynajmniej 3 akcje API: 1 wyślij + 1 odczyt + 1 usuń. Inne funkcje SQS, takie jak zmiana widoczności, spowodują więcej działań API. Ten nieoczekiwany mnożnik jest dość nieprzyjemny i zazwyczaj powoduje, że SQS jest 2-10 razy droższy niż strumienie Kinesis dla dużych zestawów danych (powiedzmy, że przetwarzają 100 milionów wiadomości miesięcznie).
Vlad Poskatcheev

9

Kinesis rozwiązuje problem części mapy w typowym scenariuszu redukcji mapy dla danych przesyłanych strumieniowo. Chociaż SQS nie zapewnia tego. Jeśli masz dane strumieniowe, które muszą być zagregowane na kluczu, kineza zapewnia, że ​​wszystkie dane dla tego klucza trafiają do określonego fragmentu, a fragment może zostać zużyty na jednym hoście, co ułatwia agregację klucza w porównaniu z SQS


5

Dodam jeszcze jedną rzecz, o której nikt inny nie wspomniał - SQS jest o kilka rzędów wielkości droższy.


3
Jesteś pewny? Z moich obliczeń wynika, że ​​kineza jest znacznie droższa, ale nigdy nie byłem utalentowany przy użyciu kalkulatora ceny Amazon Simple.
Didier A.

Patrząc na aktualne przykłady cen w programie aws: Kinesis z 267 mln wiadomości kosztuje około 60 USD, podczas gdy przesłanie takiej ilości wiadomości za pośrednictwem SQS dałoby 107 USD. Oczywiście zrobiłem naprawdę szybkie porównanie i różni się to znacznie w różnych przypadkach użycia, ale ta odpowiedź zdecydowanie zasługuje na uznanie.
Moszi

1
Załóżmy, że robisz wachlarz, aby powiedzieć 2 konsumentów i 100 milionów wiadomości dziennie. Koszt SNS to 50 USD / dzień. Koszt SQS to 40 USD / dzień / konsumenta lub 80 USD / dzień łącznie. Kinesis wynosi 1,4 USD / dzień dla PUT i 0,36 USD / odłamek. Nawet przy 100 fragmentach (100 MB / s na wejściu, 200 MB / s na wyjściu) to tylko 3,60 USD / dzień + 1,40 USD / dzień. Tak więc kineza przy 4 USD / dzień w porównaniu z SNS / SQS po 130 USD / dzień.
Carlos Rendon

@Moszi Jak doszedłeś do tego obliczenia? Standardowa kolejka SQS z 15 000 000 wiadomości miesięcznie i 10 GB transferu danych i przesyłania danych kosztuje tylko 5,60 USD / mc, podczas gdy ładunek 256 KB (maks. SQS) i ok. 15 000 000 jednostek PUT / mc (130 fragmentów) w kinezy kosztuje 1638,43 USD / mies.
simoncpu

3
Chciałbym wiedzieć, dlaczego w tym wątku istnieje taka dysproporcja w kosztach.
Thomas

2

Przypadki użycia kinazy

  • Zbieranie danych dziennika i zdarzeń
  • Analizy w czasie rzeczywistym
  • Przechwytywanie danych mobilnych
  • Kanał danych „Internet przedmiotów”

Przypadki użycia SQS

  • Integracja aplikacji
  • Oddzielanie mikrousług
  • Przydziel zadania do wielu węzłów roboczych
  • Oddziel żądania użytkowników na żywo od intensywnej pracy w tle
  • Wiadomości wsadowe do przyszłego przetwarzania
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.