Почему я должен использовать Amazon Kinesis, а не SNS-SQS?

У меня есть сценарий использования, при котором поступает поток данных, и я не могу использовать его с той же скоростью, и мне нужен буфер. Это можно решить с помощью очереди SNS-SQS. Я узнал, что Kinesis решает ту же задачу, так в чем же разница? Почему я должен предпочесть (или не предпочесть) Kinesis?

На первый взгляд они немного похожи, но ваш вариант использования определит, какой инструмент подходит. IMO, если вы можете обойтись с SQS, тогда вы должны - если он будет делать то, что вы хотите, это будет проще и дешевле, но вот лучшее объяснение из часто задаваемых вопросов AWS, которое дает примеры соответствующих сценариев использования для обоих инструментов для помочь вам решить:

Часто задаваемые вопросы

Имейте в виду, что этот ответ был правильным на июнь 2015

После некоторого изучения проблемы, имея в виду тот же вопрос, я обнаружил, что SQS (с SNS) предпочтительнее для большинства случаев использования, если только порядок сообщений не важен для вас (SQS не гарантирует FIFO для сообщений).

У Kinesis есть 2 основных преимущества:

1. Вы можете прочитать одно и то же сообщение из нескольких приложений
2. Вы можете перечитать сообщения в случае необходимости.

Оба преимущества могут быть достигнуты при использовании SNS в качестве вентилятора для SQS. Это означает, что производитель сообщения отправляет только одно сообщение в SNS. Затем SNS разветвляет сообщение на несколько SQS, по одному для каждого потребительского приложения. Таким образом, вы можете иметь столько потребителей, сколько захотите, не думая о том, как распределить емкость.

Кроме того, мы добавили еще одну SQS, которая подписана на SNS, которая будет хранить сообщения в течение 14 дней. В обычном случае никто не читает из этого SQS, но в случае ошибки, которая заставляет нас хотеть перематывать данные, мы можем легко прочитать все сообщения из этого SQS и повторно отправить их в SNS. В то время как Kinesis обеспечивает только 7 дней хранения.

В заключение, SNS + SQS намного проще и предоставляют большинство возможностей. IMO, вам нужен действительно веский аргумент, чтобы выбрать Kinesis.

Kinesis поддерживает возможности нескольких потребителей, что означает, что одни и те же записи данных могут обрабатываться в одно и то же время или в разное время в течение 24 часов у разных потребителей, аналогичное поведение в SQS может быть достигнуто путем записи в несколько очередей, и потребители могут читать из нескольких очередей. Однако повторная запись в несколько очередей увеличит задержку в секундах (несколько миллисекунд) в системе.

Во-вторых, Kinesis предоставляет возможность маршрутизации для выборочной маршрутизации записей данных на разные сегменты с использованием ключа разделения, который может обрабатываться конкретными экземплярами EC2, и может включать микропакетный расчет {Подсчет и агрегирование}.

Работать с любым программным обеспечением AWS легко, а с SQS - проще всего. В Kinesis необходимо заранее выделять достаточное количество сегментов, динамически увеличивая количество фрагментов для управления пиковой нагрузкой и уменьшая их для экономии затрат, также необходимых для управления. это боль в Kinesis, с SQS таких вещей не требуется. SQS бесконечно масштабируется.

Семантика этих технологий различна, потому что они были разработаны для поддержки различных сценариев:

• SNS / SQS: элементы в потоке не связаны друг с другом
• Kinesis: элементы в потоке будут связаны друг с другом

Давайте разберем разницу на примере.

1. Предположим, у нас есть поток заказов, для каждого заказа нам необходимо зарезервировать некоторый запас и запланировать доставку. После этого мы можем безопасно удалить элемент из потока и начать обработку следующего заказа. Мы полностью выполнили предыдущий заказ, прежде чем приступить к следующему.
2. Опять же, у нас тот же поток заказов, но теперь наша цель - группировать заказы по пунктам назначения. Когда у нас есть, скажем, 10 заказов в одном месте, мы хотим доставить их вместе (оптимизация доставки). Теперь история другая: когда мы получаем новый элемент из потока, мы не можем закончить его обработку; скорее, мы «ждем», чтобы появилось больше товаров для достижения нашей цели. Более того, если происходит сбой процессора, мы должны «восстановить» состояние (чтобы ни один порядок не был потерян).

Как только обработка одного элемента не может быть отделена от обработки другого, мы должны иметь семантику Kinesis для безопасной обработки всех случаев.

Выдержка из документации AWS :

Мы рекомендуем Amazon Kinesis Streams для сценариев использования с требованиями, аналогичными следующим:

• Маршрутизация связанных записей на тот же процессор записей (как в потоковом MapReduce). Например, подсчет и агрегация проще, когда все записи для данного ключа направляются на один и тот же процессор записей.

• Заказ записей. Например, вы хотите перенести данные журнала с хоста приложения на хост обработки / архивирования, сохраняя при этом порядок операторов журнала.

• Возможность для нескольких приложений использовать один и тот же поток одновременно. Например, у вас есть одно приложение, которое обновляет панель мониторинга в реальном времени, а другое - архивирует данные в Amazon Redshift. Вы хотите, чтобы оба приложения использовали данные из одного и того же потока одновременно и независимо друг от друга.

