Консумирайте SQS съобщения с помощта на AWS ламбда функция

Имам 2 FIFO SQS опашки, които получават JSON съобщения, които трябва да бъдат индексирани към elasticsearch. Една опашка непрекъснато добавя делта промени към базата данни и ги добавя към опашката. Втората опашка се използва за повторно индексиране на базата данни, т.е. всичките 50Tb, ако данните трябва да се индексират на всеки няколко месеца (където всичко се добавя към опашката). Имам ламбда функция, която консумира съобщенията от опашките и ги поставя в подходящата опашка (или активния индекс, или индексирането, което се изгражда отново).

Как трябва да задействам ламбда функцията, за да обработя най-добре натрупаните съобщения в 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 тема с 2 регистрирани абоната.

  1. Абонат: SQS
  2. Абонат: Lambda Function

Има предимството, че вашата Lambda се извиква по същото време, когато съобщението се съхранява в 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
Периодичното стартиране на ламбда функцията няма да работи за мен, тъй като ще индексирам повторно масивна база данни (стотици милиони документи), така че не мога да си позволя да не се обработват съобщения (т.е. времето между края на ламбда и следващото начало). - 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. Ако имате постоянен и в реално време поток от данни, обмислете използването на Kinesis Streams с 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