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

Ответ 1

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

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

Ответ 2

Имейте в виду, что этот ответ был правильным для июня 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.

Ответ 3

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

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

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

Ответ 4

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

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

Позвольте понять разницу на примере.

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

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

Ответ 5

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

Ответ 6

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

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

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

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

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

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

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

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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

• Расходы SQS за сообщение (каждый 64 КБ считается одним запросом).
• Расходы на кинезиты за осколок в час (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 долларов в месяц. Однако Кинсис также взимает 0,015 доллара за каждый час. Вам нужно как минимум 1 осколок на 1 МБ в секунду. При 1 ГБ в день 1 осколок будет много, поэтому он добавит еще $0,36 в день, общая стоимость составляет 10,82 доллара США в месяц. При 1 ТБ в день вам потребуется как минимум 13 осколков, что добавляет еще 4,68 доллара в день, общая стоимость составляет 158 долларов США в месяц.

Ответ 9

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

Ответ 10

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