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

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ę?

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

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.

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.

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 są 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.

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.

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.

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

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.

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

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

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