Лучшее решение для передачи огромных всплесков сообщений в AWS SQS - PullRequest
Новая
       13

Лучшее решение для передачи огромных всплесков сообщений в AWS SQS

0 голосов
/ 08 апреля 2019

Ожидается, что приложение, над которым я работаю, периодически сталкивается с всплесками входящих сообщений, которые нужно обрабатывать (события Facebook webhook).Живые тесты этого приложения еще не проводились, но, исходя из опыта подобных проектов, ожидается, что эти пики могут резко начаться и удерживаться на скорости ~ 0,8-3k сообщений / сек в течение нескольких часов.Начало скачка предсказуемо с точностью до нескольких секунд-десятков секунд.

Представляется целесообразным передавать эти сообщения в какую-либо очередь, например AWS SQS, и затем обрабатывать их с удобной скоростью.Если это так, что было бы оптимальным решением для повторной отправки таких волн сообщений в SQS, чтобы приложение для прослушивания всегда было доступно, особенно в начале скачка (в противном случае Facebook может отображать ошибку 503 «Ваш веб-крючок не работает»):

  • хостинг приложения для прослушивания в AWS EC2 с балансировщиком нагрузки;

  • хостинг приложения для прослушивания в AWS Lambda (возможно, с реализацией некоторых мер Lambda-потепления, таких как эти )

  • другие идеи?Было бы удобно, если бы SQS мог подтвердить подписку на веб-знакомства Messenger, чтобы Facebook отправлял эти сообщения непосредственно в SQS, но это, к сожалению, невозможно из-за «пассивного» характера SQS.

Спасибозаранее.

Ответы [ 2 ]

0 голосов
/ 08 апреля 2019

Мне нравится архитектура с тонким веб-приложением, единственная обязанность которого - принимать входящий запрос и немедленно выгружать его в очередь или поток.На другом конце потока находится рабочее приложение, которое заботится о фактической обработке событий.

другие идеи?

Лично я бы использовал API Gatewayсопоставляется с Kinesis (или Kinesis Firehose) для внешнего интерфейса вместо EC2.Таким образом, я могу положиться на AWS для обеспечения балансировки нагрузки, автоматического масштабирования, исправлений ОС, конфигурации сети и так далее.Кроме того, Kinesis предлагает значительные возможности буферизации, поэтому нет необходимости повторно отправлять шип сообщения.Для рабочей части приложения это зависит от того, какое действие необходимо выполнить.Для кратковременных операций я рекомендую Lambda, но AWS также предлагает интеграцию с EMR, Redshift, Elasticsearch и так далее.

0 голосов
/ 08 апреля 2019

размещение приложения прослушивания на AWS EC2 с балансировщиком нагрузки

Я думаю, что вы можете упростить это, перейдя без сервера.

размещение приложения прослушивания на AWS Lambda (возможно, реализация некоторых мер по сглаживанию лямбды

Я не думаю, что Lambda будет хорошим вариантом из-за ограничения в 1000 одновременных выполнений, хотя его можно увеличить.

другие идеи? Было бы удобно, если бы SQS мог подтвердить подписку на веб-знакомства Messenger, чтобы Facebook отправлял эти сообщения непосредственно в SQS, но это, к сожалению, невозможно из-за «пассивного» характера SQS

Я бы предложил использовать AWS API Gateway с интеграцией сервисов AWS с использованием SQS. Вы можете настроить События webhook Facebook, чтобы перейти непосредственно к конечной точке REST API Gateway. Вы можете настроить аутентификацию и регулировку в соответствии со своими требованиями в шлюзе API.

...