Возможно ли (или эффективно) запустить полный бэкэнд с помощью AWS Lambda (vs say, Elastic Beanstalk)

Я относительно новичок в мире серверов, поэтому простите меня, если некоторые из них являются основными (и первый бит текста будет объяснять мне логику, чтобы убедиться, что это не ошибка). Все мои вопросы будут выделены жирным шрифтом, чтобы облегчить вашу помощь:).

Я изучал и преподавал некоторые из технологий AWS, и я заметил в своем мобильном хабе, если вы хотите облачную логику, они позволяют только "автоматическую" настройку функций лямбда. После прочтения и исследования я нашел несколько ресурсов, которые указывают на "безсерверную" архитектуру (которая включает поддержку Lambda). Раньше я понимал, что Elastic Beanstalk был представлен, чтобы помочь значительно упростить управление серверами (особенно для мобильных).

Для мобильных разработчиков есть два варианта (очевидно, больше, но для простоты мы согласны):

Настройте эластичный beanstalk, который будет иметь как минимум 1 экземпляр, работающий 24/7, и имеет несколько конечных точек для каждого URL
С помощью API Gateway мы можем легко перенаправить URL-адреса к определенным функциям лямбда. При этом мы можем обрабатывать любые запросы (так же, как настройка приложения Elastic Beanstalk).

Все это заставляет меня думать, что полный бэкэнд Lambda будет полностью возможен и легко создать за небольшую часть стоимости работы сервера, работающего 24 часа в сутки. Это правильно?

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

Для простых серверов мы могли бы настроить несколько функций Lambda и назвать это днем (и, вероятно, намного проще и дешевле (по крайней мере для небольших проектов), чем с использованием эластичного beanstalk).

Однако для более сложных серверов с большим количеством URL-адресов и соединений с базой данных все становится интереснее.

Это проблемы, которые я вижу с использованием Lambda в вышеуказанной ситуации.

Каждый URL-адрес будет иметь API-шлюз API с собственной функцией Lambda. Если какой-либо код или модули используются в нескольких функциях, нам придется копировать и вставлять их в каждую функцию.
Управление несколькими лямбда-функциями (и шлюзами API) - это просто больше, чем управление единым проектом/репо/независимо от того, что вы хотите называть своим кодом.
Каждая функция, требующая подключения к БД, должна подключаться к функции (vs, например, имея постоянное соединение в приложении Node.js).

Единственный способ (я мог подумать), чтобы избежать первых двух проблем, - сделать одну надежную функцию, которая действует как отправка (основная функция принимает параметр из шлюза API и определяет, какой файл должен работать в функции Lambda).

Есть ли какие-то важные моменты, которые мне не хватает, чтобы определить, стоит ли использовать лямбда над эластичным бобовым стеком?

Ответ 1

Похоже, вы уже поняли. Вы правы, что использование Lambda вместо того, чтобы сервер, работающий 24 часа в сутки, может значительно снизить затраты. В этой статье говорится:

И это экономит некоторые из клиентов Amazon большие деньги, по крайней мере один счастливый Лямбда-клиент сэкономит 80% своих облачных счетов.

Возможно, вы захотите посмотреть серверную версию, которая управляет некоторыми болевыми точками.

Я думаю, что во многих случаях боли исчезнут, так как Amazon добавляет больше возможностей для Lambda, и для него создаются дополнительные инструменты для сторонних разработчиков. Я постоянно открываю новые возможности для Lambda, но я также постоянно обнаруживаю, что использование, похоже, хорошо подходит, но на самом деле не работает на Lambda, по крайней мере, пока. Например, мне действительно нужно каким-то образом ограничить количество экземпляров Lambda-функции, которая может работать одновременно, чтобы предотвратить расширение доступных подключений к базе данных или ограничение использования ограничений для сторонних API-интерфейсов. Мне также очень нужны функции лямбда для работы внутри моего VPC, но ожидается, что это произойдет очень скоро.

Ответ 2

Вопрос на самом деле - FAAS vs PAAS. Архитектуру Lambda/Serverless можно рассматривать как функцию как службу, в то время как Beanstalk попадает под Платформа как служба.

Было много путаницы между FAAS и PAAS. Многие говорят, что FAAS также является PAAS. Я хотел бы указать на отличительные черты между FAAS и PAAS.

Скажем, у меня есть приложение CRUD, в котором есть операции Создать, прочитать, обновить и удалить. Обычно веб-приложение получает больше трафика в операции Чтение.

