Получение сообщений SQS с помощью лямбда-функции AWS

У меня есть 2 очереди FIFO SQS, которые получают сообщения JSON, которые должны индексироваться в elasticsearch. Одна очередь постоянно добавляет дельта-изменения в базу данных и добавляет их в очередь. Вторая очередь используется для переиндексации базы данных, то есть всего 50 ТБ, если данные должны индексироваться каждые пару месяцев (когда все добавляется в очередь). У меня есть лямбда-функция, которая потребляет сообщения из очередей и помещает их в соответствующую очередь (либо активный индекс, либо перестраиваемое индексирование).

Как мне активировать лямбда-функцию, чтобы лучше всего обрабатывать накопившиеся сообщения в SQS, чтобы она обрабатывала обе очереди как можно быстрее?

У меня есть ограничение: элементы очереди нужно обрабатывать по порядку. Если бы лямбда-функция могла работать бесконечно без ограничения в 5 минут, я мог бы продолжать выполнять одну функцию, которая постоянно обрабатывает сообщения.


amazon-web-services aws-lambda amazon-sqs
person CorribView    schedule 23.02.2018    source источник
comment
правильно ли я понимаю: каждые несколько месяцев у вас появляется несколько миллионов рабочих мест. Вы хотите запускать задания последовательно, поэтому никакого параллелизма, верно?   -  person hansaplast    schedule 24.02.2018
comment
Я только что обновил вопрос, добавив дополнительные сведения о том, для чего используются очереди и как работает этот процесс.   -  person CorribView    schedule 24.02.2018

Ответы (3)


arrow_upward
1
arrow_downward

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

  1. Подписчик: SQS
  2. Подписчик: лямбда-функция

Имеет то преимущество, что ваша лямбда вызывается одновременно с сохранением сообщения в SQS.

person MaiKaY    schedule 23.02.2018
comment
Я бы предпочел не добавлять к этому дополнительный слой, если это возможно, так как это увеличит сложность и стоимость. - person CorribView; 23.02.2018

arrow_upward
1
arrow_downward

Стандартный способ сделать это - использовать События Cloudwatch, которые периодически запускайте . Это позволяет регулярно извлекать данные из очереди.

Поскольку вам нужно опрашивать SQS, это может не привести к самой быстрой обработке сообщений. Кроме того, будьте осторожны, если у вас постоянно есть сообщения для обработки - Lambda в конечном итоге будет намного дороже, чем небольшой экземпляр EC2 для обработки сообщений.

person stdunbar    schedule 23.02.2018
comment
Периодический запуск лямбда-функции для меня не сработает, поскольку я буду переиндексировать массивную БД (100 миллионов документов), поэтому я не могу позволить себе не обрабатывать сообщения (т.е. время между окончанием лямбда-выражения и следующее начало). - person CorribView; 23.02.2018
comment
@CorribView, почему вы хотите использовать Lambda? Не будет ли EC2 лучшим вариантом, поскольку кажется, что вам в любом случае нужен только один параллельный рабочий, и он должен будет работать постоянно? - person hansaplast; 23.02.2018
comment
Я должен согласиться с @hansaplast - Lambda может быть не лучшим выбором. Если вы хотите минимизировать обслуживание, вы можете использовать среда Elastic Beanstalk Worker, которая обеспечит масштабируемость и будет работать почти в реальном времени. Кроме того, вы можете настроить размер экземпляров, если пропускная способность не соответствует вашим требованиям. Но, конечно, вы могли бы просто иметь EC2, чтобы справиться с этим. - person stdunbar; 23.02.2018
comment
Его нужно будет запускать только время от времени (раз в 2 месяца), когда индекс будет переиндексирован. Мы также работаем над отказом от инстансов EC2 в среднесрочной перспективе и переделываем нашу конструкцию, чтобы она была безсерверной с использованием микросервисов. - person CorribView; 23.02.2018
comment
@CorribView - так что раскрутите EC2, дайте ему сделать то, что нужно, и выключите. С вас практически не взимается плата, когда EC2 не работает (в зависимости от того, сколько EBS вы используете), и в конечном итоге это будет более своевременным и экономичным. На мой взгляд, безсерверный режим подходит не для всех вариантов использования. - person stdunbar; 23.02.2018
comment
Я только что обновил вопрос, добавив более подробную информацию для нашего варианта использования. Вращение экземпляров может быть вариантом для полной переиндексации (что случается редко), но я не уверен, что это лучшее решение для дельта-изменений процесса, которое будет меньше. На самом деле периодический запуск лямбды каждую минуту для изменений дельты должен работать. Может быть, я пытаюсь вставить слишком много колышков в слишком мало отверстий! - person CorribView; 24.02.2018

arrow_upward
0
arrow_downward

Не уверен, что полностью понимаю вашу проблему, но вот мои 2 цента:

  1. Если у вас есть постоянный и поток данных в реальном времени, рассмотрите возможность использования _ 1_ с 1 осколком, чтобы сохранить FIFO. Вы можете использовать данные в пакете из n элементов, используя lambda. Вам решать, какой размер пакета n и размер памяти lambda.

    • with this solution you pay a low constant price for Kinesis Streams and a variable price for Lambdas.

  2. Если вы действительно любите SQS и в реальном времени не работает, вы можете потреблять предметы с Lambdas, EC2 или Batch. Либо вы запускаете много lambdas с помощью CloudWatch Events, либо поддерживаете EC2, либо регулярно запускаете AWS Batch задание.

    • there is an economic equation to explore, each solution is the best for one use case and the worst for another, make your choice ;)
    • Я предпочитаю SQS + Lambdas, когда есть мало предметов для потребления, и SQS + Batch, когда их много.

  3. Вы, вероятно, также можете подумать об использовании SNS + SQS + Lambdas, как @maikay говорит в своем ответе, но я бы не стал выбирать это решение.

Надеюсь, это поможет. Не стесняйтесь обращаться за разъяснениями. Удачи!

person Costin    schedule 25.02.2018