• Возможность потреблять записи в том же порядке несколько часов спустя. Например, у вас есть приложение для выставления счетов и приложение для аудита, которое работает за несколько часов после приложения для выставления счетов. Поскольку Amazon Kinesis Streams хранит данные до 7 дней, вы можете запустить приложение аудита до 7 дней после приложения для выставления счетов.

Мы рекомендуем Amazon SQS для сценариев использования с требованиями, аналогичными следующим:

• Семантика обмена сообщениями (например, подтверждение / сбой на уровне сообщений) и время ожидания видимости. Например, у вас есть очередь рабочих элементов и вы хотите отслеживать успешное завершение каждого элемента независимо. Amazon SQS отслеживает подтверждение / сбой, поэтому приложение не должно поддерживать постоянную контрольную точку / курсор. Amazon SQS удалит заблокированные сообщения и повторно отправит ошибочные сообщения после заданного времени ожидания видимости.

• Индивидуальная задержка сообщения. Например, у вас есть очередь заданий, и вам нужно запланировать отдельные задания с задержкой. Amazon SQS позволяет настроить задержку отдельных сообщений на 15 минут.

• Динамически увеличивающийся параллелизм / пропускная способность во время чтения. Например, у вас есть рабочая очередь, и вы хотите добавить больше читателей, пока не будет очищено отставание. С помощью Amazon Kinesis Streams вы можете масштабировать до достаточного количества шардов (однако учтите, что вам нужно заранее выделить достаточно шардов).

• Использование способности Amazon SQS масштабировать прозрачно. Например, вы буферизуете запросы и изменения нагрузки в результате случайных скачков нагрузки или естественного роста вашего бизнеса. Поскольку каждый буферизованный запрос может быть обработан независимо, Amazon SQS может прозрачно масштабироваться для обработки нагрузки без каких-либо инструкций от вас.

Самым большим преимуществом для меня является тот факт, что Kinesis является воспроизводимой очередью, а SQS - нет. Таким образом, у вас может быть несколько получателей одних и тех же сообщений Kinesis (или одного и того же получателя в разное время), где с помощью SQS, когда сообщение было подтверждено, оно ушло из этой очереди. Из-за этого SQS лучше подходит для рабочих очередей.

Другое дело: Kinesis может вызвать лямбду, а SQS - нет. Так что с SQS вы должны либо предоставить экземпляр EC2 для обработки сообщений SQS (и справиться с ним в случае сбоя), либо у вас должна быть запланированная лямбда (которая не масштабируется или увеличивается - вы получаете только один раз в минуту) ,

Изменить: этот ответ больше не является правильным. SQS может напрямую запускать лямбду с июня 2018 года

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

Модели ценообразования отличаются, поэтому в зависимости от вашего варианта использования одна или другая может быть дешевле. Используя простейший случай (не включая SNS):

• SQS взимает плату за сообщение (каждый 64 КБ считается одним запросом).
• Kinesis взимает плату за осколок в час (1 осколок может обрабатывать до 1000 сообщений или 1 МБ / с), а также за объем вводимых вами данных (каждые 25 КБ).

С учетом текущих цен и без учета уровня бесплатного пользования, если вы отправляете 1 ГБ сообщений в день при максимальном размере сообщения, Kinesis будет стоить намного дороже, чем SQS (10,82 долл. США в месяц для Kinesis против 0,20 долл. США в месяц для SQS). , Но если вы отправляете 1 ТБ в день, Kinesis несколько дешевле (158 долларов в месяц против 201 долларов в месяц за SQS).

Подробности: SQS взимает 0,40 долл. США за миллион запросов (по 64 КБ каждая), поэтому 0,00655 долл. США за ГБ. При 1 ГБ в день это чуть меньше 0,20 доллара в месяц; при 1 ТБ в день он составляет чуть более 201 доллара в месяц.

Kinesis взимает 0,014 доллара за миллион запросов (по 25 КБ каждая), то есть 0,00059 доллара за ГБ. При 1 ГБ в день это меньше, чем 0,02 доллара в месяц; при 1 ТБ в день это около 18 долларов в месяц. Тем не менее, Kinesis также взимает $ 0,015 за шард-час. Вам нужен как минимум 1 осколок на 1 МБ в секунду. При 1 ГБ в день будет достаточно одного шарда, так что это добавит еще 0,36 доллара в день, при общей стоимости 10,82 доллара в месяц. При 1 ТБ в день вам потребуется как минимум 13 осколков, что добавляет еще 4,68 долл. В день, а общая стоимость - 158 долл. В месяц.

Kinesis решает проблему части карты в типичном сценарии сокращения карты для потоковой передачи данных. Пока SQS в этом не уверен. Если у вас есть потоковые данные, которые должны быть агрегированы по ключу, kinesis гарантирует, что все данные для этого ключа отправляются на определенный сегмент, а сегмент может использоваться на одном хосте, что упрощает агрегацию по ключу по сравнению с SQS.

Я добавлю еще одну вещь, о которой никто не упомянул - SQS на несколько порядков дороже.

Случаи использования Kinesis

• Сбор данных журнала и событий
• Аналитика в реальном времени
• Мобильный захват данных
• Поток данных «Интернет вещей»

Примеры использования SQS

• Интеграция приложений
• Развязка микросервисов
• Распределите задачи по нескольким рабочим узлам
• Отделить живые запросы пользователей от интенсивной фоновой работы
• Пакетные сообщения для дальнейшей обработки