+---------------------------------------------+--------------------------------------------------------+
|                     FAAS                    |                          PAAS                          |
+---------------------------------------------+--------------------------------------------------------+
| In case of traffic, it scales that specific | But it scales the whole application,                   |
| function handling the read operation.       | a separate auto-scaled instance in case of bean stalk. |
+---------------------------------------------+--------------------------------------------------------+
| Pay one and only when your function         | Have to pay for atleast a single instance,             |
| is invoked.                                 | even though there is no traffic.                       |
+---------------------------------------------+--------------------------------------------------------+

С моей точки зрения, эти две точки различают FAAS, так называемую "серверную" архитектуру, от PAAS.

Ответ 3

Как уже указывалось другими, есть некоторые преимущества в использовании Lambda vs Elastic Beanstalk или ваших самоуправляемых экземпляров EC2.

Затраты

В то время как AWS поддерживает автоматическое масштабирование для эластичного бобового стека и EC2. Вероятно, нужно всегда запускать как минимум два экземпляра для восстановления после сбоев. Запуск двух экземпляров "nano" как минимум для восстановления после сбоя каждый экземпляр стоит вам (без резервированных скидок): $0.0059 * 24 * 30.5 = $4.31 для VM и $0,05 * 8 GB = $0,40. Таким образом, один экземпляр составляет 4,81 доллара США, а два экземпляра - 9,62 доллара США. Тем не менее, для работы AutoScaling вам нужно установить Load-Balancer, по крайней мере, на $0,0225 * 24 * 30,5 = $16,47 (не считая сборов LCU). Балансировщик нагрузки может использоваться несколькими службами. Для этого расчета я просто раздробил его на 10 штук и пришел к выводу, что один микросервис с использованием Eleastic Beanstalk или EC2 будет стоить вам $9,62 + 1,65 = $11,27.

Так как это сравнивается с Лямбдой? С Lambda вы платите за звонок и за гигабайт секунду. Я игнорирую расходы на вызов, так как он составляет 0,20 доллара за 1 миллион запросов. 1 миллион запросов - 0,4 запросов в секунду в месяц. Если у вас есть более высокие нагрузки, вам придется также оплачивать расходы на балансировку нагрузки. Lambda оценена как $0,00001667 за ГБ-секунду. Эластичный бобовый шток и EC2 будут потреблять части памяти нанос 512 МБ для операционной системы и контейнера. Я просто предполагаю, что 256 МБ действительно пригодны для использования. Имея два экземпляра, это будет 2 * 256 МБ /1024 МБ * 60 * 60 * 24 * 30,5 = 1317600 ГБ-секунд. Это количество GB-секунд будет стоить вам 1317600 * $0,00001667 = $21,96 долларов. Хотя это звучит дороже, помните, что ваш трафик, вероятно, не распространяется равномерно, поэтому вам, вероятно, понадобится больше экземпляров, следовательно, увеличивая затраты. С Lambda вы платите только то, что вы на самом деле используете.

масштабирование

Лямбда-шкалы по требованию, и, как уже говорилось, вы платите только то, что вам действительно нужно, а не из-за недоиспользования базовой линии.

Непредсказуемая производительность

Ловушка Лямбды - непредсказуемая производительность. В то время как контейнеры будут использоваться повторно, они нуждаются в разминании каждого нового экземпляра. Первые запросы обычно будут медленными, особенно при использовании Java. Node.js должен быть легче во время запуска, но медленнее во время выполнения. Например, когда создается новый Java-экземпляр с низкой памятью на 128 МБ, и у вашего Lambda есть несколько библиотек, первый вызов может занять 30 секунд или дольше. Экземпляры зависают между запросами. Если экземпляр не используется какое-то время, потребуется больше времени, чтобы снова проснуться. Увеличение памяти может уменьшить время прогрева и пробуждения. Однако главной проблемой может быть доступ к внешним источникам данных. Поскольку экземпляры замораживаются между запросами, правильный пул соединений не поддерживается. Если вы все равно подключаете пул соединений, вы можете получить устаревшие соединения. В зависимости от открытия и закрытия базы данных и драйверов соединение может быть довольно дорогостоящим.

Другие ограничения

Как упоминалось выше, объединение пулов напрямую не поддерживается, что может быть проблемой для доступа к базе данных или доступа к другим системам в целом. Если вы используете фреймворки для ускорения разработки, они могут быть непригодны для использования в Lambda.

Ограничения, отмеченные Mark B, теперь исчезли. В настоящее время Lambdas может работать в VPC. Несмотря на то, что я не знаю официального способа ограничить количество параллельных экземпляров, если вы используете VPC, вы можете ограничить подсеть доступных IP-адресов, и для каждой Lambda потребуется IP-адрес, чтобы вы могли ограничить количество экземпляров Lambda косвенно.

Хорошие прецеденты

Если не слишком много внимания уделяется постоянной производительности, Lambda дешево и масштабируемо. Очень хорошо подходит обработка небольших партий.